Updated 2007/05/31

Sun[tm] Studio 12: C++ 5.9 Compiler Readme

Contents

  1. Introduction
  2. About the Sun Studio 12, C++ 5.9 Compiler
  3. New and Changed Features
  4. Software Corrections
  5. Problems and Workarounds
  6. Limitations and Incompatibilities
  7. Documentation Errors
  8. Shippable Libraries
  9. Standards Not Implemented

 

A. Introduction

This document contains information about the Sun Studio 12 C++ 5.9 compiler. Throughout this document, the compiler is also referred to as version 5.9 of the C++ compiler. This document describes the new features that are included with this release, software corrections that are addressed by this release, and lists known problems, limitations, and incompatibilities. Information in this document updates and extends information in the software manuals.

Product Documentation

 

B. About Sun Studio 12, C++ Compiler 5.9

This 5.9 version of the C++ compiler is upwardly source-compatible and binary-compatible with C++ compiler versions 5.0 through 5.8. That is, you can compile source code written for versions 5.0 through 5.8 of the C++ compiler using this C++ compiler. In addition, you can link object code that was generated by C++ compiler versions 5.0 through 5.8 with object code that is generated by this C++ compiler. You should always link with the latest compiler which, for this release, is version 5.9.

The C++ compiler also offers the -compat option for compiling source code that was written for the 4.2 C++ compiler. The -compat option was introduced in version 5.0.

 

C. New and Changed Features

This section describes the new and changed features for the Sun Studio 12 C++ 5.9 compiler. For details on any of the compiler options, see the C++ User's Guide or the CC(1) man page.

For additional information regarding new features in other Sun Studio 12 components, see the SDN Sun Studio portal at http://developers.sun.com/sunstudio/documentation/index.jsp.

A New Way To Specify 32-bit or 64-bit Address Model

You no longer need use the -xarch option to specify a 32-bit or 64-bit address model (LP64 versus ILP32). Two new options make it easier:

Deprecated -xarch Flags and Their Replacements Across SPARC and x86
If you are using -xarch=v9 or -xarch=amd64 to specify a 64-bit address model, use just -m64 instead. No -xarch value is required.

Deprecated -xarch Flags and Their Replacements on SPARC Only

Deprecated -xarch Flags and Their Replacements on x86 Only

Disallowed Combinations and Warnings
The compilers do not allow the combination of a deprecated -xarch value and the new -m32, -m64 options on the command line. For example, specifying -xarch=v9 -m32 is now a fatal error. Specifying -xarch=sparc -xarch=v9 is also a fatal error.

Some older -xarch values do not have 64-bit counterparts. You cannot combine the following -xarch options with -m64 on the command line.

If you specify a 32-bit -xarch value followed by -m64, the compiler does not issue a warning. For example -m64 -fast or -fast -m64 are allowed. However, if you specify a 64-bit -xarch value followed by -m32, the compiler issues a warning that -m32 overrides the -xarch value. This situation does not occur using macro options, only when an -xarch option has been explicitly specified.

New C++ Compiler Features

In addition to the new options and features detailed in the rest of this readme, the following new C++ compiler options are supported in this release:

New x86 Features and Updates

The following are new x86 flags for the -xarch option:

Changes to -fast
The -fast option on x86 now includes -xregs=frameptr, which means that the compiler can use the frame-pointer register (%ebp on IA32, %rbp on AMD64) as a general purpose register to generate code for all the compilation units. Consequently frame pointers will not be generated in each function or routine.

However, if you want to override this new behavior, specify -xregs=no%frameptr after -fast in the compilation command and the frame-pointer register will not be used as a general purpose register. The following example demonstrates how to override the -fast default for -xregs:

      CC -fast -xregs=no%frameptr foo.cc

New SPARC Features and Updates

This release of the Sun Studio compilers includes support for the SPARC64 VI and UltraSPARC T2 processors. Use the following new options to specify these processors:

You can also specify the following -xchip options to generate code for these processors without setting the -xarch value automatically as happens when you use -xtarget:

New Math and Visual Instruction Set Support in SPARC64 VI

Specify the following new option if you want to use instructions from the SPARC-V9 instruction set including the UltraSPARC extensions, the Visual Instruction Set (VIS) version 1.0, the UltraSPARC-III extensions, the Visual Instruction Set (VIS) version 2.0, and the SPARC64 VI extensions for floating-point multiply-add:

