Print-friendly Version

This document allows you to compare the features added to the Sun C++ compiler for the following compiler and tools releases:

• Sun Studio 12 (SS12): C++ compiler version 5.9 released June 2007
  
• Sun Studio 11 (SS11): C++ compiler version 5.8 released November 2005
• Sun Studio 10 (SS10): C++ compiler version 5.7 released January 2005
• Sun Studio 9 (SS9): C++ compiler version 5.6 released July 2004
• Sun ONE Studio 8 (S1S8): C++ compiler version 5.5 released May 2003
• Forte Developer 6 update 2 (FD6u2): C++ compiler version 5.3 released July 2001
• Forte Developer 6 (FD6): C++ compiler version 5.1 released May 2000

Sun Studio 12 C++ New 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:

• -m32 specifies the ILP32 model: 32-bit ints, longs, and pointer types.
• -m64 specifies the LP64 model: 32-bit ints, 64-bit longs and pointers types. (Note that -m64 is the default on 64-bit Linux platforms.)

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.

• Use -m64 in place of -xarch=generic64
• Use -m64 -xarch=native in place of -xarch=native64

Deprecated -xarch Flags and Their Replacements on SPARC Only

• Use -xarch=sparc in place of -xarch=v8plus
• Use -xarch=sparcvis in place of -xarch=v8plusa
• Use -xarch=sparcvis2 in place of -xarch=v8plusb
• Use -xarch=sparc -m64 in place of -xarch=v9
• Use -xarch=sparcvis -m64 in place of -xarch=v9a
• Use -xarch=sparcvis2 -m64 in place of -xarch=v9b

Deprecated -xarch Flags and Their Replacements on x86 Only

• Use -xarch=sse2 -m64 in place of -xarch=amd64.
• Use -xarch=sse2a -m64 in place of -xarch=amd64a.

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.

• SPARC platforms: -xarch=v7, -xarch=v8, -xarch=v8a
• x86 platforms: -xarch=386, -xarch=pentium_pro, -xarch=pentium_proa, -xarch=sse, -xarch=ssea

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:

• Support for g++ extensions:
  • __typeof__
  • __attribute
  • __alignof__ now accepts expressions
  • long long bitfields, currently by default only on Linux

• Improved function inlining
  The C++ compiler will now generate some system functions inline at high optimization levels, avoiding calls into system libraries.

• Support for the following open-source libraries:

  • BOOST http://www.boost.org
    See http://blogs.sun.com/sga/category/Boost for the latest status of our compilers and BOOST libraries.
  • LOKI http://sourceforge.net/projects/loki-lib

• Standard-conforming lifetime of temporary variables by default
  The compiler no longer requires a command-line option to provide standard-conforming lifetime of temporary variables. This behavior is now the default.

• Complex expressions in template parameters
  The compiler was previously unable to handle expressions in non-type template arguments in certain cases. For example:

  template<class T, int I, int J>
  T func( T (&arr)[I*J] ) { ... } // I*J is a "complex template expression"

  The compiler can now handle such usage.
• Improved debugging
  

  This release of the C++ compiler provides enhanced debugging of OpenMP programs as well as enhanced debugging of optimized code.

• Debug format now defaults to DWARF
  The C++ compiler now emits debug information in the DWARF format by default. This makes it easier for third-party debuggers and tools to inter-operate with Sun compilers. The DWARF format also makes it easier for Sun Studio to add debugging support for optimized code.

New x86 Features and Updates

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

• -xarch=sse3 specifies that the compiler should generate instructions based on both the SSE3 and SSE2 architectures.
• -xarch=sse3a specifies that the compiler should generate instructions based on the SSE3, SSE2 and AMD extended architectures as well as the 3DNow extensions.

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:

• -xtarget=sparc64vi
• -xtarget=ultraT2

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:

• -xchip=sparc64vi
• -xchip=ultraT2

You can also specify the -xarch values explicitly:

• -xarch=[v8plusc|v9c] for the SPARC64 VI fused multiply-add instructions set architecture
• -xarch=[v8plusv|v9v] for privileged and hyper-privileged code

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:

• -xarch=sparcfmaf

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:

• -D__FP_FAST_FMA__
• -D__FP_FAST_FMAF__

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

• -fma={none,fused}

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

This release of the Sun Studio compilers supports the Linux OS as follows.

• SuSE Linux Enterprise Server 9 with Service Pack 3 (or later)
• Red Hat Enterprise Linux 4
• Other Linux distributions based on the 2.6 kernel though these are not officially supported

See the release notes for processor and distribution version requirements.

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

• -compat=4
• -xia (relates to interval arithmetic)
• -library=gc (relates to garbage collection library)

The New Thread Analyzer

• -xinstrument[=[no%]datarace]

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.

Sun Studio 11 C++ New 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.

• New -xarch Flags For x64 Development
  

  The -xarch option now supports the following new flags for development on the 64-bit x86 platform: amd64a, pentium_proa, ssea, sse2a. See the description of -xarch in the Sun Studio 11 CC(1) man page for more information.

• Support For x86 -xpagesize Options
  

  The -xpagesize, -xpagesize_heap, -xpagesize_stack options are now enabled for x86 platforms as well as SPARC.

• A New -xmodel Option To Specify x64 Memory Models
  

  The new -xmodel option lets you specify the kernel, small, or medium memory models on the 64-bit AMD architecture. If the size of your global and static variables exceeds two gigabytes, specify -xmodel=medium. Otherwise, use the default -xmodel=small setting.

• Support For SSE/SSE2 Integral Media Intrinsics
  

  This release supports intrinsic functions for SSE2 128-bit XMM register integral media-instructions. Include the sunmedia_intrin.h header file in the source code and specify the -xbuiltin option to take advantage of these functions. Furthermore, these intrinsic functions require SSE2 support so specify options such as -xarch=sse2, -xarch=amd64, or -xtarget=opteron.

  Essentially, the compiler generates inline code for these instrinsic functions. This is easier than manipulating the instructions through assembly language and it can be optimized by the compiler. For more information about intrinsics, explanations for the function prototypes contained in the header files, and the data types used by these functions, see the Intel C++ Intrinsics Reference section of the Intel(R) C++ Compiler for Linux Systems manual.

