Updated 2001/06/07

Sun Workshop[tm] 6 update 2 C++ Compiler Readme


Contents

  1. Introduction
  2. About Sun WorkShop 6 update 2 C++ Compiler
  3. New Features
  4. Software Corrections
  5. Problems and Workarounds
  6. Limitations and Incompatibilities
  7. Documentation Errata
  8. Shippable Libraries
  9. Standards Not Implemented

A. Introduction

This document contains last-minute information about the C++ compiler. This document describes the software corrections addressed by this release and lists known problems, limitations, and incompatibilities.

For installation-related and late-breaking information about this release, see the Sun WorkShop 6 update 2 Release Notes. Information in the release notes overrides information in all readme files.

To access the release notes and the full Forte[tm] Developer/Sun WorkShop[tm] documentation set, point your Netscape[tm] Communicator 4.0 or compatible browser to the documentation index (file:/opt/SUNWspro/docs/index.html). The documentation index provides access to the following C++ documents.

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

   example% CC -xhelp=readme

To access the HTML version of this readme, point your Netscape Communicator 4.0 or compatible browser to:

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

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



B. About Sun WorkShop 6 update 2 C++ Compiler

The Sun WorkShop 6 update 2 C++ (5.3) compiler runs on SPARC[tm] processors running Solaris[tm] SPARC Platform Edition, and Intel processors running Solaris Intel Platform Edition, versions 2.6, 7, and 8. Information unique to one or more platforms is identified as "(SPARC)" or "(IA)."

This 5.3 version of the C++ compiler is upwardly source-compatible and binary-compatible with C++ compiler versions 5.0, 5.1, and 5.2. That is, you can compile source code written for versions 5.0, 5.1, and 5.2 of the C++ compiler using the 5.3 C++ compiler. In addition, you can link object code that was generated by C++ compiler versions 5.0, 5.1, and 5.2 with object code that was generated by the 5.3 C++ compiler.

The 5.3 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.

Note-- You cannot link 4.2 and standard-mode C++ code together.

The C++ compiler is invoked by typing CC at a shell prompt.



C. New Features

This section describes the new and changed features for this release of the Sun WorkShop 6 update 2 C++ (5.3) compiler. In addition, it lists the new features that were introduced in the Sun WorkShop 6 and Sun WorkShop 6 update 1 releases.

See also the What's New in Sun WorkShop 6 update 2, which describes all the new features in the Sun WorkShop 6 update 1 release and in the Sun WorkShop 6 release. You can access this book by pointing your browser to http://docs.sun.com. Click Search Book Titles Only, and search for "What's New."

  1. Sun WorkShop 6 update 2 New Features
  2. Sun WorkShop 6 update 1 New Features
  3. Sun WorkShop 6 New Features


  1. Sun WorkShop 6 update 2 New Features

    The Sun WorkShop 6 update 2 C++ (5.3) compiler includes the following 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


  2. Sun WorkShop 6 update 1 New Features

    The following list summarizes the new and changed features that were introduced with the Sun WorkShop 6 update 1 C++ (5.2) Compiler. For a detailed explanation of these features, see What's New in Sun WorkShop 6 update 2. You can access this book by pointing your browser to http://docs.sun.com. Click Search Book Titles Only, and search for "What's New."



    Support for the UltraSPARC[tm] III Processor The -xtarget and -xchip options now accept ultra3.
    Compile-Time Performance The compiler is substantially faster for many large programs, particularly those that use templates heavily.
    Lifetime of Temporary Objects (Standard mode only) A new -features=tmplife suboption instructs the compiler to destroy temporary objects according to the requirements of the C++ standard.
    Overriding the Default Search Path With the -I- Option The new -I- option gives you more control over the algorithm that the compiler uses when searching for include files.
    Interval Arithmetic Support for C++ (SPARC platform) This release of the C++ compiler provides a C++ interface to the interval arithmetic library. Use the -xia and -library=[no%]interval options to access the interface.
    Mixed-Language Linking The new -xlang option enables you to link mixed Fortran and C++ object files.
    Enabling and Disabling Trigraph Recognition The new -xtrigraphs option enables and disables trigraph translation.
    Filtering Linker Error Messages The new -filt option allows you to customize the filtering of linker error messages. For example, you can request mangled names.
    Shared libCstd and libiostream Libraries Shared versions of libCstd and libiostream are available in the lib directory of the C++ compiler.
    Optimization Pragmas The C++ compiler recognizes the new optimization pragmas no_side_effect and returns_new_memory.
    Recognition of .c++ Extension The C++ compiler now recognizes .c++ as a valid filename suffix.
    Prefetch Latency Specifier The new -xprefetch=...,latx:<factor> suboption determines how far apart the instruction the compiler generates to prefetch data will be from the subsequent use of the data in a load or store instruction.


  3. Sun WorkShop 6 New Features

    The following list summarizes the new and changed features that were introduced with the Sun WorkShop 6 C++ (5.1) compiler. For a detailed explanation of these features, see Chapter 2 in What's New in Sun WorkShop 6 update 1. You can access this book by pointing your browser to http://docs.sun.com. Click Search Book Titles Only, and search for "What's New."



    Partial Specialization A template can 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.
    Explicit Function Template Argument If a template argument cannot be deduced from the function arguments, you can specify it explicitly using the syntax f<template args>(function args).
    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 ) { ... }
    Member Templates In standard mode, classes and class templates can have templates as members.
    Definitions-Separate Template Organization Restriction Removed The compiler no longer has a restriction against definitions-separate template organization for -instances != extern;

    • -instances=explicit
    • -instances=global
    • -instances=semiexplicit
    • -instances=static

    Regardless of the -instances setting, by default the compiler now includes separate source files in the search for definitions.
    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 the UltraSPARC II instruction set architecture (-xarch=v8plus, v8plusa, v8plusb, v9, v9a, or v9b).
    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.
    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.
    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.
    Using Your Own C++ Standard Library By specifying the -library=no%Cstd option, you can use your own version of the C++ standard library, instead of the version supplied with the compiler.
    Cache Versioning The C++ compiler has the ability to detect cache version differences and issue the appropriate error message.
    Restrictions on Bitfield Size Removed The restriction on the size of a bitfield to 32 or less is removed. Bitfields can be any size.