You must also specify -m32 or -m64 when you specify -xarch=sparcfmaf to get 32-bit code or 64-bit code respectively. When you specify -xarch=sparcfmaf, the compiler predefines the following new values:

Note: You must use -xarch=sparcfmaf in conjunction with the new -fma=fused option detailed below and some optimization level in order for the compiler to find opportunities to use the multiply-add instructions automatically.

New Option for Floating-Point, Fused or Multiply-Add Instructions

Specify the following new option to enable or disable the automatic generation of floating-point, fused, multiply-add instructions:

The none value indicates that the compiler should not generate any floating-point, fused, or multiply-add instructions. The fused value allows the compiler to attempt to find opportunities to improve the performance of the code by using floating-point, fused, or multiply-add instructions.

Linux Support

See the release notes for processor and distribution version requirements.

The following features of Sun C++ are not available on Linux:

The New Thread Analyzer

The following new compiler option causes the compiler to instrument your multi-threaded application for analysis by the new Thread Analyzer. 

The default is -xinstrument=no%datarace. See tha(1) and the Thread Analyzer User's Guide. The user's guide includes two tutorials, a FAQ and lists of supported APIs.

 

D. Software Corrections

This section discusses the following software corrections.

  1. Correct Interpretation of Large Decimal Integer Constants
  2. Ambiguity: Constructor Call or Pointer-to-Function
  3. Support for -instance=static and -instance=semi-explicit With Static Variables Within Templates
  4. Different Behavior for Function-Local Static Variables for Extern Inline Functions
  5. Template Syntax Error is No Longer Ignored
  1. Correct Interpretation of Large Decimal Integer Constants

    The C++ standard says that a decimal integer constant without a suffix is treated as an int if the value fits in an int, otherwise as a long int. If the value does not fit in a long int, the results are undefined.

    In 32-bit mode, types int and long have the same size and data range. The C++ compiler followed the 1990 C standard rule, treating a value between INT_MAX+1 and LONG_MAX as unsigned long. This treatment produced unexpected results in some programs.

    The 1999 C standard changed the rule about unsuffixed decimal integers so that they are never treated as unsigned types. The type is the first of int, long, or long long that can represent the value.

    The C++ compiler follows the C99 rule when in standard mode, but continues to follow the C90 rule in -compat=4 mode. (In -compat=4 mode, the compiler behaves like the C++ 4.2 compiler.)

    If you want a large decimal integer to be treated as unsigned, the portable solution is to use a u or U suffix. You can use the other suffixes for other types as well. For example:

            // note: 2147483648 == (INT_MAX+1)
        2147483648     // (signed) long long
        2147483648LL   // (signed) long long
        2147483648U    // same as 2147483648u
  2. 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
  3. Support for -instance=static and -instance=semiexplicit With Static Variables Within Templates

    With prior versions of the C++ compiler, use of the static instances method and use of the semi-explicit instances method were not supported with static variables within templates. This restriction does not exist since version 5.2 of the C++ compiler.

  4. Different Behavior for Function-Local Static Variables for Extern Inline Functions

    Under the ARM rules, function-local static variables for extern inline functions are file static. Under the ISO standard, function-local static variables for extern inline functions are global variables that are shared among compilation units.

    Versions 5.0 and 5.1 of the C++ compiler implemented the ARM behavior for both compatibility mode (-compat) and standard mode (the default mode). All versions of the C++ compiler since version 5.2 of the C++ compiler implement the ARM behavior for compatibility mode and the ISO behavior for standard mode. For example,

    one.cc

    inline int inner() { 
      static int variable = 0; return variable++; 
    }
    int outer() { return inner(); }

two.cc

    inline int inner() { 
      static int variable = 0; return variable++; 
    }
    int main() { return inner() + outer(); }

    When compiled in compatibility mode (-compat), the two variables are different and the result of main is 0 (zero).

    When compiled in standard mode (the default mode), the two variables are the same and the result of main is 1 (one). To obtain the old behavior in standard mode, declare the inline function static.

  5. Template Syntax Error is No Longer Ignored

    The following template syntax has never been valid, but Sun C++ 4 and 5.0 did not report the error. All versions since 5.1 of the C++ compiler report this syntax error when you compile in standard mode (the default mode).

      template<class T> class MyClass<T> { ... }; // definition error
  template<class T> class MyClass<T>;         // declaration error

    In both cases, the "<T>" on "MyClass<T>" is invalid, and must be removed, as shown in the following example,

      template<class T> class MyClass { ... }; // definition
  template<class T> class MyClass;         // declaration

 

