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.
This section describes known issues, problems, and workarounds for the C++ compiler in this release.
The following headers are for concurrency features and are not supported in the Oracle Solaris Studio 12.4 release:
<atomic>
<future>
<thread>
<mutex>
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 Solaris 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. A fix for this library problem should be available in later Oracle Solaris updates. For more information, see Understanding the Effects of the Changed Default C++ Template Compilation Model.
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 Solaris Studio 12.4 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 following conditions might cause linking problems and only apply when using the default –compat=5 mode.
A function is declared in one place as having a const parameter and in another place as having a non-const parameter.
Example:
void foo1(const int);
void foo1(int);
These declarations are equivalent, but the compiler mangles the names differently. To prevent this problem, do not declare value parameters as const. For example, use void foo1(int) ; everywhere, including the body of the function definition.
A function has two parameters with the same composite type, and just one of the parameters is declared using a typedef.
Example:
class T;
typedef T x;
// foo2 has composite (that is, pointer or array)
// parameter types
void foo2(T*, T*);
void foo2(T*, x*);
void foo2(x*, T*);
void foo2(x*, x*);
All declarations of foo2 are equivalent and should mangle the same. However, the compiler mangles some of them differently. To prevent this problem, use typedefs consistently.
If you cannot use typedefs consistently, a workaround is to use a weak symbol in the file that defines the function to equate a declaration with its definition. For example:
#pragma weak "__1_undefined_name" = "__1_defined_name"
Note that some mangled names are dependent on the target architecture. (For example, size_t is unsigned long for the SPARC V9 architecture (–m64 ), and unsigned int otherwise.) In such a case, two versions of the mangled name are involved, one for each model. Two pragmas must be provided, controlled by appropriate #if directives.
This section does not apply when compiling with –compat=g or –std=c++11.
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.
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;
}
The following issue should be noted in this release of the cc compiler.
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.
The following issues should be noted in this release of the f95 compiler:
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.
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 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.