This section describes some of the known issues at the time of this Oracle Developer Studio 12.5 release, and provides information about how to work around these problems.
This section describes known issues, problems, and workarounds for the compilers in this release.
This section describes known issues that apply to the cc, CC, and f95 compilers.
OpenMP processor binding does not respect processor reservations using the taskset command on Linux.
Using flag –xarch=amdsse4a or –msse4a in the compilation line to generate an executable program, then when running this program, it causes a segmentation fault on a processor which does not support ISA sse4a, for example, an Intel processor.
–xtarget=S7 and –xchip=S7 options are supported in the compiler driver but not documented in the compiler man pages.
Oracle Developer Studio 12.5 compilers will not execute on UltraSPARC T1 systems, including SPARC T1000 and SPARC T2000 systems. You will receive the following error if you try:
ld.so.1: cc: fatal: cc: hardware capability (CA_SUNW_HW_1) unsupported: 0x20
This section describes known issues, problems, and workarounds for the C++ compiler in this release.
Not all of BOOST libraries compile successfully. The results you get might depend on the version of BOOST you use, and how you exercise the libraries. BOOST libraries are included in Oracle Developer Studio compiler testing and progress is being made toward compiling all of BOOST. If you run into a problem that prevents you from making progress, please report it.
The Apache stdcxx library installed in Oracle Solaris 10 8/11 and later, and in the initial releases of Oracle Solaris 11, 11.1, and 11.2, does not work correctly with the new compiler default of –template=no%extdef. You will probably need to add the option –template=extdef to CC command lines that use this library. The problem is fixed in Oracle Solaris 11.3 SRU2. No fix for Oracle Solaris 10 is currently available. For more information, see Understanding the Effects of the Changed Default C++ Template Compilation Model (http://www.oracle.com/technetwork/articles/servers-storage-dev/changed-default-cpp-template-model-2292727.html).
The Apache stdcxx library installed in Oracle Solaris 10 8/11 has a syntax error in header stdcxx4/loc/_moneypunct.h. This error was not seen by earlier compilers, but is caught by the Oracle Developer Studio 12.5 C++ compiler. There is no way to disable the error detection.
Some C++ statements could potentially be interpreted as a declaration or as an expression-statement. The C++ disambiguation rule is that if a statement can be a declaration, it is a declaration.
In Oracle Solaris Studio 12.2 and earlier, the compiler misinterpreted cases like the following:
struct S {
S();
};
struct T {
T( const S& );
};
T v( S() ); // ???
The programmer probably intended the last line to define a variable v initialized with a temporary of type S. Previous versions of the compiler interpreted the statement that way.
But the construct "S() " in a declaration context can also be an abstract declarator (that is, one without an identifier) meaning "function with no parameters returning of value of type S." In that case, it is automatically converted to the function pointer "S(*)() ". The statement is thus also valid as a declaration of a function v having a parameter of function-pointer type, returning a value of type T.
The compiler now makes the correct interpretation, which might not be what the programmer intended.
There are two ways to modify the code to make it unambiguous:
T v1( (S()) ); // v1 is an initialized object
T v2( S(*)() ); // v2 is a function
The extra pair of parentheses in the first line is not valid syntax for v1 as a function declaration, so the only possible meaning is "an object of type T initialized with a temporary value of type S."
Similarly, the construct "S(*)() " cannot possibly be a value, so the only possible meaning is as a function declaration.
The first line can also be written as:
T v1 = S();
Although the meaning is completely clear, this form of initialization can sometimes result in extra temporaries being created, although it usually does not.
Writing code like the following is not recommended because the meaning is not clear, and different compilers might give different results.
T v( S() ); // not recommended
The name mangling performed by Oracle Developer Studio in –compat=5 mode has errors. Fixing the errors would have created binary incompatibilities. The errors were found and corrected prior to Oracle Studio releases on x86/Oracle Solaris with –m64 and on Linux, but remain on the other platforms. A new option, –abiopt=mangle6 corrects the mangling errors on sparc/Oracle Solaris and x86 Oracle Solaris with the –m32 option.
Refer to –abiopt=[mangle5|mangle6] in Oracle Developer Studio 12.5: C++ User’s Guide.
A program using templates and static objects causes link-time errors of undefined symbols if you compile with –instances=extern. This is not a problem with the default setting –instances=global. The compiler does not support references to non-global namespace-scope objects from templates. Consider the following example:
static int k;
template<class T> class C {
T foo(T t) { ... k ... }
};
In this example, a member of a template class references a static namespace-scope variable. Keep in mind that namespace scope includes file scope. The compiler does not support a member of a template class referencing a static namespace-scope variable. In addition, if the template is instantiated from different compilation units, each instance refers to a different k, which means that the C++ One-Definition Rule is violated and the code has undefined behavior.
Depending on how you want to use k and the effect it should have, the following alternatives are possible. The second option only is available for function templates that are class members.
You can give the variable external linkage:
int k; // not static
All instances use the same copy of k.
You can make the variable a static member of the class:
template<class T> class C {
static int k;
T foo(T t) { ... k ... }
};
Static class members have external linkage. Each instance of C<T>::foo uses a different k. An instance of C<T>::k can be shared by other functions. This option is probably what you want.
When you use #pragma align inside a namespace, you must use mangled names. For example, in the following code, the #pragma align statement has no effect. To correct the problem, replace a, b, and c in the #pragma align statement with their mangled names.
When compiling as C++11, you can use the standard keyword alignas to avoid problems with pragmas.
namespace foo {
#pragma align 8 (a, b, c) // has no effect
//use mangled names: #pragma align 8 (__1cDfooBa_, __1cDfooBb_, __1cDfooBc_)
static char a;
static char b;
static char c;
}
This section describes known issues and problems for the C compiler in this release.
The implementation of standard C macro FLT_ROUNDS that is supplied with the C compiler for SPARC Linux behaves as the C standard specifies and returns the appropriate value for the current rounding mode. It does not always return the value 1 as specified in the man page in SPARC Linux that describes the functions defined in the standard C header file fenv.h.
Specifying the flag –xustr=ascii_utf16_ushort results in an error if –std=c11 (the compiler default) is in effect.
To avoid the error, you must specify an option that changes the C language dialect accepted by the compiler to an earlier version of C. The recommended options to use are –std=c99 or –std=c89.
The –xustr=ascii_utf16_ushort option will also be accepted if you use any of the following options that change the C language dialect: –ansi, –Xc, –Xa, –Xt, or –Xs.
This section describes known issues and problems for the Fortran compiler in this release.
Blank space before the end of a no advance print line does not affect output position.
Having the X edit descriptor at the end of a format of an output statement does not affect the position of the next character in the output record. This causes a difference if the output statement has ADVANCE='NO' and there are more characters to be transferred to the same record by subsequent output statements.
In many cases, this can be worked around by having a blank character string edit descriptor instead of the n X edit descriptor. They are not exactly the same since the blank character string edit descriptor actually causes blank characters to go into the record whereas the n X only skips over the next n characters, usually causing blanks to be in those skipped positions by default.
Valid code rejected when a line consists of two continuation ampersands.
An empty continuation line with a single ampersand is forbidden by the Fortran standard. However, with two ampersands on the same line, an empty continuation line can still be created without falling under the standard restriction. The compiler does not handle that case and gives an error. The workaround is to delete that line which only affects the readability of the program without adding any semantics. BOZ constants sometimes get truncated.
In some relatively more complex scenarios, such as an array construct, a BOZ constant might get truncated to the default integer size of 4 bytes even though the corresponding item it is supposed to be assigned to is an 8-byte integer entity. The workaround is to use constants of correct type and kind in array construct instead of BOZ constants.
Correction of rounding algorithm in the new release might cause differences in outputs of list-directed, name-list directed, and formatted-writes sing the ROUND='NEAREST' and ROUCH='COMPATIBLE' compared to outputs in previous releases. The rounding difference should only be in the least-significant digit.
Padding values that are generated using the –pad=common compiler option might be different in code that is compiled with Oracle Developer Studio 12.5 compared to prior releases. If you use –pad=common to compile two or more files that reference the same common block, you must compile them with the f95 compiler from the same Oracle Developer Studio release.
This is a reminder that the Oracle Solaris Studio 12.2 release removed the obsolete FORTRAN 77 libraries. This means that old executables compiled with the legacy Sun WorkShop f77 compiler that depend on the shared libraries libF77, libM77 and libFposix will not run.
The array intrinsic functions OT_PRODUCT and MATMUL are highly tuned for the appropriate SPARC platform architectures. As a result, they use the global registers%g2, %g3, and %g4 as scratch registers.
For interval arithmetic, the array intrinsics ANY, ALL, COUNT, MAXVAL, MINVAL, SUM, PRODUCT are also affected.
User code should not assume these registers are available for temporary storage if calls are made to the array intrinsics listed above. Data in these registers will be overwritten when the array intrinsics are called.
The debugger dbx requires all object files used in the compilation to be included in the executable file. Usually, programs satisfy this requirement with no extra work on the part of the user. An exceptional case arises from the use of archives containing modules. If a program uses a module, but does not reference any of the procedures or variables in the module, the resulting object file will not contain references to the symbols defined in the module. The linker only links with a object file from an archive if there is a reference to a symbol defined in the object file. If there is no such reference, the object file will not be included in the executable file. dbx will give a warning when it tries to find the debugging information associated with the module that was used. It will not be able to provide information about the symbols whose debugging information is missing.
Use the –u linker option to work around this problem. This option takes a symbol as its option argument. It adds that symbol to the set of undefined linker symbols, so it will have to be resolved. The linker symbol associated with a module is normally the module name with all letters in lower case followed by an underscore.
For example, to force the object file containing the module MODULE_1 to be taken from an archive, specify the linker option –u module_1_. If linking using the f95 command, use –Qoption ld –umodule_1_ on the command line.
There is no reliable way to accurately obtain the clock rate on AMD processors when system power saving is enabled. As a result, using timing functions based on gethrtime (3F) (the Fortran compiler's Linux version of the Oracle Solaris gethrtime (3C) function) to get high resolution real time on Linux platforms will only be accurate on AMD systems with power saving disabled. A reboot of the system might be required to disable the power-saving features.
This section lists known limitations of the debugging tools and performance analysis tools.
dbx has the following limitations:
Using older copies of libC.so.5 or libC.so.4 might cause problems for dbx in the area of C++ exceptions. Warning messages about bad stabs and unhandled exceptions might result.
Workaround: Install the latest libC.so.5 on all systems.
Fortran users should compile with the –stackvar option to take full advantage of runtime checking.
Some programs might not work properly with the –stackvar option. In such cases, try the –C compiler option, which enables array subscript checking without RTC.
The dbx command line interpreter is an older version of the Korn shell (ksh) that does not support Code Set Independence (CSI). Multi-byte characters can be misinterpreted when typed on the dbx command line.
The following features of dbx are not available on the Linux OS:
Fix and continue
Performance data collection on multithreaded applications.
Pretty-print
Breakpoints on the following events:
fault
lastrites
lwp_exit
sysin
sysout
sync
Index DWARF (compiler option –xs=no)
The following problems might occur when debugging programs on Linux platforms:
TLS access is not supported.
To debug 32-bit programs, you must start dbx with the –x exec32 option.
The pipe operator in the Korn shell is limited on Linux platforms. Any dbx command that needs to access the target process does not work as part of a pipeline. For example, the following command is likely to cause dbx to hang:
where | head -1
Workarounds:
Type Ctrl-C to display a new dbx prompt.
dbx caches a lot of information, so for the above example, the following sequence of commands works:
where where | head —1
Redirect command output to a file and then display the file contents.
(dbx) > bag where (dbx) cat bag
dbx does not support the following features for the GNU C and C++ compilers:
VL array (gcc 4.1 and before)
OpenMP
RTTI
Template definition
Default argument
using directive
friend
The following issues exist for dbx on Oracle Linux 6:
Indirect reference symbols used in system libraries can sometimes cause dbx to set breakpoints at the reference rather than the actual function.
When debugging code compiled with gcc 4.4.4 compilers, be aware that dbx does not see macros defined using the –D compiler option.
The stabs format for debugging information is supported in Oracle Developer Studio, but Oracle has announced that the format might eventually be discontinued in favor of DWARF format. Oracle is not required to implement stabs support for new features or for enhancements to existing features.
The following debugging features are not supported by the stabs format.
New C++11 and new C++14 features.
New C11 features
Parameters and local variables in optimized code.
Macros (when code is compiled with the –g3 option).
Subsets of debugging info (generally when compiled with –xdebuginfo={...}).
Object Oriented Fortran
See dbx attach Profiling (collect -P) for information about data collection problems when dbx is attached to a process.
Debugging support for exception handling is limited if GNU runtime libraries are used.
This section describes known problems with the Performance Analyzer tool and er_print utility.
Performance Analyzer crashes with Java 7U65. Use at least Java 7U75 when using the Performance Analyzer tool.
The Library Visibility functionality for shared objects does not always work properly in conjunction with filtering.
Performance Analyzer and er_print cannot find shared objects embedded in jar files. In addition, under some circumstances Performance Analyzer and er_print cannot find Java class files or source files. To work around these issues, use addpath to point to the directories containing the files. See the Troubleshooting section of the Help in Performance Analyzer for more detailed information.
When you compare experiments you might see the following issue:
Source and Disassembly views show inclusive and exclusive metrics instead of only inclusive metrics as expected.
You might see the following issues related to CPUs with variable clock rate:
On a system with a variable clock rate, hardware counter profiling metrics for cycle-based counters are under-reported when the processor runs at less than maximum speed and the metrics are converted to times.
On systems with multiple CPUs running at different clock frequencies, experiments will be processed based on the clock rate for one CPU, which can lead to over-counting or under-counting on other CPUs.
Profiling OpenMP applications that use many threads on SPARC T5, M5, and M6 systems might produce very large experiments that cannot be read. The workaround is to set the environment variable SP_COLLECTOR_NO_OMP before you run collect. Note that when you set this variable, you cannot see OpenMP constructs and metrics in the resulting experiment and the User, Expert, and Machine view modes all look the same.
Remote login with a pass phrase is not yet supported.
This section describes known problems with the collect utility and data collection for the Performance Analyzer tool.
Profiling of mixed Java and C++ applications might not be complete when using JDK 1.7.0_40 through JDK 1.7.0_59 due to a bug in the JDK. The stack for calls from Java to C++ are not properly unwound.
Heap tracing on Linux does not trace calls to calloc.
Collection of count data (collect -c) does not work for binaries that were compiled with –std=c++11.
Clock profiling on SPARC T4/T5 M5/M6 might have irregular samples due to a bug in Oracle Solaris setitimer(ITIMER_REALPROF, ...)
Hardware counter profiling with attribute system=1 has the following known issues. Some system time might not be counted correctly for usleep(). On Oracle Solaris 10, using the system attribute can hang the application.
Clock profiling might incorrectly report User CPU Time as Wait CPU Time due to a bug in Oracle Solaris
You might see following problems with profiling signals in kernel zones:
Clock-profiling signals in kernel zones are erratically delivered, leading to missing data.
Hardware counter dtlb_misses.any doesn't work on Westmere kernel zones
Memoryspace profiling on x86 is not supported on kernel zones
On SPARC, hardware counter profiling samples might be delayed by many seconds; lost samples will result in undercounts
Clock-profiling samples in kernel zones might report the wrong microstate
HWC-profiling samples on a the control domain of a system which is running kernel zones might be lost.
HWC-profiling samples on a kernel zone might be lost.
Profiling SPECJBB2015 on Linux can cause a crash or hang.
Various cornercases of stack unwind might fail on x86, both Oracle Solaris and Linux
This section describes known problems with the er_kernel utility.
er_kernel refuses to run on an Oracle Solaris system that is running under Oracle VM to avoid an Oracle VM bug that causes a reboot
Callstacks might sometimes omits a frame, typically when the leaf function is within its epilogue
Hardware counter profiling samples on the control domain of a system which is running kernel zones might be lost.
Hardware counter profiling samples on a kernel zone might be lost.
Hardware counter profiling with er_kernel in a kernel zone might only support a single hardware counter
This section describes problems with profiling an application when using the dbx collector command.
There is a limitation in using the dbx collector on Java. You cannot specify a Java class file for the target. Instead, you must specify the JVM as the target and specify the class file as a parameter to the dbx run command. For example:
> dbx /path-to-your-jdk/bin/java (dbx) collector enable (dbx) collector java on (dbx) run [JVM-options] [Java-class-file-to-execute]
On Linux, profiling of any Java applications with dbx or collect -P might fail.
This section describes problems with profiling a running application when using the dbx attach command:
If you attach dbx to a running process that was started without LD_PRELOAD to preload the collector library libcollector.so a number of errors can occur. You cannot collect any tracing data: synchronization wait tracing, heap tracing, I/O tracing, or MPI tracing. Tracing data is collected by interposing on various libraries, and if libcollector.so is not preloaded, the interposition cannot be done.
If the target program installs a signal handler after dbx is attached to the process, and the signal handler does not pass on the SIGPROF and SIGEMT signals in Oracle Solaris or the SIGIO signal in Linux, some or all profiling data might be lost.
If the target program uses libcpc.so hardware-counter experiments might fail because both the collector and the program are using the library.
If the target program calls setitimer (2), clock profiling experiments can be corrupted because both the collector and the program are using the timer.
Attaching to a target that is in the middle of a call into the malloc library might cause the target to fail. Requesting hardware counters when attaching greatly increases the probability of such failures.
On Linux, attaching to a Java program with dbx or collect -P might fail.
On Linux, attaching to a target that is in the middle of a blocking or non-blocking call might cause the target to fail.
On Linux, attaching to a multithreaded target will not properly record data for threads that are already created at the time of the attach. No warning about missing data is provided. Note that this includes any Java targets because the JVM is multithreaded.
This section describes known limitations in the IDE.
To create a project from binary on a remote host, the remote host must have Oracle Solaris Studio 12.3 or 12.4 or Oracle Developer Studio 12.5 available. This feature is not supported on earlier releases.
This section describes known limitations to the code analysis tools.
False positives or negatives might be found if you do not properly instrument your code. For more information, see Supported Binaries in Oracle Developer Studio 12.5: Discover and Uncover User’s Guide.
The discover and uncover tools do not work with an x86_64 binary compiled with –xmodel=medium when the program size (text + data) is large enough to extend beyond the maximum range of –xmodel=small (232 - 224 - 1).
The discover tool doesn't work on an ancillary file, which is a file containing debug information created with the linker option –z ancillary in Oracle Solaris 11.3.
To use any of the Code Analysis tools on Oracle Linux, the original binary must be compiled and linked with the –xannotate=[yes] option.
To use Discover SSM in a kernel zone of an SSM capable machine, the configuration of the zone should include host-compatibile=native
This section describes known issues, problems, and workarounds for the Java Installer.
The command line, non-interactive mode ./developerstudio.sh --non-interactive will not install the OIC component.
To avoid this, the command line, non-interactive mode for installation must specify OIC together with all the Compiler and Tools components after the –-install-components option as follows:
./developerstudio.sh --non-interactive --install-components oic, dbxtool, code-analyzer-tool, performance-and-thread-analysis-tools, performance-library, c-and-cpp-compilers, dmake
In addition, if a Japanese or Chinese locale is required, add the components (comma-separated) japanese-localization and simplified-chinese-localization to the --install-components line.