Updated 2002/04/01

Forte[tm] Developer 7: C++ Compiler Readme

Contents

  1. Introduction
  2. About the Forte Developer 7 C++ Compiler
  3. New and Changed Features
  4. Software Corrections
  5. Problems and Workarounds
  6. Limitations and Incompatibilities
  7. Documentation Errors
  8. Shippable Libraries
  9. Standards Not Implemented

 

A. Introduction

This document contains information about the Forte[tm] Developer 7 C++ compiler. Throughout this document, the compiler is also referred to as version 5.4 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.

Information in the release notes updates and extends information in all readme files. To access the release notes and the complete Forte Developer documentation set, go to the documentation index at 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:

   CC -xhelp=readme

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

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

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

 

B. About the C++ Compiler

This release of the C++ compiler is available on the Solaris[tm] operating environment (SPARC[tm] Platform Edition) versions 7, 8, and 9.

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

The 5.4 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 C++ compiler. For information about other Forte Developer 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.

 

D. Software Corrections

This section discusses the following software corrections.

  1. Ambiguity: Constructor Call or Pointer-to-Function
  2. __ctype Not Defined Errors Fixed in Solaris 8 update 2 and Patch
  3. Support for -instance=static and -instance=semiexplicit With Static Variables Within Templates
  4. Different Behavior for Function-Local Static Variables for Extern Inline Functions
  5. Template Syntax Error is No Longer Ignored
  6. 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 a 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. __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> before including the header <stdlib.h>.

  3. 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, 5.3 and 5.4 versions of the C++ compiler.

  4. 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, 5.3 and 5.4 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.

  5. 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, 5.3, and 5.4 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
  6. 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 known software problems and possible workarounds for those problems. For updates, check Forte Developer Hot Product News at http://www.sun.com/forte/fcc/hotnews.html.

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

    If a function has a local variable of a type with a destructor, and if the function also has an omp parallel region containing a function call, the compiler aborts. The following example aborts upon compilation: 

    class A {
    public:
       ~A(){};
};

void bar();    // any function

void foo()
{
    A a;       // local variable having a destructor
    #pragma omp parallel
    {
        bar(); // function call in a parallel region
    }
}

example% CC try.cc -xO3 -xopenmp
compiler(iropt) error:  connect_labelrefs: undefined label L77000031
example%

    However, the workaround is to move the parallel region into a separate function.

    struct A {
    ~A() {}
};

void bar();    // any function

void workaround()
{
    #pragma omp parallel
    {
            bar(1);
    }
}

void foo()
{
    A a;
    workaround();
}
  2. Cross-Language Linking Error

    If you issue the -xlang=f77 command, the compilation process encounters a linker error. To avoid the error and still include the appropriate runtime libraries, issue -xlang=f77,f90 instead.

  3. Name Mangling Linking Problems

    The following conditions may cause linking problems.

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

      Example:

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

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

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

      Example:

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

      All declarations of foo2 are equivalent and should mangle the same. However, the compiler mangles some of them differently. To prevent this problem, use typedefs consistently.

      If you cannot use typedefs consistently, a workaround is to use a weak symbol in the file that defines the function to equate a declaration with its definition. For example:

      #pragma weak "__1_undefined_name" = "__1_defined_name"

      Note -- Some mangled names are dependent on the target architecture. (For example, size_t is unsigned long for the SPARC V9 architecture, and unsigned int otherwise.) In such a case, two versions of the mangled name are involved, one for each model. Two pragmas must be provided, controlled by appropriate #if directives.

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

  4. Using make With Standard Library Header Files on Version 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 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.

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

    In compatibility mode (-compat), the C++ compiler incorrectly mangles the link names for pointers to member functions. The consequence of this error is that the demangler, and hence some debugging tools, like dbx and c++filt, report the member functions as having an extra leading parameter consisting of a reference to the class type of which the function is a member. To correct this problem, add the flag -Qoption ccfe -abiopt=pmfun1. Note, however, that sources compiled with this flag may be binary incompatible with sources compiled without the flag. In standard mode (the default mode), there is no problem with mangled names. 

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

  7. #pragma align Inside Namespace Requires Mangled Names

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

      namespace foo {
    #pragma align 8 (a, b, c)
    static char a;
    static char b;
    static char c;
  }
  8. 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); // ambiguous, "1" is type int
f1(1.0); // ambiguous, "1.0" is type double

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

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

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

    The operation is ambiguous because it can be resolved as

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

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

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

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

  9. Multithreaded C++ Programs Using Alternate Threads Hang When Debugged in 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 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 

This section discusses limitations and incompatibilities with systems or other software.

  1. Incompatiblity between -xia and -library=stlport4

    You cannot use C++ interval math with the STLport C++ library. A program using the -xia option can be compiled and linked only as documented in the C++ Interval Arithmetic Programming Reference.

  2. C++ Shared Library Patch

    A SUNWlibC patch is provided for each version of the Solaris Operating Environment supported by this Forte Developer 7 release on each of the supported platforms. 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::basic_ostream<char,std::char_traits<char> >&operator<<(td::basic_ostream<char,std::char_traits<char> >&,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 Forte Developer release, see the Forte Developer 7 Release Notes. The release notes are available as a text file on the Forte Developer 7 CD at /cdrom/devpro_v10n1_sparc/release_notes.txt. The release notes are available through the documentation index page on the Forte Developer 7 web site at http://www.sun.com/forte/fcc/documentation.

  3. 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:

    • Sun WorkShop C++ (5.0) compiler
    • Forte Developer 6 C++ (5.1) compiler
    • Forte Developer 6 update 1 C++ (5.2) compiler
    • Forte Developer 6 update 2 C++ (5.3) compiler
    • Forte Developer 7 (5.4) compiler
    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, 5.3, and 5.4 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, 5.3, or 5.4 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, 5.3, and 5.4 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

      However, in compatibility mode (with the -compat compiler option), you cannot issue -library=rwtools7_std because the standard library is not available:

      example% CC -compat foo.cc -> compatibility mode, standard library not available

      Do not issue -library=rwtools7, -library=rwtools7_dbg, -library=rwtools7_std, or -library=rwtools7_std_dbg with -library=stlport4. Tools.h++ is not supported with STLport.

      The binaries produced by the options -library=rwtools7_std and -library=rwtools7,iostream are not compatible. If you use one of these options, you should use the same option to compile all source files.

      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, 5.3, and 5.4 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. See the C++ User's Guide for more information.

    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, 5.3, and 5.4 do. If you are using the 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, 5.3, or 5.4 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 Forte Developer 7 C++ (5.4) compiler, or
      • Compile the new objects using the Forte Developer 7 C++ (5.4) compiler with the -compat 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 Forte Developer 7 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 Errors 

 

H. Shippable Libraries

 

I. Standards Not Implemented 

 

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