• New -xvector Flags for x64 SSE2 Platforms
  

  The -xvector option enables automatic generation of calls to the vector library functions and/or the generation of the SIMD (Single Instruction Multiple Data) instructions.

• Binary Optimizer for SPARC
  

  A new -xbinopt option allows the compiler to prepare the binary file for further optimization by the binopt(1) binary optimizer.

• Calling Dependent Static Functions From a Function Template
  

  The C++ standard says that function calls that depend on a template parameter can refer only to visible function declarations having external linkage. Specify -features=[no%]tmplrefstatic if your application code depends on the compiler ignoring this rule and calling a dependent static function from a function template. See the C++ User's Guide for examples of -features=[no%]tmplrefstatic.

• New SPARC -xtarget and -xchip Values
  

  The new -xtarget flags ultra3iplus, ultra4plus, and ultraT1 along with the new -xchip flags ultra3iplus, ultra4plus, and ultraT1 provide code generation for the UltraSPARC IIIiplus, UltraSPARC T1, and UltraSPARC IVplus processors.

• A New Format For Debugger Information
  

  The C++ compiler can now generate debugger information in the dwarf format. The default is still the stabs format, but you can generate dwarf data by setting the new option -xdebugformat to -xdebugformat=dwarf.

• Enhancements to the STACKSIZE Environment Variable
  

  The syntax of the STACKSIZE environment variable has been enhanced to accept a units keyword for denoting the slave thread stacksize: B for Bytes, K for Kilobytes, M for Megabytes, G for Gigabytes.

  For example, setenv STACKSIZE 8192 sets the slave thread stack size to 8 MB. 1235B sets the slave thread stack size for 1235 Bytes. 1235G sets it for 1235 Gigabytes. The default for an integer value without a suffix letter is still Kilobytes.

• OpenMP Autoscoping
  

  Autoscoping is now available for C++ programs. This feature is described in chapter 3 of the Sun Studio 11 OpenMP API User's Guide.

Sun Studio 10 C++ New Features

This section describes the new and changed features for the Sun Studio 10 C++ 5.7 compiler.

• This release supports the compilation of 64-bit code for Solaris x86 platforms. The following is a brief summary of the new option-flags. See the CC(1) man page for complete descriptions of -xarch and -xtarget options.

  • A new -xarch option, -xarch=amd64, specifies compilation for the 64-bit AMD instruction set.

  • A new -xtarget option, -xtarget=opteron, specifies the -xarch, -xchip, and -xcache settings for 32-bit AMD compilation.

  • You must specify -xarch=amd64 to the right of -fast and -xtarget on the command line to generate 64-bit code. The new -xtarget=opteron option does not automatically generate 64-bit code. It expands to -xarch=sse2, -xchip=opteron, and -xcache=64/64/2:1024/64/16 which results in 32-bit code. The -fast option also results in 32-bit code because it is a macro which also defines -xtarget=native. All the current -xtarget values, with the exception of -xtarget=native64 and -xtarget=generic64, result in 32-bit code. You must specify -xarch=amd64 after (to the right of) -fast or -xtarget to compile 64-bit code, as in:
    

    CC -fast -xarch=amd64 
    

    or

    CC -xtarget=opteron -xarch=amd64
    

  • The existing -xarch=generic64 option now supports the x86 platform in addition to the traditional SPARC platform.

  • The C++ compiler now predefines __amd64 and __x86_64 when you specify -xarch=amd64.

• A new x86-only flag for the -xregs option, -xregs=[no%]frameptr, lets you use the frame-pointer register as an unallocated callee-saves register to increase the run-time performance of applications. See the CC.1 man page for full details.

• The Sun Studio 10 C++ 5.7 compiler supports template-template parameters. This means that you can specify a template definition with parameters that are themselves templates, rather than types or values. Recall that a template instantiated on a type is itself a type. Consider the following code example:

  template<typename T> class MyClass {
  ... }; 
  std::list< MyClass<int> > x;
  

  Since MyClass<int> is a type, the code example does not use template-template parameters. However, in the following code example, the class template C has a parameter that is a class template, and object x is an instance of C using class template A as its argument. Member y of c has type A<int>.

  // ordinary class
  template
  template<typename T> class A {
   T x;
  
  };
  
  // class template having a template
  parameter
  template< template<typename U> class V > class
  C {
   V<int> y;
  };
  // instantiate C on
  template
  C<A> x;
  
  

• The C++ compiler, in default standard mode, now allows nested classes to access private members of the enclosing class.

  The C++ standard says that nested classes have no special access to members of the enclosing class. However, most people feel this restriction is not justified because member functions have access to private members, so member classes should too. In the following example, function foo tries to access a private member of class outer. According to the C++ standard, the function has no access unless it is declared a friend function:
  

  class outer {
   int i; // private in
  outer
   class inner {
   int foo(outer* p) {
  
  return p->i; // invalid
   }
   };
  };
  

  The C++ Committee is in the process of adopting a change to the access rules giving the same access to member classes that member functions have. Many compilers have implemented this rule in anticipation of the changed language rule.

  To restore the old compiler behavior, disallowing the access, use the compiler option -features=no%nestedaccess. The default is -features=nestedaccess. See the CC(1) man page for a complete description of this option.

Sun Studio 9 C++ New Features

This section describes the new and changed features for the C++ compiler. For information about other Sun Studio 9 components, see the What's New manual. To access this manual, go to http://docs.sun.com.

• Improved performance through new defaults for the -xarch, -xcode, -xmemalign, and -xprefetch options and through a new expansion for the -O option.

• New -xarch, -xtarget, and -xchip flags for the x86 architecture.

• Improved run-time performance through the new -xprefetch_auto_type and -sync_stdio options.

• Expanded SPARC support with the new -xchip and -xtarget flags.

• Loop optimizations with -xautopar, -xvector, -xdepend.

• Improved compile-time performance through automatically generated precompiled header files with -xpch.

• Default support for extern INLINE functions and recognition of restricted pointers with the -xrestrict option.

• Control of optimization levels through the #pragma opt directive and the -xmaxopt option.

• Enhanced UTF-16 wide-character support with the -xustr option.

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 9 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 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 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:

