This chapter describes the Silicon Graphics C++ compiler environment and contains the following major sections:
“Silicon Graphics C++ Environment” discusses the different Silicon Graphics C++ compilers for IRIX 6.0 and 5.3 systems.
“Comparing CC to cfront” compares the Silicon Graphics C++ to other C++ environments.
“Using the Compilers” discusses the differences between the 32- and 64-bit versions of the Silicon Graphics compilers, shows the command lines for the compilers, and gives some examples of typical command lines.
“cfront Compatibility” discusses the restrictions on C++ code that are enforced by the Silicon Graphics C++ environment, but were not enforced by cfront.
“C++ Libraries” discusses the C++ libraries in the Silicon Graphics C++ environment.
“Debugging” discusses the Silicon Graphics C++ debugging environment.
The Silicon Graphics C++ environment is available in two varieties, targeted for IRIX 6.0 and 5.3 systems. The 6.0 32-bit compiler and the 5.3 compiler are functionally identical. See Figure 1-1 for details.
 | Note: CC -64, the 64-bit version of the CC compiler, can only be run on 6.0–based systems. |
As shown in Figure 1-1, there are 32- and a 64-bit versions of the C++ compiler for the IRIX 6.0 operating system. For completeness and backwards-compatibility, the old Silicon Graphics C++ compiler (OCC), based on cfront, is still available. The supported C++ compilers for the 6.0 system are listed below:
| CC | 64- and 32-bit native C++ compiler. | |
| OCC | 32-bit C++ compiler, based on C++ to C translation using cfront. |
On 64-bit hardware, CC generates 64-bit code by default (without using the –64 extension explicitly), while on 32-bit hardware, it generates 32-bit code by default.
There are also two versions of the C++ compiler for the 5.3 operating system: CC and DCC. Again, for completeness and backwards-compatibility, the old Silicon Graphics C++ compiler (OCC), based on cfront, is still made available. The supported C++ compilers for the 5.3 system are listed below:
| CC | 32 bit native C++ compiler. Functionally identical to 6.0 32–bit CC. | |||
| DCC | Delta/C++ compiler. The delta feature enables you to use dynamic classes to minimize the need for recompilation upon changing a class, thereby greatly increasing productivity. For complete information on DCC, see Chapter 4, “DCC: the Delta/C++ Compiler.”
| |||
| OCC | 32-bit C++ compiler, based on C++ to C translation using cfront. |
For complete details on cfront compatibility, see “cfront Compatibility”. For further details on the commands themselves, refer to the CC(1), OCC(1), and DCC(1) reference pages.
There are a number of advantages to using the new compilers instead of cfront.
CC is a native compiler that is a drop-in replacement for cfront. This is a major advantage, as cfront first translates C++ code to C, and then compiles the C code.
For instance, OCC (previously CC) runs cpp, then cfront (the C++ front end) on the C++ source to produce C source code. Then the cc command is invoked on the C code, which invokes cfe (the C front end). CC just runs edgcpfe, the C++ front end, which does its own preprocessing.
Preprocessing, which is normally invoked as a separate process by OCC, is built into the CC front end (edgcpfe). This eliminates the overhead of an entire preprocessing step and the cost of launching a separate process.
In addition, debugger support is much easier, since a native compiler can generate a richer set of symbolic debugger information than cfront.
Template instantiation in current C++ systems is frequently laborious. For example, cfront saves information about each file it compiles in a special directory and instantiates nothing during normal compilations. At link time, it looks for entities that are referenced but not defined and whose names indicate that they are template entities. cfront then consults the special directory to find the file containing the source for the entity and compiles the source to generate an object file containing object code for that entity. This object code for instantiated objects is then combined with the “normal” object code in the link step.
CC instantiates template functions within your source files. For initial compilations, this makes no difference. For subsequent rebuilds, this reduces the time required to instantiate templates during the link phase and may prevent additional compilations, significantly improving compile-time performance. (cfront builds each template function in a separate object file, and the time required to compile each object file is significant.)
CC diagnoses several non-standard constructs quietly accepted by cfront, and fixes many cfront defects. Use CC to avoid cfront compiler bugs and for stricter adherence to C++ standards.
| Note: Exception handling is not supported in CC. CC will optimize to –O2 only (-O2 and -O are equivalent). OCC supports no exception handling. |
This section discusses how to use the Silicon Graphics compilers to compile your C++ programs. It describes the differences between the 64- and 32-bit versions of the compiler, describes the CC and OCC command lines (and some of the more commonly used options), and contains some examples.
The default compiler depends on your hardware: on 64-bit systems, CC defaults to -64 mode; on 32-bit systems, CC defaults to -32 mode. If you use CC with options supported by OCC but not supported by standard CC, or you use CC with the -use_cfront option, you invoke OCC.
The 64- and 32-bit versions of CC are both native compilers that are based on the same front end. The CC -64 front end is fecc, which has 64-bit pointers, addresses, and long ints. The CC -32 front end is edgpcfe, a front end with 32–bit pointers, addresses, and long ints.
| Note: 64-bit objects are incompatible with 32-bit objects, and they cannot be linked together. 64-bit objects can only be created on 6.0-based systems. You can do this as follows: |
Specify the -64 option on the IRIX 6.0 command line to compile source files for 64-bit objects. With -mips4, this is the default for the MIPSpro compilers installed on an IRIX 6.x system
Specify the -32 option on the IRIX 6.0 command line to compile source files for 32-bit objects. With -mips1, this is the default for the MIPSpro compilers installed on an IRIX 5.x system.
A compilation on an IRIS 5.3 (and later) system always produces 32-bit objects. The compiler back-end (optimizer and code generator) is different in -32 and -64 modes.
Some additional differences between the 64- and 32-bit version of CC are listed below.
CC -64 and CC -32 support different template instantiation options.
The warning options used by the -woff option are different in CC -64 and CC -32.
Refer to MIPSpro Compiling, Debugging, and Performance Tuning for a more complete discussion on how to set up the IRIX environment for -32 versus –64 compilers. Refer to the MIPSpro Porting and Transition Guide for further information on -64 compilers.
The command line for CC is shown below.
CC [ option ] . . . file . . . |
CC compiles with many of the same options as cc(1). CC -64 is the default on 6.x (64-bit) systems, and CC -32 is the default on 5.x (32-bit) systems.
| Note: cfront compatibility mode is disabled by default when you compile in 64-bit mode. |
See the CC(1) reference page for more information.
DCC [ option ] ... file ... |
| Note: DCC is supported only in IRIS 5.3 systems, and in 32-bit mode only. |
DCC compiles with many of the same options as cc and CC. See the DCC(1) reference page for supported and unsupported CC options.
By default, DCC does not enable dynamic classes. You can make your classes dynamic
selectively or for all classes defined in the current directory
selectively or for all classes defined in the current hierarchy
selectively or for all classes defined in the source code
For complete details on dynamic classes, see “Dynamic Classes”.
The command line for compiling with cfront is shown below.
OCC [ option ] . . . file . . . |
You may also use the following command line:
CC -use_cfront [ option ] . . . file . . . |
For complete information on all the options available with OCC, see the OCC(1) reference page.
Some typical C++ compiler command lines are given below.
To suppress the loading phase of your compilation and compile only one program, the command line is the following:
CC -c program
To compile with full warning about questionable constructs, the command line is the following:
CC -fullwarn program1 program2 . . .
To compile with warning messages off, the command line is the following:
CC -w program1 program2 . . .
To compile in 64-bit mode with cfront compatibility enabled, the command line is the following:
CC -64 -use_cfront program1 program2 . . .
To compile in 32-bit mode with cfront compatibility disabled, the command line is the following:
CC -32 +p program1 program2 . . .
To compile with delta capability and the Smart Build facility, the command line is
DCC -smart program1 program2 . . .
(For information on Smart Build, see “Smart Build,” in Chapter 4.)
The Silicon Graphics compilers (with the exception of OCC) force you to adhere to C++ code standards more strictly than cfront does. Code that you compiled successfully with cfront may not compile under the Silicon Graphics C++ environment, even in cfront compatibility mode. You must compile with OCC to get exact cfront compatibility. This section discusses cfront compatibility restrictions when compiling with CC.
For examples of code that were valid under the cfront environment but are invalid in the Silicon Graphics C++ environment, see “cfront Compatibility Examples”. Specific examples are cited in the following list of restrictions.
In some cases, the Silicon Graphics C++ compilers are not backwards-compatible with cfront because cfront has defects, behaves in a non-deterministic manner, or fails to adhere to the standard. The C++ incompatibilities that cfront ignores but the Silicon Graphics compilers catch are listed below:
If a C++-style (//) comment line is terminated with a backslash, the Silicon Graphics compiler will (correctly) continue the comment line into the next source line. (cfront, which uses the standard UNIX cpp, incorrectly terminates the comment at the end of the line.) See Example 6-1.
You must have an explicit declaration of a constructor or destructor in the class if there is an explicit definition of it outside the class. See Example 6-2.
You may not delete a pointer to a const. See Example 6-3.
You may not pass a pointer to volatile data to a function that is expecting a pointer to non-volatile data. See Example 6-4.
The Silicon Graphics compiler does not disambiguate between overloaded functions with a char* and long parameter, respectively, when called with an expression that is a 0 cast to a char type. See Example 6-5.
You may not use redundant type specifiers. See Example 6-6.
When in a conditional expression, the Silicon Graphics compiler does not convert a pointer to a class to an accessible base class of that class. See Example 6-7.
You may not assign a 0 to a pointer, if the 0 is the right-expression of a comma operator. See Example 6-8.
You must not use the same identifier for more than one formal argument in a function definition.
The Silicon Graphics compiler will mangle member functions declared as extern “C” differently from cfront. CC does not strip the type signature when you are building the mangled name. If you try to do so, you will see the following warning:
Mangling of classes within an extern “C” block does not match cfront name mangling.
You may not be able to link code containing a call to such a function with code containing the definition of the function that was compiled with cfront.
cfront incorrectly strips the “signed” keyword whenever it encounters a signed declaration (for example, signed char), and mangles the resulting name accordingly. The generated object file contains a different name for member functions with parameters having this type.
The Silicon Graphics compiler does not do this, so if the definition of such a member function is compiled with cfront, and a call to it is compiled by the Silicon Graphics compiler, the code will not link. If you try to do so, you will see the following warning:
Mangling of signed character does not match cfront name mangling.
You must compile both the definition and the call with the Silicon Graphics compiler. If you do not have access to the source file defining the function, modify the declaration of the function in its header file by removing the signed keyword, or replacing it with an unsigned keyword.
cfront also removes declarations that include “const”.
By default, all C++ programs link with the standard library libC.so. This library contains all the iostream library functions, as well as the C++ storage allocation functions ::new and ::delete.
Silicon Graphics also provides the complex arithmetic library libcomplex.a. If you want to use this package you must explicitly link with this library. For example,
CC complexapp.c++ –lcomplex |
See the C++ Language System Library for more information on the complex and iostream libraries.