Updated 2004/12/10

Sun[tm] Studio 10: C++ 5.7 Compiler Readme

Contents

  1. Introduction
  2. About the Sun Studio 10, C++ 5.7 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 10 C++ 5.7 compiler. Throughout this document, the compiler is also referred to as version 5.7 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 10 software is not installed in the default /opt directory, ask your system administrator for the equivalent path on your system.

 

B. About Sun Studio 10, C++ Compiler 5.7

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

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

The 5.7 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 both the Sun Studio 9 C++ 5.6 compiler and the Sun Studio 10 C++ 5.7 compiler.

Sun Studio 10 C++ 5.7 Compiler New Features

Sun Studio 10 C++ 5.7 Changed Features

Sun Studio 9 C++ 5.6 Compiler New Features

 

The New -xarch Default: v8plus

The default architecture for which the C++ compiler produces code is now v8plus (UltraSPARC). Support for v7 will be dropped in a future release.

The new default yields higher run-time performance for nearly all machines in current use. However, applications that are intended for deployment on pre-UltraSPARC computers no longer execute by default on those computers. Compile with -xarch=v8 to ensure that the applications execute on those computers.

If you want to deploy on v8 systems, you must specify the option -xarch=v8 explicitly on every compiler command line as well as any link-time commands. The provided system libraries run on v8 architectures.

If you want to deploy on v7 systems, you must specify the option -xarch=v7 explicitly on every compiler command line as well as any link-time commands. The provided system libraries use the v8 instruction set. For the Sun Studio 10 release, the only supported operating system for v7 is the Solaris 8 release. When a v8 instruction is encountered, the Solaris 8 operating system interprets the instruction in software. The program runs, but performance is degraded.

For the x86 platform, -xarch defaults to -xarch=generic. Note that -fast on the x86 platform expands to -xarch=native.

For more information on -xarch, see either the C++ man page CC(1) or the C++ User's Guide.

The New -xarch, -xtarget, and -xchip Flags on the x86 Platform

The C++ compiler supports new flags for -xarch, -xtarget, and -xchip. These new flags are designed to take advantage of Pentium 3 and Pentium 4 chips in combination with Solaris software support for SSE and SSE2 instructions on the x86 platform. The new options are as follows:

You can determine which combination of the -xchip, -xtarget, and -xarch options is appropriate for your needs by following these guidelines:

For more information on -xarch, -xtarget, and -xchip see either the C++ man page CC(1) or the C++ User's Guide.

The New -O Expansion

(SPARC and x86 ) The -O macro now expands to -xO3 instead of -xO2.

The change in default yields higher run-time performance. However, -x03 may be inappropriate for programs that rely on all variables being automatically considered volatile. Typical programs that might have this assumption are device drivers and older multi-threaded applications that implement their own synchronization primitives. The work around is to compile with -xO2 instead of -O.

For more information on -O, see either the C++ man page CC(1) or the C++ User's Guide.

The New -xprefetch Default

(SPARC) The default of -xprefetch is now -xprefetch=auto,explicit. This change adversely affects applications that have essentially non-linear memory access patterns. To disable the change, specify -xprefetch=no%auto,no%explicit.

For more information on -xprefetch, see either the C++ man page CC(1) or the C++ User's Guide.

The New -xmemalign Default

(SPARC) The default of -xmemalign is -xmemalign=8i for all v8 architectures. The default for all v9 architectures is -xmemalign=8s .

For more information on -xmemalign, see either the C++ man page CC(1) or the C++ User's Guide.

The New -xcode Default

(SPARC) The default on V9 is -xcode=abs44. The default on V8 is still -xcode=abs32. There is no support for -xcode on the x86 platform.

Note --For v9, you cannot use the default -xcode=abs44 in code intended for a shared library. Such a build of a shared library fails with relocation errors. You must either compile with -xcode=abs64 or with options to generate position-independent code, such as -xcode=pic13 or -xcode=pic32.

For more information on -xcode, see either the C++ man page CC(1) or the C++ User's Guide.

The New -xchip and -xtarget Flags

(SPARC) The -xchip and -xtarget options now support ultra3i and ultra4 as values so you can build applications that are optimized for the UltraSPARC IIIi and UltraSPARC IV processors.

Extern INLINE Functions

The C++ standard says that inline functions have external linkage, like non-inline functions, unless declared static. C++ 5.7 gives inline functions external linkage by default. If an inline function must be generated out of line (for example, if its address is needed), only one copy is linked into the final program. Previously, each object file that needed a copy had its own copy with local linkage.

This implementation of extern inline functions is compatible with binary files created by earlier compiler versions, in the sense that program behavior is no less standard-conforming than before. The old binaries might have multiple local copies of inline functions, but new code will have at most one copy of an extern inline function.

This implementation of extern inline functions is compatible with the C99 version of inline functions using the C 5.7 compiler that is included in this release. That is, following the C and C++ rules for extern inline functions, the same inline function can be defined in both C and C++ files, and only one copy of the external function will appear in the final program.

There is one incompatibility between the compilers in that the C language permits a non-inline function to support (provide the external definition for) an inline function. The C++ language has no such concept. Mixing the two approaches to inlining will result in a linker error. Consider this example: 

//File a.h
#ifdef __cplusplus
extern "C" {
#endif
inline int f() { return 1; }
#ifdef __cplusplus
}
#endif

//File b.c
#include "a.h"
int g() { return f(); }

In file b.c, the inline function f is supported by a function that has no indication that it is supporting an inline function.