• -xchip=pentium3 optimizes for Pentium 3 style processor.
• -xchip=pentium4 optimizes for Pentium 4 style processor.
• -xtarget=pentium3 sets -xarch=sse, -xchip=pentium3, and -xcache=16/32/4:256/32/4.
• -xtarget=pentium4 sets -xarch=sse2, -xchip=pentium4, and -xcache=8/64/4:256/128/8.
• -xarch=sse adds the SSE instruction set to the pentium_pro instruction set.
• -xarch=sse2 adds the SSE2 instruction set to those permitted by SSE.

  SPECIAL NOTE
  Programs that are compiled with -xarch={sse | sse2} to run on Solaris x86 SSE/SSE2 Pentium 4-compatible platforms must be run only on platforms that are SSE/SSE2 enabled. Running such programs on platforms that are not SSE/SSE2-enabled could result in segmentation faults or incorrect results occurring without any explicit warning messages. Patches to the OS and compilers to prevent execution of SSE/SSE2-compiled binaries on platforms not SSE/SSE2-enabled might be made available at a later date.

  OS releases starting with Solaris 9 update 6 are SSE/SSE2-enabled on Pentium 4-compatible platforms. Earlier versions of Solaris OS are not SSE/SSE2-enabled.

  This warning extends also to programs that employ .il inline assembly language functions or __asm() assembler code that utilize SSE/SSE2 instructions.

  If you compile and link in separate steps, always link using the compiler and with -xarch={sse | sse2} to ensure that the correct startup routine is linked.

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

• Are you building on a Pentium 3 or Pentium 4 machine that is running Solaris 9 update 5 or earlier and are you specifying -fast, -xarch=native or -xtarget=native?

  If so, the compiler makes the following expansions:

  • -xarch is set to pentium_pro (not pentium3 or pentium4 as you might expect) because the Solaris 9 update 5 or earlier operating systems do not support SSE and SSE2 instructions.

    Note: You can specify -xarch=sse or -xarch=sse2 despite using these versions of Solaris software, but you must run the executable that results from your build on a machine that is running Solaris 9 update 6 or later because these versions of Solaris software support SSE and SSE2 instructions.

  • -xchip is set to pentium3 or pentium4 as appropriate.

  • -xcache is set to 16/32/4:256/32/4 for a Pentium 3 processor or 8/64/4:256/128/8 for a Pentium 4 processor.

• Are you building on a Pentium 3 or Pentium 4 machine running Solaris 9 update 6 or later and are you specifying -fast, -xarch=native or -xtarget=native?

  If so, the compiler makes the following expansions:

  • -xarch is set to sse for Pentium 3 or sse2 for Pentium 4.
  • -xchip is set to pentium3 or pentium4 as appropriate.
  • -xcache is set to 16/32/4:256/32/4 for Pentium 3 or 8/64/4:256/128/8 for Pentium 4.

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

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

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

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

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

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

The C++ standard says that inline functions have external linkage, like non-inline functions, unless declared static. C++ 5.6, for the first time, 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.6 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();

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.

• -xautopar
• -xvector
• -xdepend

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

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.

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.

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.

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.

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.

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.

Sun ONE Studio 8 C++ New Features

This section describes the new and changed features for the C++ compiler. For information about other Sun ONE Studio 8 components, see the What's New manual. To access this manual on your local system or network, go to file:/opt/SUNWspro/docs/index.html. You can also access this manual by going to http://docs.sun.com.

This release of the C++ compiler improves template instantiation significantly. Programs that use the default template instantiation model are no longer restricted from building more than one program in a directory.

Most programs that rely on an alternate instantiation model, such as -instances=static, can now use the new default instantiation model.

The improvements and changes to template instantiation will either improve compile time by avoiding a template cache, or reduce executable size by avoiding duplicate static functions.

For details, see -instances in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

There are now two different ways you can control the exporting of symbols in dynamic libraries. This facility is called linker scoping, and has been supported by linker mapfiles for some time. First, you can now embed new declaration specifiers in code. By embedding __global, __symbolic, and __hidden directly in code, you no longer need to use mapfiles. Second, you can override the default setting for variable scoping by specifying -xldscope at the command line.

For details, see -xldscope in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide. The declaration specifiers are detailed in chapter 4, "Language Extensions" of the C++ User's Guide.

This release introduces two new pragmas and a new compiler option designed to help you track the behavior of macros in your application. This includes macros defined in system headers.

You can use the -xdumpmacros option at the command line to see the macro definitions and also to see where macros are defined, undefined, and used in your program. To narrow your focus, use the new dumpmacros and end_dumpmacros pragmas directly in the source.

For details, see -xdumpmacros in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

Use the -xvis=[yes|no] option when you are using the assembly-language templates defined in the VIS instruction set Software Developers Kit (VSDK). The default is -xvis=no.

The VIS instruction set is an extension to the SPARC v9 instruction set. Even though the UltraSPARC processors are 64-bit, there are many cases, especially in multimedia applications, when the data are limited to eight or 16 bits in size. The VIS instructions can process four 16-bit data with one instruction so they greatly improve the performance of applications that handle new media such as imaging, linear algebra, signal processing, audio, video and networking.

For more information on the VSDK, see http://www.sun.com/processors/vis .

For details, see -xvis in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

On operating systems that support the C99 standard (ISO/IEC 9899:1999, Programming Language - C), -xlang=c99 specifies C99 runtime behavior for C and C++ code that invokes C library functions. Some C99 behavior, like the C complex type, depends on the use of the -xc99=%all option with the C compiler, and some behavior, like printf, does not.

Note that C99 support is not available in compat mode (-compat=4).

For details, see -xlang in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

Specify -xustr=ascii_utf16_ushort if you need to support an internationalized application that uses ISO10646 UTF-16 string literals. In other words, use this option if your code contains string literals that you want the compiler to convert to UTF-16 strings in the object file. Without this option, the compiler neither produces nor recognizes sixteen-bit character string literals. This option enables recognition of the U"ASCII_string" string literals as an array of unsigned short int. Since such strings are not yet part of any standard, this option enables recognition of non-standard C++.

For details, see -xustr in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

The C++ compiler continues its implementation of the OpenMP interface for explicit parallelization.

