NAME
cc - CONVEX C compiler
SYNOPSIS
cc [option ...] file ... [-link loader_option ...]
DESCRIPTION
cc is the CONVEX C compiler. It accepts several types of
arguments:
Filenames whose names end with ".c" or ".C" must be C
source programs. They are compiled and each object
program is placed in a file in the current directory
with the same root name as the source filename and a
suffix of ".o". For example, compiling /x/y/z.c will
place the object code in ./z.o.
Filenames which end with ".s" must be assembly source
programs and are assembled, producing a ".o" file.
Other files can be object files or libraries; they are
passed to ld to be linked together with the objects
from all compilations and assemblies. If a single
source file is compiled and loaded by a cc command, the
".o" file is deleted.
COMPATIBILITY
The CONVEX C compiler operates in one of four compatibility
modes.
-ext This mode provides an extended implementation of ANSI C
and an ANSI C and POSIX compatible library system.
This is the default.
-std This option causes the compiler to operate as an ANSI C
conforming compiler. Certain extensions, notably the
long long type, are not available in this mode. When
linking occurs in this mode an ANSI C and POSIX P1003.1
conforming library system is used; many of the exten-
sions provided by the default library system are not
available.
-str This option causes the compiler to operate as an ANSI C
conforming compiler and to attempt to detect features
of the program which cause it not to conform to ANSI
Standard C. When linking occurs in this mode, only the
functions defined by ANSI Standard C are available.
-pcc Forces language and library interpretation based on the
original Kernighan and Ritchie definition, the Common C
Compiler, and other traditional operating systems.
This mode is compatible with CONVEX C V3.0 and other C
compilers previously shipped by CONVEX.
These options are interpreted before all others, regardless
of their position on the command line.
OPTIMIZATION OPTIONS
There are two versions of the C compiler available: one that
is capable of only scalar optimizations and another that can
perform scalar, vector, and parallel optimizations. The
former is available on all CONVEX computer systems, while
the latter is an optional product available only to licensed
sites. You can determine which product you have by attempt-
ing to compile a program with the -O2 option. An error mes-
sage will be generated if you do not have the fully optimiz-
ing version.
-alias standard
-alias cautious
-alias worst
The -alias option affects the assumptions the compiler
makes regarding overlapping of variables, particularly
when referenced by a pointer. standard causes the com-
piler to assume the program obeys the ANSI C standard.
worst causes the compiler to do worst case alias
analysis; it assumes that a pointer may reference any
piece of memory other than an auto variable whose
address has never been taken. cautious causes the com-
piler to behave as it does for standard except when
casts between pointer types are seen. In that case it
behaves like worst.
Incorrect code may be generated if the implied condi-
tions do not hold.
When the -pcc flag is provided, worst is the default,
otherwise, the default is cautious.
-alias array_args
Assume that formal array parameters do not overlap each
other or any external variable that is used in the
function (unless all uses are read-only). Incorrect
code will be generated if this assumption is not true.
This conflicts with the language definition, but may
allow greater optimization, particularly vectorization,
to occur.
This option may not be used if the formal parameter
itself is assigned by the function (e.g., formalParame-
ter = &x[10]); assignments may be made to the elements
of the formal (e.g., formalParameter[10] = x[10]).
-alias ptr_args
Assume that the variables identified by formal pointer
parameters do not overlap each other or any external
variable that is used in the function (unless all uses
are read-only). Incorrect code will be generated if
this assumption is not true. This conflicts with the
language definition, but may allow greater optimiza-
tion, particularly vectorization, to occur.
This option may not be used if the formal parameter
itself is assigned by the function (e.g., formalParame-
ter = &x[10]); assignments may be made to the elements
of the formal (e.g., formalParameter[10] = x[10]).
-alias restrict_args
This option tells the compiler to treat the code as
though a restrict qualifier was applied to each pointer
parameter. The restrict qualifier tells the compiler
that a pointer provides exclusive access to the data
object at a given memory location. When you use the
restrict qualifier, you must access the object pointed
to by a restrict pointer only through that pointer. If
you reference the object by some other means, the com-
piler may incorrectly optimize code as a result.
-ds Causes the compiler to perform dynamic selection on
loops selected by the compiler on the basis of profita-
bility. Multiple copies of the loop running sequen-
tial, vector or parallel modes are generated; the
optimal version gets executed based on the trip count
of the loop. This option is only effective at optimi-
zation level -O2 and -O3.
-ep n
Specifies the expected number of processors that will
execute the program. Optimizes single-program perfor-
mance at the expense of overall system throughput. The
n argument must be within the range of 1 and maximum
number of processors available on the target machine
architecture. This option is ignored if paralleliza-
tion is not requested.
-except precise
-except default
The -except options concern the treatment of arithmetic
exceptions generated within functions. The command line
options are -except precise and -except default.
The -except precise option generates code that ensures
that any arithmetic exceptions generated within func-
tions before the return will be received by the pro-
gram. Without -except precise, there is a small possi-
bility that the location of an arithmetic exception
might be reported incorrectly or lost.
The code generated under -except precise is specific to
the target architecture for which you are compiling and
is only guaranteed to work for that architecture. The
target architecture is determined by the -tm option,
or, in absence of -tm, defaults to the machine on which
you are compiling.
Use -except precise only when absolutely necessary as
it causes additional instructions to be inserted before
every return, and this will degrade performance.
-except default cancels the effects of -except precise.
This is provided mainly for overriding an -except pre-
cise supplied in the CCOPTIONS environment variable.
-no No machine-independent optimization is performed; this
is the default but can be overridden by the -O options.
-nopeel
Disallows loop boundary value peeling, which is turned
on by default at optimization levels -O2 and -O3. Refer
to -peel and -peelall below. Refer also so the subsec-
tion, ``Loop Boundary Value Peeling,'' below.
-noptst
Disallows test promotion, which is turned on by default
at optimization levels -O2 and -O3. Refer to -ptst and
-ptstall below. Refer also to the subsection, ``Test
Promotion,'' below.
-nptr
Disable procedural pointer tracking. Pointer tracking
reduces aliasing on pointers by keeping track of the
possible objects that each pointer could reference.
Pointer tracking is performed at optimization levels
-O1 and above.
-On Performs machine-independent optimizations, level n,
where:
n=0 selects basic block scalar optimization;
n=1 selects -O0 plus function-wide scalar optimization;
n=2 selects -O1 plus vectorization;
n=3 selects -O2 plus parallelization.
-peel
Causes removal of the first and/or last iterations of a
loop when doing so removes conditional tests from the
loop. This is typically possible when the loop contains
a test that always evaluates to zero or a nonzero value
for the first and/or last iteration. By default, the
compiler peels boundary values and expands code up to a
limit. With the -peel option, this limit is increased
and code expansion may become significant. The -peel
option works only with the -O2 and -O3 options. Refer
to the subsection, ``Loop Boundary Value Peeling,'' for
more information.
-peelall
Same as -peel, but allows code expansion without bound.
For code containing large numbers of boundary value
operations, this can increase the size of the code
enough to flag compile-time errors. The -peelall option
works only with the -O2 and -O3 options. Refer to the
subsection, ``Loop Boundary Value Peeling,'' for more
information.
-ptst
Causes a test to be promoted out of the loop that
encloses it by replicating the containing loop for each
branch of the test. By default, the compiler will
replicate code up to a limit. With the -ptst option,
this limit is increased and code expansion may become
significant. The -ptst option works only with the -O2
and -O3 options. Refer to the subsection, ``Test Promo-
tion,'' for more information.
-ptstall
Same as -ptst, but allows code replication without
bound. For loops containing large numbers of tests,
this can increase the size of the code beyond the capa-
bilities of the compiler enough to flag compile-time
errors. The -ptstall option works only with the -O2 and
-O3 options. Refer to the subsection, ``Test Promo-
tion,'' for more information.
-rl This option is equivalent to -ds -ur. It is only
effective with options -O2 and -O3.
-uo Performs potentially unsafe optimizations, i.e., may
move the evaluation of common subexpressions and/or
invariant code from within conditionally executed code.
The code is then executed unconditionally.
-ur Causes the compiler to perform loop unrolling on loops
selected by the compiler on the basis of profitability.
This option is only effective at optimization levels
-O2 and -O3.
-va A synonym for -alias array_args.
Loop Boundary Value Peeling
Test-loop optimizations modify loops containing tests to
improve vector performance. Tests can be promoted out of the
loops or completely eliminated. By minimizing the number of
tests within a loop, the compiler reduces the number of
masked vector instructions that must be executed, thereby
improving performance.
One type of test-loop optimization is loop boundary value
peeling. This involves removing the first and/or last itera-
tions of a loop when doing so removes conditional tests from
the loop. This is typically possible when the loop contains
a test condition for the first and/or last iteration.
For example:
Original Loop:
for( i=0; i<100; i++ )
if( i == 0 ){
a[i] = b[i];
} else if( i == 99 ){
a[i] = c[i];
} else {
a[i] = -a[i];
}
Peeled Loop:
a[0] = b[0];
for( i=1; i<98; i++ )
a[i] = -a[i];
a[99] = c[99];
In the above example, the compiler automatically peels off
the first and last tests and rewrites the loop to cover the
remaining indices.
In some cases, boundary value peeling requires relocating
large amounts of code and can greatly increase the size of
the executable file. By default, the compiler peels boundary
values and expands the code up to a limit; you can increase
this limit by using the -peel option. You can allow the com-
piler to expand code without bound by using the -peelall
option. In codes containing large numbers of boundary value
operations, allowing code expansion without bound can
greatly lengthen compile time and can increase the size of
the code enough to flag compile-time errors under certain
circumstances.
Boundary value peeling can be shut off completely with the
-nopeel option.
NOTE. Loop boundary value peeling is not performed on loops
with no tests on boundary values. In other words, the com-
piler will not try to peel unpeelable loops.
Test Promotion
A second type of test-loop optimization is test promotion.
This involves promoting a test out of the loop that encloses
it by replicating the containing loop, or loops, for each
branch of the test. The replicated loops contain fewer tests
than the originals (or no tests at all), so they execute
much faster. Multiple tests can be promoted, with loop
replications made for each. For example:
Original Loop:
for( i=0; i<100; i++ )
if( val )
a[i] = b[i];
else
a[i] = c[i];
Promoted Test:
if( val )
for( i=0; i<100; i++ )
a[i] = b[i];
else
for( i=0; i<100; i++ )
a[i] = c[i];
It is important to note that, for loops containing large
numbers of tests, this loop replication can greatly increase
the size of the code.
The amount of code replication and test promotion can be
controlled with compiler options; by default, the compiler
promotes tests and replicates code up to a conservative
limit. The -ptst option increases this limit and can cause a
noticeable increase in compile time. The -ptstall option
promotes all tests regardless of code replication. This may
cause a large increase in compile time and can increase the
size of the code enough to flag compile-time errors. The
-noptst option shuts test promotion off.
CODE GENERATION OPTIONS
-asm This flag is silently ignored; it is no longer
required.
-c Do not run the linker. The object module generated
from x.c or x.s is left in x.o.
-compat rrf=stack
-compat rrf=old
The -compat option controls backward compatibility
options. The rrf= selection controls the return
mechanism used by record returning functions. Records
are either structures or unions. In the old method,
the default, the called function allocates memory for
the record that is being returned. In the stack method,
the calling function allocates memory for the record
that is being returned. The two methods are not compa-
tible with each other. The old method can produce
incorrect results in some circumstances. You can use
the -d record_fn_defn=w and -d record_fn_call=w diag-
nostic message control options to identify program con-
structs that are affected by this change.
-extern distinct
-extern same
The -extern option may be used to control the interpre-
tation of a program in which different files declare an
uninitialized variable (e.g., "int i;") at file scope.
When same is used both files refer to the same vari-
able. This is the default in all modes, is traditional
on BSD Systems and is a conforming extension to Stan-
dard C. When distinct is used the files refer to dis-
tinct variables; this results in a multiply defined
symbol being detected by the linker. This is the
definition provided by the ANSI C standard.
-fd A synonym for -float sp_ops, described below.
-fi Translate floating-point constants to IEEE format and
perform floating-point operations in IEEE mode. This
option requires that the machine be equipped with IEEE
floating-point hardware. If no floating-point format
is specified, the site default is used. Arithmetic
performed under this option does not conform to the
IEEE standard.
-float sp_ops
-float dp_ops
-float sp_const
-float dp_const
These options control the floating-point system used by
the compiler. sp_ops and dp_ops control the precision
of the operations performed on float operands. When
sp_ops is specified, 32 bit operations are performed.
When dp_ops is specified, the float operands are con-
verted to double and 64 bit operations are performed.
sp_ops generally causes programs using float variables
to run faster but some accuracy may be lost.
sp_const and dp_const control the representation of
unsuffixed floating-point constants (which are normally
represented in double precision). sp_const causes
these constants to be represented in single precision.
Some loss of accuracy may result. dp_const explicitly
invokes the default.
Use of sp_ops is more effective when combined with
sp_const since expressions like x == 0.0 are performed
in double precision when only sp_ops is specified.
sp_ops is the default in all but -pcc mode.
dp_const is the default in all modes.
-fn Translate floating-point constants to native CONVEX
format and perform floating-point operations in native
mode. If no floating-point format is specified, the
site default is used.
-mi n
Specifies the expected memory interleave on the target
machine. n is an integer representing the expected
memory interleave. When this option does not appear,
the interleave of the machine the compiler is running
on is used. You can use the getsysinfo command to
determine the memory interleave on a machine.
-parens ignore
-parens explicit
-parens implicit
Toggle the manner in which parentheses and the ANSI C
grammar are used to determine the order of evaluation
of expressions.
The value ignore gives the compiler freedom to re-order
expressions; even explicit parentheses are ignored.
This is the default in -pcc and -ext modes and is the
traditional method used in C.
The value explicit tells the compiler to honor explicit
parentheses but ignore ordering implied by the grammar
and associativity rules. This is similar to the rules
used by Fortran and many other languages.
The value implicit tells the compiler that explicit
parentheses and ordering implied by the grammar and
associativity rules should be honored. This means that
a+b+c must be evaluated in the order implied by
(a+b)+c. This is the default in -std and -str modes.
These rules apply only to floating-point expressions;
operations on other types are always subject to re-
ordering.
-re Specifies that the compiler generate re-entrant code by
generating both a scalar and a parallel version of
parallel loops. The default, at optimization level
-O3, is to generate non-reentrant code for functions
with parallel regions. This option has no effect on
functions without parallel code; it should be used to
compile a function for which the compiler generates
parallel code, if you wish to call that function from a
parallel region. It is always safe to use -re; the
text segment will be unnecessarily large if -re is used
when it is not required.
-S Generates symbolic assembly code for each program unit
in a source file. Assembler output for a source file
x.c is put on file x.s; no object file is generated.
The default is to write only an object file.
-sc Instructs the compiler to check the program for compi-
lation and syntax errors. No optimization, vectoriza-
tion, or code generation is performed.
-string read_write
String constants are stored in the data segment and may
be modified. This is the default when -pcc is speci-
fied.
-string read_only
String constants are stored in the text segment and may
not be modified. This option increases the sharability
of a program when multiple copies of it are running at
once. This is the default if -pcc is not specified.
-tm x
Specifies the target machine architecture. The values
for x are:
c1,C1
Executable code runs on a CONVEX C100 Series
computer.
c2,C2
Executable code runs on a CONVEX C200 Series
computer.
c32,C32
Executable code runs on a CONVEX C3200 Series
computer, or on a CONVEX C200 Series computer
that is equipped with scalar accelerator
hardware. Use the getsysinfo command to
determine whether your C2 computer has this
hardware.
c34,C34
Executable code runs on a CONVEX C3400 Series
computer.
c34j,C34J
Executable code runs on a CONVEX C3400-ES
Series computer.
c38,C38
Executable code runs on a CONVEX C3800 Series
computer.
The default value is the type of machine the
compiler is running on. When invoking the
linker machine dependent versions of some
libraries are used.
DEBUGGING AND PROFILING OPTIONS
-cxdb
Produces additional information for use by CXdb, the
CONVEX visual debugger. No additional information is
generated if the source file contains asm statements or
if the -S or -pb command line options are used. This
flag can be used with all levels of optimization, but
unless the -no option (NO optimization) is specified,
there may be source statements for which no debugging
information is generated for CXdb. When this option is
included on the command line, a subdirectory called
.CXdb is created that contains auxiliary information.
Refer to CONVEX CXdb User's Guide for more information.
CXdb is an optional product.
-db Produces additional information for use by the symbolic
debugger, csd, and the post-mortem dump utility (pmd).
It also passes the -lg flag to the loader. This flag
can be used with all levels of optimization, but unless
the -no option (NO optimization) is specified, there
may be source statements for which no debugging infor-
mation is generated for csd. Information about vari-
ables declared in the inner blocks of functions is pro-
duced only at level -no.
-metrics
Produces commonly used software source metrics and
cross reference information. This information is writ-
ten in ASCII format to a file of the source file's name
with the extension ".met". Refer to metrics(1) for
additional information. metrics is an optional pro-
duct.
-p Causes the compiler to produce code that counts the
number of times each routine is called. If loading
takes place, replaces the standard startup routine by
one that automatically calls monitor(3) at the start
and arranges to write out a "mon.out" file at normal
termination of execution of the object program. A pro-
filed library is searched, instead of the standard C
library. An execution profile can then be generated by
use of prof(1) (optional product).
-pa Produces counting code for routine-level and loop-level
profiles using the CXpa utility. Refer to the CONVEX
CXpa User's Guide for more information. CXpa is an
optional product.
-pab Produces counting code for block-level profiles using
the CXpa utility. Refer to the CONVEX CXpa User's
Guide for more information. CXpa is an optional pro-
duct.
-par Includes instrumentation for routine-level profiles
using the CXpa utility. Refer to the CONVEX CXpa
User's Guide for more information. CXpa is an optional
product.
-pb Causes the compiler to produce statement-level counting
code that produces an execution profile named bmon.out
at normal termination. Listings of source-level execu-
tion counts can then be obtained using bprof(1). bprof
is an optional product.
-pg Causes the compiler to produce counting code in the
manner of -p, but invokes a runtime recording mechanism
that keeps more extensive statistics and produces a
gmon.out file at normal termination. An execution pro-
file can then be generated by use of gprof(1) (optional
product).
COMPILER OUTPUT OPTIONS
-d name
-d name=e
-d name=w
The -d option provides low level control of diagnostic
output. The form -d name suppresses the named message.
The form -d name=w causes the named message to be
reported as a warning. The form -d name=e causes the
named message to be reported as an error. The message
names are documented in the following section.
-nv Suppresses all vectorization summary messages
(synonymous with -or none).
-nw Suppresses all warning diagnostic messages.
-or table
Specifies the contents of the optimization report to be
produced; either the loop table, the array table, or
both can be displayed. The value for table can be
none, all, array or loop. If this option is not speci-
fied, only the loop table is displayed.
DIAGNOSTIC OPTIONS
The following names can be used to control specific mes-
sages. The CONVEX C documentation on C compiler error mes-
sages provides examples for most of these diagnostic
options.
arg_ptr_qual Detects actual function parameters that
do not have the same type qualifiers as
those declared in the function proto-
type.
arg_ptr_ref Detects actual function parameters that
are not the same pointer type as those
declared in the function prototype.
assign_in_condition Detects assignment expressions in loca-
tions where conditional expressions are
expected, such as for statements and if
statements.
bad_escape The compiler encountered an unknown
escape sequence. Acceptable escape
sequences in all compatibility modes
are: \', \", \?, \\, \b, \f, \n, \r, \t,
and \v. The escape sequences \a and \x
are interpreted as the characters 'a'
and 'x', respectively, in the backward-
compatible mode.
class_ignored Indicates that an explicit storage class
is used to declare a struct tag, union
tag, enum tag, or enum member.
const_not_init Detects uninitialized constant vari-
ables.
division_by_zero Detects compile time division by zero.
dollar_names Detects identifiers embedded with the $
character.
escape_range_sequence
Detects when an escape sequence in an
integer constant is greater than 0xff.
float_suffix Detects when the floating-point suf-
fixes, f, F, l, or L, are used. This
option has no effect in the strict and
conforming compatibility modes.
function_parameter Reports when a function is used as a
function parameter; only function
pointers can be used as a function
parameter.
hidden_arg Indicates that the parameter of a func-
tion is hidden by an identifier with the
same name declared in the outermost
block of that function. This diagnostic
affects only the backward-compatible
mode.
hidden_extern Indicates that a declaration using
extern inside a function definition
causes an identifier not in the block to
be obscured. This diagnostic affects
only the backward-compatible mode.
hides_outer Indicates that an identifier prevents
access to an identifier of the same name
in an enclosing block.
implicit_decl Detects when an implicit declaration is
used because a function has not been
declared previously.
integer_overflow Detects when an integer constant larger
than 64 bits is used.
long_long_suffix Detects when the integer literal suf-
fixes LL or ll are used. These suffixes
are permitted only in the extended and
backward-compatible modes because the
long long data type is not available in
the strict and conforming compatibility
modes.
metrics_file Indicates that the specified metrics
file could not be opened.
metrics_off Indicates that metrics collection has
ceased. This occurs because the metrics
file could not be opened or because a
error was encountered in your source
code.
negative_to_uns Indicates when a negative constant is
assigned to an unsigned type.
no_arg_type Checks for function arguments declared
without a data type.
no_external_declaration
Detects when no declarations are acces-
sible to other compilation units.
no_newline Indicates that a source file is not ter-
minated with the newline character.
non_int_bit_field Check for bit fields that have type
other than int or unsigned int.
nothing_declared Detects empty declarations such as int;.
null_effect_expression
Detects intrinsic math function calls
that have no effect.
pointer_alignment_efficiency
Checks for operations that can result in
inefficient memory alignment.
pp_argcount Indicates that the number of arguments
in the actual argument list of a macro
does not match the number of arguments
in the formal argument list.
pp_argsended Indicates that an actual argument list
of a function-like macro does not have a
terminating right parenthesis.
pp_badstr Indicates incorrect use of #, the
stringizing operator that is used in
macro definitions.
pp_badtp Indicates that an invalid token paste
was attempted - the result of combining
the left and right operands of the ##
macro definition operator is not a valid
token.
pp_badtp_cmdl Indicates that the result of combining
the left and right operands of the ##
macro definition operator on the command
line is illegal.
pp_error_directive Indicates that a #error preprocessor
directive has been encountered in the
source code.
pp_extra Indicates that a preprocessor directive
has extra arguments. One common example
is when the #endif directive is followed
by text.
pp_idexpected Indicates that a #ifdef or #ifndef does
not have a legal identifier as an argu-
ment, or a formal argument of a
function-like macro is not a legal iden-
tifier.
pp_line_range Indicates the argument for the #line
preprocessor directive does not have a
value between 1 and 32767, inclusive.
pp_macro_arg Indicates that two or more formal macro
arguments have the same name.
pp_macro_redefinition
Indicates that the replacement list for
a function-like macro is not the same as
its original definition. The preproces-
sor uses the most recent replacement
list.
pp_macro_redefinition_cmdl
Indicates that the replacement list for
a function-like macro is not the same as
its original definition on the command
line. The preprocessor uses the most
recent replacement list.
pp_malformed_directive
Indicates that the proper syntax for a
preprocessor directive was not used.
pp_old_dir Indicates that the comment style syntax
for a compiler directive (pragma) was
used.
pp_parse Indicates that a #if directive has an
invalid integer expression.
pp_undef Indicates that the argument of the
#undef directive is not permitted.
pp_undef_cmdl Indicates that you attempted to unde-
fined a macro that cannot be undefined
on the command line.
pp_unrecognized_directive
Detects a preprocessor directive that
the preprocessor does not recognize.
pp_unrecognized_pragma
Detects a pragma that the compiler does
not recognize.
ptr_convert_truncates
Indicates that the cast operator data
type does not provide enough space for
the pointer that it is retyping.
qualified_cast Indicates that the cast operator data
type is qualified (const or volatile).
The qualification is ignored.
record_fn_call Checks for function calls that are
affected by the new method for returning
structures from functions. Refer to the
description of the -compat option for
more details.
record_fn_defn Checks for function definitions that are
affected by the new method for returning
structures from functions. Refer to the
description of the -compat option for
more details.
shift_too_large Checks for constant right operands of
shift operands that are too large.
short_cvt_truncates Indicates that an integral type larger
than a short integer is being assigned
to a short integer.
skip_to_char This diagnostic indicates that the com-
piler is skipping to a character to
recover from an error.
skip_to_eof This diagnostic indicates that the com-
piler must skip to the end of a file to
recover from an error.
strict_syntax Detects the lack of a semicolon after
the last member in a struct or union
declaration or the presence of a comma
after the last enumeration constant in
an enum declaration list.
unsigned_suffix Detects use of the integer literal suf-
fixes U or u. This option is not effec-
tive with the =e setting.
MISCELLANEOUS OPTIONS
-altcc path
This option invokes an alternate compiler driver. For
example,
cc -altcc /usr/lib/newcc/cc bar.c
is equivalent to
/usr/lib/newcc/cc bar.c.
To invoke an alternate C compiler, it is necessary to
specify both the driver and the components, as in:
cc -altcc /usr/lib/newcc/cc -B/usr/lib/newcc bar.c
-Bdir
Finds substitute compiler components (cocc, cpp, and
errmsg.cc) in the directory dir. If dir is not speci-
fied, the standard backup version in the directory
/usr/lib/oldcc is used instead. For example, the com-
mand
cc -B/usr/new
would invoke the compiler in
/usr/new
instead of the default
/usr/lib/cc/cocc.
To invoke an alternate C compiler, it is necessary to
specify both the components and the driver, as in:
cc -B/usr/lib/newcc -altcc /usr/lib/newcc/cc bar.c
-o name
Specifies that name is the name of the executable file
produced by ld. If this option is not specified, the
default name is a.out. If -c was specified and there
is only one file to compile or assemble, name is the
name of the object module produced.
-tl time
Sets the maximum CPU time limit on compilations to time
minutes. If the CPU time exceeds the allotted time,
the compilation is aborted.
-vn Identifies compiler version.
VENDOR COMPATIBILITY OPTIONS
The following options are provided for compatibility with
compilers of other vendors.
-g A synonym for -db.
-n Ignored with a warning.
-O A synonym for -O1.
-OL A synonym for -O1.
-V A synonym for -vn.
-w A synonym for -nw
PREPROCESSOR OPTIONS
The CONVEX C compiler invokes an internal C macro preproces-
sor on each file and compiles the resulting text. The fol-
lowing options affect the preprocessing phase of transla-
tion.
-C Retains comments in the output. C style comments are
usually removed.
-Dname
-Dname=def
Define the name (as if by #define) as def, or 1 if def
is omitted.
-E Runs only the internal C preprocessor on the named C
source files and sends the result to the standard out-
put stream (stdout). The source is not checked for
errors and no object, assembly or executable code is
produced.
-Idir
Adds dir to the search list for #include files.
-I- The `-I-' option inhibits the use of the current direc-
tory (where the current input file came from) as the
first search directory for `#include'. There is no way
to override the effect of `-I-'
-k Runs the internal C preprocessor on the named C source
files and generates a dependency description for
make(1); results are printed out on the standard output
stream.
-P This option gives you preprocessed code without the
control lines. It does not allow you to redirect the
output; the output is placed in a file in the current
directory with the same root name as the source
filename and a suffix of ".i".
-Uname
Remove any initial definition of name. Names prede-
fined by the preprocessor are discussed below.
The compiler passes these options directly to the internal C
preprocessor without interpretation. See cpp(1) for further
details.
If the compiler option -pcc is present it is passed to each
invocation of the internal preprocessor.
PREDEFINED SYMBOLS
The following macros are predefined in the preprocessor.
__convex__
This symbol is predefined in all compatibility modes as
1. To remain compatible with previous preprocessors,
the ``convex'' symbol is also predefined only in the
backward-compatible mode, but its availability may be
discontinued in a future release of the preprocessor.
_CONVEX_SOURCE
_POSIX_SOURCE
The symbols _CONVEX_SOURCE and _POSIX_SOURCE are prede-
fined in extended mode. In -std mode the user will
generally want to define the symbol _POSIX_SOURCE to
make the POSIX symbols available in the include files.
_CONVEX_FLOAT_
_IEEE_FLOAT_
The symbol _CONVEX_FLOAT_ is defined when the compiler
is operating in native float point mode, _IEEE_FLOAT_
is defined in IEEE mode. See the description of the
options -fi and -fn above.
__DATE__
This symbol is predefined in the extended, standard,
and strict modes of the preprocessor. It returns the
current date. This definition may not be removed with
the #undef directive or the -U command line option.
__FILE__
This symbol is predefined in all modes of the prepro-
cessor. It returns the current file name. This defini-
tion cannot be removed with the #undef directive or the
-U command line option.
__LINE__
This symbol is predefined in all modes of the prepro-
cessor. It returns the current line number. This defin-
ition cannot be removed with the #undef directive or
the -U command line option.
__STDC__
The symbol __STDC__ is defined as the decimal constant
1 when either the -std or -str flags are specified.
The definition of this symbol indicates that the com-
piler conforms to the ANSI C Standard. This definition
may not be removed by the -U option or #undef.
__stdc__
The symbol __stdc__ is defined as the decimal constant
1 in all modes except the -pcc mode. It indicates that
the compiler is an ANSI style compiler, but not that it
is conforming, due to CONVEX extensions.
__NO_INLINE_MATH
The symbol __NO_INLINE_MATH is defined in -str and -std
modes to suppress recognition of macros which define
certain library functions. This is necessary to get
conforming implementations of some functions which
would otherwise not set errno in a standard conforming
manner. Refer to intro(3m) for more details.
__TIME__
This symbol is predefined in the extended, standard,
and strict modes of the preprocessor. It returns the
current time. This definition may not be removed with
the #undef directive or the -U command line option.
__unix__
This symbol is always predefined as constant 1. To
remain compatible with previous preprocessors, the
``unix'' symbol is also predefined only in the
backward-compatible mode, but its availability may be
discontinued in a future release of the preprocessor.
__convexc__
This symbol is always defined. It should be used to
identify the compiler. Other symbols defined by the
internal preprocessor (see cpp(1)) identify the machine
and operating system.
convexvc
This symbol is defined in -pcc mode. Its use is
obsolescent; the symbol __convexc__ should be used
instead.
The internal preprocessor defines a number of symbols as
well; see cpp(1) for a discussion of these symbols.
Other names beginning with "__" or _[A-Z] may be predefined
by cc. Such names are reserved to CONVEX; their usage or
availability may change in subsequent releases. Applica-
tions should not depend on the presence or absence of such
names except as defined above.
LOADER USAGE
A number of compiler options impact the manner in which cc
invokes the loader. Options for the loader may also be
specified directly by the user. CONVEX recommends always
using the appropriate compiler to invoke the loader rather
than invoking it directly. This will insulate the program
from changes in library structure when new compiler releases
are installed.
The compiler always passes the flags -X, -NL, and -L/usr/lib
to the loader. The compiler flags -fi and -fn are passed to
the loader (in addition to the effects they have on the com-
piler). The compiler option -o causes a similar -o option
to be passed to ld. -Eposix is passed to the loader except
when -pcc is given, in which case -Enoposix is passed.
The compiler compatibility mode controls the libraries
searched by the loader; this is normally accomplished by
passing one or more -l options to the loader.
The following options, when present on the cc command line
are passed to ld(1):
-D -E -F -L -M -T -X -d -e -l -m -r -s -t -u -x -y
See the CONVEX Compiler Utilities User's Guide for their
meaning and use. The -l option must be specified after all
object files on the cc command line to be effective. Loader
options which require a value (e.g., -L and -E) must be
written with no spaces between the flag and value (e.,g.,
-L/mydir) when passed through cc.
The -link option causes the following argument to be passed
to ld. If the following argument does not start with - or
starts with -l the argument is added to the loader's file
list, otherwise it is added to the loader's flag list. For
example, -link -v3.2.8.5 -link -link passes the flag
-v3.2.8.5 to the loader causing it to set the version number
of the executable, and passes -link in the file list causing
the loader to search the library libink.a.
OBJECT FILE COMPATIBILITY
When invoked without the -pcc flag CONVEX C generates object
files that are not compatible with object files created by
compilers prior to CONVEX C V4.1.
When invoked with the -pcc flag, object files created by
previous C compilers can be linked with those created by the
CONVEX C; the -pcc flag must be used when linking the
objects and you must use the CONVEX C compiler to perform
the link step.
Object files created by any mode of CONVEX C can be mixed
with object files created by any other mode of CONVEX C.
Object files created by CONVEX C should not be linked using
other C compilers.
ENVIRONMENT VARIABLES
The CONVEX C compiler prepends the value of the environment
variable CCOPTIONS (if it is set) to each command line so
that options need not be specified every time cc is invoked.
For example,
setenv CCOPTIONS '-O2'
causes all compilations to be done at -O2 and
setenv CCOPTIONS '-pcc'
causes all compilations to be done in backwards compatible
mode.
The preprocessor /lib/cpp has a similar variable CPPOPTIONS
that can be used to affect its behavior. However, CPPOP-
TIONS does not have any effect when the compiler invokes its
internal C preprocessor.
FILES
file.c C language input file
file.o object code output file
file.met metrics output file
a.out executable output file
.CXdb subdirectory containing files
generated for cxdb
/tmp/cocc* temporary file
/lib/cpp standalone preprocessor -
compatible with traditional C
/usr/lib/cc/cpp standalone preprocessor -
CONVEX preprocessor
/usr/lib/cc/cocc compiler
/usr/lib/cc/errmsg.cc compiler error message text
/bin/cc compiler control program
/usr/lib/crt/crt0.o runtime start off
/usr/lib/crt/mcrt0.o startup routine for prof
profiling
/usr/lib/crt/gcrt0.o startup routine for gprof
profiling
/usr/lib/crt/bcrt0.o startup routine for bprof
profiling
/usr/lib/libbint.a Cray-compatible bit intrinsics
library
/usr/lib/libc_old.a backward mode library
/usr/lib/libc.a extended mode library
/usr/lib/libp1.a standard mode library
/usr/lib/libansic.a strictly conforming mode
library
/usr/lib/libC1.a C1 machine dependent library
/usr/lib/libC2.a C2 machine dependent library
/usr/lib/libC1_old.a backward compatible C1 machine
dependent library
/usr/lib/libC2_old.a backward compatible C2 machine
dependent library
/usr/include standard directory for
"#include" files
/lib/bscan optional bprof scanner
mon.out file produced for analysis by
prof(1)
gmon.out file produced for analysis by
gprof(1)
bmon.out file produced for analysis by
bprof(1)
Each library has a profiled version whose name is formed by
by inserting _p before the .a.
BUGS
See the CONVEX C release notes in /usr/doc for a description
of known bugs causing wrong answers.
SEE ALSO
adb(1), as(1), cpp(1), csd(1)(optional product),
cxdb(1)(optional product), gprof(1)(optional product),
ld(1), prof(1)(optional product), bprof(1)(optional pro-
duct), metrics(1)(optional product), monitor(3), a.out(5)
CONVEX C Guide
CONVEX C Optimization Guide
CONVEX C Quick Reference
CONVEX Compiler Utilities User's Guide
B. W. Kernighan and D. M. Ritchie, The C Programming
Language, Second Edition, Prentice-Hall, 1988
B. W. Kernighan and D. M. Ritchie, The C Programming
Language, Prentice-Hall, 1978
B. W. Kernighan, Programming in C-a tutorial
DIAGNOSTICS
The CONVEX C Guide provides detailed information regarding
error messages produced by the compiler.
A successful compilation is indicated by returning status 0.
Occasional messages may be produced by the assembler or
loader.