E. Problems and Workarounds

This section discusses known software problems and possible workarounds for those problems. For updates or patches check the updated information at http://developers.sun.com/sunstudio/support/.

  1. Linking Fails When -xipo or -xcrossfile Are Present with -instances=static
  2. Preprocessed .i File Generates Compiler Error
  3. Cross-Language Linking Error
  4. Name Mangling Linking Problems
  5. Debugging Tools Erroneously Report Extra Leading Parameter for Member Functions


  6. UPDATED ANSWER: No Support For Referencing a Non-Global Namespace Object From a Template


  7. #pragma align Inside Namespace Requires Mangled Names
  8. Function Overload Resolution
  9. Multithreaded C++ Programs Using Alternate Threads Hang When Debugged in Solaris 8 Operating System
  1. 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.

  2. Preprocessed .i File Generates Compiler Error

    __global became a new keyword in C++ 5.5 as part of the new xldscope compiler option. If you generate a preprocessed file, a .i file, by using an older compiler and then try to compile that .i file with version 5.5 or later, you can get error messages if the keyword __global is used as an identifier in the .i file.

    To workaround the problem, add #pragma disable_ldscope to the top of the .i file. If the code is intended for an older compiler, the new linker scoping keywords, such as __global, will not be used. You can add the line #pragma enable_ldscope to the end of the .i file if it is included in other files.

  3. Cross-Language Linking Error

    If you issue the -xlang=f77 command, the compilation process encounters a linker error. To avoid the error and still include the appropriate runtime libraries, issue -xlang=f77,f90 instead.

  4. Name Mangling Linking Problems

    The following conditions may cause linking problems.

    For more information, see the C++ Migration Guide. To access this guide in HTML, point your browser to file:/opt/SUNWspro/docs/index.html.

    Note - If your Sun Studio 12 compilers and tools are not installed in the default /opt directory, ask your system administrator for the equivalent path on your system.

  5. Debugging Tools Erroneously Report Extra Leading Parameter for Member Functions

    In compatibility mode (-compat), the C++ compiler incorrectly mangles the link names for pointers to member functions. The consequence of this error is that the demangler, and hence some debugging tools, like dbx and c++filt, report the member functions as having an extra leading parameter consisting of a reference to the class type of which the function is a member. To correct this problem, add the flag -Qoption ccfe -abiopt=pmfun1. Note, however, that sources compiled with this flag may be binary incompatible with sources compiled without the flag. In standard mode (the default mode), the problem does not occur. 

  6. UPDATED ANSWER
    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 specify -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.

    3. You can make the variable local to the function:

      template<class T> class C {
             T foo(T t) { static int k; ... k ... }
};

      Each instance of C<T>::foo uses its own copy of k, which is not visible outside the function.

  7. #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;
  }
  8. Function Overload Resolution

    Early releases of the C++ compiler did not perform function overload resolution in accordance with the requirements of the C++ standard. The current release fixes many bugs in resolving calls to overloaded functions. In particular, the compiler would sometimes pick a function when a call was actually ambiguous, or complain that a call was ambiguous when it actually was not.

    Some workarounds for ambiguity messages are no longer necessary. You may see new ambiguity errors that were not previously reported.

    One major cause of ambiguous function calls is overloading on only a subset of built-in types.

       
int f1(short);
int f1(float);
...
f1(1); // ambiguous, "1" is type int
f1(1.0); // ambiguous, "1.0" is type double

    To fix this problem, either do not overload f1 at all, or overload on each of the types that do not undergo promotion: int, unsigned int, long, unsigned long, and double. (And possibly also types long long, unsigned long long, and long double.)

    Another major cause of ambiguity is type conversion functions in classes, especially when you also have overloaded operators or constructors.

    class T {
public:
        operator int();
        T(int);
        T operator+(const T&);
};
T t;
1 + t // ambiguous

    The operation is ambiguous because it can be resolved as

    T(1) + t     // overloaded operator