The compiler has expanded OpenMP functionality to allow the following:

• Class objects are permitted in OpenMP data clauses.
• OpenMP pragmas are permitted in class member functions.

The following example shows the use of class objects in an OpenMP parallel region and the use of OpenMP constructs within a class member function.

#include <omp.h>
class A{
public:
 int i;

A(){i = 5;}; // ctor
 A(const A& a){ i = a.i; };
// copy ctor
 A& operator=(const A& a) // asgn
op
 {
 if (this != &a)
 i =
a.i;
 return *this;
 };
 ~A(){}; //
dtor
 void foo();
};

void A::foo() // member
function with pragma
{
 #pragma omp parallel
 i =
omp_get_thread_num();
}

main()
{
 A a, b, c;
 b.i =
10;
 c.i = 100;
 // Class objects used in OpenMP data
clauses
 #pragma omp parallel private(a) firstprivate(b)

{
 #pragma omp for lastprivate(c) private(a) //
Reprivitization
 for(int i = 0; i < 50; i++)

c.i = i * a.i;
 a = b;
 }
 a.foo();
}

Here are the known problems with handling valid OpenMP programs:

• The use of class objects as threadprivate variables may not function correctly.
• Try and catch blocks within OpenMP regions may not function correctly.
• Use of the std::string class objects in an OpenMP data clause or within an OpenMP parallel region may cause anomalous behavior.

For details of the compiler option, see -xopenmp in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide. For details of Sun's implementation of OpenMP, see the Sun ONE Studio 8 Compiler Collection OpenMP API User's Guide.

The -xprofile option offers the following improvements:

• Support for profiling shared libraries
• Thread-safe profile collection using -xprofile=collect -mt
• Improved support for profiling multiple programs or shared libraries in a single profile directory.

With -xprofile=use, the compiler can now find profile data in profile directories that contain data for multiple object files with nonunique basenames. For cases where the compiler is unable to find an object file's profile data, the compiler provides a new option -xprofile_pathmap=collect-prefix: use-prefix.

For details, see -xprofile and -xprofile_pathmap in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

When you specify -xe, the compiler checks only for syntax and semantic errors and does not produce any object code.

Use the -xe option if you do not need the object files produced by compilation. For example, if you are trying to isolate the cause of an error message by deleting sections of code, you can speed the edit and compile cycle by using -xe.

For details, see -xe in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

Use -xprofile_ircache[=path] with -xprofile=collect|use to improve compilation time during the use phase by reusing compilation data saved from the collect phase.

With large programs, compilation time in the use phase can improve significantly because the intermediate data is saved. Note that the saved data could increase disk space requirements considerably.

For details, see -xprofile_ircache in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

Use -instlib=filename to inhibit the generation of template instances that are duplicated in a library and the current object. In general, if your program shares large numbers of instances with libraries, try -instlib=filename and see whether or not compilation time improves.

For details, see -template, -instances, and -pti in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

Usually, the C++ compiler will not generate an inline template function unless the function is called and cannot be inlined. However, you can specify -template=geninlinefuncs and the compiler instantiates inline member functions of the explicitly instantiated class template which were not generated previously. Linkage for these functions is local in all cases.

For details, see -template in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

This release of the compiler introduces the new precompiled-header feature. The precompiled-header file may reduce compile time for applications whose source files share a common set of include files containing a large amount of source code. A precompiled header works by collecting information about a sequence of header files from one source file, and then using that information when recompiling that source file, and when compiling other source files that have the same sequence of headers. You can take advantage of this feature through the -xpch and -xpchstop options in combination with the #pragma hdrstop directive.

For details, see the -xpch and -xpchstop and options in CC(1). The Sun ONE Studio 8 Compiler Collection C++ User's Guide details these options as well as #pragma hdrstop.

Specify the -xjobs=n option to set how many processes the compiler creates to complete its work. This option can reduce the build time on a multi-cpu machine. Currently, -xjobs works only with the -xipo option. When you specify -xjobs=n, the interprocedural optimizer uses n as the maximum number of code generator instances it can invoke to compile different files.

For details, see -xjobs in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

Use the -xmemalign option to control the assumptions the compiler makes about the alignment of data. By controlling the code generated for potentially misaligned memory accesses and by controlling program behavior in the event of a misaligned access, you can more easily port your code to Solaris.

The -xmemalign option is also used to improve performance for data that is aligned more than necessary, and to access structures that are packed more than normal.

For details, see -xmemalign in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

The -xchar[={signed|s|unsigned|u}] option is provided solely for the purpose of easing the migration of code from systems where the char type is defined as unsigned. Do not use this option unless you are migrating from such a system. Only code that relies on the sign of a char type needs to be rewritten to explicitly specify signed or unsigned. See the C++ User's Guide or CC(1) for more information.

Use the new -xport64 option to help you port code to a 64-bit environment. Specifically, this option warns against problems such as truncation of values (including pointers), sign extension, and changes to bit-packing that are common when you port code from a 32-bit architecture such as V7 (ILP32) to a 64-bit architecture such as V9 (LP64).

For details, see -xport64 in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

Use the new linker supported thread-local storage facility of the compiler to do the following:

• Utilize a fast implementation for the POSIX interfaces for allocating thread-specific data.
• Convert multi-process programs to multi-thread programs.
• Port Windows applications using thread-local storage to Solaris.
• Utilize a fast implementation for the threadprivate variables in OpenMP.

Thread-local storage is now available in the compiler through the declaration of thread-local variables. The declaration consists of a normal variable declaration with the addition of the variable specifier __thread and the command line option -xthreadvar.

For details, see -xthreadvar in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide. The declaration specifiers are detailed in chapter 4, "Language Extensions" of the C++ User's Guide.

Use the new functionality of -xF to enable the optimal reordering of variables and functions by the linker. This can help solve the following problems which negatively impact run-time performance:

• Cache and page contention caused by unrelated variables that are near each other in memory.
• Unnecessarily large work-set size as a result of related variables which are not near each other in memory.
• Unnecessarily large work-set size as a result of unused copies of weak variables that decrease the effective data density.

For details, see -xF in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

The C++ compiler now supports four new pragmas that you can use to help improve the optimization of your code. See the C++ User's Guide for complete descriptions of these pragmas:

