JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
What's New in the Oracle Solaris Studio 12.3 Release     Oracle Solaris Studio 12.3 Information Library
search filter icon
search icon

Document Information

Preface

1.  Introducing the Oracle Solaris Studio 12.3 Release

2.  Compilers

3.  Libraries

4.  Code Analysis Tools

5.  Performance Analysis Tools

6.  Debugging Tools

7.  The Oracle Solaris Studio IDE

8.  Other Tools

9.  Known Problems, Limitations, and Workarounds in This Release

Compilers

Issues Common To The Compilers

Documentation Errata

C++

Apache Standard Library Issue on Solaris

Ambiguity: Constructor Call or Pointer-to-Function

Linking Fails If You Combine -xipo or -xcrossfile With -instances=static

Name Mangling Linking Problems

No Support For Referencing a Non-Global Namespace Object From a Template

#pragma align Inside Namespace Requires Mangled Names

Fortran

Fortran 77 Libraries Removed

Array Intrinsic Functions Use Global Registers:

F95 Modules in Archive Libraries Not Included In Executable:

gethrtime(3F) on Linux Platforms

Tools

dbx

Known dbx issues and Workarounds

dbx Limitations and Incompatibilities

Performance Analyzer

collect Utility

Thread Analyzer

er_kernel Utility

IDE

dmake

dmake Limitations

Installation

Index

Compilers

This section describes known issues, problems, and workarounds for the compilers in this release.

Issues Common To The Compilers

Documentation Errata

Errors in the published compiler documentation are listed below.

C++

Apache Standard Library Issue on Solaris

The Apache stdcxx library installed in Solaris 10u10 and earlier and in the initial release of Solaris 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.3 C++ compiler. There is no way to disable the error detection.

A fix for this bug is available in a patch for Solaris 10, and in the first Solaris 11 SRU. The fix will be included in Solaris 10u11 and Solaris 11u1 when they become available.

Ambiguity: Constructor Call or Pointer-to-Function

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.

Earlier versions of 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

Linking Fails If You Combine -xipo or -xcrossfile With -instances=static

The template option -instances=static (or -pto) does not work in combination with either of the -xcrossfile or -xipo options. Programs using the combination will often fail to link.

If you use the -xcrossfile or -xipo options, use the default template compilation model, -instances=global instead.

In general, do not use -instances=static (or -pto) at all. It no longer has any advantages, and still has the disadvantages documented in the C++ Users Guide.

Name Mangling Linking Problems

The following conditions may cause linking problems.

No Support For Referencing a Non-Global Namespace Object From a Template

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 namesapce-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.

  1. You can give the variable external linkage:

                  int k; // not static 

    All instances use the same copy of k.

  2. 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.

#pragma align Inside Namespace Requires Mangled Names

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;
        }

Fortran

The following issues should be noted in this release of the f95 compiler:

Previous releases of the Fortran compiler introduced incompatibilities that carry forward to this release of the compiler and should be noted if you are updating from earlier Fortran compiler releases. The following incompatibilies are worth noting:

Fortran 77 Libraries Removed

Here 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.

Array Intrinsic Functions Use Global Registers:

The array intrinsic functions ANY, ALL, COUNT, MAXVAL, MINVAL, SUM, PRODUCT, DOT_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.

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.

F95 Modules in Archive Libraries Not Included In Executable:

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.

gethrtime(3F) on Linux Platforms

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.