Updated 2007/05/31 |
Sun[tm] Studio 12: C++ 5.9 Compiler Readme |
Contents
- Introduction
- About the Sun Studio 12, C++ 5.9 Compiler
- New and Changed Features
- Software Corrections
- Problems and Workarounds
- Limitations and Incompatibilities
- Documentation Errors
- Shippable Libraries
- Standards Not Implemented
A. Introduction
This document contains information about the Sun Studio 12 C++ 5.9 compiler. Throughout this document, the compiler is also referred to as version 5.9 of the C++ compiler. This document describes the new features that are included with this release, software corrections that are addressed by this release, and lists known problems, limitations, and incompatibilities. Information in this document updates and extends information in the software manuals.
Product Documentation
- Release Notes: Available on the Sun Developer Network (SDN) Sun Studio portal at http://developers.sun.com/sunstudio/documentation/ss12/release_notes.html. Information in the release notes updates and extends information in all readme files.
- Compilers and Tools Documentation: Product man pages, HTML versions of readmes, and manuals can be accessed from /installation_directory/SUNWspro/docs/index.html. The default installation directory for Solaris platforms is /opt. If your Sun Studio software is not installed in the default /opt directory, ask your system administrator for the equivalent path on your system.
- Developer Resources Portal: For technical articles, code samples, documentation, and a knowledge base, see the SDN Sun Studio portal at http://developers.sun.com/sunstudio. For additional information, see the Support page on the portal.
B. About Sun Studio 12, C++ Compiler 5.9
This 5.9 version of the C++ compiler is upwardly source-compatible and binary-compatible with C++ compiler versions 5.0 through 5.8. That is, you can compile source code written for versions 5.0 through 5.8 of the C++ compiler using this C++ compiler. In addition, you can link object code that was generated by C++ compiler versions 5.0 through 5.8 with object code that is generated by this C++ compiler. You should always link with the latest compiler which, for this release, is version 5.9.
The C++ compiler also offers the -compat option for compiling source code that was written for the 4.2 C++ compiler. The -compat option was introduced in version 5.0.
C. New and Changed Features
This section describes the new and changed features for the Sun Studio 12 C++ 5.9 compiler. For details on any of the compiler options, see the C++ User's Guide or the CC(1) man page.
For additional information regarding new features in other Sun Studio 12 components, see the SDN Sun Studio portal at http://developers.sun.com/sunstudio/documentation/index.jsp.
A New Way To Specify 32-bit or 64-bit Address Model
You no longer need use the -xarch option to specify a 32-bit or 64-bit address model (LP64 versus ILP32). Two new options make it easier:
- -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>The compiler can now handle such usage.
T func( T (&arr)[I*J] ) { ... } // I*J is a "complex template expression"- 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.ccNew 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
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
- -xarch=sparcvis2
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 Specify the following new option to enable or disable the automatic generation of floating-point, fused, 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
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
The following new compiler option causes the compiler to instrument your multi-threaded application for analysis by 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.
This section discusses the following software corrections.
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
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
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.
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.
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
This section discusses known software problems and possible workarounds for those problems. For updates or patches check the updated information at http://developers.sun.com/sunstudio/support/.
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.
__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.
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.
The following conditions may cause linking problems.
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.
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 12 compilers and tools are not installed in the default /opt directory, ask your system administrator for the equivalent path on your system.
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.
A program using templates and static objects causes link-time errors of undefined symbols if you specify -instances=extern. This is not a problem with the default setting -instances=global. The compiler does not support references to non-global namespace-scope objects from templates. Consider the following example:
static int k; template<class T> class C { T foo(T t) { ... k ... } };
In this example, a member of a template class references a static namesapce-scope variable. Keep in mind that namespace scope includes file scope. The compiler does not support a member of a template class referencing a static namespace-scope variable. In addition, if the template is instantiated from different compilation units, each instance refers to a different k, which means that the C++ One-Definition Rule is violated and the code has undefined behavior.
Depending on how you want to use k and the effect it should have, the following alternatives are possible. The second option only is available for function templates that are class members.
int k; // not staticAll instances use the same copy of k.
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.
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.
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; }
Early releases of the C++ compiler did not perform function overload resolution in accordance with the requirements of the C++ standard. The current release fixes many bugs in resolving calls to overloaded functions. In particular, the compiler would sometimes pick a function when a call was actually ambiguous, or complain that a call was ambiguous when it actually was not.
Some workarounds for ambiguity messages are no longer necessary. You may see new ambiguity errors that were not previously reported.
One major cause of ambiguous function calls is overloading on only a subset of built-in types.
int f1(short); int f1(float); ... f1(1); // ambiguous, "1" is type int f1(1.0); // ambiguous, "1.0" is type double
To fix this problem, either do not overload f1 at all, or overload on each of the types that do not undergo promotion: int, unsigned int, long, unsigned long, and double. (And possibly also types long long, unsigned long long, and long double.)
Another major cause of ambiguity is type conversion functions in classes, especially when you also have overloaded operators or constructors.
class T { public: operator int(); T(int); T operator+(const T&); }; T t; 1 + t // ambiguous
The operation is ambiguous because it can be resolved as
T(1) + t // overloaded operator 1 + t.operator int() // built-in int addition
You can provide overloaded operators or type conversion functions, but providing both leads to ambiguities.
In fact, type conversion functions by themselves often lead to ambiguities and conversions where you did not intend for them to occur. If you need to have the conversion available, prefer to use a named function instead of a type conversion function. For example, use int to_int(); instead of operator int();
With this change, the operation 1 + t is not ambiguous.
It can be interpreted only as T(1) + t. If you want the
other interpretation, you must write
1 + t.to_int().
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.
This section discusses limitations and incompatibilities with systems or other software. For last minute information for this Sun Studio 12 release, see the Sun Studio 12 Release Notes. The release notes are on the Sun Studio 12 web site at http://developers.sun.com/sunstudio/documentation/ss12/release_notes.html. Information in the release notes updates and extends information in all readme files.
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 { : } }
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.
A SUNWlibC patch is provided for each version of the Solaris Operating Environment supported by this Sun Studio 12 release on each of the supported platforms. The patch should be installed not only on the systems used for compiling, but on all systems where the resulting programs are run. Without these patches, some programs fail to link and some programs terminate in unusual ways due to runtime errors. For example, the linker may report a message similar to the following:
Undefined symbol | First referenced in file |
std::ostream &operator<<(std::ostream&,const RWCString&) | test.o |
ld: fatal: Symbol referencing errors. No output written to test
You may also see an error message such as the following:
Hint: try checking whether the first non-inlined, non-pure virtual function of ...
For information about required and optional patches for this Sun Studio 12 release, see the Sun Studio 12 web site at http://developers.sun.com/sunstudio/support/.
If you are using version 4.0, 4.1, or 4.2 of the C++ compiler and wish to migrate to one of the newer versions listed below, see chapter 6 of the C++ Migration Guide which discusses, in detail, the considerations and preparations you must peform to ease the migration.
- Sun Studio 12 C++ (5.9) compiler
- Sun Studio 11 C++ (5.8) compiler
- Sun Studio 10 C++ (5.7) compiler
- Sun Studio 9 C++ (5.6) compiler
- Sun Open Net Environment (Sun ONE) Studio 8 C++ (5.5) compiler
- Forte Developer 7 C++ (5.4) compiler
- Forte Developer 6 update 2 C++ (5.3) compiler
- Forte Developer 6 update 1 C++ (5.2) compiler
- Forte Developer 6 C++ (5.1) compiler
- Sun WorkShop C++ (5.0) compiler
There is no new information at this time.
/opt/SUNWspro/READMEs/runtime.libraries
Note - If your Sun Studio 12 software is not installed in the /opt directory, ask your system administrator for the equivalent path on your system.
You cannot redistribute or otherwise disclose the header files, source code, object modules, or static libraries of object modules in any form.
The License to Use appears in the End User Object Code License, which you can view from the back of the plastic case containing the CD-ROM.
As before, if you choose to link either library statically, you can do so with no further action or permissions needed. To ensure compatibility of your program on different operating system versions, link with the shared-library versions.
The C++ compiler supports the ISO standard for C++, ISO IS 14882:1998, Programming Language C++. The following list describes requirements in the standard that are not supported in this release:
Copyright © 2007 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.