• #pragma does_not_read_global_data
• #pragma does_not_return
• #pragma does_not_write_global_data
• #pragma rarely_called

For details, see Appendix B, "Pragmas" in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

The C++ compiler can now perform link-time optimization on relocatable object files when you specify the -xlinkopt command. See CC(1).

Specify -xlinkopt and the compiler performs some additional optimizations at link time without modifying the .o files that are linked. The optimizations appear only in the executable program. The -xlinkopt option is most effective when you use it to compile the whole program, and with profile feedback.

For details, see -xlinkopt in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

Use the -xpagesize=n option to set the preferred page size for the stack and the heap. n can be 8K, 64K, 512K, 4M, 32M, 256M, 2G, 16G, or default. You must specify a valid page size for the Solaris operating environment on the target platform, as returned by getpagesize(3C). If you do not specify a valid page size, the request is silently ignored at run-time. You can use pmap(1) or meminfo(2) to determine page size of the target platform.

This option is a macro for -xpagesize_stack and -xpagesize_heap.

For details, see -xpagesize, -xpagesize_heap, and -xpagesize_stack in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

You can now use the new -erroff option to suppress warning messages from the compiler front-end. Note that neither error messages nor messages from the driver are affected. You can also use -erroff to single out a particular warning message so that either it alone is suppressed or it alone is issued.

For example, -erroff=tag suppresses the warning message specified by this tag. On the other hand, -erroff=%all,no%tag suppresses all warning messages except the messages identified by tag. You can display the tag for a warning message by using the -errtags=yes option.

For details, see -erroff in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

You can now use the -errtags and -errwarn compiler options to stop compilation if the compiler issues a particular warning. Set -errtags=yes to find the tag for a particular warning and then specify -errwarn=tag where tag is the unique identifier returned by -errtags for a particular warning message.

You can also abort compilation if any warning is issued by specifying -errwarn=%all. See also -xwe in CC(1).

For details, see -errtags and -errwarn in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

The -filt=[no%]stdlib option is set by default and simplifies names from the standard library in both the linker and compiler error messages. This makes it easier for you to recognize the name of standard-library functions. Specify -filt=no%stdlib disable this filtering.

For details, see -filt in CC(1) or in the Sun ONE Studio 8 Compiler Collection C++ User's Guide.

Forte Developer 6 update 2 C++ New Features

The Sun WorkShop 6 update 2 C++ (5.3) compiler includes the following additional new and changed features.

1. Standard Iostreams Version of the Tools.h++ Library
2. Shared libCstd and libiostream
3. Performance Improvements
4. More Control Over Anachronism Warnings
5. Acceptance of Non-Standard Source Code
6. The -xinline Option is Reenabled With New Argument
7. New -xbuiltin Option Enables Better Optimization of Standard Library Calls.
8. Enhanced -fast Option
9. New -xipo Option for Interprocedural Optimization
10. You Can Now Compile and Request License Information in the Same Command Line
11. Variable-Argument Preprocessor Function Macros
12. A Trailing Comma in enum Is No Longer Treated as an Error
13. Choose Handling of Nonlocal Static Object Initializers
14. New and Changed Values for -xchip and -xtarget

1. Standard Iostreams Version of the Tools.h++ Library

   This release of the C++ compiler contains two versions of the Tools.h++ library:

   • One that works with classic iostreams. This version of the Tools.h++ library is compatible with the Tools.h++ library that was shipped with earlier versions of the compiler.
     
     To use the classic iostreams version of Tools.h++ in standard mode (the default mode), use the option -library=rwtools7,iostream. To use the classic iostreams version of Tools.h++ in compatibility mode (-compat[=4]), use the option -library=rwtools7.
     
     
   • One that works with standard iostreams. This version of the Tools.h++ library is incompatible with the classic iostreams version of Tools.h++. This version is available only in standard mode. It is not available in compatibility mode (-compat[=4]).
     
     To use the standard iostreams version of Tools.h++ in standard mode (the default mode), use the option -library=rwtools7_std.
     
     
2. Shared libCstd and libiostream

   Shared libCstd

   The Sun WorkShop 6 update 2 C++ (5.3) Compiler includes a shared version of the libCstd library.

   To use the shared version of libCstd, do the following:

   1. As superuser, manually create the following symbolic links. You need to create these links for this release only. Since this is an update release, the default link line uses the libCstd.a version. Subsequent releases of the compiler may link in the shared version as the default:

      ln -s /usr/lib/libCstd.so.1
      /opt/SUNWSpro/lib/libCstd.so
      ln -s /usr/lib/libCstd.so.1
      /opt/SUNWSpro/lib/v8plus/libCstd.so
      ln -s
      /usr/lib/sparcv9/libCstd.so.1 /opt/SUNWSpro/lib/v9/libCstd.so
      

      The last two symbolic links are not needed for IA.

      Note -- If your compiler is not installed in the /opt/SUNWSpro directory, ask your system administrator for the equivalent path on your system.

   2. Once these symbolic links are created, libCstd will be linked dynamically by default. To test this, compile any program with /opt/SUNWSpro/bin/CC, then type the command ldd a.out. The output will show a dependency on /usr/lib/libCstd.so.1.

      To link this library statically, use the option -staticlib=Cstd.

   
   
   

   Shared libiostream

   The Sun WorkShop 6 update 2 C++ (5.3) Compiler includes a shared version of the classic iostream library libiostream.

   To use the shared version of libiostream, do the following:

   1. As superuser, manually create the following symbolic links:

       ln -s /usr/lib/libiostream.so.1 \
      
      /opt/SUNWspro/lib/libiostream.so
       
       ln -s
      /usr/lib/sparcv9/libiostream.so.1 \
      
      /opt/SUNWspro/lib/v9/libiostream.so
      

      For Intel 32-bit processor architecture, you do not need the last link.

      Note -- If your compiler is not installed in the /opt/SUNWSpro directory, ask your system administrator for the equivalent path on your system.

   2. Once these symbolic links are created, libiostream will be linked dynamically by default.

      To link this library statically, use -staticlib=iostream and -library=iostream.

   
   
