- 1 -
6.0 C++ Compiler Release Notes
- 2 -
________________________________________________
Contributors:
Engineering contributions by John Wilkinson, Andy Palay, Shankar Unni,
Michey Mehta, Anil Pal, Ravi Shankar, Roy Mittendorff, Rune Dahl and
Chandrasekhar Murthy
________________________________________________
c Copyright 1992-1994, Silicon Graphics, Inc. - All rights reserved
This document contains proprietary information
of Silicon Graphics, Inc. The contents of this
document may not be disclosed to third parties,
copied, or duplicated in any form, in whole or
in part, without the prior written permission of
Silicon Graphics, Inc.
Restricted Rights Legend
Use, duplication, or disclosure of the technical
data contained in this document by the
Government is subject to restrictions as set
forth in subdivision (c) (1) (ii) of the Rights
in Technical Data and Computer Software clause
at DFARS 52.227-7013, and/or in similar or
successor clauses in the FAR, or the DOD or NASA
FAR Supplement. Unpublished rights reserved
under the Copyright Laws of the United States.
Contractor/manufacturer is Silicon Graphics,
Inc., 2011 N. Shoreline Blvd., Mountain View, CA
94039-7311.
6.0 C++ Compiler Release Notes
- 3 -
Document Number 007-1606-010
Silicon Graphics, Inc.
Mountain View, California
Silicon Graphics and IRIS are registered
trademarks and IRIX, Graphics Library, IRIS
POWER Series, and Personal IRIS are trademarks
of Silicon Graphics, Inc.
1. Introduction
The Silicon Graphics C++ Compiler is an
environment for compiling programs written in
the C++ programming language. This environment
allows access to standard IRIX features and to
the Graphics Library.
NOTE: This release of the compiler is based on a
new C++ compiler frontend from the Edison
Design Group. There are really two
compilers: a 32-bit version, which is
invoked when any of the options -32,
-mips1, or -mips2 is specified on the
command line; and a 64-bit version, which
is invoked otherwise. The 32-bit version
is based on release 2.19 of the Edison
frontend; the 64-bit versions is based on
relase 2.22. The old frontend, based on
release 3.0.1 of the USL C++ Translator,
is also available by specifying the
options -32 -use_cfront.
Please read Chapter 3 carefully for a
description of the differences between the old
compiler and the new one, especially section 3.4
that deals with the new template instantiation
mechanism.
The C++ Compiler product includes:
o CC, the C++ compiler driver (not to be
confused with cc).
o fecc, the 64-bit C++ compiler frontend.
o edgcpfe, the 32-bit C++ compiler frontend.
o The utilities edg_prelink, c++patch and
c++filt.
- 4 -
o For users wishing to use the old frontend,
cfront, a language translator for C++-to-C
translation, and the utilities markc++,
ptcomp, and ptlink.
o The libraries libcomplex.a, and
libmangle.a.
o Include files specific to C++.
o Online manual page for CC(1).
o Online release notes for CC(1).
o C++ Programmer's Guide, which includes the
hard-copy CC(1) manual page.
The C++ library /usr/lib/libC.so is installed in
the subsystem c++_eoe.sw.lib. This allows
application libraries written in C++ to be used
on systems that do not have C++ installed. Note
that this library is now a dynamic shared object
and is not an archive. There is also a non-
shared archive form of the library,
/usr/lib/nonshared/libC.a.
Note: Packaged with this software is a separate
sheet that contains the Software License
Agreement. This software is provided to
you solely under the terms and conditions
of the Software License Agreement.
Please take a few moments to review the
Agreement.
This document contains the following chapters:
1. Introduction
2. Installation Information
3. New Features for This Release
4. Known Problems and Workarounds
1.1 Release_Identification_Information_
Following is the release identification
information for 6.0 C++ Compiler.
C++ Compiler
- 5 -
Software Option Product
- 6 -
Version 6.0
Product Code SC4-C++-6.0
Software Requirements IRIX 6.0
IRIS Development
Option 6.0
1.2 Online_Release_Notes
After you install the online documentation for a
product (the relnotes subsystem), you can view
the release notes on your screen.
If you have a graphics system, select ``Release
Notes'' from the Tools submenu of the Toolchest.
This displays the grelnotes(1) graphical browser
for the online release notes. Refer to the
grelnotes(1) man page for information on options
to this command.
If you do not have a graphics system, you can
use the relnotes command. Refer to the
relnotes(1) man page for accessing the online
release notes.
1.3 Product_Support
Silicon Graphics, Inc., provides a comprehensive
product support maintenance program for its
products.
If you are in the U.S. or Canada and would like
support for your Silicon Graphics-supported
products, contact the Technical Assistance
Center at 1-800-800-4SGI.
If you are outside the U.S. or Canada, contact
the Silicon Graphics subsidiary or authorized
distributor in your country.
- 1 -
6.0 C++ Compiler Release Notes
- 2 -
________________________________________________
Contributors:
Engineering contributions by John Wilkinson, Andy Palay, Shankar Unni,
Michey Mehta, Anil Pal, Ravi Shankar, Roy Mittendorff, Rune Dahl and
Chandrasekhar Murthy
________________________________________________
c Copyright 1992-1994, Silicon Graphics, Inc. - All rights reserved
This document contains proprietary information
of Silicon Graphics, Inc. The contents of this
document may not be disclosed to third parties,
copied, or duplicated in any form, in whole or
in part, without the prior written permission of
Silicon Graphics, Inc.
Restricted Rights Legend
Use, duplication, or disclosure of the technical
data contained in this document by the
Government is subject to restrictions as set
forth in subdivision (c) (1) (ii) of the Rights
in Technical Data and Computer Software clause
at DFARS 52.227-7013, and/or in similar or
successor clauses in the FAR, or the DOD or NASA
FAR Supplement. Unpublished rights reserved
under the Copyright Laws of the United States.
Contractor/manufacturer is Silicon Graphics,
Inc., 2011 N. Shoreline Blvd., Mountain View, CA
94039-7311.
6.0 C++ Compiler Release Notes
- 3 -
Document Number 007-1606-010
Silicon Graphics, Inc.
Mountain View, California
Silicon Graphics and IRIS are registered
trademarks and IRIX, Graphics Library, IRIS
POWER Series, and Personal IRIS are trademarks
of Silicon Graphics, Inc.
2. Installation_Information
This chapter lists supplemental information to
the IRIS Software Installation Guide. The
information listed here is product-specific; use
it with the installation guide to install this
product.
2.1 C++_Compiler_Subsystems
Following is a description of the C++ Compiler
subsystems:
c++_dev.sw.c++ The C++ compiler
c++_dev.sw.lib C++ demangling and
complex libraries
c++_dev.sw.libns Non_shared C++
runtime library
c++_dev.hdr.lib Standard C++
header files
c++_dev.man.c++ Man pages for C++
and the standard
C++ header files
c++_dev.man.relnotes These release
notes
c++_dev.books.c++LangSysOverview C++ Language
System Overview
c++_dev.books.c++Lang_System_Lib C++ Language
System Library
c++_dev.books.C++Product_Ref The C++ Language
System Product
Reference Manual
- 4 -
c++_dev.books.c++_PG C++ Language
System
Programmer's Guide
2.2 C++_Compiler_Subsystem_Disk_Use
This section lists the subsystems (and their
sizes) of the C++ Compiler option.
If you are installing this option for the first
time, the subsystems marked ``default'' are
those that are installed if you use the ``go''
menu item. To install a different set of
subsystems, use the ``install,'' ``remove,''
``keep,'' and ``step'' commands to customize the
list of subsystems to be installed, then select
the ``go'' menu item.
Subsystem Name Subsystem Size
(512-byte blocks)
c++_dev.sw.c++ (default) 7916
c++_dev.sw.lib (default) 1340
c++_dev.sw.libns (default) 396
c++_dev.hdr.lib (default) 97
c++_dev.man.c++ (default) 449
c++_dev.man.relnotes (default) 152
c++_dev.books.C++LangSysOverview 3384
c++_dev.books.C++Lang_System_Lib 1152
c++_dev.books.C++Product_Ref 3285
c++_dev.books.C++_PG 478
2.3 Installation_Method
All of the subsystems for the C++ Compiler can
be installed using inst from IRIX.
The procedure for installing the CROSS64
development option (to be installed from the 6.0
IDO CD-ROM onto a machine running 5.2 IRIX) is
specialized. For the details of this procedure,
consult the 6.0 IRIX Development Option release
notes. For information about using the CROSS64
development option, see the release notes for
the 6.0 Baae Compiler Development Option.
- 5 -
2.4 Compatibility
2.4.1 Compatibility_with_C++_3.2.1
The C++ 6.0 compiler operating in 32-bit mode is
fully link-compatible with code compiled with
C++ 3.2.1, with the following exceptions:
2.4.1.1 Signed_char_parameters
Due to a bug in C++ 3.2.1, signed char
parameters were mangled into the function name
as plain char. If you have such a function, and
the caller and callee are compiled with
different compilers (3.2.1 versus 6.0), the
resultant program will not link. To fix this,
change the parameter type to a plain char, or
recompile both caller and callee with the same
compiler.
2.4.1.2 Stricter_error_checking_than_3.2.1
The C++ 6.0 compiler is much stricter in its
enforcement of the C++ language as described by
the The Annotated C++ Reference Manual (Margaret
Ellis and Bjarne Stroustrup, Addison-Wesley
1990), far more so than even C++ 3.2.1. Some
code changes may be required to correct
previously uncaught errors in the code.
2.4.1.3 Template_mechanism_differences
The template instantiation mechanism is quite
different in the two compilers. Normally, this
is hidden from the user, at least for
straightforward links. However, the use of
archives and DSOs (Shared Libraries) exposes
this mechanism to the user, and Makefiles will
have to be migrated to move from C++ 3.2.1 to
C++ 6.0.
Please see Chapter 5, on Templates, for the
pitfalls in mixing 3.2.1 and 6.0 compiled
objects with templates, and the steps required
for migrating to the new compiler.
- 6 -
2.4.2 Compatibility_with_C++_2.1.1
Some source code that compiled correctly under
C++ 2.1.1 must be changed to compile under C++
6.0, and some code compiled under C++ 2.1.1 must
be recompiled to link successfully with code
compiled under C++ 6.0. The following sections
list the differences between version 3.x and
version 2.1.1 that affect compatibility:
2.4.2.1 Nested_Classes
C++ versions 3.0 and later support true nesting
of classes, enumerations, and unions, as
specified in the C++ Product Reference Manual.
An enumeration declared within a class, for
example, is not recognized outside the class
declaration unless it is qualified by the class
name. For example:
class X {
enum E {...
};
E e; // OK in 2.1.1; error in 3.0 or later; should be X::E e;
2.4.2.2 Stricter_Error_Checking
C++ 3.0 and later enforce the The Annotated C++
Reference Manual (Margaret Ellis and Bjarne
Stroustrup, Addison-Wesley 1990) more strictly
than C++ 2.1.1 did, so some code that does not
conform to the ARM and that compiled under C++
2.1.1 might fail to compile under C++ 3.0 and
later.
2.4.2.3 Linkage_Directives
The #pragma linkage directive is no longer
supported.
2.4.3 Compatibility_with_C++_3.0
2.4.3.1 Header_Files
The header files /usr/include/CC/osfcn.h and
/usr/include/CC/libc.h used to contain
prototypes for standard IRIX functions. These
files now consist entirely of #include
directives. This should improve compatibility
across releases. On the other hand, it results
- 7 -
in including prototypes for many more functions,
and might cause new name-space collisions in
some cases.
2.4.3.2 No_C++-2.1_Compatibility_Mode
The -v2 option is no longer supported. All
source code must now conform to the syntax and
semantics of C++ 3.x as defined in the C++
Product Reference Manual.
2.4.4 Compatibility_with_C++_3.1
2.4.4.1 Overloaded increment and decrement
operators
The overloaded increment and decrement operators
are now supported in both prefix and suffix form
as described in the ARM. As a result, the
suffix forms now require an extra int parameter
in their prototypes. For example:
class C {
public:
C& operator++(); // should be operator++(int)
};
main()
{
C c;
...
c++; // Accepted by version 3.1 but not by version 3.2 or 6.0
}
2.5 C++_Compiler_Files
After installing the C++ Compiler, you should
have the following files:
/usr/bin/CC C++ compiler
driver
/usr/lib/64bit/cmplrs/fecc The 64-bit
compiler
frontend
/usr/lib/64bit/cmplrs/be The 64-bit
compiler
backend
- 8 -
/usr/lib/DCC/edgcpfe The 32-bit
compiler
frontend
/usr/lib/DCC/edg_prelink The "prelinker"
which controls
template
instantiation.
/usr/lib/c++/c++patch C++ post-
processor
/usr/include/CC C++ include
file directory
/usr/lib/libcomplex.a C++ complex
math library
/usr/lib/c++/libmangle.a C++ name-
demangler
library
/usr/lib/c++/c++filt C++ name-
demangling
utility
/usr/catman/u_man/cat1/CC.z C++ compiler
driver manual
page
/usr/relnotes/CC C++ Release
Notes directory
/usr/lib/c++/cfront The old C++
Translator, for
use with
-use_cfront
/usr/lib/c++/markc++ The old utility
to identify C++
files for
dbx(1)
/usr/lib/c++/ptcomp Old tool for
Template
support for
cfront
/usr/lib/c++/ptlink Old tool for
Template
support for
- 9 -
cfront
Note that the C++ library /usr/lib/libC.so is
installed from the subsystem c++_eoe.sw.lib.
This allows application libraries written in C++
to be used on systems that do not have C++
installed.
2.6 C++_Compiler_Documentation
Silicon Graphics has produced the following C++
Compiler documentation:
o CC(1) man page (printed and online version)
o 6.0 C++ Release Notes (this online
document)
- 1 -
6.0 C++ Compiler Release Notes
- 2 -
________________________________________________
Contributors:
Engineering contributions by John Wilkinson, Andy Palay, Shankar Unni,
Michey Mehta, Anil Pal, Ravi Shankar, Roy Mittendorff, Rune Dahl and
Chandrasekhar Murthy
________________________________________________
c Copyright 1992-1994, Silicon Graphics, Inc. - All rights reserved
This document contains proprietary information
of Silicon Graphics, Inc. The contents of this
document may not be disclosed to third parties,
copied, or duplicated in any form, in whole or
in part, without the prior written permission of
Silicon Graphics, Inc.
Restricted Rights Legend
Use, duplication, or disclosure of the technical
data contained in this document by the
Government is subject to restrictions as set
forth in subdivision (c) (1) (ii) of the Rights
in Technical Data and Computer Software clause
at DFARS 52.227-7013, and/or in similar or
successor clauses in the FAR, or the DOD or NASA
FAR Supplement. Unpublished rights reserved
under the Copyright Laws of the United States.
Contractor/manufacturer is Silicon Graphics,
Inc., 2011 N. Shoreline Blvd., Mountain View, CA
94039-7311.
6.0 C++ Compiler Release Notes
- 3 -
Document Number 007-1606-010
Silicon Graphics, Inc.
Mountain View, California
Silicon Graphics and IRIS are registered
trademarks and IRIX, Graphics Library, IRIS
POWER Series, and Personal IRIS are trademarks
of Silicon Graphics, Inc.
3. New_Features_for_This_Release
This chapter lists the changes to the C++
compiler from the previous version (3.2.1) of
this compiler. Section 3.5 has a very brief
summary of the additions from C++ 2.1.1 to C++
3.2.1 and C++ 6.0.
3.1 New_Native_C++_Compiler
C++ 6.0 is a new native C++ compiler for Irix
6.0. This compiler is based on a different
frontend (one from the Edison Design Group) than
the previous releases (which were based on USL's
cfront), and bypasses the generation of C
intermediate code.
Among the changes to be expected in this
compiler are:
o Much tighter error checking than cfront
(see section 3.2 below).
o A couple of obscure link compatibility
changes (related to name mangling - see
section 3.3 below).
o A different template instantiation
mechanism, which has less overhead and is
easier to use with libraries. (see section
3.4 below).
NOTE: The previous compiler (the Cfront-based
translator that was shipped with C++ 3.2.1)
is still available in this release, by
specifying the -use_cfront and -32 options
to CC, or by setting the environment
variable USE_CFRONT to 1 before executing
the compiler and specifying the -32 option.
- 4 -
Thus, users who need to continue compiling with
the old Translator can do so by globally setting
this environment variable for their builds.
Also, in case of specific incompatibilities (see
section 3.3 below) that cannot be worked around,
individual compilation units can be compiled
with the old translator by using the -use_cfront
option to get the old name mangling for those
types.
WARNING: We are only continuing to ship the old
translator as a way to allow a phased
migration to the new compiler. In a
future release of this compiler, the
translator will be removed.
- 5 -
3.2 Source Compatibility with C++ 3.2.1
(tighter error checking)
Source changes may be necessitated if your C++
source code contains any of several errors not
caught by C++ 3.2.1.
In each of the sections below, the errors shown
are not caught by C++ 3.2.1 (known as Cfront in
the text below), but are caught by C++ 6.0.
3.2.1 //_Comments_ending_in_a_\
There is a serious bug in preprocessor in C++
3.2.1, where C++-style comments ending in a "\"
are not continued to the next line.
If you depend on this bug, and have "real" code
in the line following such a line, C++ 6.0 will
treat this line as a part of the preceding
comment, causing syntax errors in the best case,
and obscure runtime bugs in the worst case.
For example, the following code will have a very
hard-to-detect bug:
...
// Increment the counter \
i++; // silently swallowed by C++ 6.0
...
The workaround is to remove the trailing "\" in
the // comment. A good way to scan for such
errors is to run the following command on your
source files:
% grep '//.*\\\\$'
and then edit them to remove the trailing "\".
- 6 -
3.2.2 Defining implicitly declared copy
constructors
Cfront allows you to define an implicit copy
constructor, even if you have not explicitly
declared it in the class declaration. This is an
error, that C++ 6.0 will catch and reject.
For example:
class Test {
protected:
virtual void func(); // causes implicit declaration of
// copy constructor
int x;
};
Test::Test(const Test& p) { x = p.x; } // Error
The workaround, of course, is to explicitly
declare the copy constructor in the class before
defining it.
3.2.3 Duplicate_parameter_names
C++ 6.0 does not allow you to use duplicate
parameter names for a function, even if it's
just a declaration.
For example, C++ 6.0 will reject the following:
extern void compare(char *s, char *s); // Error
Use different names for the paramteres.
3.2.4 Mismatched pointer types in conditional
(?:) expressions
Cfront allows the two branches to have different
pointer types, if the types they point to are
related to each other by inheritance. C++ 6.0
does not allow this, requiring the user to
explicitly cast one of the operands.
For example:
- 7 -
class A { };
class B : A { };
A *a;
B *b;
... test ? a : b ... // error
... test ? (B *)a : b ... // correct
3.2.5 0-valued comma expression treated as a
constant 0
C++ 6.0 does not consider the following
assignment valid, though Cfront did:
Type *ptr;
ptr = (expr1, 0); // error
ptr = (Type *) (expr1, 0); // correct
In order to be treated as a NULL pointer of the
correct type, the 0 must be a naked, unadorned
0, not the last term in a comma expression.
3.2.6 Deleting_a_const_pointer
C++ 6.0 does not allow you to delete a const
pointer. Cfront allows you to do this in certain
circumstances, like a member of a class that is
a const pointer to the same type.
- 8 -
class Foo {
public:
~Foo();
protected:
const Foo *next;
};
Foo::~Foo()
{
delete next; // Error
delete (Foo *)next; // OK
}
3.2.7 Assigning a pointer to volatile to a
pointer to non-volatile
Cfront essentially ignores the volatile
qualifier when doing assignment compatibility
checks, but C++ 6.0 enforces it strictly.
For example:
void main()
{
volatile int *a = 0;
int *b;
b = a; // Error
b = (int *)a; // OK
}
3.2.8 Ambiguity resolution for char constants
against long and void * parameters
Given an overloaded function, whose variants
take either a long or a void * (or any pointer),
Cfront incorrectly disambiguates to the long
variant when the function is called with a char
or short constant equal to 0, or with an
unsigned 0 (0U).
C++ 6.0 correctly points out this ambiguity. The
workaround is to explicitly cast the constant to
(long) (if that is what is desired).
- 9 -
extern void foo(void *);
extern void foo(long);
void main()
{
foo('\0'); // Error
foo((long)'\0'); // OK
foo(0U); // Error
foo((long)0U); // OK
}
3.2.9 Redundant_type_specifiers
C++ 6.0 will reject redundant type specifiers
like const.
For example:
typedef const int Int;
const Int p; // Error: == const const int p;
The workaround is to delete the redundant
specifier.
3.2.10 Syntax or semantic errors in the FALSE
portion of constant conditionals
Cfront has a surprising "feature" that if you
have an if statement (or other conditional) with
a constant test expression, then the code in the
FALSE part of the conditional is not checked for
semantic errors, like undeclared identifiers or
assignment mismatches.
C++ 6.0, on the other hand, will catch these
errors and report them at compile time.
For example:
- 10 -
char *p;
if (0) {
p = 1; // Error: type mismatch
q = x; // Error: undeclared identifiers
}
The workaround, naturally, is to fix the code in
the FALSE part of the conditional (or remove it
entirely by, for instance, surrounding it with
an #if 0 / #endif pair).
- 11 -
3.3 Link Compatibility with C++ 3.2.1 (tighter
error checking)
There are a couple of places where the name
mangling used by C++ 6.0 does not quite match
that of C++ 3.2.1 (cfront). One of these is due
to a fix for a bug in cfront.
3.3.1 Name_mangling_for_signed_char_parameters
Cfront used to drop the signed in signed char,
both in the intermediate code (which is
absolutely incorrect, since a plain char is
unsigned on SGI systems), and in the mangled
function name, if it had a signed char as a
parameter.
C++ 6.0 preserves the signed both in the
intermediate code and in the signature.
One consequence of this is that if you have a
function declared with a signed char parameter,
and the caller and callee are compiled with
different flavors of C++ (6.0 .vs. 3.2.1), then
the program will not link.
The workaround for this is to make sure that all
the callers and the callee are compiled with the
same function.
If this is not possible, then if the caller is
compiled with C++ 6.0, you can change the
parameter type to plain char (which will match
the callee anyway, given the above C++ 3.2.1
bug), and the program will link and run
correctly. However, we strongly discourage
this..
NOTE: When C++ 6.0 comes across such a parameter
(a signed char or a const signed char), it
emits a warning about this fact:
"test.c", line 1: warning(3672): Mangling of signed character
does not match cfront name mangling.
extern void func(signed char p);
^
This warning can be suppressed with the
-woff 3672 option.
- 12 -
3.3.2 Name mangling for extern ``C'' member
functions
If you declare a class inside an extern "C"
block, Cfront does not append the parameter
signature to the member functions (though it
does append the class name).
C++ 6.0 does nothing of the sort (i.e. it
mangles such functions normally).
This is one case where there is no workaround,
if you wish the caller and callee code to be
compiled with different compilers - you must
compiler both with the same compiler.
- 13 -
3.4 New_Template_Mechanism
C++ 6.0 comes with a new template instantion
mechanism that is different from the one used by
cfront. In 64-bit mode, no automatic
instantiation mechanism is currently available;
template definitions must be present in every
translation unit that requires their
instantiation. The following is a concise
description of the template mechanism for the
32-bit compiler. For more details on the
template mechanisms for both 32-bit and 64-bit
compilers, see the C++ Programmer's Guide.
3.4.1 Description_of_new_template_mechanism
In place of a user-specifiable ptrepository
directory, and a defmap file to record
information about templates, required
instantiations and include files (the cfront
way), the new compiler spreads this information
around.
C++ 6.0 does not have a ptrepository directory
(or even an equivalent). Instead, most of the
information about templates is incorporated as
special symbols in the object files themselves.
The new model is based on recording which
templates need to be instantiated in each
compilation unit into permanent files in the
directories where the objects are created, and
on subsequent compiles, even after a make clean,
the instantiations are created during the
compile.
In each directory where an object (.o) file is
created, the compiler creates a directory called
ii_files, which contain a number of .ii
files, one for each object .o.
These files only record which instantiations
need to be created during the compile. The first
time around, these files are essentially empty
(containing only a compilation command and
working directory). During the first link, a
program called edg_prelink scans all the object
files, looking for templates that need to be
instantiated, and for compilation units that can
do this instantiation (all this information is
embedded in the object files).
- 14 -
It then assigns each instantiation to an object
file that can instantiate it (writing this into
the .ii file corresponding to that object), and
fires off compiles for each object file for
which it added such a line.
This process may be repeated a few times
initially, until everything has been
instantiated.
On subsequent compiles, even if you remove all
the object files (as long as the .ii files are
left around), the compiler will instantiate
everything it needs in the first compile,
leaving no work to be done during the prelink
phase. This speeds up compiles enormously.
If, at any stage, a prelink detects the presence
of a new use of a template, it will do the above
steps with the .ii file(s) and recompile any
such affected objects.
3.4.2 Compatibility with cfront-compiled
templates
The two mechanisms are somewhat incompatible in
that C++ 6.0 will not see template
instantiations created by the old cfront, and
vice versa (they store the information about
template instantiations in different locations).
If you mix and match compilers, the program will
in all probability still link and run, though
you may end up with some unnecessary code bloat.
However, there may be situations in which
necessary instantiations may not be created. If
this happens, please recompile the compilation
units which are capable of instantiating those
templates using the new compiler.
3.4.3 Migrating_to_the_new_template_mechanism
There isn't much effort involved, usually.
Most of the old -pt* are ignored by the new
compiler. Occasionally a warning is emitted if
equivalent functionality (like the -ptr option)
is not present in the new compiler.
- 15 -
The source setup can be more or less the same as
for cfront: if you have separate template body
source files, keep them in the same directory as
the template header files (or anywhere else in
the include search path), and the compiler will
automatically find them and include them.
NOTE: It is important to protect even the body
files against multiple inclusion, since the
compiler may attempt to automatically
include these body files more than once (if
they contain more than one template
definition). You can achieve this using the
classic idiom:
#ifndef _BODY_FILE_C_
#define _BODY_FILE_C_ 1
... body of file ...
#endif
where "_FILE_H" is some unique identifier,
one per file.
3.4.4 Libraries_and_templates_in_C++_6.0
C++ 6.0 will automatically instantiate any
template instances used in a shared library,
without any effort on the part of the
programmer. Just link a DSO (see appendix A)
with the -shared, and the prelinker will be run
automatically.
If you want to keep instantiations unique across
DSOs (i.e. have only a single instantiation of a
particular template with a particular parameter
across all your DSOs), make sure you specify the
all the libraries when linking your DSO. E.g.
if lib1.so has an instantion of Stack, and
you want lib2.so to use the one in lib1.so,
specify lib1.so in the link line for lib2.so.
Archives (.a's) are *slightly* trickier, though
they are a *vast* improvement over cfront.
Before running ar to archive the objects, run
the prelinker over them as follows:
/usr/lib/DCC/edg_prelink
- 16 -
where is a list of any
libraries that may contain instantiations that
can be used in this archive (so that we don't
have to re-instantiate them).
Then proceed with the archive. Thus, a sample
make rule can be:
libfoo.a: $(OBJECTS) $(OTHERLIBS)
/usr/lib/DCC/edg_prelink $(OBJECTS) $(OTHERLIBS)
$(AR) cruv libfoo.a $(OBJECTS)
This even, for the first time, allows you (if
you don't specify any other libraries in the
edg_prelink argument list) to create (and
distribute) completely self-contained archive
libraries (at least, as far as templates go), so
that you don't have to distribute template body
files to instantiate the libraries' templates
for each program linked against it.
This last is especially important if your
libraries (that use templates) are also callable
from C programs..
3.4.5 Template-related_options_in_C++_6.0
New options are as follows:
-ptused Instantiate any templates that are used,
regardless of wherever else they may be
installed. In C++ 6.0, such multiple
instantiations do not cause a problem: they
are emitted in a way that the linker can
ignore duplicates for these instantiations,
and even, in most cases, remove duplicate
code.
-ptall Same as above, except that if any member
of a class is instantiated, instantiate all
member functions for that parameter type.
Old cfront options are as follows:
-ptr This option is ignored with a
warning, since there is no repository in
C++ 6.0.
- 17 -
-pte<.extension> This option is quietly ignored:
the compiler automatically searches for
files with different extensions: .c, .C,
.cpp, .CPP, .cxx, .CXX, .cc and .c++.
-pta Same as -ptall.
-ptl Ignored with a warning, there is no
ptrepository to lock.
-ptn Same as for Cfront
-ptv Same as for Cfront
-pts Ignored with a warning, meaningless for new
mechanism.
These options, and the template mechanism, are
explained in more detail in the C++ Programmers
Guide manual.
- 18 -
3.5 Changes_and_Additions_from_C++_2.1.1
This chapter lists the changes to the C++
Translator since Version 2.1.1.
3.5.1 Support_for_Templates
C++ 3.2.1 and C++ 6.0 provide support for
templates, as described in Chapter 14 of the C++
Product Reference Manual.
Please read chapter 4 for a concise summary of
the template instantiation mechanisms in C++
3.2.1 and C++ 6.0.
3.5.2 Support_for_Dynamic_Shared_Objects
It is now possible to make dynamic shared
objects (DSOs) from C++ object files, even when
run-time initialization is required. To make a
DSO instead of an executable file, use the
-shared option on the CC command line.
- 1 -
6.0 C++ Compiler Release Notes
- 2 -
________________________________________________
Contributors:
Engineering contributions by John Wilkinson, Andy Palay, Shankar Unni,
Michey Mehta, Anil Pal, Ravi Shankar, Roy Mittendorff, Rune Dahl and
Chandrasekhar Murthy
________________________________________________
c Copyright 1992-1994, Silicon Graphics, Inc. - All rights reserved
This document contains proprietary information
of Silicon Graphics, Inc. The contents of this
document may not be disclosed to third parties,
copied, or duplicated in any form, in whole or
in part, without the prior written permission of
Silicon Graphics, Inc.
Restricted Rights Legend
Use, duplication, or disclosure of the technical
data contained in this document by the
Government is subject to restrictions as set
forth in subdivision (c) (1) (ii) of the Rights
in Technical Data and Computer Software clause
at DFARS 52.227-7013, and/or in similar or
successor clauses in the FAR, or the DOD or NASA
FAR Supplement. Unpublished rights reserved
under the Copyright Laws of the United States.
Contractor/manufacturer is Silicon Graphics,
Inc., 2011 N. Shoreline Blvd., Mountain View, CA
94039-7311.
6.0 C++ Compiler Release Notes
- 3 -
Document Number 007-1606-010
Silicon Graphics, Inc.
Mountain View, California
Silicon Graphics and IRIS are registered
trademarks and IRIX, Graphics Library, IRIS
POWER Series, and Personal IRIS are trademarks
of Silicon Graphics, Inc.
5. Known_Problems_and_Workarounds
The C++ 6.0 compiler implements the C++ language
as described in The Annotated C++ Reference
Manual (Margaret Ellis and Bjarne Stroustrup,
Addison-Wesley 1990), without, however, the
exception handling feature described in Chapter
15 of that book. The current compiler does not
reflect any of the changes to the language
adopted by the ANSI C++ Standards Committee
since the publication of The Annotated C++
Reference Manual.
- 1 -
4.0 C++ Compiler Release Notes
- 2 -
Document Number 007-1606-010
________________________________________________
Contributors:
Engineering contributions by John Wilkinson, Andy Palay, Shankar Unni,
Michey Mehta, Anil Pal, Ravi Shankar, Roy Mittendorff, Rune Dahl and
Chandrasekhar Murthy
________________________________________________
c Copyright 1992-1994, Silicon Graphics, Inc. - All rights reserved
This document contains proprietary information
of Silicon Graphics, Inc. The contents of this
document may not be disclosed to third parties,
copied, or duplicated in any form, in whole or
in part, without the prior written permission of
Silicon Graphics, Inc.
Restricted Rights Legend
Use, duplication, or disclosure of the technical
data contained in this document by the
Government is subject to restrictions as set
forth in subdivision (c) (1) (ii) of the Rights
in Technical Data and Computer Software clause
at DFARS 52.227-7013, and/or in similar or
successor clauses in the FAR, or the DOD or NASA
FAR Supplement. Unpublished rights reserved
under the Copyright Laws of the United States.
Contractor/manufacturer is Silicon Graphics,
Inc., 2011 N. Shoreline Blvd., Mountain View, CA
94039-7311.
- 3 -
3.0 C++ Translator Release Notes
Document Number 007-1606-010
Silicon Graphics, Inc.
Mountain View, California
Silicon Graphics and IRIS are registered
trademarks and IRIX, Graphics Library, IRIS
POWER Series, and Personal IRIS are trademarks
of Silicon Graphics, Inc. C++ Translator is a
trademark of AT&T.
1. Dynamic_Shared_Objects
A Dynamic Shared Object, or DSO, is an ELF
format object file, very similar in structure to
an executable program but with no "main". It
has a shared component, consisting of shared
text and read-only data; a private component,
consisting of data and the GOT (Global Offset
Table); several sections that hold information
necessary to load and link the object; and a
liblist, the list of other shared objects
referenced by this object. Most of the libraries
supplied by SGI are available as dynamic shared
objects.
A DSO is relocatable at runtime; it can be
loaded at any virtual address. A consequence of
this is that all references to external symbols
must be resolved at runtime. References from
the private region (.e.g. from private data) are
resolved once at load-time; references from the
shared region (e.g. from shared text) must go
through an indirection table (GOT) and hence
have a small performance penalty associated with
them.
Code compiled for use in a shared object is
referred to as Position Independent Code (PIC),
whereas non-PIC is usually referred to as non-
shared. Non-shared code and PIC cannot be mixed
in the same object.
At Runtime, exec loads the main program and then
loads rld, the runtime linking loader, which
finishes the exec operation. Starting with
main's liblist, rld loads each shared object on
the list, reads that object's liblist, and
repeats the operation until all shared objects
- 4 -
have been loaded. Next, rld allocates common
and fixes up symbolic references in each loaded
object. (This is necessary because we don't
know until runtime where the object will be
loaded.) Next, each object's init code is
executed. Finally, control is transferred to
"__start".
For a more complete discussion of DSOs,
including answers to questions frequently asked
about them, see the dso(5) man page.