D. Software Corrections

This section discusses the following software corrections.

  1. Ambiguity: Constructor Call or Pointer-to-Function
  2. Empty Virtual Base Class Problem Fixed
  3. __ctype Not Defined Errors Fixed in Solaris 8 update 2 and Patch
  4. Support for -instance=static and -instance=semiexplicit With Static Variables Within Templates
  5. Different Behavior for Function-Local Static Variables for Extern Inline Functions
  6. Template Syntax Error is No Longer Ignored
  7. The -staticlib Option Now Works With -G
  1. Ambiguity: Constructor Call or Pointer-to-Function

    Some C++ statements could potentially be interpreted as a declaration or as an expression-statement. The C++ disambiguation rule is that if a statement can be declaration, it is a declaration.

    The 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
  2. Empty Virtual Base Class Problem Fixed

    In earlier versions of the compiler, a program might behave unpredictably if it had a complex class hierarchy that contained empty virtual base classes. The workaround was to add a data member to the empty virtual base class. This workaround is no longer necessary.

    This fix does not affect binary compatibility. You can still link old and new object files. If the code worked before, it will continue to work, even if you have recompiled just some of the modules.

    If your code did not work before because of this bug, you should recompile all modules that define or use any of the classes having empty virtual base classes.

  3. __ctype Not Defined Errors Fixed in Solaris update 2 and Patch

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

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

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

  4. Support for -instance=static and -instance=semiexplicit With Static Variables Within Templates

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

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

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

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

    one.cc

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

two.cc

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

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

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

  6. Template Syntax Error is No Longer Ignored

    The following template syntax has never been valid, but Sun C++ 4 and 5.0 did not report the error. The 5.1, 5.2, and 5.3 versions 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
  7. The -staticlib Option Now Works With -G

    Previously, the -staticlib option had no effect when building shared libraries. Now it does.



E. Problems and Workarounds