3. Performance Improvements

   The following performance improvements have been made, relative to the Sun WorkShop 6 update 1 C++ (5.2) Compiler:

   • Significant improvement in compile time, especially for parallel compilations in the same directory that have heavy use of templates.
     

     This improvement was achieved by overhauling the mechanism used to manage the template repository. This overhaul also does away with the need for messages that refer to the locking of the repository. For parallel builds, you need to invoke dmake -j <jobs> instead of make.
     
     

   • Better performance of the standard library, particularly iostreams and the string class. String class improvements rely on special code generation when the -xarch=v8plus or -xarch=v9 option is selected.
     
     
   • Better management of inline function generation. Some functions will now be inlined that previously were considered to exceed the compiler's complexity measure. Default inlining has been tuned to reduce compilation time at low levels of optimization, and to improve run-time speed at high levels of optimization.
     
     
4. More Control Over Anachronism Warnings

   In compatibility mode (-compat[=4]), the compiler is silent about transition errors. The compiler emits warnings about these errors when you specify +w or +w2.

   In standard mode, the compiler emits warnings about transition errors.

   When you use the new -features=no%transitions option in either compatibility mode or standard mode, the compiler emits error messages instead of warnings.

   Messages about the following language constructs are controlled by this feature:

   • Redefining a template after it was used.
   • Omitting the typename directive when it is needed in a template definition.
   • Implicitly assuming type int when a type specifier is missing.
   
   
5. Acceptance of Non-Standard Source Code

   The new -features=extensions option enables you to compile nonstandard code that is commonly accepted by other C++ compilers.

   You can use this option when you must compile invalid code, and you are not permitted to modify the code to make it valid.

   You can easily turn each supported instance of invalid code into valid code that all compilers will accept. If you are allowed to make the code valid, you should do so instead of using this option. Using this option perpetuates invalid code that will be rejected by some compilers.

   When you add -features=extensions to a compile command, the compiler supports the following language extensions.

   • Overriding virtual functions can be less restrictive than the functions they override.
   • Forward declarations of enum types and variables are allowed
   • Incomplete enum types are taken as forward declarations
   • enum name is allowed as a scope qualifier
   • Anonymous struct declarations are allowed
   • Passing the address of an anonymous class instance is allowed
   • A static namespace-scope function is allowed as a class friend
   • The predefined __func__ symbol for function name is allowed
   
   
   
6. The -xinline Option is Reenabled With New Argument

   The -xinline option is enabled again. In addition, it includes the %auto argument.

   The new usage statement is:

   -xinline=[%auto][[,][no%]< func_name>[,[no%]<func_name>...]]

   This option enables you to specify which user-written routines can be inlined by the optimizer.

   Note -- This option has no effect on C++ inline functions.

   Values

   %auto	Enable automatic inlining at optimization levels -xO4 or higher. This argument tells the optimizer that it can inline functions of its choosing. Note that automatic inlining is normally turned off when explicit inlining is specified on the command line by -xinline=[no%]<func_name>...
   <func_name>	Strongly request that the optimizer inline the function. If the function is not declared as extern "C", the function name must be mangled. You can use the nm command on the executable file to find the mangled function names. For functions declared as extern "C", the names are not mangled by the compiler.
   no%<func_name>	If you prefix the name of a routine on the list with no%, the inlining of that routine is inhibited. The rule about mangled names for <func_name> applies to no%<func_name> also.

   Only routines in the file being compiled are considered for inlining unless you use -xcrossfile[=1]. The optimizer decides which of these routines are appropriate for inlining.

   Defaults

   If the -xinline option is not specified, the compiler assumes -xinline=%auto.

   If -xinline= is specified with no arguments, no functions are inlined, regardless of the optimization level.

   Interactions

   The -xinline option has no effect for optimization levels below -xO3. At -xO4 and higher, the optimizer decides which functions should be inlined, and does so without the -xinline option being specified. At -xO4 and higher, the compiler also attempts to determine which functions will improve performance if they are inlined. If you force inlining of a function with -xinline, you might actually diminish performance.

   Although -xinline=<func_name> has an effect at optimization level -xO3, -xinline=%auto is ignored at this level.

   A routine is not inlined if any of the following conditions apply, with no warnings.

   • Optimization is less than -xO3
   • The routine cannot be found.
   • Inlining it is not profitable or safe.
   • The source is not in the file being compiled, or if you use -xcrossfile[=1], the source is not in the files named on the command line.

   Examples

   To enable automatic inlining while disabling inlining of the function declared int foo(), use

   example% CC -xO5 -xinline=%auto,no%__1cDfoo6F_i_ -c
   a.cc
   

   To strongly request the inlining of the function declared as int foo(), and to make all other functions as the candidates for inlining, use

   example% CC -xO5 -xinline=%auto,__1cDfoo6F_i_ -c
   a.cc
   

   To strongly request the inlining of the function declared as int foo(), and to not allow inlining of any other functions, use

   example% CC -xO5 -xinline=__1cDfoo6F_i_ -c a.cc
   

7. New -xbuiltin Option Enables Better Optimization of Standard Library Calls

   By default, the functions declared in standard library headers are treated as ordinary functions by the compiler. However, some of those functions can be recognized as "intrinsic" or "built-in" by the compiler. When treated as built-in, the compiler can generate more efficient code. For example, the compiler can recognize that some functions have no side effects, and always return the same output given the same input. Some functions can be generated inline directly by the compiler.

   The -xbuiltin (or alternately, -xbuiltin=%all) option asks the compiler to recognize as many of the built-in standard functions as possible. The exact list of recognized functions varies with the version of the compiler code generators.

8. Enhanced -fast Option

   The -fast option now expands to include the -xbuiltin=%all option.

