cc(1)cc(1)NAMEcc - C compiler
SYNOPSIScc [option...] file... [option...]
Default Options:
cc-std -arch generic -assume aligned_objects -noansi_alias-assume
math_errno -call_shared-cpp-error_limit 30 -float-nofp_reorder
-fprm n -fptm n -g0 -I/usr/include -inline manual -intrinsics
-member_alignment-nomisalign -nestlevel=50 -newc-O1-p0-nopg
-preempt_symbol -SD/usr/include -signed-tune generic -weak_volatile
-writable_strings
OPTIONS
Options described in this section are divided into the following cate‐
gories. The default options for each category, if any, are listed:
Compiler Selection Options
Default: -newc
Language Mode Options
Default: -std
Overall Compiler Behavior Options
Defaults: -arch generic, -error_limit 30,
-nestlevel=50
Compiler Diagnostic Controls Options
Default: -SD/usr/include
C Preprocessor Options
Defaults: -cpp, -I/usr/include
Options that Affect the Linker or Loader
Default: -call_shared
Optimization Options
Defaults: -noansi_alias, -assume math_errno,
-float, -nofp_reorder, -inline manual, -intrinsics,
-O1, -preempt_symbol, -tune generic
Feedback-directed Optimization Options
Default: None
Source-code Debugging Options
Default: -g0
Program Profiling Options
Defaults: -p0, -nopg
Data Alignment Options
Defaults: -assume aligned_objects, -member_alignment
-nomisalign
Data Volatility Options
Default: -weak_volatile
C Language Options
Defaults: -signed, -writable_strings
Stack-handling and Pointer-handling Options
Default: None
IEEE Floating-point Support Options
Defaults: -fprm n, -fptm n
Compiler Development Options (Not Generally Used)
Default: None
Compiler Selection Options
Invokes the compiler with the default option settings shown in the SYN‐
OPSIS section. This option is provided to turn off -migrate, and it is
the default. Invokes the compiler with a set of optimization settings
that are slightly different from those associated with -newc. These
settings are consistent with the cc-migrate settings for versions of
the DEC OSF/1 operating system that preceded DIGITAL UNIX Version 4.0.
This option is provided for backwards compatibility only, and its use
is strongly discouraged.
Language Mode Options
The language mode options are mutually exclusive. When more than one
such option appears on the command line, the last one listed will take
effect. The default is -std. Selects the relaxed ANSI language mode.
This is the default. Accepts standard ANSI C89 and C99 features, but
allows some common programming practices disallowed by the standards.
This option does not restrict the Tru64 UNIX name space (for
example, the names defined in system header files). To restrict
that name space so that only ANSI reserved names are visible
from the ANSI header files, use the _ANSI_C_SOURCE macro. See
standards(5) for more details.
This option sets the macro __STDC_VERSION__ to 199901L, and the
macro __STDC__ to 0. Selects the K & R language mode. Enforces
the K & R programming style, with certain ANSI extensions in
areas where the K & R behavior is undefined or ambiguous. In
general, -std0 compiles most pre-ANSI C89 programs and produces
expected results. The -std0 option leaves the macros __STDC__
and __STDC_VERSION__ undefined. Selects the strict ANSI C89
language mode. Strictly enforces the ANSI C89 standard and all
its prohibitions (such as those that apply to the handling of
void types, the definition of lvalues in expressions, the mixing
of integrals and pointers, and the modification of rvalues).
This option does not restrict the Tru64 UNIX name space (for
example, the names defined in system header files). To restrict
that name space so that only ANSI reserved names are visible
from the ANSI header files, use the _ANSI_C_SOURCE macro. See
standards(5) for more details.
This option sets the macro __STDC__ to 1 and leaves the macro
__STDC_VERSION__ undefined. Note that this option also affects
linker-defined symbols. See ld(1) for more information.
This option, combined with -O3 or higher, turns on ANSI aliasing
rules (-ansi_alias option). Selects the strict ANSI C99 lan‐
guage mode. Strictly enforces the ANSI C99 standard and all its
prohibitions.
This option does not restrict the Tru64 UNIX name space (for
example, the names defined in system header files). To restrict
that name space so that only ANSI reserved names are visible
from the ANSI header files, use the _ANSI_C_SOURCE macro. See
standards(5) for more details.
This option sets the macro __STDC_VERSION__ to 199901L, and the
macro __STDC__ to 1. Enables additional features from Amendment
1 to the ANSI C89 standard.
This option sets the macro __STDC_VERSION__ to 199409L in all
language modes except for the following:
-c99 (__STDC_VERSION__ is set to 199901L)
-vaxc (__STDC_VERSION__ is not set)
This option has no effect on the macro __STDC__. Selects the
Microsoft language mode, which provides some compatibility with
the Microsoft Visual C compiler. Although this option does not
provide full compatibility, it can be useful as a porting aid.
It provides the following extensions. Except for these exten‐
sions, the -ms option is equivalent to -std. Thread Local Stor‐
age (TLS) and structured exception handling are always enabled.
Allow a declaration of an unnamed structure within another
structure. You can reference all members of the inner structure
as members of the named outer structure. This is similar to the
C++ treatment of nested unions lacking a name, but extended to
both structures and unions. For example:
struct {
struct {
int a;
int b;
}; /*No name here */
int c; }d; /* d.a, d.b, and d.c are valid member names. */
Allow duplicate typedef declarations. For example:
typedef int typedefname; typedef int typedefname; Allow typedef
declarations that are redeclared to a compatible type. For exam‐
ple:
typedef enum {a,b,c} typedefname; typedef enum {d,e,f} typedef‐
name; Allow declaration of a structure with a trailing incom‐
plete array. This is useful if you are dealing with counted
arrays, where the first element of the structure is used to hold
a count of the array elements, the second element is an array of
data, and the structure is always allocated dynamically. The
sizeof operator treats the incomplete array as having a length
of zero. For example:
struct {
int a;
int b[]; }s; Allow a static function declaration in block
scope (that is, inside another function). For example:
f() {
static int a(int b); } Allow & to produce an lvalue expres‐
sion in certain cases. For example:
int *a, *b;
f() {
&*a=b; } Allow integers and pointers to be compared with‐
out a cast. For example:
int *a,b; f() { if (a==b)
b=1; } Treat the char type as either signed char or unsigned
char, depending of the default in effect. For example, a pointer
to char can be assigned to a pointer to signed char, assuming
that the -signed option is in effect:
signed char *a; Suppress warning messages for declarations that
contain two semicolons; that is, allow completely empty declara‐
tions at file scope. For example:
int a;; Suppress warning messages for declarations that contain
a variable name but no type. For example:
b;
This is assigned type int. Ignore any extra comma at the end of
the last enumerator in an enumeration declaration. For example:
enum E {a, b, c,}; /* Ignore the comma after "c". */ Allow
typedef declarations that have a type specifier but no identi‐
fier name declaring the new type. For example:
typedef struct { int a; }; Suppress warning messages when one of
the following unsupported Microsoft pragmas is encountered:
#pragma code_seg #pragma optimize #pragma warning
Selects the K & R language mode. This option is equivalent to
-std0. Selects the K & R language mode. This option is equiva‐
lent to -std0. Selects the VAX C language mode. This is similar
to -std (relaxed ANSI mode) but extends the language semantics
in ways that are incompatible with ANSI C. It provides close
compatibility with the vaxc compiler.
Overall Compiler Behavior Options
Causes the compiler to recognize additional keywords. The following
options are available: The default compilation mode on OpenVMS systems
includes recognition of the following keywords that are not available
on Tru64 UNIX except in -vaxc mode: _align, globaldef, globalref, glob‐
alvalue, noshare, readonly, variant_struct, and variant_union. This
option causes these keywords to be recognized. It may help in porting
applications from OpenVMS systems. Cause the compiler to recognize the
restrict keyword (from the C9X review draft). Specifies which version
of the Alpha architecture to generate instructions for. All Alpha pro‐
cessors implement a core set of instructions and, in some cases, the
following extensions: BWX (byte/word-manipulation extension), MVI (mul‐
timedia extension), FIX (square root and floating-point convert exten‐
sion), and CIX (count extension). (The Alpha Architecture Reference
Manual describes the extensions in detail.)
The option specified by the -arch option determines which
instructions the compiler can generate: Generate instructions
that are appropriate for all Alpha processors. This option is
the default. Generate instructions for the processor that the
compiler is running on (for example, EV6 instructions on an EV6
processor). Generate instructions for the EV4 processor (21064,
21064A, 21066, and 21068 chips) and EV5 processor (some 21164
chips). (Note that chip number 21164 is used for both EV5 and
EV56 processors.)
Applications compiled with this option will not incur any emula‐
tion overhead on any Alpha processor. Generate instructions for
EV56 processors (some 21164 chips).
This option permits the compiler to generate any EV4 instruc‐
tion, plus any instructions contained in the BWX extension.
Applications compiled with this option may incur emulation over‐
head on EV4 and EV5 processors. Generate instructions for EV6
processors (21264 chips).
This option permits the compiler to generate any EV6 instruc‐
tion, plus any instructions contained in the following exten‐
sions: BWX, MVI, and FIX.
Applications compiled with this option may incur emulation over‐
head on EV4, EV5, EV56, and PCA56 processors. Generate instruc‐
tions for EV67 processors (21264A chips).
This option is the same as the ev6 option except that it also
permits the compiler to generate any instructions contained in
the CIX extension.
If your application uses CIX instructions, it may incur emula‐
tion overhead on all processors that are older than EV67. Gen‐
erate instructions for PCA56 processors (21164PC chips).
This option permits the compiler to generate any EV4 instruc‐
tion, plus any instructions contained in the BWX and MVI exten‐
sions.
Applications compiled with this option may incur emulation over‐
head on EV4, EV5, and EV56 processors.
A program compiled with any of the options will run on any Alpha
processor. Beginning with DIGITAL UNIX V4.0 and continuing with
subsequent versions, the operating system kernel includes an
instruction emulator. This capability allows any Alpha chip to
execute and produce correct results from Alpha instruc‐
tions--even if the some of the instructions are not implemented
on the chip. Applications using emulated instructions will run
correctly, but may incur significant emulation overhead at run
time.
The psrinfo -v command can be used to determine which type of
processor is installed on any given Alpha system.
Note the following differences between the -arch evx and -tune
evx options (where x designates a specific processor): -arch evx
implies -tune evx, but -tune evx does not imply -arch evx.
-arch evx can generate unguarded evx-specific instructions. If
you run that application on a pre-evx processor, those instruc‐
tions may get emulated (and emulated instructions can be up to
1000 times slower than actual instructions). -tune evx can gen‐
erate evx-specific instructions, but those are always amask-
guarded. That expands the code size but avoids instruction emu‐
lation. If you want the best performance possible on an evx
processor and are not concerned about performance on earlier
processors, the best choice would be -arch evx (which implies
-tune evx). If you want good performance on an evx processor
but also want the application to run reasonably fast on earlier
processors, the best choice would probably be -tune evx. Sup‐
presses the loading phase of the compilation and forces the cre‐
ation of an object file. Generates runtime code to check the
values of array subscripts (and equivalent pointer arithmetic
involving pointers produced by converting an array name to a
pointer) to verify that the resulting address lies within the
range for which the C standard requires well-defined behavior.
The exact source code constructs that trigger these checks, and
the values used for a given bounds check, are not simple to
describe. In some cases the checks will trap on a partial
address computation even though the final result of the computa‐
tion is within bounds. A failed bounds check at runtime produces
a Trace/BPT trap, which may be caught by signal(SIGTRAP, han‐
dler). See the Programmer's Guide for more details.
The -nocheck_bounds option (the default) disables the runtime
checking of array bounds. When syntactic or semantic errors are
detected by the compiler's front end, invokes the editor defined
by the environment variable EDITOR (or vi if EDITOR is unde‐
fined). Two files are opened for editing: the error message
file, which indicates the location of the error, and the source
file. When you exit from the editor, the compilation is
restarted.
The n argument specifies the number of times a compilation can
be interrupted in this way. If no number is specified, the com‐
pile-edit-compile cycle repeats indefinitely until all errors
are corrected. The -edit0 option turns off this feature. To
abort the cycle, you must press Ctrl-C while the process is in
the compilation phase (that is, while it is not in the editor).
When compiling on a character-based terminal, the compile job
has to be in the foreground for this option to take effect. When
compiling on a workstation, this option takes effect whether it
is in the foreground or background. Sets a limit on the number
of error-level diagnostics that the compiler will emit. The
default is 30. Specifies a file that is to be included before
the first line in a source file is actually compiled. This
enables users to develop include files containing sets of prag‐
mas that control a particular aspect of a compilation (for exam‐
ple, optimizations or diagnostics). Controls the size of shared
data in memory that can be safely accessed from different
threads. The possible size values are byte, longword, and quad‐
word.
Specifying byte allows single bytes to be accessed from differ‐
ent threads sharing data in memory without corrupting surround‐
ing bytes. This option will slow runtime performance.
Specifying longword allows naturally aligned 4-byte longwords to
be accessed safely from different threads sharing data in mem‐
ory. Accessing data items of 3 bytes or less, or unaligned
data, may result in data items written from multiple threads
being inconsistently updated.
Specifying quadword allows naturally aligned 8-byte quadwords to
be accessed safely from different threads sharing data in mem‐
ory. Accessing data items of 7 bytes or less, or unaligned
data, may result in data items written from multiple threads
being inconsistently updated. This is the default. Sets the
nesting-level limit for include files. The default is 50.
Includes the generated machine code in the listing file. By
default, machine code is not listed. To produce the listing
file, you must also specify -source_listing. Suppresses cre‐
ation of an object file. By default, an object module file is
created with the same name as that of the first source file of a
compilation unit and with the file extension.
Use the -noobject option when you need only a listing of a pro‐
gram or when you want the compiler to check a source file for
errors. Names the final output file output. Ensures that the
compiler's assumptions about pointer sizes and data alignments
are not in conflict with the default values that were in effect
when the system libraries were created.
The keywords for the -protect_headers option are as follows:
Enables the protect headers feature. This is the default if the
file being compiled is a C source file. Disables the protect
headers feature. This is the default if the file being compiled
is a non-C source file. Cancels any previous -protect_headers
options and places the compiler's default behavior in effect.
If more than one -protect_headers option appears on the command
line, only the last one is applied. See protect_headers_setup(8)
for details. Compiles the specified source files and generates
symbolic assembly language output in corresponding files suf‐
fixed with Specifies one or more items to be included in the
listing file. When specifying multiple keywords, separate them
by commas and no intervening blanks. To use any of the -show
keywords, you must also specify the -source_listing option.
The keywords for the -show option are as follows: Turns off all
show options. Turns on all show options. Produces a brief
macro and symbol table map in the program listing, omitting most
macros and symbols that are unreferenced. Attributes such as
line number of declaration, size, alignment, storage class, and
type are shown for each symbol. Adds a list of line numbers to
each identifier produced by the brief or symbol show options,
identifying the listing lines that contain references to that
identifier. If neither brief nor symbol is specified, the
default is brief. Listing line numbers are the sequential num‐
bers that span included files, and appear just before the text
of each source line in the source listing. When appropriate,
the line number designating a reference to a symbol is annotated
with one or more suffixes indicating the way in which the symbol
was used on that line, as follows:
= Assigned or initialized
& Address taken
() Function called
* Simple dereference
-> Member dereference
[] Subscripted (that is, using [] syntax)
b Invoked as a builtin function
Places final macro expansions in the program listing. When you
specify expansion, the number printed in the margin indicates
the maximum depth of macro substitutions that occur on each
line. Expansion is not shown for lines that are preprocessor
directives. Produces header lines at the top of each page of
listing. Places contents of header files in program listing.
Places source program statements in program listing. Places
compile-time performance statistics in the program listing.
Same as [no]brief, except that unreferenced macros and symbols
are not suppressed.
If you specify -source_listing but do not specify -show key‐
words, the compiler includes header lines and source statements
in the program listing (-show header,source). Produces a source
program listing file with the same name as the source file and
with a file extension. You must specify this qualifier to get a
listing. The default is to not produce a listing file. Prints
the compilation phases as they execute with their arguments and
their input and output files. Prints resource usage in the C-
shell time format. Prints the macros defined at the start of the
compilation. Prints the version of the compiler driver.
Compiler Diagnostic Controls Options
Performs compile-time code checking. With this option, the compiler
checks for code that exhibits nonportable behavior, represents a possi‐
ble unintended code sequence, or possibly affects operation of the pro‐
gram because of a quiet change in the ANSI C Standard. Some of these
checks have traditionally been associated with the lint utility.
The -check option is equivalent to -msg_enable level5. The cc
driver converts -check into -msg_enable level5 (the -v option
notifies you of this transformation). Causes the compiler to
dump, to stdout, all messages enabled by any given cc command
line. The compiler then exits, without doing a compilation.
Provides users with the ability to control the diagnostic mes‐
sages issued by the compiler. The message output can be tuned in
groups (based on message level or message group) or individually
(based on the message ID strings enclosed in parentheses at the
end of message text strings).
The -msg_actiontype option has eight different forms, each
resulting in a different action that changes the status, sever‐
ity, or frequency that will be applied to the messages identi‐
fied by the msg_list argument. The following message-control
options are supported: Enable a specific message or group of
messages. Disable a specific message or group of messages.
(Note that messages with error or fatal severity cannot be dis‐
abled; only warning and informational messages can be disabled.)
Always emit the messages identified by the msg_list argument.
Emit the identified messages only once. Change the identified
messages to be fatal, compilation-ending errors. Change the
identified messages to be warnings. (Note that error- or fatal-
severity messages cannot be changed to warning-severity mes‐
sages.) Change the identified messages to be informational mes‐
sages. (Note that error- or fatal-severity messages cannot be
changed to informational-severity messages.) Change the identi‐
fied messages to be error messages. (Note that fatal-severity
messages cannot be changed to error-severity messages.)
The msg_list argument to the -msg_actiontype option is a comma-
separated list of one or more message levels, message groups, or
message IDs. Enabling a message level also enables all lower
levels, and disabling a level also disables all higher levels.
For example, disabling level 3 messages disables levels 3 - 6.
Operations other than enabling or disabling apply only to the
specified (or default) level, not to lower levels.
The following message levels and message groups are supported:
Message Levels: Very important messages that are enabled by
default. Level 0 messages cannot be disabled as a class
(level0), but individual level 0 messages can be disabled if
they are warning- or informational-severity messages. (Error- or
fatal-severity messages cannot be disabled.)
Messages at this level correspond to messages covered by pragma
nostandard. These include all messages that should be displayed
for code in header files. Important messages, but less impor‐
tant than level 0 messages. These messages are not displayed if
pragma nostandard is active. Level 1 is the default for DIGITAL
UNIX releases prior to V4.0E. Moderately important messages.
Level 2 is the default for DIGITAL UNIX V4.0E and later (Tru64
UNIX) versions. Less important messages. (The -w0 option
enables level 3 messages.) Useful messages associated with the
-check and -portable options. Less useful -check and -portable
messages than the messages associated with level 4. The -check
option is equivalent to -msg_enable level5. All messages,
including all messages not in any of the lower levels. Disabling
level 6 messages does not affect the lower-level messages; it
affects only the messages added by level 6.
Message Groups: Messages reporting code or practices that may
have unintended consequences on 64-bit architectures. Messages
reporting unusual or inefficient data alignment. Messages
reporting the use of C features that would be invalid or have a
different meaning if compiled by a C++ compiler. Messages
reporting code or practices that, although correct and perhaps
portable, are sometimes considered ill-advised because they can
be confusing or fragile to maintain (for example, assignment as
the test expression in an if statement). Messages reporting the
use of obsolete features, features that were accepted by early C
compilers but were subsequently removed from the language. Mes‐
sages reporting the use of features that are not in the ANSI C89
standard. Same as noc89. Messages reporting the use of features
that are not in the ANSI C89 standard. Same as noansi. Messages
reporting the use of features that are not in the ANSI C99 stan‐
dard. Messages reporting the use of features that are new in
the ANSI C99 standard. Messages reporting the use of features
that are valid in ANSI C, but which are identified in the stan‐
dard as being obsolescent and likely to be removed from the lan‐
guage in a future version of the standard. Messages reporting
assignments and/or casts that may cause overflow or other loss
of data significance. Messages reporting code that might result
in poor run-time performance. Messages reporting the use of
language extensions or other constructs that might not be porta‐
ble to other compilers or platforms. -msg_enable portable is
equivalent to -portable. Messages reporting questionable or
non-portable use of preprocessing constructs. Messages report‐
ing questionable coding practices. Similar to check, but mes‐
sages in this group are more likely to indicate a programming
error, not just a non-robust style. Messages relating to func‐
tion return values. Messages reporting expressions, declara‐
tions, and code paths that are not used. Directs the compiler
to issue diagnostics for certain constructs that may not be por‐
table to other compilers or platforms. -portable is equivalent
to -msg_enable portable. Suppresses certain warning- and infor‐
mational-level diagnostic messages that are inappropriate for
system header files. The suppressed messages relate to non-por‐
table constructs in header files whose pathnames are prefixed by
string directory.
The default is -SD/usr/include.
Specifying -SD without a directory string cancels the effect of
any previous -SD options on the command line (including the
default, -SD/usr/include). It also disables the -protect_headers
feature's suppression of diagnostic messages by defining the
macro __DECC_EMPTY_SD_OPTION. (The -protect-headers feature pro‐
vides message suppression in the file __DECC_include_pro‐
logue.h.) Produces longer error and warning messages. Messages
in this form may give the user more hints about why the compila‐
tion failed. Controls the display of messages as well as the
actions that occur as a result of the messages. The value of n
can be one of the following: Displays compiler messages for less
important issues. This is equivalent to -msg_enable level3. For
Tru64 UNIX V4.0E and later versions, -msg_enable level2 is the
default. Suppresses warning and informational messages and dis‐
plays error and fatal messages. This is equivalent to specifying
-w. If the compiler encounters an error that generates a warn‐
ing-level diagnostic message, the compiler displays the message
and then aborts. Does not print warning messages. However,
when warnings occur, exits with nonzero status. Causes the com‐
piler to produce warning messages when a function is called that
is not declared with a full prototype. This checking is more
strict than required by ANSI C.
C Preprocessor Options
Passes all comments directly to the preprocessor output, except com‐
ments on preprocessor directive lines. Determines whether to call the
C macro preprocessor on C and assembly source files before compiling.
-cpp is the default. Defines the name as if with a #define
statement. If no definition is given, the name is defined as 1.
Runs only the C macro preprocessor on the files and sends the
result to the standard output device. Specifies a search path
for header files whose names do not indicate a specific direc‐
tory path (that is, whose names do not begin with a /). The
actual search path depends upon the form of the #include direc‐
tive used for the file: If the #include "filename" form of the
directive is used, the C macro preprocessor searches for the
file first in the directory in which it found the file that con‐
tains the directive, then in the search path indicated by the -I
option, and finally in the standard directory, /usr/include. If
the #include <filename> form of the directive is used, the pre‐
processor searches for the file first in the search path indi‐
cated by the -I option, and then in the standard directory,
/usr/include.
You can specify multiple iterations of the -I[dir] option in the
cc command line; each instance of the -[dir] option appends
locations to the previously established -I[dir] search path. If
no dir is specified in any instance of the -I[dir] option, the C
macro preprocessor never searches the standard directory,
/usr/include, for header files.
The -nocurrent_include option can also modify the search path.
Outputs a set of make dependency rules to standard output for
each source file on the command line (and suppresses compila‐
tion). The make dependencies include all of the header files
upon which each source file depends. The make targets are the
object files for those source files. The output lines are
indented to show header file nesting. Requests dependency files
from the preprocessor (and linker if it is also run). It does
not suppress compilation like the -M option. This option is
passed directly to the preprocessor and linker. For more infor‐
mation, see cpp(1) and ld(1). Changes the behavior of the
#include "filename" directive to not search the source file's
directory for filename. This option causes the #include "file‐
name" directives to behave like #include <filename> directives.
This option allows makefiles to control the search order for
header files by using -I options. Directs the preprocessor to
delete comments (replacing them with nothing at all). This
allows traditional token concatenation.
This is the default in -std0 mode. In -std and -std1 mode, the
default is to replace comments with a single space. Runs only
the C preprocessor and puts the result for each or source file
in a corresponding file. The file has no #line_number preproces‐
sor directives in it. Extracts prototype declarations for func‐
tion definitions and puts them in a suffixed file. The suboption
i includes identifiers in the prototype, and the suboption s
generates prototypes for static functions as well. Directs the
preprocessor to use single quotes in __FILE__ expansions instead
of double quotes. See cpp(1) for details. Removes any macro
definition of name at the start of the compilation. name could
have been defined with a -D option or predefined by the com‐
piler. If no name is specified or if name is not defined, the -U
option is ignored. (To display a list of predefined macros, use
the -v option.)
Options that Affect the Linker or Loader
Produces a dynamic executable file that uses shareable objects during
run time. This is the default. The loader uses shareable objects to
resolve undefined symbols. The run-time loader (/sbin/loader) is
invoked to bring in all required shareable objects and to resolve any
symbols that remained undefined during static link time. Passes the
-compress option to the compilation phase (if the -c option is present)
or passes the -compress_r option to ld (if the -r option is present).
Use of this option causes the output object file to be produced in com‐
pressed object file format, resulting in a substantially smaller object
file. Runs the procedure rearranger, cord, on the resulting file after
linking. The rearrangement is done to reduce the cache conflicts asso‐
ciated with accessing the program's text. The output of cord is left in
the file specified by the -o output option or a.out by default. At
least one -feedback file must be specified. See prof(1) for information
on creating feedback files. Causes any unresolved symbols matching
pattern to be ignored. Such symbols are not displayed and are not
treated as errors or warnings. You can enter this option multiple times
on a command line. The patterns use shell wildcard characters (?, *, [,
]). The wildcard characters must be properly quoted to prevent them
from being expanded by the shell. For more information, see sh(1).
Used in conjunction with -call_shared to request strict dependency
testing for the executable file produced. Executable files built in
this manner can be executed only if the shared libraries that they use
were not modified after the executable was built. Makes the procedure
represented by the symbol into a termination routine. A termination
routine is a routine that is called without an argument when either the
file that contains the routine is unloaded or the program that contains
the routine exits. Makes the procedure represented by the symbol into
an initialization routine. An initialization routine is a routine that
is called without an argument when either the file that contains the
routine is loaded or the program that contains the routine is started.
Directs the linker to read the contents of file filename as if the con‐
tents had been supplied on the ld command line.
Inside file filename, lines ending with \ are treated as contin‐
uation lines, and lines starting with # are treated as comment
lines and ignored. The -v option can be used to display the
expansion of files specified in a -input file. The files can be
nested up to 20 levels. Prevents the linker from using archive
libraries to resolve symbols. This option is used in conjunction
with -call_shared. The -noarchive option is position sensitive;
it affects only those options and variables that follow it on
the command line. This option can also be used more than once on
the command line. Directs the linker to produce a static exe‐
cutable. The output object created by the linker will not use
any shared objects during execution. Directs the linker to use
the threadsafe version of any library specified with the -l
option when linking programs. This option also tells the linker
to include the POSIX 1003.1c-conformant DECthreads interfaces in
libpthread when linking the program. This option also defines
the _REENTRANT macro. Produces dynamic shareable objects. The
loader will produce a shareable object that other dynamic exe‐
cutables can use at run time.
The following options are used with -shared: Checks the location
of this shared object's segments and make sure they stay out of
the way of other object's segments in the location_file. Multi‐
ple instances of this option are allowed. Creates an rpath
record containing the specified path string. The path string is
a colon-separated list of directories that is meaningful only
when creating an executable with shared linkage. If an item in
the path supplied to -rpath is of the form $VARNAME or ${VAR‐
NAME}, the linker interprets it as an environment variable.
Additional rpath directories found in shared objects on the link
command line are appended to path. Duplicate entries are
excluded. The loader uses the rpath record to search for shared
libraries at run time. Establishes the version identifier (or
identifiers) associated with a shared library. The string ver‐
sion-string is either a single version identifier or a colon-
separated list of version identifiers. No restrictions are
placed on the names of version identifiers; however, it is
highly recommended that UNIX directory naming conventions be
followed.
If a shared library is built with this option, any executable
built against it will record a dependency on the specified ver‐
sion or, if a list of version identifiers is specified, the
rightmost version specified in the list. If a shared library is
built with a list of version identifiers, the loader will allow
any executable to run that has a shared library dependency on
any of the listed versions. Sets DT_SONAME for a shared object.
The name can be a single component name (for example, libc.a), a
full pathname (starting with a slash), or a relative pathname
(containing a slash). The default DT_SONAME used for shared
objects is the filename component of the output file name.
Specify the output file name using the -o option as described
previously. Registers the location of this shared object's seg‐
ments and makes sure they stay out of the way of others in the
location_file. Location_file is updated if it is writable.
Directs the linker to load the executable file in the lower
31-bit addressable virtual address range. The -T and -D options
to the ld command can also be used, respectively, to ensure that
the text and data segments are loaded into low memory.
The -taso option, however, in addition to setting default
addresses for text and data segments, also causes shared
libraries linked outside the 31-bit address space to be appro‐
priately relocated by the loader. If you specify -taso and also
specify text and data segment addresses with -T and -D, those
addresses override the -taso default addresses. The -taso option
can be helpful when porting programs that assume address values
can be stored in 32-bit variables (that is, programs that assume
that pointers are the same length as int variables). Directs
the linker to use the threadsafe version of any library speci‐
fied with the -l option when linking programs. This option also
tells the linker to include the POSIX 1003.4a Draft 4 conformant
DECthreads interfaces. It is supported only for compatibility
with earlier releases of Tru64 UNIX. New designs should use the
-pthread option.
Optimization Options
Directs the compiler to assume the ANSI C aliasing rules, and thus
allows the optimizer to be more aggressive in its optimizations.
The aliasing rules are explained in Section 3.3, paragraphs 20
and 25 of the ANSI C Standard, reprinted as follows:
“An object shall have its stored value accessed only by an
lvalue that has one of the following types: The declared type of
the object, A qualified version of the declared type of the
object, A type that is the signed or unsigned type corresponding
to the declared type of the object, A type that is the signed or
unsigned type corresponding to a qualified version of the
declared type of the object, An aggregate or union type that
includes one of the aforementioned types among its members
(including, recursively, a member of a subaggregate or contained
union), or A character type.”
If your program does not access the same data through pointers
that have different types (and for this purpose, signed and
qualified versions of an otherwise same type are considered to
be the same type), then assuming ANSI C aliasing rules allows
the compiler to generate better optimized code.
If your program does access the same data through pointers that
have different types (for example, by a “pointer to int” and a
“pointer to float”), you must not allow the compiler to assume
ANSI C aliasing rules because these rules can result in the gen‐
eration of incorrect code.
The -noansi_alias option turns off ANSI C aliasing rules.
The default is -noansi_alias except when compiling with -std1
(when combined with -O3 or higher) or -fast. Tells the compiler
whether the source code follows all ANSI rules about arguments,
that is, whether the type of an argument matches the type of the
parameter in the called function or whether a function prototype
is present so the compiler can automatically perform the
expected type conversion.
Specifying -noansi_args means that the argument type may not
match the expected parameter type. This option is important, for
example, when the caller passes a parameter of type long and the
called routine expects an int. The -noansi_args option forces
the compiler to generate argument cleaning code to convert the
argument to the appropriate type. Except when the -std1 option
is specified, -noansi_args is the default. Note that it is safe
to specify -ansi_args if you use ANSI-style function prototypes
at all call sites.
Specifying -ansi_args means that your code meets the ANSI C
requirements, so no special argument cleaning code is generated.
This is a performance gain. When -std1 is specified, -ansi_args
is the default. Specifies the assumption that all array parame‐
ters are or are not restricted. The default is -assume noar‐
ray_parameter_restricted_pointers. For the sample declaration:
foo(int * __restrict p1, int p2[], int * p3, int **p4);
The following statements apply: By default, only p1 is
restricted. If you specify -assume array_parame‐
ter_restricted_pointers, p1 and p2 are restricted. If you spec‐
ify -assume parameter_restricted_pointers, p1, p2, p3 and p4 are
restricted, but *p4 is not restricted If you specify -assume
restricted_pointers, p1, p2, p3, p4, and *p4 are restricted. If
you specify -assume ignore_restricted_pointers, no pointers are
restricted, not even p1.
Each of these assumptions is negatable independently by prefix‐
ing a no to the assumption name. By default, all of the assump‐
tions are in this negated state. The state of each assumption is
resolved separately by processing negations in left-to-right
order. For example, -assume norestricted_pointers -assume
restricted_pointers is resolved to -assume restricted_pointers.
At the same time, the four assumptions have strictly-increasing
strength in the order shown, such that the behavior is deter‐
mined only by the strongest assumption in effect at the end of
the command line, regardless of their relative placement. Thus
if -ignore_restricted_pointers is in effect, the state of any
other assumption is ignored. For the other assumptions, this
"strength" effect is a natural result of supersetting.
The -assume norestricted_pointers option disables the __restrict
keyword from all pointers. This can help detect inappropriate
use of __restrict. If the code works correctly at high optimiza‐
tion with __restrict turned off, but breaks with it turned on,
it is likely that the compiler encountered a pointer that was
restricted in error. Restricted pointers are an assertion by the
programmer to aid optimization; the compiler cannot detect erro‐
neous assertions. Specifies the assumption that the restricted
attribute is or is not ignored for all pointers. The default is
-assume noignore_restricted_pointers. For more information, see
-assume [no]array_parameter_restricted_pointers. Controls the
compiler's assumption about a program's dependence on the set‐
ting of errno by math library routines: By default (-assume
math_errno), the compiler assumes that the program might inter‐
rogate errno after any call to a math libarry routine that is
capable of setting errno. The definition of the ANSI C math
library allows programs to depend on this behavior, which unfor‐
tunately restricts optimization because this causes most math
functions to be treated as having side effects. Specifying
-assume nomath_errno instructs the compiler to assume that the
program does not look at the value of errno after calls to math
functions. This assumption allows the compiler to reorder or
combine computations to improve the performance of those math
functions that it recognizes as intrinsic functions. In prac‐
tice, robust floating-point code seldom relies on errno to
detect domain or range errors, so -assume nomath_errno can often
be safely used to improve performance. Specifies the assumption
that all pointer parameters are or are not restricted. The
default is -assume noparameter_restricted_pointers. For more
information, see -assume [no]array_parameter_restricted_point‐
ers. Specifies the assumption that all pointers are or are not
restricted. The default is -assume norestricted_pointers. For
more information, see -assume [no]array_parame‐
ter_restricted_pointers. Specifies that no occurrences of the
address-of operator (&) are being applied outside the current
compilation unit to extern variables that are declared inside
the current compilation unit. Making this assertion allows the
compiler to perform better optimizations.
This option is often suitable for use with the -ifo option,
which presents a group of source files to the compiler as a sin‐
gle compilation unit. Enables runtime checking of certain
OpenMP constructs. This includes runtime detection of invalid
nesting and other invalid OpenMP cases. When invalid nesting is
discovered at runtime and this option is set, the executable
will fail with a Trace/BPT trap. If this option is not set and
invalid nesting is discovered, the behavior is indeterminate
(the executable may hang, and so on). See also the -mp and -omp
options. Provides a single method for turning on a collection
of optimizations for increased performance.
Note that the -fast option can produce different results for
floating-point arithmetic and math functions, although most pro‐
grams are not sensitive to these differences.
The -fast option defines the following compiler options and sym‐
bols to improve run-time performance. You can adjust the opti‐
mizations by specifying the negation of any given option.
Directs the compiler to assume the ANSI C aliasing rules, and
thus allows the optimizer to be more aggressive in its optimiza‐
tions.
See the description of this option elsewhere in this reference
page for more detailed information about this operation. Tells
the compiler that the source code follows all ANSI rules about
arguments; that is, whether the type of an argument matches the
type of the parameter in the called function, or whether a func‐
tion prototype is present so the compiler can automatically per‐
form the expected type conversion.
See the description of this option elsewhere in this reference
page for more detailed information about this operation. Allows
the compiler to reorder or combine computations to improve the
performance of those math functions that it recognizes as
intrinsic functions.
See the description of this option elsewhere in this reference
page for more detailed information about this operation. Speci‐
fies that this is a strictly-conforming ANSI C program with
respect to the dereferencing of pointer-to-short variables.
This allows the compiler to assume that any short accessed
through a pointer is naturally aligned (as the C language
requires). It typically produces the fastest code but can
silently generate the wrong results if any such short object
crosses a quadword boundary.
See the description of this option elsewhere in this reference
page for more detailed information about this operation. This
option affects the compilation of a number of system header
files, causing them to compile #pragma intrinsic directives for
certain functions that they declare. The exact functions
affected may vary depending on the language mode and other macro
definitions. See the header files math.h, stdio.h, stdlib.h,
string.h, and strings.h for details. The exact effect of each
#pragma intrinsic varies by function, by optimization options,
and by other compile-time options. The basic effect is to
inform the compiler that the function specified in the pragma is
the one by that name whose behavior is known to the compiler
(that is, it is a standard C or commonly-used library function
rather than a user-written external function). This gives the
compiler license to perform additional checks on the usage of
the function and issue diagnostics, and to optimize and/or re‐
write calls to it based on the compiler's understanding of what
the function does. Some possible optimizations include generat‐
ing complete inline code, generating partial inline code with
calls to one or more different functions, or just using charac‐
teristics of the function to move the call site or avoid some of
the overhead triggered by an external call. This option affects
the compilation of stdio.h in two ways: Whenever the header file
would otherwise define getc and putc as preprocessor macros
expanding into code to access the _cnt and _ptr members of the
referenced FILE object directly, instead these macros are
defined to invoke inlined static functions defined in the header
file. The use of an inlined static function instead of a simple
macro prevents the argument from being evaluated more than once
(so arguments containing side effects do not cause a problem),
and the function generally will produce better code because it
uses local declarations to avoid aliasing assumptions that the
compiler has to make when analyzing the traditional macro expan‐
sions of getc and putc. Note that getc and putc are not expanded
inline when i/o locking is required, as is normally the case for
reentrant or thread-safe compilations. If -D_INTRINSICS was
also specified, making printf and fprintf intrinsic functions,
then certain of the low-level runtime support routines that may
be called for special cases of format strings are defined as
inline static functions in the header file, avoiding external
calls to these routines in libc. Causes the /usr/include/math.h
file to redefine the names of certain common math routines,
including sqrt and exp, so that faster but slightly less accu‐
rate functions are used. The fast math routines do not support
IEEE exceptional behavior. Tells the compiler that it is not
necessary to promote expressions of type float to type double.
See the description of this option elsewhere in this reference
page for more detailed information about this operation. Allows
floating-point operations to be reordered during optimization.
See the description of this option elsewhere in this reference
page for more detailed information about this operation. Per‐
forms inter-file optimizations, but only if more than one file
is specified on the command line.
See the description of this option elsewhere in this reference
page for more detailed information about this operation. Con‐
trols whether the compiler recognizes certain functions as
intrinsic functions.
See the description of this option elsewhere in this reference
page for more detailed information about this operation. Sets
the optimization level.
See the description of this option elsewhere in this reference
page for more detailed information about this operation. Makes
string literals read-only for improved performance.
See the description of this option elsewhere in this reference
page for more detailed information about this operation. Speci‐
fies that the compiler should use the profile information con‐
tained in file when performing optimizations.
There are two forms of this option. One form is selected if file
is a data file, typically produced by prof after running a
pixie-instrumented version of the program. The other form is
selected if file is an executable program file. The -feedback
option automatically determines whether file is a data file or
an executable file and processes it accordingly.
If file is a data file, the -feedback option uses the data in
file to guide the compiler optimizer (and cord if -cord is also
specified). The -g1 debug level is recommended here in either
case.
If file is an executable file, the -feedback option uses the
data in file to guide the compiler optimizer (and spike if
-spike is also specified). If file does not exist, this compila‐
tion step prepares it to receive profiling data in the future.
See Spike and Profile-Directed Optimization in the Programmer's
Guide for details. The compiler defaults to the -g1 debug level
here, overriding any explicit -g0, but honoring any -g, -g2, or
-g3 option.
While both the cord and spike post-link optimizers reorder pro‐
cedures to reduce cache thrashing, spike is typically more
effective. When employing both -feedback and spike, use the sec‐
ond (executable) form of file, which allows both the compiler
and spike to use data derived from a single profile training
run. Specifies whether certain code transformations that affect
floating-point operations are allowed. These changes can affect
the accuracy of the program's results.
The -nofp_reorder option, the default, directs the compiler to
use only certain scalar rules for calculations. This setting can
prevent some optimizations. The -fp_reorder option frees the
compiler to reorder floating-point operations based on algebraic
identities (inverses, associativity, and distribution). For
instance, this allows the compiler to move divide operations
outside of loops, thus improving performance.
If you specify -fp_reorder and the compiler reorders code to
improve performance, the results can differ from the default,
for example, due to the way intermediate results are rounded.
However, the -fp_reorder results are not categorically less
accurate than those gained by the default. Provide improved
optimization (inter-file optimization) and code generation
across file boundaries that would not be possible if the files
were compiled separately.
When you specify -ifo on the command line in conjunction with a
series of file specifications, the compiler does not concatenate
each of the specified source files. Instead, each file is
treated separately for purposes of parsing, except that the com‐
piler will issue diagnostics about conflicting external declara‐
tions and function definitions that occur in different files.
For purposes of code generation, the compiler treats the files
as one application. The default is to not provide inter-file
optimization. Specifies whether to provide inline expansion of
functions. This is the default for -O2, -O3, -O4. The -noinline
option disables this optimization.
When choosing calls to expand inline, the compiler also consid‐
ers the function size, how often the call is executed, how many
registers the inline expansion will require, and other factors.
You can specify one of the following as the keyword to control
inlining: No inlining is done, even if requested by a #pragma
inline preprocessor directive. This is the default when compil‐
ing with the -O0 option. Inlines only those function calls
explicitly requested for inlining by a #pragma inline directive.
This is the default when compiling with the -O1 option. Inlines
all of the function calls in the manual category, plus any addi‐
tional calls that the compiler determines would improve run-time
performance without significantly increasing the size of the
program. This is the default when compiling with the -O2 or -O3
option. Inlines all of the function calls in the manual cate‐
gory, plus any additional calls that the compiler determines
would improve run-time performance, even where it may signifi‐
cantly increase the size of the program. Inlines every call
that can be inlined while still generating correct code. Recur‐
sive routines, however, will not cause an infinite loop at com‐
pile time.
For optimization level 0 (-O0), the -inline option is ignored
and no inlining is done. The #pragma noinline preprocessor
directive can also prevent inlining of any function. The
-intrinsics option causes the compiler to recognize intrinsic
functions wherever it can automatically, based only on name and
call signature. Unlike -D_INTRINSICS, this option can treat
library function calls as intrinsic even when the appropriate
header file is not included. Any function declaration or call
site (in the case of implicit declaration) with a name matching
the name of an intrinsic function is examined to see if its
parameters and return result are consistent with the intrinsic
function of that name. If so, calls are treated as being intrin‐
sic. If not, a diagnostic is issued and calls are treated as
ordinary external function calls.
When the compiler identifies a function as an intrinsic func‐
tion, it is then free to make code optimizations (transforma‐
tions) based on what it knows about the operations performed by
the standardized version of that function--given an optimization
level (-On) that enables the intrinsic treatment of that partic‐
ular function.
The optimization level determines which functions can be treated
as intrinsics: No intrinsic functions. The -intrinsics option
has no effect at this optimization level. Memory and string
functions: alloca, bcopy, bzero, memcpy, memmove, memset, str‐
cpy, strlen
Math functions: abs, fabs, labs, atan, atan2, atan2f, atand,
atand2, atanf, ceil, ceilf, cos, cosd, cosf, floor, floorf, sin,
sind, sinf. fprintf, printf, snprintf, sprintf acos, acosf,
asin, asinf, cosh,coshf, exp, expf, log, log10, log10f, logf,
log2, pow, powf, sqrt, sqrtf, sinh, sinhf, tan, tand, tanf,
tanh.
The effects of the various optimization levels are cumulative;
for example, -fast causes the functions at the -02 (or -O) and
-O3 optimization levels to be treated as intrinsics--in addition
to the intrinsic function treatment that is triggered by -fast
itself.
The -intrinsics option is in effect by default. To disable the
default, specify the -nointrinsics option. To disable the
intrinsic treatment of individual functions, specify the func‐
tion names in a pragma function directive in either your source
code or a file associated with a -FI option (“file include”
option).
Although -intrinsics is the default (and it will generally treat
calls to [f]printf as intrinsic), in order to have the low-level
support routines for intrinsic [f]printf inlined, the compila‐
tion must include and also specify both -D_INTRINSICS and
-D_INLINE_INTRINSICS on the command line. Causes the compiler
to recognize an older form of parallel programming directives,
as well as OpenMP directives, and pass libots3 and appropriate
thread libraries to the linker. It also predefines the macro
_OPENMP with a value of 0. Programs may use both forms of direc‐
tives if they are in sections of code that do not interact with
each other -- the purpose being to ease migration from the older
form to OpenMP. See also the -omp and -check_omp options.
Determines the level of optimization. The following table lists
the types of optimizations that can be performed at each level:
────────────────────────────────────────────────────────────────────────
Level Optimization
────────────────────────────────────────────────────────────────────────
-O0 None
-O1 Local optimizations and recognition of common sub‐
expressions. Global optimizations, including code
motion, strength reduction and test replacement,
split lifetime analysis, and code scheduling.
-O2, -O Inline expansion of static procedures. Additional
global optimizations that improve speed (at the
cost of extra code size), such as integer multipli‐
cation and division expansion (using shifts), loop
unrolling, and code replication to eliminate
branches.
-O3 Inline expansion of global procedures.
-O4 Software pipelining using dependency analysis, vec‐
torization of some loops on 8-bit and 16-bit data
(char and short), and insertion of NOP instructions
to improve scheduling.
────────────────────────────────────────────────────────────────────────
If your application will be built into a shared library, avoid
using the -O3 and -O4 options, because these levels may inhibit
the ability to preempt symbols. Also, benchmarking is recom‐
mended to determine if -O4 is better than -O3 for your particu‐
lar application, as this is not always true. Performs code
optimization after linking, including nop (no operation)
removal, removal, and reallocation of common symbols. This
option also positions the $gp register so that the maximum num‐
ber of addresses fall in the $gp-accessible window. This option
is most effective when used with the -non_shared option. When
you specify -om by itself, you get the full range of postlink
optimizations. You can request a particular optimization by
specifying -om followed by one of the following options: Removes
unused entries after optimization, and then compresses the sec‐
tion. Removes dead code (unreachable instructions) generated
after applying optimizations. The section is not compressed by
this option. Uses the pixie-produced information stored in the
augmented executable by means of the cc command's -feedback
option and the pixie (or prof) command's -update option. Sets
the size threshold of “common” symbols. Every “common” symbol
whose size is less than or equal to num will be allocated close
to each other. This option can be used to improve the probabil‐
ity that the symbol can be accessed directly from the $gp regis‐
ter. (Normally, om tries to collect all “common” symbols
together, not just symbols that conform to certain size con‐
straints.) Uses the pixie-produced information in file.Counts
and file.Addrs to reorganize the instructions to reduce cache
thrashing. Turns off instruction scheduling. Turns off align‐
ment of labels. Normally, the -om option will align the targets
of all branches on quadword boundaries to improve loop perfor‐
mance. Splits frequently accessed routines into “hot” and
“cold” code segments, and stores these segments in different
parts of the image. The hot segments are the most frequently
executed parts of the code, as determined by feedback data pro‐
duced by a representative run of the program. The hot segments
are stored near other parts of the program that are also exe‐
cuted frequently. In this way, the most frequently executed
parts of the program are compacted in a way that makes them more
likely to fit into the cache. This speeds up the execution time
of that code.
For additional information on om, send email to wrl-techre‐
ports@decwrl.dec.com, specifying help on the subject line. Then,
follow the instructions in the reply you receive to obtain
report number 94/1. Causes the compiler to recognize the OpenMP
(http://www.openmp.org) shared memory parallel programming API
pragmas and pass libots3 and appropriate thread libraries to the
linker. It also predefines the macro _OPENMP with a nonzero
value. Note that under this option, the older parallel program‐
ming directives enabled by the -mp option are ignored. See also
the -mp and -check_omp options. Supports symbol preemption on a
module-by-module basis. During optimization, inlining is per‐
formed only on functions within a single compilation unit. This
is the default in the following cases: At optimization levels
-O3 and -O4. When -ifo is used. When the compilation is pro‐
ceeding directly to an a.out executable file, that is, when none
of the following options are specified on the command line: -c,
-r, or -shared.
In all other cases, -preempt_symbol is the default. Preserves
full symbol preemption; that is, supports symbol preemption on a
symbol-by-symbol basis within a module as well as between mod‐
ules. Restricts the optimizer so that calls to extern functions
are ineligible for inline replacement.
The default taken for a compilation is either -preempt_symbol or
-preempt_module. See the description of the -preempt_module
option for details on the conditions that determine which option
is taken as the default. Specifies that speculation may occur
anywhere in the executable image.
Speculation is a compiler optimization that causes the hardware
to begin executing an operation before it determines that the
flow of control will actually reach that operation. If the flow
of control does reach that operation, the result will be avail‐
able sooner than it would have been without speculative execu‐
tion. If the flow of control does not reach that operation, the
result will simply be ignored.
Since unsuccessful speculative operations can generate excep‐
tions, all exceptions are dismissed when any module that con‐
tributes to the application is compiled with the -speculate all
option (though floating-point instructions specifying software
completion are still handled normally). This optimization is
therefore inappropriate for codes that use any form of local
exception handling (or is linked to other codes that do). Spec‐
ifies that speculation is allowed only in the code in the source
module that is being compiled.
A module compiled with -speculate by_routine cannot use any form
of local exception handling, but can be linked with other mod‐
ules that do. The run-time system checks each exception to see
if it occurred in a speculative routine. It dismisses exceptions
from routines that are speculatively executed, but signals
exceptions from other routines. (Note, though, that floating-
pointing instructions specifying software completion [/S] are
still given normal exception handling.) As a result, you should
use the -speculate by_routine option only for modules that are
known to be error-free and that do not depend on fault and trap
handling. If code compiled speculatively incurs a lot of excep‐
tions, it may result in an overall performance loss. If this is
so, you should discontinue use of this feature.
The -speculate by_routine option yields somewhat slower execu‐
tion than the -speculate all option, but does not restrict trap
and fault handling in other modules with which it is linked.
Invokes the spike tool to perform code optimization after link‐
ing a program. -spike is a replacement for -om and does similar
optimizations. See spike(1) for complete information on the
spike command, its options, and its relationship to -spike.
-spike is particularly useful with -feedback. All of the spike
command's options can be passed directly to -spike by using the
-WS compiler option. The following example shows the syntax: %
cc-spike -feedback prog -o prog *.c \
-WS,-splitThresh,.999,-noaggressiveAlign
For detailed examples using the -spike option and spike command,
see spike(1) and the Programmer's Guide. Instructs the opti‐
mizer to tune the application for a specific version of the
Alpha hardware. This will not prevent the application from run‐
ning correctly on other versions of Alpha but it may run more
slowly than generically-tuned code on those versions.
The option argument can be one of the following, which selects
instruction tuning appropriate for the listed processor(s): All
Alpha processors. This is the default. The processor on which
the code is compiled. The 21064, 21064A, and 21068 processors.
The 21164 processor. (Both EV5 and EV56 are numbered 21164.)
The 21264 processor. The 21264A processor. The 21164PC proces‐
sor.
See also the -arch option for an explanation of the differences
between -tune and -arch. Controls the loop-unrolling optimiza‐
tion (available only at levels -O2 and higher). -unroll n
allows the compiler to unroll loops up to n times. -unroll 1
disables the optimization. -unroll 0 (the default) allows the
compiler to decide what is best.
Feedback-directed Optimization Options
Generates accurate profile information to be used with -feedback opti‐
mizations, as follows: Compile the source code with the -gen_feedback
option. Run pixie on the executable file. Execute the pixie version
of the program to generate execution statistics on the program. Use
prof to create a feedback file from the execution statistics. Recom‐
pile the program with the -feedback option and optimization level -O1
or above. This provides the compiler with execution information that
the compiler can use to improve certain optimizations. Generates an
executable image that has profiling code added to it. Using this option
is equivalent to running the pixie command on an existing image. The
pixie-instrumented file is called a.out (or as specified with the -o
option). The uninstrumented file is given an extension of of the
-prof_use_om_feedback, -prof_dir, and -pids options. Generates a non-
optimized executable image that, when run, will generate profiling data
that the compiler can use to improve its optimization choices (with
-prof_use_feedback).
This switch is equivalent to the combination -prof_gen
-gen_feedback and does not require the direct use of the pixie
or prof tools or the -feedback option. It is the simplest way to
use feedback-directed compiler optimization.
The recommended usage is as follows: Compile the source code
with -prof_gen_noopt. Run the program. Recompile the source
code with -prof_use_feedback.
For more information, see pixie(5) and prof(1), and -prof_gen,
-gen_feedback, and -prof_use_feedback. For information about
manipulating the name and location of the feedback data files,
see -pids and prof_dir. Uses profiling feedback to improve com‐
piler optimization. Using this option is equivalent to using the
prof(1) command to produce a feedback file, and then using the
cc-feedback command to recompile the program.
To use the -prof_use_feedback option, first compile your program
with the -prof_gen and -gen_feedback options and then run the
program to generate the needed profiling data. Uses profiling
feedback to rearrange the resulting image to reduce cache con‐
flicts of the program text. This option uses the -om postlink
optimizer, and is equivalent to using the -om-WL,-om_ire‐
org_feedback options. If the -pids option is also specified,
this option merges the performance data files using the prof
-pixie -merge command.
To use the -prof_use_om_feedback option, first compile your pro‐
gram with the -prof_gen option and then run the program to gen‐
erate the profiling data. Specifies a location to which the
profiling data files (.Counts and -prof_gen option and the
-prof_use_feedback or -prof_use_om_feedback option to specify a
location for the profiling data files. If you do not specify
this option, the profiling files are written to the current
directory.
Specifying the -prof_dir option also enables the -pids option.
[Disables] or enables the addition of the process-id to the
filename of the basic block counts file (.Counts). This facili‐
tates collecting information from multiple invocations of the
pixie output file. Unless the -prof_dir option is specified, the
default is -nopids.
Source-code Debugging Options
Produces symbol table information for debugging. When no value is spec‐
ified for n, the compiler produces symbol table information for full
symbolic debugging and suppresses optimizations that limit full sym‐
bolic debugging (same as -g2).
The value of n can be one of the following (-g is the same as
-g2): Produces only enough symbol table information for linking.
Names and addresses of external symbols, and the addresses and
basic layout of the stack-frame are available. Profiling tools
work, but the names of local procedures, source lines, and
source file names are not available. The debugger allows proce‐
dure traceback and all instruction-level commands. However,
line-oriented commands do not work. No symbol types are avail‐
able, and the names of stack-frame and static variables are not
available. All optimizations are supported. Produces limited
symbol table information. Profiling and debugging tools provide
line numbers, source file names, and the names of local proce‐
dures, when appropriate. Line-oriented debugging commands work,
but symbol types and the names of stack-frame variables are not
available. Most profiling tools work to their fullest ability,
but some advanced Atom tools may provide more information at
higher debug levels. All optimizations are supported. Produces
symbol table information for full symbolic debugging and sup‐
presses some optimizations. Symbol types and stack-frame vari‐
ables names are available. Optimization is suppressed (-g2
implies -O0). Produces symbol table information for fully opti‐
mized code. This level of debugging supplies the same informa‐
tion as -g2, but it also allows all compiler optimizations. As a
result, some of the correlation is lost between the source code
and the executable program.
Program Profiling Options
Determines the level of profiling. The -p option prepares for profiling
by periodically sampling the value of the program counter. This option
affects linking only, so that when linking occurs, the standard run-
time startup routine is replaced by the profiling run-time startup rou‐
tine (mcrt0.o) and the level 1 profiling library (libprof1.a) is
searched. When you use the -p option together with either the -pthread
option or the -threads option, the profiling library libprof1_r.a is
used.
When profiling begins, the startup routine calls monstartup (see
monitor(3)) and produces, in file mon.out, execution-profiling
data for use with the postprocessor prof(1).
The value n can be one of the following: Do not permit any pro‐
filing. This is the default. If linking occurs, the standard
run-time startup routine (crt0.o) is used, and no profiling
library is searched. Same as -p. Turns gprof profiling on or
off when compiling and linking the file immediately following
this option. The gprof profiler produces a call graph showing
the execution of a C program.
When this option is turned on, the standard run-time startup
routine is replaced by the gcrt0.o routine. Programs that are
linked with the -pg option and then run will produce, in file
gmon.out, a dynamic call graph and profile. You then run gprof
on the gmon.out file to display the output. When you use the
-pg option together with either the -pthread option or the
-threads option, the profiling library libprof1_r.a is used.
For more information, see the gprof(1) reference page.
Data Alignment Options
Controls the alignment assumptions for code generated for indirect load
and store instructions.
The -assume aligned_objects option causes the compiler to assume
that a dereferenced object's alignment matches or exceeds the
alignment indicated by the pointer to the object. On Alpha sys‐
tems, dereferencing a pointer to a longword- or quadword-aligned
object is more efficient than dereferencing a pointer to a byte-
or word-aligned object. Therefore, when the compiler assumes
that a pointer object of an aligned pointer type does point to
an aligned object, it can generate better code for pointer
dereferences of aligned pointer types.
The -assume noaligned_objects option causes the compiler to gen‐
erate longer code sequences to perform indirect load and store
operations in order to avoid hardware alignment faults for arbi‐
trarily aligned addresses. Although the -assume
noaligned_objects option may generate less efficient code than
-assume aligned_objects, by avoiding hardware alignment faults,
it speeds the execution of programs that reference unaligned
data.
The -assume aligned_objects option is the default. The compiler
assumes that the alignment of pointers meets or exceeds that of
the objects to which they point. The following rules apply: A
pointer of type short points to objects that are at least short-
aligned. A pointer of type int points to objects that are at
least int-aligned. A pointer of type struct points to objects
that have an alignment of struct (that is, the alignment of the
strictest member alignment, or byte alignment if you have speci‐
fied #pragma nomember_alignment for struct).
If your module breaks one of these rules, you must use the
-assume noaligned_objects option to compile the module; other‐
wise, your program may get alignment faults during execution,
which will degrade performance.
The -assume aligned_objects and -assume noaligned_objects
options can be used in the same cc command, allowing you to turn
this option on and off as needed by individual source files.
The -misalign option is a synonym for -assume noaligned_objects
and the -nomisalign option is a synonym for -assume
aligned_objects. Controls whether the compiler can assume that
this is a strictly-conforming ANSI C program with respect to the
dereferencing of pointer-to-short variables.
Specifying -assume trusted_short_alignment allows the compiler
to assume that any short object accessed through a pointer is
naturally aligned. This may produce the fastest code but can
silently generate the wrong results if any such short object
crosses a quadword boundary.
Specifying -assume notrusted_short_alignment tells the compiler
that dereferenced short objects may not be naturally aligned (as
both ANSI C and K&R C require). This may produce slightly slower
code, but that code will produce the correct results regardless
of data alignment. This is the default.
Note that -assume notrusted_short_alignment does not override
the __unaligned type qualifier, the -misalign option, or the
-assume noaligned_objects option. Controls the compiler's
alignment assumptions for code generated for indirect load and
store instructions.
The -misalign option is a synonym for -assume noaligned_objects
and the -nomisalign option is a synonym for -assume
aligned_objects. The -assume [no]aligned_objects option is dis‐
cussed earlier in this reference page. Directs the compiler to
byte-align data structure members (with the exception of bit-
field members).
By default, data structure members are aligned on natural bound‐
aries (that is, on the next boundary appropriate to the type of
the member) instead of the next byte. For example, an int vari‐
able member is aligned on the next longword boundary, and a
short variable member is aligned on the next word boundary.
Any use of the #pragma member_alignment, #pragma nomember_align‐
ment, or #pragma pack directives within the source code over‐
rides the setting established by this option.
The use of the -nomember_alignment option can cause conflicts
between the compiler's assumptions about data layouts and the
default values that were in effect when the system libraries
were created. See protect_headers_setup(8) for details on how to
avoid this conflict. Aligns structure members and entire struc‐
tures based on the integer n, where n can be 1, 2, 4, or 8. This
option sets a limit on the alignment given to structure members
so that each member after the first is stored on a maximum of an
n-byte boundary. For example, a 4-byte int member is aligned on
a 4-byte boundary under either -Zp8 or -Zp4. But under -Zp2 it
is aligned to the next 2-byte boundary, and under -Zp1 it begins
at the next byte (that is, it is unaligned). -Zp is equivalent
to -Zp1.
This option can also affect the alignment of the entire struc‐
ture, which is computed by default as the maximum alignment
requirement of any of its members. For example, if a structure
contains an 8-byte pointer followed by a 4-byte int, the entire
structure is assumed to be 8-byte aligned and padded to 16
bytes, by default (effectively -Zp8). Therefore, in an array of
such structures each array element starts on an 8-byte boundary.
Under -Zp4, the layout of members within the structure is
unchanged (the pointer is still at offset 0 and the int is at
offset 8), but now the entire structure is assumed to be only
4-byte aligned, and there is no padding added after the int, so
the size of the entire structure is only 12 bytes.
The use of the -Zpn option (where n!=8) can cause conflicts
between the compiler's assumptions about data layouts and the
default values that were in effect when the system libraries
were created. See protect_headers_setup(8) for details on how to
avoid this conflict.
Data Volatility Options
Affects the generation of code for assignments to objects that are less
than or equal to 16 bits in size (for instance char, short) that have
been declared as volatile. The generated code includes a load-locked
instruction for the enclosing longword or quadword, an insertion of the
new value of the object, and a store-conditional instruction for the
enclosing longword or quadword. By using this locked instruction
sequence for byte and word stores, the -strong_volatile option allows
byte and word access of data at byte granularity. This means that
assignments to adjacent volatile small objects by different threads in
a multithreaded program will not cause one of the objects to receive an
incorrect value. Affects the generation of code for assignments to
objects that are less than or equal to 16 bits in size (for instance
char, short) that have been declared as volatile. The generated code
includes a read of the enclosing longword or quadword, an insertion of
the new value of the object, and a store of the enclosing longword or
quadword. This is the default.
The -weak_volatile option does not generate locked instructions
for this sequence. This allows byte or word access to memory-
like I/O devices for which larger accesses will not cause read
or write side effects. Because the sequence does not access byte
or word data independently directly in memory (that is, ensure
byte granularity), adjacent volatile data can be corrupted when
such byte or word accesses are performed in a multithreaded
environment (for example, two volatile shorts stored in a long‐
word and accessed asynchronously).
C Language Options
Promotes expressions of type float to double. This is the default when
-std0 is used. Prevents the compiler from promoting expressions of
type float to type double. This is the default except in -std0 mode.
Causes the compiler to assign the type float (rather than double) to
floating-point constants if their values can be represented in single
precision. This option is not available in -std1 mode. Allows the com‐
piler to assume that string literals are read-only. This may improve
application performance. This option overrides -writable_strings, which
is the default.
Attempting to modify string literals when -readonly_strings is
specified may yield unpredictable results (for example, a seg‐
mentation fault). Causes all char declarations to have the same
representation and range of values as signed char declarations.
This is used to override a previous -unsigned option. This is
the default. Causes all char declarations to have the same rep‐
resentation and range of values as unsigned char declarations.
Prints warnings for all lines that may require the <varargs.h>
macros. Causes all variables to be treated as volatile. Causes
all string literals to be writable. This is the default.
This option overrides -readonly_strings.
Stack-handling and Pointer-handling Options
Forces all uninitialized stack variables to be initialized with
0xfff58005fff58005. When this value is used as a floating-point vari‐
able, it is treated as a floating-point NaN and causes a floating-point
trap. When it is used as a pointer, an address or segmentation viola‐
tion usually occurs. Causes the compiler to respect #pragma
pointer_size directives, which control the size of pointers. These
directives are ignored otherwise. Also causes the -taso option to be
passed to the linker (if linking).
Pointers are 64 bits by default. This option, when used in con‐
juction with the pointer_size pragmas, allows applications to
use 32-bit pointers. Images built with this option must be
linked with the -taso option in order to run correctly. See the
Programmer's Guide for information on #pragma pointer_size.
Same as the -xtaso option, except -xtaso_short also directs the
compiler to allocate 32-bit pointers by default. You can still
use 64-bit pointers, but only by the use of pointer_size prag‐
mas.
The use of the -xtaso_short option can cause conflicts between
the compiler's assumptions about pointer sizes and data layouts
and the default values that were in effect when the system
libraries were created. See protect_headers_setup(8) for
details on how to avoid this conflict. Makes all procedures in
the source file use $fp (register 15) as the frame pointer.
IEEE Floating-point Support Options
Specifies chopped rounding mode (round toward zero). Dynamically sets
rounding mode for IEEE floating-point instructions. The dynamic round‐
ing mode is determined from the contents of the floating-point control
register and can be changed or read at execution time by a call to
write_rnd(3) or read_rnd(3). If you specify -fprm d, the IEEE float‐
ing-point rounding mode defaults to round to nearest. Specifies normal
rounding mode (unbiased round to nearest). This is the default. Speci‐
fies round toward minus infinity mode. Generates instructions that do
not trigger floating-point underflow or inexact trapping modes. Any
floating point overflow, divide-by-zero, or invalid operation will
unconditionally generate a trap. The -fptm n option is the default.
Generates traps on floating-point underflow as well as overflow,
divide-by-zero, and invalid operation. Ensure support of all portable
features of the IEEE Standard for Binary Floating-Point Arithmetic
(ANSI/IEEE Std 754-1985), including the treatment of denormalized num‐
bers, NaNs, and infinities and the handling of error cases. This option
also sets the _IEEE_FP C preprocessor macro.
If your program must use IEEE signaling features that are not
portable across different IEEE implementations, see the ieee(3)
reference page for a discussion of how to access them under the
Tru64 UNIX operating system. Ensures that any trap (such as
floating-point overflow) is reported to have occurred in the
procedure or guarded scope that caused the trap. Any trap occur‐
ring outside that scope is not reported to have occurred in the
procedure or guarded scope, with the exception of well-defined
trapb instructions following jsr instructions.
Compiler Development Options (Not Generally Used)
Halts compiling after the pass specified by the character c, producing
an intermediate file for the next pass. The c character can be one of
the following: [fablL] (see the -t option for an explanation). It
selects the compiler pass in the same way as the -t option. If this
option is used, the symbol table file produced and used by the passes
is given the name of the last component of the source file with the
suffix changed to file is always retained after the compilation is
halted. Passes the argument, or arguments (argi), to the compiler
pass, or passes (c[c...]). Each c character can be one of the follow‐
ing: [ ablLzpfy ] (see the -t option for an explanation). The c selects
the compiler pass in the same way as the -t option. The -t, -h, and -B
options are used together to specify a location and/or name for one or
more compiler passes, tools, libraries, or include files, other than
their normal locations or names.
The -t option specifies which compiler passes (or components)
the -h and -B options that follow apply to. The c characters
can be one or more of the following:
────────────────────────────────────────────────────────────
Character Name of pass, tool, or component
────────────────────────────────────────────────────────────
h header file location (see note following table)
p cpp
f gemc_cc
a as0
b as1
l ld
z cord
r [m]crt0.o
n libprof1.a
L om
C pixie
D prof
y ftoc
B bbtool
────────────────────────────────────────────────────────────
Note
If the character h is in the -t argument, a directory is added
to the list of directories to be used in searching for header
files. The name of this directory has the form $COMP_TAR‐
GET_ROOT/usr/include/string. This directory is to contain the
header files for the string release of the compiler. The stan‐
dard directory is still searched.
If -t is not specified, the -h and -B options are applied to all
tools.
The -t and -h options are not processed until the next -B option
is processed. If more than one -t option or more than one -h
option appear on the command line before the next -B option,
only the last of the previous -t and -h option arguments are
used. Specifies the directory where the tool (or other compo‐
nent) specified with -t is located. If -h is omitted, the tool
is assumed to be in the usual location (for example,
/usr/lib/complrs/cc). If path is omitted, the tool is assumed
to be in the root directory (/). Specifies a suffix to add to
the normal names of any components specified with the -t option.
If string is omitted, the usual component names are used.
Directs the compiler to give recognizable names to intermediate
files and retain them for debugging purposes. Each file is
given the name of the last component of the source file, replac‐
ing its suffix with the conventional suffix for the type of file
(for example, suffix for binary ucode produced by the front
end). These intermediate files are never removed, even when a
pass encounters a fatal error. When ucode linking is performed
and the -K option is specified, the base name of the files cre‐
ated after the ucode link is u.out, by default. If -ko output is
specified, the base name of the object file, if it exists, is
output. If output includes a suffix, the suffix is not included
as part of the base name.
Invoking the compiler with a name of the form ccstring has the same
effect as using a -Bstring option on the command line.
In the following example, the -t, -h, and -B options specify that the
gemc_cc component to be used by the compiler is located in
/usr/projects and has the name gemc_cc.debugging: % cc-tf
-h/usr/projects -B.debugging prog1.c
DESCRIPTION
The cc command invokes the C compiler. It accepts any of the following
file arguments: Arguments whose names end with are assumed to be C
source programs. They are compiled, and each object program is left in
a file whose name consists of the last component of the source with
substituted for file is deleted only when a single source program is
compiled and loaded all at once. Arguments whose names end with are
assumed to be symbolic assembly language source programs. They are
assembled, producing a file. Arguments whose names end with are
assumed to be C source files after being processed by the C preproces‐
sor. Arguments whose names do not end with are assumed to be either C-
compatible object files, typically produced by an earlier cc run, or
libraries of C-compatible routines.
The cc command accepts options that are specific to either the cc com‐
mand or the ld command (linker). When the compiler recognizes position-
sensitive linker options (-L, -all, -exclude, -exported_symbol, -hid‐
den, -hidden_symbol, -l, -none, -non_hidden, -noarchive, -noso, and
-so_archive), it maintains their relative order for the linker. This
reference page describes the options that are specific to the cc com‐
mand. See ld(1) for a description of the linker options.
All of the input files, plus the results of the compilations, are
loaded in the order given to produce an executable program with the
default name a.out. The compiler can produce object files in extended
COFF format (the normal result). It can also produce object files in
symbolic assembly language format when invoked with the -S option.
When the compiler is invoked, it defines C preprocessor macros that
identify the language of the input files and the environments in which
the code can run. You can reference these macros in #ifdef statements
to isolate code that applies to a particular language or environment.
Use the following statement to uniquely identify Tru64 UNIX: #if
defined (__digital__) && defined (__unix__)
The C preprocessor macros are listed in the following table. Note that
the type of standards you apply and the type of source file determine
which macros are defined.
─────────────────────────────────────────────────────────────────
Macro Source File Type -std option
─────────────────────────────────────────────────────────────────
__DECC .c
__DECC_VER .c -std0, -std, -std1
LANGUAGE_C .c -std0
__LANGUAGE_C__ .c -std0, -std, -std1
unix .c, .s -std0
__unix__ .c, .s -std0, -std, -std1
__osf__ .c, .s -std0, -std, -std1
__alpha .c, .s -std0, -std, -std1
__arch64__ .c, .s -std0, -std, -std1
__digital__ .c, .s -std0, -std, -std1
_LONGLONG .c, .s -std0, -std, -std1
SYSTYPE_BSD .c, .s -std0
_SYSTYPE_BSD .c, .s -std0, -std, -std1
LANGUAGE_ASSEMBLY .s -std0, -std, -std1
__LANGUAGE_ASSEMBLY__ .s -std0, -std, -std1
─────────────────────────────────────────────────────────────────
You can explicitly define macros with the -D option to control which
functions are declared in header files and to obtain standards confor‐
mance checking. See standards(5) for a list of the macro names and
details on the function declarations and standards conformance checking
associated with the various macros.
While the -D option controls which functions are declared in header
files, the -stdn options control how strictly the declarations conform
to the ANSI C standard. For strict ISO C and ANSI C conformance, the
compiler command line must include the -std1 option.
To facilitate setting default compiler options, you can create an
optional configuration file named comp.config or an environment vari‐
able named DEC_CC: The comp.config file allows system administrators to
establish a set of compilation options that are applied to compilations
on a system-wide basis. The compiler options in comp.config must be
specified on a single line, and the comp.config file should be stored
in the compiler target directory, /usr/lib/cmplrs/cc. The DEC_CC envi‐
ronment variable allows C users to establish a set of compilation
options that are applied to subsequent compilation on a per-user basis.
The DEC_CC environment variable can contain two distinct sets of
compilation options separated by a single vertical bar (|). The
options before the vertical bar are known as prologue options
and the options after the bar are know as epilogue options.
The DEC_CC environment variable can begin or end with a vertical
bar, or have no vertical bar at all. If no vertical bar is
present, the options are treated as prologue options by default.
Any vertical bar found after the first vertical bar is treated
as whitespace and a warning is issued.
Compiler options are processed in the following order during a compila‐
tion: comp.config prologue options DEC_CC prologue options command line
options DEC_CC epilogue options comp.config epilogue options
If -v is specified on the command line, the contents of DEC_CC and
comp.config, if present, are displayed.
EXAMPLES
To compile the file helloworld.c using the compiler's defaults use the
following command: cc helloworld.c
Because no output file is named in the command line, the result
of the compilation is written to the executable file named
a.out. In this example, the -v option displays the name of each
compilation pass--and its arguments--as it executes. cc-v hel‐
loworld.c
/usr/lib/cmplrs/cc/gemc_cc -D__LANGUAGE_C__ -D__unix__ -D__osf__
-D__alpha -D_SYSTYPE_BSD -D_LONGLONG -D__digital__ -D__arch64__
-I/usr/include -v-preempt_module-intrinsics -g0 -O2-std
-noansi_alias -o helloworld.o helloworld.c
These macros are in effect at the start of the compilation.
----- ------ --- -- ------ -- --- ----- -- --- ------------
-D__DECC -D__osf__ -D__arch64__ -D__PRAGMA_ENVIRONMENT -D_LONG‐
LONG -D__digital__-D__X_FLOAT -D__DATE__="Sep 2 1998"
-D__DECC_MODE_RELAXED -D__DECC_VER=50860509 -D_SYSTYPE_BSD
-D__ALPHA-D__IEEE_FLOAT-D__unix__ -D__TIME__="10:34:23"
-D__Alpha_AXP -D__INITIAL_POINTER_SIZE=0 -D__STDC__=0 -D__LAN‐
GUAGE_C__ -D__alpha /usr/lib/cmplrs/cc/gemc_cc: 0.05u 0.02s 0:00
77% 0+10k 0+3io 0pf+0w 10stk+1288mem /usr/lib/cmplrs/cc/ld -g0
-O1-call_shared /usr/lib/cmplrs/cc/crt0.o helloworld.o -lc
/usr/lib/cmplrs/cc/ld: 0.01u 0.01s 0:00 14% 0+11k 0+11io 0pf+0w
11stk+1288mem
ENVIRONMENT VARIABLES
The following environment variables can affect compiler operation:
Allows C users to establish a set of compilation options that are
applied to subsequent compilation on a per-user basis. See the DESCRIP‐
TION section for more information. The compiler driver uses the value
of DRV_DUMP to control the display of internal messages. This variable
is primarily used to diagnose the driver behavior. If set, causes the
compiler driver to display all the commands that would be invoked, but
to not actually execute those commands. Provides a default value for
locale variables that are not set. If any of these variables contains
an invalid setting, the compiler behaves as if none were set. If set
to a non-empty string, this variable overrides values in all locale
variables, including LANG. Determines the locale for the interpreta‐
tion of sequences of bytes of text data as characters (for example,
single- as opposed to multi-byte characters in arguments and input
files). Determines the locale used for diagnostic messages. Deter‐
mines the locale of message catalogs for the processing of LC_MESSAGES.
Provides a pathname that overrides the default directory for temporary
files, if any.
For more information on the internationalization environment variables,
see i18n_intro(5) and l10n_intro(5).
FILES
Input file Object file Loaded output Temporary Compiler configuration
file (optional) C macro preprocessor HP C compiler Post-link optimizer
Symbolic to binary assembly language translator Binary assembly lan‐
guage assembler and reorganizer Run-time startup Startup for prof pro‐
filing Startup for gprof profiling Standard library, see intro(3) Level
1 profiling library Reentrant level 1 profiling library for code com‐
piled with -pthread or -threads Standard directory for header files
Interface between prof and cord Procedure-rearranger File produced for
analysis by prof File produced for analysis by gprof
SEE ALSOas(1), atom(1), c89(1), cord(1), dbx(1), ftoc(1), gprof(1), hiprof(5),
ieee(3), ladebug(1), ld(1), monitor(3), pixie(5), prof(1), pro‐
tect_headers_setup(8), standards(5), third(5), what(1)
ANSI X3.159-1989
B. W. Kernighan and D. M. Ritchie, The C Programming Language
B. W. Kernighan, Programming in C -- a tutorial
D. M. Ritchie, C Reference Manual
Programmer's Guide
Assembly Language Programmer's Guide
Compaq C Language Reference Manual
cc(1)