Updated 2005/11/02

Sun[tm] Studio 11: C++ 5.8 Compiler Readme

Contents

  1. Introduction
  2. About the Sun Studio 11, C++ 5.8 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 11 C++ 5.8 compiler. Throughout this document, the compiler is also referred to as version 5.8 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

To view the text version of this readme, type the following at a command prompt:

        CC -xhelp=readme

To view the HTML version of this readme, go to the default installation directory:

   file:/opt/SUNWspro/docs/index.html

Note - If your Sun Studio 11 software is not installed in the default /opt directory, ask your system administrator for the equivalent path on your system.

 

B. About Sun Studio 11, C++ Compiler 5.8

This release of the C++ compiler is available on Solaris[tm] Operating System: versions 8, 9, and 10.

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

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 11 C++ 5.8 compiler. For details on any of the compiler options, see the C++ User's Guide or the CC(1) man page.

For information about new features in other Sun Studio components, see the What's New manual. You can find all the manuals, man pages, and readme files in the Sun Studio 11 collection on the SDN Sun Studio portal at http://developers.sun.com/sunstudio/documentation/ss11/index.html.

 

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. __ctype Not Defined Errors Fixed in the Solaris 8 update 2 and PatchSoftware.
  4. Support for -instance=static and -instance=semiexplicit With Static Variables Within Templates
  5. Different Behavior for Function-Local Static Variables for Extern Inline Functions
  6. 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. __ctype Not Defined Errors Fixed in Solaris 8 update 2 and Patch Software

    The Solaris 8 operating system had a bug that could cause "__ctype not defined" errors from the C++ compiler when you use MB_CUR_MAX from <stdlib.h>.

    This bug has been fixed in the Solaris 8 update 2 operating system. The fix is available in Solaris patches 109607-01 (SPARC) and 109608-01 (x86) as well.

    If the update or the patches have not been installed, the workaround is to include the standard header <ctype.h> before including the header <stdlib.h>.

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

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

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

    • 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 -- Some mangled names are dependent on the target architecture. (For example, size_t is unsigned long for the SPARC V9 architecture, 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.

    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 11 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 is type conversion functions in classes, especially when you also have overloaded operators.

    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 11 release, see the Sun Studio 11 Release Notes. The release notes are on the Sun Studio 11 web site at http://developers.sun.com/sunstudio/documentation/ss11/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 11 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 11 release, see the Sun Studio 11 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 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 © 2005 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.