This section discusses the following software bugs that were not fixed in this release due to binary compatibility or other constraints. For updates, check the Forte Developer Hot Product News web page (http://www.sun.com/forte/developer/hotnews.html).

  1. Name Mangling Linking Problems
  2. Using make With Standard Library Header Files on Versions 2.6 and 7 of the Solaris Operating Environment
  3. Debugging Tools Erroneously Report Extra Leading Parameter for Member Functions
  4. Reference From Template to Non-Global File-Scope Object is Not Supported
  5. Standard Header Warning Messages
  6. #pragma align Inside Namespace Requires Mangled Names
  7. Function Overload Resolution
  8. Multithreaded C++ Programs Using Alternate Threads Hang When Debugged in Solaris 8 Operating Environment
  1. Name Mangling Linking Problems

    The following conditions may cause linking problems.

    • A function is declared in one place as having a const parameter and in another place as having a non-const parameter.

      Example:

        void foo1(const int);
  void foo1(int);

      These declarations are equivalent, but the compiler mangles the names differently. To prevent this problem, do not declare value parameters as const. For example, use void foo1(int); everywhere, including the body of the function definition.

    • A function has two parameters with the same composite type, and just one of the parameters is declared using a typedef.

      Example:

        class T;
  typedef T x;
  // foo2 has composite (that is, pointer or array)
  // parameter types
  void foo2(T*, T*)
  void foo2(T*, x*);
  void foo2(x*, T*);
  void foo2(x*, x*);

      All declarations of foo2 are equivalent and should mangle the same. However, the compiler will mangle 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 will be 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.

  2. Using make With Standard Library Header Files on Versions 2.6 and 7 of the Solaris Operating Environment

    The standard library file names do not have ".h" suffixes. Instead, they are named istream, fstream, and so forth. In addition, the template source files are named istream.cc, fstream.cc, and so forth.

    If, in the Solaris 2.6 or 7 operating environment, you include a standard library header in your program, such as <istream>, and your makefile has .KEEP_STATE, you will encounter problems. For example, if you include <istream>, make thinks that istream is an executable and uses the default rules to build istream from istream.cc resulting in very misleading error messages. (Both istream and istream.cc are installed under the C++ include files directory). Here are possible workarounds:

    • Use the -r option which disables the default make rules. This solution may break the build process.
    • Use the dmake utility in serial mode instead of make: dmake -m serial
    • Avoid the use of .KEEP_STATE.

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

    In compatibility mode (-compat=4), 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), there is no problem with mangled names. 

  4. Reference From Template to Non-Global File-Scope Object is Not Supported

    A program using templates and static objects causes link-time errors of undefined symbols. The compiler currently does not support reference to non-global file-scope objects from templates.

  5. Standard Header Warning Messages

    There are known problems with standard headers that cause lots of warnings when +w is used.

  6. #pragma align Inside Namespace Requires Mangled Names

    When you use #pragma align inside a namespace, you must use mangled names. For example, in the following code, the #pragma align statement has no effect. To correct the problem, replace a, b, and c in the #pragma align statement with their mangled names.

      namespace foo {
    #pragma align 8 (a, b, c)
    static char a;
    static char b;
    static char c;
  }
  7. Function Overload Resolution

    Earlier 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); // ambigous, "1" is type int
f1(1.0); // ambiguous, "1.0" is type double

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

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

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

    The operation is ambiguous because it can be resolved as

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

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

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

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

  8. Multithreaded C++ Programs Using Alternate Threads Hang When Debugged in Solaris 8 Operating Environment

    Multithreaded C++ programs built with alternate threads hang when you attempt to debug them in the Solaris 8 operating environment. 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=4 compiler option).

    In cases where alternate threads are being considered for performance tuning, it is strongly recommended that the multithreaded program first be debugged using the default thread library, and that alternate threads be used afterward.



F. Limitations and Incompatibilities 

1. C++ Shared Library Patch