//File c.c
int f() { return 1; }

If you mix c.c with a C++ use of f as shown below, you will get a "multiple definition" error from the linker. 

//File d.cc
#include "a.h"
int h() { return f(); }

The solution is to inform the C compiler that the function f supports an inline function. Use the following implementation of c.c instead. 

//File c.c
#include "a.h"
extern inline int f();
Loop Optimizations with -xautopar, -xvector, -xdepend

The C++ compiler now supports the following options for optimization of loops whose computations can be parallelized. These options must be used with an optimization level of -xO3 or higher.

Refer to the description of -xautopar, -xvector, and -xdepend, in the C++ man page CC(1) for details.

Restricted Pointers Through -xrestrict

C++ does not support the restrict keyword introduced in C99. But the C++ compiler now accepts the C compiler option -xrestrict.

This option makes claims about functions in the compilation to the effect that function parameters of pointer type do not refer to the same or overlapping objects. This option is somewhat more dangerous for C++ than for C, because the claim may not be true for inline functions that are defined in header files.

Refer to the description of -xrestrict in the C++ man page CC(1) for details.

Control of Optimization Levels Through #pragma opt and -xmaxopt

You can combine the #pragma opt directive with the command line option -xmaxopt to specify the level of optimization the compiler applies to individual functions.

The combination is useful when you need to reduce the optimization level for specific functions, for example to avoid a code enhancement like elimination of stack frames, or to increase optimization level for specific functions.

Refer to the description of -xmaxopt in the C++ man page CC (1) for details.

Improved Run-Time Performance Through a New -xprefetch_auto_type Option.

Use the new -xprefetch_auto_type option to generate indirect prefetches for the loops indicated by the option -xprefetch_level=[1|2|3] in the same fashion that the prefetches for direct memory accesses are generated.

Options such as -xalias_level can improve the optimization benefits of -xprefetch_auto_type. They affect the aggressiveness of computing the indirect prefetch candidates and therefore the aggressiveness of the automatic indirect prefetch insertion because they help produce better memory alias disambiguation information.

For more information on the -xprefetch_auto_type option, see either the CC(1) man page or the C++ User's Guide.

Improved Run-Time Performance Through a New -sync_stdio Option.

One of the causes of poor run-time performance could be the synchronization of C++ iostreams and C stdio. Such synchronization is required by the C++ standard and the compiler enables such synchronization by default. However, you can disable the synchronization by specifying -sync_stdio=no.

For more information on the -sync_stdio option see the C++ Users's Guide or the CC(1) man page. See also the C++ FAQ for a discussion of solutions to this problem.

Enhanced UTF-16 Support Through -xustr

Version 5.5 of the C++ compiler introduced support for UTF-16 string literals. This release expands support for UTF-16 character literals that use the syntax U'x' which is analogous to the U"x" syntax for strings. The same -xustr option is required to enable recognition of UTF-16 character literals.

This release also supports numeric escapes in UTF-16 character and string literals, which are analogous to numeric escapes in ordinary character literals and strings. For example: 

    U"ab\123ef" // octal representation of character
    U'\x456'    // hexadecimal representation of character

Refer to the description of -xustr in the C++ man page CC(1) for details.

Automatically Generated Precompiled Header Files with -xpch

This release of the C++ compiler expands the precompiled header facility to include an automatic capability on the part of the compiler to generate the precompiled header file. You still have the option to manually generate the precompiled header file, but if you are interested in the new capability of the compiler, see the explanation for the -xpch option in the CC(1) man page for more information. See also the CCadmin(1) man page.

 

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/prodtech/cc/support_index.html.

  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. 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 10 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. 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. The compiler currently 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 10 release, see the Sun Studio 10 Release Notes. The release notes are on the Sun Studio 10 web site at http://developers.sun.com/tools/cc/documentation/ss10_docs/release_notes.html. Information in the release notes updates and extends information in all readme files.

  1. x86 only: Compiling and Linking in Separate Steps With-xipo and -xO

    If you are specifying -xipo and also specifying optimization at -xO4 or -xO5, make sure you specify the same level of optimization at both compile time and link time. For example, you can specify the following command 

    CC foo.cc -xipo -xO4 -c
    to produce the foo.o object file. Later, when you link in a separate step, make sure the level of optimiztion is the same: 
    CC foo.o -xipo -xO4

  2. 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
            {
              :
            }
          }

  3. SPARC only: INTERVAL reduction variables

    Currently, reduction clauses with INTERVAL type variables are not supported. If such a reduction clause is found, an error message is generated.

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

  5. C++ Shared Library Patch

    A SUNWlibC patch is provided for each version of the Solaris Operating Environment supported by this Sun Studio 10 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 10 release, see the Sun Studio 10 web site at http://developers.sun.com/prodtech/cc/support_index.html.

  6. 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 WorkShop C++ (5.0) compiler
    • Forte Developer 6 C++ (5.1) compiler
    • Forte Developer 6 update 1 C++ (5.2) compiler
    • Forte Developer 6 update 2 C++ (5.3) compiler
    • Forte Developer 7 C++ (5.4) compiler
    • Sun Open Net Environment (Sun ONE) Studio 8 C++ (5.5) compiler
    • Sun Studio 9 C++ (5.6) compiler
    • Sun Studio 10 C++ (5.7) compiler

 

G. Documentation Errors 

There is no new information at this time.

H. Shippable Libraries

 

I. Standards Not Implemented 

 

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