1 + t.operator int()    // built-in int addition

    You can provide overloaded operators or type conversion functions, but providing both leads to ambiguities.

    In fact, type conversion functions by themselves often lead to ambiguities and conversions where you did not intend for them to occur. If you need to have the conversion available, prefer to use a named function instead of a type conversion function. For example, use int to_int(); instead of operator int();

    With this change, the operation 1 + t is not ambiguous. It can be interpreted only as T(1) + t. If you want the other interpretation, you must write
    1 + t.to_int().

  9. Multithreaded C++ Programs Using Alternate Threads Hang When Debugged in the Solaris 8 Operating System

    Multithreaded C++ programs built with the alternate threads library in /usr/lib/lwp/ hang when you attempt to debug them in the Solaris 8 operating system. 32-bit multithreaded C++ programs built with the -R /usr/lib/lwp compiler option hang when run within dbx. 64-bit multithreaded C++ programs built with the -R /usr/lib/lwp/sparcv9 compiler option are likely to hang, especially when runtime checking is used.

    This symptom occurs with C++ code compiled in standard (default) mode (with the -compat=5 compiler option); it does not occur with code compiled in compatibility mode (with the -compat compiler option).

    In cases where you are considering using the alternate threads library for performance tuning, debug the multithreaded program first with the default thread library, then use the alternate threads library.

    This problem only occurs in Solaris 8 software.

 

F. Limitations and Incompatibilities 

This section discusses limitations and incompatibilities with systems or other software. For last minute information for this Sun Studio 12 release, see the Sun Studio 12 Release Notes. The release notes are on the Sun Studio 12 web site at http://developers.sun.com/sunstudio/documentation/ss12/release_notes.html. Information in the release notes updates and extends information in all readme files.

  1. Static Class Objects Declared Within Parallel Region (bug ID 4806414)

    Currently the declaration of static class objects within an OpenMP region is not supported. If such a declaration is found, an error is generated. The following example code generates the error: 

              #pragma omp parallel
          {
            static A a;           // A is a class type
            :
          }

Error: Static non-POD decl not allowed in parallel region.
    The following code change generates the desired behavior: 
              {
            A a;
            #pragma omp parallel // shared is the default
            {
              :
            }
          }

  2. Incompatibility between -xia and -library=stlport4

    You cannot use C++ interval math with the STLport C++ library. A program using the -xia option can be compiled and linked only as documented in the C++ Interval Arithmetic Programming Reference.

  3. C++ Shared Library Patch

    A SUNWlibC patch is provided for each version of the Solaris Operating Environment supported by this Sun Studio 12 release on each of the supported platforms. The patch should be installed not only on the systems used for compiling, but on all systems where the resulting programs are run. Without these patches, some programs fail to link and some programs terminate in unusual ways due to runtime errors. For example, the linker may report a message similar to the following:

    Undefined symbol First referenced in file
    std::ostream &operator<<(std::ostream&,const RWCString&) test.o 
        ld: fatal: Symbol referencing errors. No output written to test

    You may also see an error message such as the following:

        Hint: try checking whether the first non-inlined, 
    non-pure virtual function of ...

    For information about required and optional patches for this Sun Studio 12 release, see the Sun Studio 12 web site at http://developers.sun.com/sunstudio/support/.

  4. Compiler Version Incompatibilities

    If you are using version 4.0, 4.1, or 4.2 of the C++ compiler and wish to migrate to one of the newer versions listed below, see chapter 6 of the C++ Migration Guide which discusses, in detail, the considerations and preparations you must peform to ease the migration.

    • Sun Studio 12 C++ (5.9) compiler
    • Sun Studio 11 C++ (5.8) compiler
    • Sun Studio 10 C++ (5.7) compiler
    • Sun Studio 9 C++ (5.6) compiler
    • Sun Open Net Environment (Sun ONE) Studio 8 C++ (5.5) compiler
    • Forte Developer 7 C++ (5.4) compiler
    • Forte Developer 6 update 2 C++ (5.3) compiler
    • Forte Developer 6 update 1 C++ (5.2) compiler
    • Forte Developer 6 C++ (5.1) compiler
    • Sun WorkShop C++ (5.0) compiler

 

G. Documentation Errors 

There is no new information at this time.

H. Shippable Libraries

 

I. Standards Not Implemented 

 

Copyright © 2007 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.