A SUNWlibC patch is provided for each version of the Solaris Operating Environment supported by this Sun WorkShop 6 update 2 release on each of the supported platforms. Without these patches, some programs will not link and some programs will terminate in unusual ways due to runtime errors. For example, the linker may report a message similar to 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 WorkShop 6 update 2 release, see the Sun WorkShop 6 update 2 Release Notes. The release notes are available as a text file on the Forte Developer 6 update 2 CD at /cdrom/devpro_v9n1_<platform>/release_notes.txt (where <platform> is either sparc or intel). The release notes are also available at the Forte Developer Products Hot News web page (http://www.sun.com/forte/developer/hotnews.html).

2. Compiler Version Incompatibilities

The remainder of this section discusses the incompatibilities between Sun WorkShop C++ compiler versions 4.0, 4.1, 4.2, and the following versions:

  1. Cache Version Differences May Cause Compilation Errors
  2. C++ Interface Incompatibilities
  3. Using Tools.h++
  4. Using Multiple Template Repositories; -ptr Option Ignored
  5. Linking With 4.0.1 Libraries Containing Pointers to const Member Functions
  6. Linking With Libraries Compiled With Earlier Compilers
  7. Mixing Object Code From Different Versions
 
 
  1. Cache Version Differences May Cause Compilation Errors

    When changing compilers, it is always good practice to run CCadmin -clean on every directory that contains a SunWS_cache subdirectory (alternately, you can use rm -rf SunWS_cache). Failure to do so can result in compilation errors such as the following:

    • SunWS_cache: Error: Database version mismatch
      <path>/SunWS_cache/CC_version.

    • "<path>/SunWS_cache/CC_state",
      line 3: Error: "" not allowed here. ** Assertion ** : 0


  2. C++ Interface Incompatibilities

    The 5.0, 5.1, 5.2, and 5.3 versions of the C++ compiler are not binary compatible with versions 4.0, 4.1, and 4.2 of the C++ compiler unless the -compat option is used when compiling with the 5.0, 5.1, 5.2, or 5.3 compiler. The incompatibility is due to the changes in the class layouts, the calling sequences, and the way names are mangled to meet the requirements defined in the ANSI/ISO C++ Standard.

    The 5.0, 5.1, 5.2, and 5.3 versions of the C++ compiler are binary compatible.

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

  3. Using Tools.h++

    The C++ compiler now uses standard iostreams as the default. If you use Tools.h++ in standard mode, you must either use the -library=rwtools7_std option or include libiostream as shown in the following compiler option:

    example% CC -library=rwtools7_std foo.cc -> uses standard iostreams
example% CC -library=rwtools7,iostream foo.cc -> uses classic iostreams

    For more infomration, see Standard Iostreams Version of the Tools.h++ Library in section "F. New Features."

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

  4. Using Multiple Template Repositories; -ptr Option Ignored

    In compilers prior to C++ compiler 5.0, the -ptr flag was used to designate repositories for template instantiations. With the 5.0, 5.1, 5.2, and 5.3 versions of the C++ compiler, the -ptr flag is no longer required, as the compilation system reads from the template repositories corresponding to the object files that it reads, and writes template instances into the repository contained in the directory of the output location specified by the CC command.

    In this release, the -ptr option is obsolete and is ignored by the compiler. Even though the option is ignored, you should remove -ptr from all compilation commands because, in a later release, it may be reimplemented with a different behavior.

    Note -- Sharing a single template repository for more than one application or library has not been and is currently not supported. Attempting to do so can lead to compilation failure and unpredictable results at runtime because of template redefinitions.

  5. Linking With 4.0.1 Libraries Containing Pointers to const Member Functions

    The C++ 4.0.1 compiler generated different mangled names for pointers to const member functions than the C++ compiler versions 4.1, 4.2, 5.0, 5.1, 5.2, and 5.3 do. If you are using the Sun WorkShop 6 update 2 C++ compiler and you are unable to link with a library that was built with 4.0.1 and that contains such names, you should either recompile the library, or compile the rest of the program with the -compat -Qoption ccfe -abirel=4.0.1 flags.

    Note -- Future releases may not support the -abirel=4.0.1 flag.

  6. Linking With Libraries Compiled With Earlier Compilers

    The C++ 4.0.1 and C++ 4.1 compilers generated a mangled name that was unparsable for templates instantiated with an extern "C" function. As a consequence, debugging tools behaved incorrectly. We have corrected the problem, but some users may be unable to link objects that are compiled using versions 5.0, 5.1, 5.2, or 5.3 of the C++ compiler with libraries compiled with earlier compilers. This incompatibility should be extremely rare, but in the event that it does happen, you can either

    • Recompile the library with the Sun WorkShop 6 update 2 C++ (5.3) compiler, or
    • Compile the new objects using the Sun WorkShop 6 update 2 C++ (5.3) compiler with the -compat=4 and -Qoption ccfe -abirel=4.1 flags.

    Note -- Future releases may not support the -abirel=4.1 flag.

  7. Mixing Object Code From Different Versions

    You can mix object code from different versions of the Sun WorkShop C++ compiler in the same program, as long as you don't mix compatibility-mode and standard-mode code. However, you must link the final program using a compiler at least as new as the newest compiler version in the mix.

    Note-- You cannot link 4.2 and standard-mode C++ code together.



G. Documentation Errata 



There is no new information at this time.



H. Shippable Libraries



I. Standards Not Implemented



Copyright 2001 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303, U.S.A. All rights reserved. 

Sun, Sun Microsystems, the Sun logo, docs.sun.com, and Solaris are trademarks, registered trademarks, or service marks of Sun Microsystems, Inc. in the U.S. and other countries.