9. New -xipo Option for Interprocedural Optimization

   The new -xipo compiler flag performs whole-program optimizations by invoking an interprocedural analysis pass. Unlike -xcrossfile, -xipo will perform optimizations across all object files in the link step, and is not limited to just the source files on the compile command.

   The -xipo option is particularly useful when compiling and linking large multifile applications. Object files compiled with this flag have analysis information compiled within them that enables interprocedural analysis across source and precompiled program files. However, analysis and optimization is limited to the object files compiled with -xipo, and does not extend to object files on libraries.

   Scope

   When compiling and linking are performed in separate steps, -xipo must be specified in both steps to be effective.

   Objects that are compiled without -xipo can be linked freely with objects that are compiled with -xipo.

   Examples

   The following example compiles and links in the same step:

    example% CC -xipo -xO4 -o prog part1.cc part2.cc
   part3.cc
   

   The optimizer performs crossfile inlining across all three source files. This is done in the final link step, so the compilation of the source files need not all take place in a single compilation and could be over a number of separate compilations, each specifying the -xipo option.

   The following example compiles and links in separate steps:

    example% CC -xipo -xO4 -c part1.cc part2.cc 
   
   example% CC -xipo -xO4 -c part3.cc
    example% CC -xipo -xO4
   -o prog part1.o part2.o part3.o
   

   The object files created in the compile steps have additional analysis information compiled within them to permit crossfile optimizations to take place at the link step.

   Warnings

   Libraries do not participate in crossfile interprocedural analysis, even when they are compiled with -xipo, as shown in this example:

    example% CC -xipo -xO4 one.cc two.cc three.cc
   
   example% CC -xar -o mylib.a one.o two.o three.o
   
    ...
   
   example% CC -xipo -xO4 -o myprog main.cc four.cc mylib.a
   

   Here interprocedural optimizations will be performed between one.cc, two.cc and three.cc, and between main.cc and four.cc, but not between main.cc or four.cc and the routines in mylib.a. (The first compilation may generate warnings about undefined symbols, but the interprocedural optimizations will be performed because it is a compile and link step.)

   Interactions

   -xipo requires at least optimization level -xO4.

   -xipo conflicts with -xcrossfile. If used together, they will result in a compilation error.

10. You Can Now Compile and Request License Information in the Same Command Line

    Previously, if you mixed -xlicinfo and other options on the same line, you would either get a compile or license information but never both. Now, when you mix -xlicinfo with other options, the compiler compiles the code and displays the license information.

11. Variable-Argument Preprocessor Function Macros

    The C99 standard (section 6.10) supports preprocessor function macros that can take a variable number of arguments. This feature is now supported by the C++ compiler.

    To define a variable-argument preprocessor function macro, append a trailing '...' token to the macro's parameter list and place the __VA_ARGS__ identifier in the replacement text. For example:

     #define printwords(...) fprintf(stderr, __VA_ARGS__)
    

    The following excerpt regarding variable-argument function macros is from section 6.10.3, paragraph 12 of second edition of the C standard, ISO/IEC 9899:1999 "Programming languages -- C":

    If there is a ... in the identifier-list in the macro definition, then the trailing arguments, including any separating comma preprocessing tokens, are merged to form a single item: the variable arguments. The number of arguments so combined is such that, following merger, the number of arguments is one more than the number of parameters in the macro definition (excluding the ...).

    You can use __VA_ARGS__ only in the context of the definition of a macro using variable arguments.

12. A Trailing Comma in enum Is No Longer Treated as an Error

    Previously, code such as the following was rejected as an error. The compiler in all modes now accepts a trailing comma in enum declarations with a warning, instead of treating it as an error.

     enum Size { small, medium, large, }; // warning
    
    
    

13. Choose Handling of Nonlocal Static Object Initializers

    Use the -features=[no%]split_init option to specify whether to put all the initializers in one function or into separate functions (default).

14. New and Changed Values for -xchip and -xtarget

    The -xchip option now accepts ultra2e which specifies the timing properties of the UltraSPARCIIe processors.

    If you set -xtarget equal to any of the following values, the -xarch value is v8plusa:
    
    

    • entr2/1170
    • entr2/1200
    • entr2/2170
    • entr2/2200
    • entr3000
    • entr4000
    • entr5000
    • entr6000
    • ultra
    • ultra/140
    • ultra/170
    • ultra/200
    • ultra2
    • ultra2/1170
    • ultra2/1200
    • ultra2/1300
    • ultra2/2170
    • ultra2/2200
    • ultra2/2300
    • ultra2e
    • ultra2i
    • ultra3

Forte Developer 6 C++ New Features

This version of the Forte Developer C++ compiler includes the following additional new features:

1. Partial Specialization
2. Explicit Function Template Argument
3. Non-Type Function Template Parameters
4. Member Templates
5. Definitions-Separate Template Organization Restriction Removed
6. Prefetch Instructions
7. Extern Inline Functions
8. Ordering of Static Variable Destruction
9. Sub-Aggregate Initialization
10. Using Your Own C++ Standard Library
11. Cache Versioning
12. Restrictions on Bitfield Size Removed
13. Warnings About Conversions Between Pointer-To-Function and void*
14. New and Changed Options

1. Partial Specialization

   A template can be (fully) specialized, meaning that an implementation is defined for specific template arguments. For example:

    template<class T, class U> class A { ... }; //primary
   template
    template<> class A<int, double> { ... };
   //specialization
   
   

   A template can also be partially specialized, meaning that only some of the template parameters are specified, or that one or more parameters are limited to certain categories of type. The resulting partial specialization is itself still a template. The following examples use the previous primary template:

    template<classU> class A<int> { ... }; // Example
   no. 1
    template<class T, class U> class A<T*> { ... };
   // Example no. 2 
    template<class T> class A<T**, char>
   { ... }; //Example no.3
   
   

   • Example 1 provides a special template definition for cases when the first template parameter is type int.
   • Example 2 provides a special template definition for cases when the first template parameter is any pointer type.
   • Example 3 provides a special template definition for cases when the first template parameter is pointer-to-pointer of any type, and the second template parameter is type char.
2. Explicit Function Template Argument

   If a template argument cannot be deduced from the function arguments, you can now specify it explicitly using the syntax f<template args>(function args). For example:

    template<class Mytype> Mytype* construct(float,
   float); 
    ...
    int* x = construct<int>(a, b);
   

3. Non-Type Function Template Parameters

   This release supports non-type function template parameters, such as:

    template<int I> void foo( int a[I] ) { ... }
   
   template<int I> void foo( mytype<I> m ) { ... }
   
   

   This release does not allow expressions involving non-type template parameters in the function parameter list, as illustrated in the following examples:

    // these are not supported
    template<int I>
   void foo( mytype<2*I> ) { ... } 
    template<int I, int
   J> void foo( int a[I+J] ) { ... }
   

