3 New Features of This Release
4 Known Problems and Workarounds
- 1 -
6.00 ANSI C Release Notes
- 2 -
Document Number 007-1659-010
1. Introduction
This document contains information about the
MIPSpro C compiler driver, preprocessors, and
front ends (both traditional and ANSI C). The
MIPSpro C compiler supports compilation in both
32-bit and 64-bit modes. Compilation in 32-bit
mode is fully compatible with the Irix 5.2
compilers. Compilation in 64-bit mode follows
the LP64 data type model, where long int and
pointer types are 64 bits wide. Utilities,
header files, and libraries common to several
languages are covered in Chapters 3 and 4 of the
6.0 Base Development Release Notes (accessed as
the compiler_dev release notes).
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 of This Release
4. Known Problems and Workarounds
In addition, Appendix A discusses dynamically
shared objects (DSOs).
1.1 Release_Identification_Information
Following is the release identification
information for ANSI C:
Software Option Product ANSI C
Version 6.0
- 3 -
Product Code SC4-IDO-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 North America and would like
support for your Silicon Graphics-supported
products, contact the Technical Assistance
Center at 1-800-800-4SGI.
If you are outside North America, contact the
Silicon Graphics subsidiary or authorized
distributor in your country.
- 1 -
6.00 ANSI C Release Notes
- 2 -
Document Number 007-1659-010
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 ANSI_C_Subsystems
This section lists the subsystems of the ANSI C
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 in inst to
customize the list of subsystems to be
installed, then select the ``go'' menu item.
c_dev.books.CLanguageRef Insight-readable
version of the compiler and
C programmer's reference
guide (default)
c_dev.man.c Manual page for the cc
driver (default)
c_dev.man.util Manual pages for C source
utilities - cflow, cb, etc.
(default)
c_dev.man.relnotes Online version of these
release notes (default)
c_dev.sw.c The C front ends and
preprocessors (default)
c_dev.src.acpp The C source for the ANSI
preprocessor acpp (default)
c_dev.sw.copt The C scalar optimizer
(default)
c_dev.hdr.lib copt-specific header files -
kapio.internal.h,
- 3 -
kapio.sgi.h (default)
c_dev.sw.lib opt-specific I/O archive for
shared compiles - libkapio.a
(default)
c_dev.sw.speclib copt-specific I/O archive
for non-shared compiles -
libkapio.a
c_dev.sw.util The C source utilities -
cflow, cb, etc. (default)
c_dev.man.copt The C scalar optimizer
manual pages (default)
2.2 Installation_Method
All of the subsystems for ANSI C can be
installed using IRIX. You do not need to use
the miniroot. Refer to the IRIS Software
Installation Guide for complete installation
instructions.
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.
2.3 Prerequisites
ANSI C 6.0 requires the installation of the IRIS
Development Option (compilers portion) release
6.0. For the compiler subsystems, refer to
Chapter 2 of the 6.0 Base Compiler Release
Notes.
2.4 Compatibility
ANSI C release 6.0 is a new compiler, which is
aimed primarily at software development for a
MIPS3 or MIPS4 instruction set architecture
(ISA) in 64-bit mode (-64), but with options to
compile for a MIPS1 or MIP2 ISA in 32-bit mode
(-32). Refer to the cc(1) man pages, the
MIPSpro Compiling, Debugging and Performance
- 4 -
Tuning Guide, the MIPSpro 64-Bit Porting and
Transition Guide, and the C Language Reference
Manual for a full description of the differences
between 32-bit and 64-bit compilation modes.
In 32-bit mode, the 6.0 release of the ANSI C
compiler is fully compatible with the aerlier
releases of the compiler.
In 64-bit mode, the 6.0 release of the ANSI C
compiler follows a new Applications Binary
Interface (ABI). Objects compiled in 64-bit
mode cannot be linked together with objects
compiled in 32-bit mode, and 64-bit objects will
only run in an Irix 6.0 operating system
environment. Objects compiled in 32-bit mode
will run in both an Irix 6.0 and an Irix 5.2
operating system environment.
- 1 -
6.00 ANSI C Release Notes
- 2 -
Document Number 007-1659-010
3. New_Features_of_This_Release
This chapter details significant changes between
the 3.18/3.19 and 6.0 C compiler releases. In
32-bit mode, there are no differences between
the 6.0 C compiler and the 3.19 C compiler, and
the following discussion only highlights
language and command-line differences between
32-bit mode (-32) and 64-bit mode (-64)
compilation.
Refer to the MIPSpro Compiling, Debugging nd
Performance Tuning Guide, the MIPSpro 64-Bit
Porting and Transition Guide, and the cc(1) man
pages for a full description of the differences
between 32-bit and 64-bit compilation.
o The 64-bit compiler employs the LP64 model,
in which pointers and long integral types
are 64 bits wide. This new language
semantics may require source modification
when porting old code to a 64-bit system.
Both NULL and size_t, among other types in
the standard header files, become 64 bits
wide in 64-bit mode.
o The new 64-bit ABI changes the subprogram
interface protocol in such a manner that
inconsistencies between the use and
definition of subprograms may produce
unpredictable results. Note: Always use a
prototyped function in the scope of a
correctly prototyped declaration of the
function, and never mix prototyped and
non-prototyped declarations for the same
function. The new ABI also resulted in
changes to the and
macros, which make them incompatible with
their -32 counterparts.
o The -64 compiler has a different front-end
and back-end from the -32 compiler, and the
supported cc command-line options vary
between the two modes of compilation. In
particular, the -wlint option is not
available in 64-bit mode; instead, it
provides a fuller set of diagnostics with
the -fullwarn option. Also, a variety of
- 3 -
new options are provided in -64 mode to
tailor optimizations for a particular
application. See the cc manual pages for
further details.
o The set of diagnostic message numbers (and
hence the application of the -woff
command-line option), are completely
diffirent for -64 and -32 mode.
o The 64-bit mode compiler allows inlining of
arbitrary or individually specified
functions, to a given depth of nesting, by
means of the front-end command-line options
-Wf,-inline (inline any function), -Wf,-
inline_depth=n (inline functions up to n
levels of nested calls; the default is
n==0), -Wf,-inline=F1:F2:...:Fn (inline
functions named F1, F2, ..., and Fn).
o An extended set of intrinsic functions are
supported in 64-bit mode. These are
indicated for a function op as:
#pragma intrinsic(op)
in , , , and
. The intrinsic functions in
and will only be
inlined in terms of more specialized
functions when the command-line option
-OPT:fast_io is used. Otherwise, the
handling of intrinsics is the same in 64-
bit mode as in 32-bit mode.
o In 64-bit mode, the "typedef" storage class
specifier cannot apply to a prototyped
parameter. In 32-bit mode this is allowed,
but with a warning and ambiguous semantics:
should we treat it as a typedef and a
parameter or exclusively one or the other?
Note that a typedef declaration in a list
of unprototyped parameter declarations is
acceptable in -cckr mode, both for 32-bit
and 64-bit compilations. (ANSI/ISO 9899-
1990: sections 6.7.1 and 6.5.4.3).
o Error diagnostics are issued for implicit
conversions between integral types and
pointer types, as well as between integral
types and struct types, in ANSI conformance
- 4 -
modes (-ansi, -xansi, -ansiposix). We have
no intention of allowing such (extremely
error-prone and non-portable) implicit
conversions in any ANSI conformance mode,
and the error diagnostics will indicate
source code that needs to be fixed. Note
that such implicit conversions may compile
with warnings instead of errors in -cckr
mode. The following will produce an error
message in all modes:
struct X {int i;} *j, *k;
main()
{
j = k?k:k?0:0;
}
since k?0:0 always will be considered an
int, as opposed to a ``null pointer''
expression, which is incompatible with the
pointer operand k.
There are also other differences in the
diagnostics provided in 32-bit versus 64-
bit mode, and we are generally a little
stricter in enforcing ANSI C rules in 64-
bit mode.
- 1 -
6.00 ANSI C Release Notes
- 2 -
Document Number 007-1659-010
4. Known_Problems_and_Workarounds
Unless otherwise indicated, the following bugs
in release 6.0 of the C compiler apply to both
traditional C and ANSI C.
4.1 Known_Problems_(64-Bit_Mode)
This section describes problems known to exist
in the 6.0 C compiler runnning in 64-bit mode.
4.1.1 Preprocessor
o A warning is issued about macro
redefinitions, even when the new definition
is lexically identical to the existing
(previous) definition.
4.1.2 Compiler
o For inlined functions, we generate code and
debugging information, even though the
function may be static and inlined at every
call site.
o We cannot completely turn off the warning:
"209116.c", line 4971: warning(1556): transfer of control bypasses
initialization of:
variable "count" (declared at line 5067)
goto try_autogrow;
with the -woff 1556 option, since the
message fragment:
variable "count" (declared at line 5067)
still will be output.
4.2 Known_Problems_(32-Bit_Mode)
This section describes problems known to exist
in the 6.0 C compiler runnning in 32-bit mode.
- 3 -
4.2.1 Preprocessor
o The following is permitted by the cfe
preprocessor:
#undef __STDC__
However, it should be illegal.
o The source location for ``f()'' in:
# /* some rather
lengthy
and multi-line
comment */
void f(void) {...}
will be wrongly perceived by cfe to begin
at the line where the comment starts, since
the "#" is assumed to be a line-directive
while the whole comment is viewed as a
single space within the line-directive.
This will cause dbx to list the wrong
source lines for statements in the body of
``f()''.
o The -wlint option causes an incorrect
``implicit type conversion'' warning when
an enumerator is assigned to an enumeration
variable, and may also cause incorrect
``used before set'' warnings for variables
in the controlling expressions of loops:
void
foo(int *head)
{
enum E {e1, e2, e3} c;
int *p, *nextp;
int i;
/* incorrect warning: "implicit conversion from int to enum" */
c = e1;
/* incorrect warning: "i may be used before set" */
do {i = *(p++);} while (!i);
/* incorrect warning: "nextp may be used before set" */
for (p = head; p; p = nextp) nextp = p;
}
- 4 -
o There is a problem with constant
propagation in the context of weakextern
definitions. For the source:
#include
extern int a;
#pragma weak a=b
int b = 3;
main()
{
a = 5;
printf("%d, %d", a, b);
}
the output when compiled without any
optimization (-O0) ``5, 5'', as expected,
while with optimization the output is ``5,
3''. The latter is a result of constant
propagation, which reduces the body of
``main()'' to:
printf("%d, %d", 5, b);
thus effectively eliminating the assignment
to ``a'' and its alias ``b''.
4.2.2 Compiler
o Signed and unsigned ``long long''
bitfields, spanning across a 32-bit (word)
aligned boundary, can only be accessed
through the ``.'' operator when the left-
hand side is an addressable lvalue. This
is a limitation of our compiler front-end
(cfe) implementation and cfe will emit
error messages when this constraint is
violated. In earlier versions of the
compiler, cfe terminated with an assertion
for such expressions.
o An indexing expression with a complicated
index expression may sometime generate
illegal ucode, which causes ugen to core
dump. A workaround is to move the index
expression out and assign it to a temorary
variable, or just change the expression.
The following illustrates the only known
case of this happening:
- 5 -
char board[19];
int capture[2];
setboard (int x)
{
capture[!(board[x])]++; /* Ugen coredumps on this! */
capture[(board[x])?0:1]++; /* This works just fine! */
}
o A standalone lint is available, but it does
not support the same options and
compilation modes supported by the C
compiler (it supports the the AT&T SVR4
compilation modes, and treats ``long long''
types as ``long''). Unless lint is used to
handle lint-directives, to provide lint2
diagnostics, or to produce the lint output
files, we instead strongly recommend use of
the -wlint option with the cc command.
This option works with all the other
compiler options and flags, including
compilation in ANSI mode. Note that -wlint
does not produce the traditional output
files from the lint passes, nor does it
handle lint directives, while it does
provide lint-like diagnostics.
4.3 Known Problems with Workarounds (64-Bit
Mode)
o Benchmarks using computational kernels that
operate on arrays with dimensions of a
modulus of the cache size can cause cache
line thrashing. This condition will usually
manifest in a program taking much longer to
compile than expected, and can be analyzed
further by monitoring system performance
statistics such as I/O use during
compilation. The remedy is to increase the
size of the array by a multiple of the
cache line size. Because cache line size
is fixed for each specific architecture,
check your hardware documentation to see
what applies for your system. (126115)
o The following will produce an error message
in -cckr mode:
- 6 -
struct X {int i;} *j, *k;
main()
{
j = k?k:k?0:0;
}
since k?0:0 is an int expression, and as
such is incompatible with k which is a
pointer. (224372)
4.4 Known Problems with Workarounds (32-Bit
Mode)
o In 3.17 and earlier versions of the
compiler, no diagnostics were emitted (by
default) in -cckr mode for a function
redeclaration with incompatible parameter
types. This could be highly error-prone,
since an argument could be passed to the
same function in differing ways, dependent
on which declaration were in scope at the
point of call. Consider the following
code:
#include
int f(float f1, float f2);
f(f1, f2)
float f1, f2;
{
printf("f1=%g, f2=%g0, f1, f2);
}
main()
{
f(17.17, 17.17);
}
The unprototyped function definition
expects float arguments to be promoted to
doubles (64 bits entities), while the call
in fact heeds the prototype and passes the
arguments as floats (32 bits entities).
The values printed will be unpredictable.
To avoid this kind of unexpected behaviour
we highly recommend that users compile
their code with -prototypes in -cckr mode.
For redeclarations, where references to
parameters in the function body may access
a different bit pattern than that passed on
the caller site (as in the above example),
we now issue an error in -cckr mode. Other
- 7 -
forms of incompatible redeclarations still
pass without any diagnostics. The old
(ccom) compiler sometimes succesfully
combined such incompatible redeclarations,
but not always. We therefore found it
sounder to disallow the most blatant forms
of mismatches in this version of the
compiler.
o Note that lint incorrectly diagnoses a
syntax error for the latter of the
following two declarations for
``XSynchronize'':
typedef int Display;
extern int (*XSynchronize(int*))();
extern int (*XSynchronize(Display*))();
The first form of declaration (without the
typedef) can be used as a workaround for
this particular problem.
o The compiler will incorrectly diagnose the
last of the initializers in the following
code fragment as an incorrect initializing
expression:
typedef unsigned int size_t;
typedef struct uacdef
{
unsigned int *uacind;
unsigned int *uacaln;
unsigned int *uacrcp;
unsigned int *uaccal;
} uacdef;
size_t uacsiz[] = {
(size_t)&(((uacdef*)0))->uacrcp,
(1&0x40 ? sizeof(uacdef) : (unsigned int)&(((uacdef*)0))->uacrcp),
(1&0x40 ? sizeof(uacdef) : (size_t)&(((uacdef*)0))->uacrcp)
};
The first two forms of initializers may be
used as a workaround for this problem.
o Benchmarks using computational kernels that
operate on arrays with dimensions of a
modulus of the cache size can cause cache
line thrashing. This condition will usually
manifest in a program taking much longer to
compile than expected, and can be analyzed
- 8 -
further by monitoring system performance
statistics such as I/O use during
compilation. The remedy is to increase the
size of the array by a multiple of the
cache line size. Because cache line size
is fixed for each specific architecture,
check your hardware documentation to see
what applies for your system. (126115)