4. Member Templates

   In standard mode, classes and class templates can have templates as members, as illustrated in the following code sample:

    template <class T1> 
    class OuterClass {
   
    public: 
    // class member template 
   
   template <class T2> 
    class MemberClass 
   
   { 
    T2 MCmember; 
    T1 OCmember; 
   
   }; 
    template<class T3> operator T3() { ... }
    ...
   
    };
   
   

   Note -- Member templates are not supported in compatiblity mode (-compat[=4]).
5. Definitions-Separate Template Organization Restriction Removed

   The compiler no longer has a restriction against "definitions-separate template organization" for -instances != extern (that is, -instances=explicit, -instances=global, -instances=semiexplicit, or -instances=static). Regardless of the -instances setting, the compiler will now, by default, include separate source files in the search for definitions.

   To turn this restriction back on, use the -template=no%extdef option. Note, however, that when the -template=no%extdef option is specified, the compiler will not search for separate source files even with -instances=extern.

6. Prefetch Instructions

   You can use -xprefetch in conjunction with the header file <sun_prefetch.h> to specify prefetch instructions on those architectures that support prefetch, such as UltraSPARC II (-xarch=v8plus, v8plusa, v8plusb, v9, v9a, or v9b).

7. Extern Inline Functions

   This version of the compiler allows extern inline functions. If there is any local static data in an inline function, only one copy of the static data is used in all compilation units. However, the addresses of inline functions taken in different translation units will not compare as equal.

8. Ordering of Static Variable Destruction

   The standard has defined the order of destruction of objects with static storage duration more fully; static objects must be destroyed in the reverse order of their construction. Previous language definitions left some aspects unspecified.

   This stricter ordering is implemented for standard mode only. In compatibility mode (-compat[=4]), the order of destruction is implemented as before.

   If your program depends on a particular order of destruction and worked with an older compiler, the order required by the standard might break the program in standard mode. The -features=no%strictdestrorder command option disables the strict ordering of destruction.

9. Sub-Aggregate Initialization

   When using brace-initialization of class objects (for types where brace-initialization is allowed), the C++ standard permits a member which is itself an aggregate class to be initialized by a value of its own type. For example:

   
    struct S { // an aggregate type
    int i,
   j;
    };
   
    struct T { // an aggregate type
    S s;
   // aggregate member
    int k;
    };
   
    T t1 = { {1,
   2}, 3 }; // traditional initialization
    S s1 = { 1, 2 };
    T
   t2 = { s1, 3 }; // sub-aggregate initialization
   

10. Using Your Own C++ Standard Library

    If you want to use your own version of the C++ standard library instead of the version supplied with the compiler, you can do so by specifying the -library=no%Cstd option. This option prevents the finding any of the following headers:

    <algorithm> <bitset> <complex> <deque> <fstream> <functional> <iomanip> <ios> <iosfwd> <iostream> <istream> <iterator> <limits> <list> <locale> <map> <memory> <numeric> <ostream> <queue> <set> <sstream> <stack> <stdexcept> <streambuf> <string> <strstream> <utility> <valarray> <vector>

    When -library=no%cstd is specified, the libCstd library, which implements those headers, is not automatically linked with your program. To use any of the features declared in the above headers, you must use the -I option to point to the directory where the replacement headers are located, and you must link your program with a library or set of object files containing the implementation of the replacement headers.

    You cannot reliably replace just a portion of the headers listed above, nor can you reliably link libCstd with all or part of another library implementation. (For example, you cannot replace just the string classes and use libCstd for everything else.) Either use the library supplied with the compiler, or replace all of the functionality listed above.

    The remaining headers (<exception>, <new>, <typeinfo>, and all the headers inherited from C) are integral to the compiler itself or to Solaris, and are not affected by the -library=no%Cstd option. Linking of the library libCrun also is not affected by the -library=no%Cstd option.

    There is no mechanism to replace any of the functionality of libCrun. If you replace the standard library, the code must be compiled with the versions of <exception>, <new>, and <typeinfo> supplied with the compiler. In standard mode (the default mode) C++ programs must be linked with libCrun.

    Note - this option is available to "use at your own risk." That is, dropping in another library may not necessarily produce good results.

11. Cache Versioning

    The C++ compiler now has the ability to detect cache version differences and issue the appropriate error message. The compiler marks each template cache directory with a version string that uniquely identifies the template cache version. Subsequent releases of the compiler will also use cache version strings, although these versions may be different from the current one.

    This compiler and future compilers will detect the version strings from within the cache directories, and issue an error as appropriate. For example, a future compiler that uses a different template cache version string and processes a cache directory produced by this release of the compiler might issue the following error:

     SunWS_cache: Error: Database version mismatch
    
    /SunWS_cache/CC_version
    
    

    Similarly, this release of the compiler issues an error if it encounters a cache directory produced by a future compiler.

    The template cache directories produced by the Sun WorkShop C++ compiler 5.0 compiler are not versioned. However, the Sun WorkShop 6 C++ compiler processes these cache directories without an error or a warning. These cache directories are converted to the cache directory format used by the Sun WorkShop 6 C++ compiler.

    A template cache directory produced by the Sun WorkShop 6 C++ compiler or later releases cannot be used by the Sun WorkShop C++ compiler 5.0. The Sun WorkShop C++ compiler 5.0 is not capable of recognizing format differences and it will issue an assertion.

12. Restrictions on Bitfield Size Removed

    The restriction on the size of a bitfield to 32 or less is removed. Bitfields can now be any size.

13. Warnings About Conversions Between Pointer-To-Function and void*

    Previously, the compiler issued warnings about conversions between pointer-to-function and void*. Now, the compiler only issues these warnings when you use the +w2 option.

14. New and Changed Options

    The following list shows the new and changed options. For more information, see the entry for each option in the C++ User's Guide. To access this guide in HTML, point your browser to file:/opt/SUNWspro/docs/index.html.

    • New Options. -xcrossfile, -Bsymbolic, -features=[no%]strictdestrorder, -template=extdef.
    • Changed Options. -fast, -library=[no%]Cstd, +p, -ptr, -xprefetch.