 |
Index for
Section 1 |
|
 |
Alphabetical
listing for C |
|
 |
Bottom of
page |
|
cc(1)
NAME
cc - C compiler
SYNOPSIS
cc [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
categories. 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
-newc
Invokes the compiler with the default option settings shown in the
SYNOPSIS section. This option is provided to turn off -migrate, and it
is the default.
-migrate
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.
-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.
-std0
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.
-std1
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).
-c99
Selects the strict ANSI C99 language 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.
-isoc94
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__.
-ms 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 extensions, the -ms
option is equivalent to -std. Thread Local Storage (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 example:
typedef enum {a,b,c} typedefname;
typedef enum {d,e,f} typedefname;
· Allow declaration of a structure with a trailing incomplete 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 expression in certain cases. For
example:
int *a, *b;
f() {
&*a=b;
}
· Allow integers and pointers to be compared without 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 declarations 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
identifier 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
-common
Selects the K & R language mode. This option is equivalent to -std0.
-traditional
Selects the K & R language mode. This option is equivalent to -std0.
-vaxc
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
-accept option1[,option2,...]
Causes the compiler to recognize additional keywords. The following
options are available:
[no]vaxc_keywords
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,
globalvalue, noshare, readonly, variant_struct, and variant_union.
This option causes these keywords to be recognized. It may help in
porting applications from OpenVMS systems.
[no]restrict_keyword
Cause the compiler to recognize the restrict keyword (from the C9X
review draft).
-arch option
Specifies which version of the Alpha architecture to generate
instructions for. All Alpha processors implement a core set of
instructions and, in some cases, the following extensions: BWX
(byte/word-manipulation extension), MVI (multimedia extension), FIX
(square root and floating-point convert extension), 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:
generic
Generate instructions that are appropriate for all Alpha
processors. This option is the default.
host
Generate instructions for the processor that the compiler is
running on (for example, EV6 instructions on an EV6 processor).
ev4,ev5
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 emulation
overhead on any Alpha processor.
ev56
Generate instructions for EV56 processors (some 21164 chips).
This option permits the compiler to generate any EV4 instruction,
plus any instructions contained in the BWX extension.
Applications compiled with this option may incur emulation overhead
on EV4 and EV5 processors.
ev6 Generate instructions for EV6 processors (21264 chips).
This option permits the compiler to generate any EV6 instruction,
plus any instructions contained in the following extensions: BWX,
MVI, and FIX.
Applications compiled with this option may incur emulation overhead
on EV4, EV5, EV56, and PCA56 processors.
ev67
Generate instructions 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 emulation
overhead on all processors that are older than EV67.
pca56
Generate instructions for PCA56 processors (21164PC chips).
This option permits the compiler to generate any EV4 instruction,
plus any instructions contained in the BWX and MVI extensions.
Applications compiled with this option may incur emulation overhead
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 instructions--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
instructions may get emulated (and emulated instructions can be up
to 1000 times slower than actual instructions).
· -tune evx can generate evx-specific instructions, but those are
always amask-guarded. That expands the code size but avoids
instruction emulation.
· 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.
-c Suppresses the loading phase of the compilation and forces the creation
of an object file.
-[no]check_bounds
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 computation is within
bounds. A failed bounds check at runtime produces a Trace/BPT trap,
which may be caught by signal(SIGTRAP, handler). See the Programmer's
Guide for more details.
The -nocheck_bounds option (the default) disables the runtime checking
of array bounds.
-edit[0-9]
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 undefined). 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 compile-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.
-[no]error_limit nn
Sets a limit on the number of error-level diagnostics that the compiler
will emit. The default is 30.
-FIfilename
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 pragmas that control a particular aspect of a
compilation (for example, optimizations or diagnostics).
-granularity size
Controls the size of shared data in memory that can be safely accessed
from different threads. The possible size values are byte, longword,
and quadword.
Specifying byte allows single bytes to be accessed from different
threads sharing data in memory without corrupting surrounding 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 memory.
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 memory.
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.
-nestlevel=n
Sets the nesting-level limit for include files. The default is 50.
-machine_code
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.
-noobject
Suppresses creation 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 .o file extension.
Use the -noobject option when you need only a listing of a program or
when you want the compiler to check a source file for errors.
-o output
Names the final output file output.
-protect_headers keyword
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:
all Enables the protect headers feature. This is the default if the
file being compiled is a C source file.
none
Disables the protect headers feature. This is the default if the
file being compiled is a non-C source file.
default
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.
-S Compiles the specified source files and generates symbolic assembly
language output in corresponding files suffixed with .s.
-show keyword[,keyword,...]
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:
none
Turns off all show options.
all Turns on all show options.
[no]brief
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.
[no]cross_reference
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 numbers 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
. Member selection (no indirection)
[] Subscripted (that is, using [] syntax)
b Invoked as a builtin function
[no]expansion
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.
[no]header
Produces header lines at the top of each page of listing.
[no]include
Places contents of header files in program listing.
[no]source
Places source program statements in program listing.
[no]statistics
Places compile-time performance statistics in the program listing.
[no]symbols
Same as [no]brief, except that unreferenced macros and symbols are
not suppressed.
If you specify -source_listing but do not specify -show keywords, the
compiler includes header lines and source statements in the program
listing (-show header,source).
-source_listing
Produces a source program listing file with the same name as the source
file and with a .lis file extension. You must specify this qualifier to
get a listing. The default is to not produce a listing file.
-v 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.
-V Prints the version of the compiler driver.
Compiler Diagnostic Controls Options
-check Performs compile-time code checking. With this option, the compiler
checks for code that exhibits nonportable behavior, represents a
possible unintended code sequence, or possibly affects operation of
the program 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).
-msg_dump
Causes the compiler to dump, to stdout, all messages enabled by any
given cc command line. The compiler then exits, without doing a
compilation.
-msg_actiontype msg_list
Provides users with the ability to control the diagnostic messages
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, severity,
or frequency that will be applied to the messages identified by the
msg_list argument. The following message-control options are
supported:
-msg_enable
Enable a specific message or group of messages.
-msg_disable
Disable a specific message or group of messages. (Note that
messages with error or fatal severity cannot be disabled; only
warning and informational messages can be disabled.)
-msg_always
Always emit the messages identified by the msg_list argument.
-msg_once
Emit the identified messages only once.
-msg_fatal
Change the identified messages to be fatal, compilation-ending
errors.
-msg_warn
Change the identified messages to be warnings. (Note that
error- or fatal-severity messages cannot be changed to
warning-severity messages.)
-msg_inform
Change the identified messages to be informational messages.
(Note that error- or fatal-severity messages cannot be changed
to informational-severity messages.)
-msg_error
Change the identified 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:
level0
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.
level1
Important messages, but less important 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.
level2
Moderately important messages. Level 2 is the default for
DIGITAL UNIX V4.0E and later (Tru64 UNIX) versions.
level3
Less important messages. (The -w0 option enables level 3
messages.)
level4
Useful messages associated with the -check and -portable
options.
level5
Less useful -check and -portable messages than the messages
associated with level 4. The -check option is equivalent to
-msg_enable level5.
level6
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:
64bit
Messages reporting code or practices that may have unintended
consequences on 64-bit architectures.
alignment
Messages reporting unusual or inefficient data alignment.
c_to_cxx
Messages reporting the use of C features that would be invalid
or have a different meaning if compiled by a C++ compiler.
check
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).
defunct
Messages reporting the use of obsolete features, features that
were accepted by early C compilers but were subsequently
removed from the language.
noansi
Messages reporting the use of features that are not in the ANSI
C89 standard. Same as noc89.
noc89
Messages reporting the use of features that are not in the ANSI
C89 standard. Same as noansi.
noc99
Messages reporting the use of features that are not in the ANSI
C99 standard.
newc99
Messages reporting the use of features that are new in the ANSI
C99 standard.
obsolescent
Messages reporting the use of features that are valid in ANSI
C, but which are identified in the standard as being
obsolescent and likely to be removed from the language in a
future version of the standard.
overflow
Messages reporting assignments and/or casts that may cause
overflow or other loss of data significance.
performance
Messages reporting code that might result in poor run-time
performance.
portable
Messages reporting the use of language extensions or other
constructs that might not be portable to other compilers or
platforms. -msg_enable portable is equivalent to -portable.
preprocessor
Messages reporting questionable or non-portable use of
preprocessing constructs.
questcode
Messages reporting questionable coding practices. Similar to
check, but messages in this group are more likely to indicate a
programming error, not just a non-robust style.
returnchecks
Messages relating to function return values.
unused
Messages reporting expressions, declarations, and code paths
that are not used.
-portable
Directs the compiler to issue diagnostics for certain constructs
that may not be portable to other compilers or platforms.
-portable is equivalent to -msg_enable portable.
-SD[directory]
Suppresses certain warning- and informational-level diagnostic
messages that are inappropriate for system header files. The
suppressed messages relate to non-portable 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 provides
message suppression in the file __DECC_include_prologue.h.)
-verbose
Produces longer error and warning messages. Messages in this form
may give the user more hints about why the compilation failed.
-w[n] 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:
0 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.
1 Suppresses warning and informational messages and displays
error and fatal messages. This is equivalent to specifying -w.
2 If the compiler encounters an error that generates a warning-
level diagnostic message, the compiler displays the message and
then aborts.
3 Does not print warning messages. However, when warnings occur,
exits with nonzero status.
-warnprotos
Causes the compiler 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
-C Passes all comments directly to the preprocessor output, except
comments on preprocessor directive lines.
-[no]cpp
Determines whether to call the C macro preprocessor on C and assembly
source files before compiling.
-cpp is the default.
-Dname[=def]
Defines the name as if with a #define statement. If no definition is
given, the name is defined as 1.
-E Runs only the C macro preprocessor on the files and sends the result to
the standard output device.
-I[dir]
Specifies a search path for header files whose names do not indicate a
specific directory path (that is, whose names do not begin with a /).
The actual search path depends upon the form of the #include directive
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 contains 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
preprocessor searches for the file first in the search path
indicated 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.
-M Outputs a set of make dependency rules to standard output for each
source file on the command line (and suppresses compilation). 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.
-MD 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
information, see cpp(1) and ld(1).
-nocurrent_include
Changes the behavior of the #include "filename" directive to not search
the source file's directory for filename. This option causes the
#include "filename" directives to behave like #include <filename>
directives. This option allows makefiles to control the search order
for header files by using -I options.
-oldcomment
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.
-P Runs only the C preprocessor and puts the result for each .c or .s
source file in a corresponding .i file. The .i file has no #line_number
preprocessor directives in it.
-proto[is]
Extracts prototype declarations for function definitions and puts them
in a .H suffixed file. The suboption i includes identifiers in the
prototype, and the suboption s generates prototypes for static
functions as well.
-Q Directs the preprocessor to use single quotes in __FILE__ expansions
instead of double quotes. See cpp(1) for details.
-Uname
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
compiler. 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
-call_shared
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.
-compress
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 compressed object file format, resulting in a substantially
smaller object file.
-cord
Runs the procedure rearranger, cord, on the resulting file after
linking. The rearrangement is done to reduce the cache conflicts
associated 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.
-expect_unresolved pattern
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).
-exact_version
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.
-fini symbol
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.
-init symbol
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.
-input_to_ld filename
Directs the linker to read the contents of file filename as if the
contents had been supplied on the ld command line.
Inside file filename, lines ending with \ are treated as continuation
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.
-noarchive
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.
-non_shared
Directs the linker to produce a static executable. The output object
created by the linker will not use any shared objects during execution.
-pthread
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.
-shared
Produces dynamic shareable objects. The loader will produce a shareable
object that other dynamic executables can use at run time.
The following options are used with -shared:
-check_registry location_file
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. Multiple instances of this option are allowed.
-rpath path
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
${VARNAME}, 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.
-set_version version-string
Establishes the version identifier (or identifiers) associated with
a shared library. The string version-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 version 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.
-soname shared_object_name
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.
-update_registry location_file
Registers the location of this shared object's segments and makes
sure they stay out of the way of others in the location_file.
Location_file is updated if it is writable.
-taso
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 appropriately 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).
-threads
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.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
-[no]ansi_alias
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 generation 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.
-[no]ansi_args
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.
-assume [no]array_parameter_restricted_pointers
Specifies the assumption that all array parameters are or are not
restricted. The default is -assume
noarray_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_parameter_restricted_pointers, p1 and
p2 are restricted.
· If you specify -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 prefixing a no
to the assumption name. By default, all of the assumptions 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 determined 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 optimization 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 erroneous assertions.
-assume [no]ignore_restricted_pointers
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.
-assume [no]math_errno
Controls the compiler's assumption about a program's dependence on the
setting of errno by math library routines:
· By default (-assume math_errno), the compiler assumes that the
program might interrogate 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 unfortunately 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 practice,
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.
-assume [no]parameter_restricted_pointers
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_pointers.
-assume [no]restricted_pointers
Specifies the assumption that all pointers are or are not restricted.
The default is -assume norestricted_pointers. For more information, see
-assume [no]array_parameter_restricted_pointers.
-assume whole_program
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 single
compilation unit.
-check_omp
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.
-fast
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 programs are not
sensitive to these differences.
The -fast option defines the following compiler options and symbols to
improve run-time performance. You can adjust the optimizations by
specifying the negation of any given option.
-ansi_alias
Directs the compiler to assume the ANSI C aliasing rules, and thus
allows the optimizer to be more aggressive in its optimizations.
See the description of this option elsewhere in this reference page
for more detailed information about this operation.
-ansi_args
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
function prototype is present so the compiler can automatically
perform the expected type conversion.
See the description of this option elsewhere in this reference page
for more detailed information about this operation.
-assume nomath_errno
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.
-assume trusted_short_alignment
Specifies 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.
-D_INTRINSICS
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 rewrite calls to it based on
the compiler's understanding of what the function does. Some
possible optimizations include generating complete inline code,
generating partial inline code with calls to one or more different
functions, or just using characteristics of the function to move
the call site or avoid some of the overhead triggered by an
external call.
-D_INLINE_INTRINSICS
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
expansions 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.
-D_FASTMATH
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 accurate functions are used. The fast math
routines do not support IEEE exceptional behavior.
-float
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.
-fp_reorder
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.
-ifo
Performs 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.
-intrinsics
Controls 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.
-O3 Sets the optimization level.
See the description of this option elsewhere in this reference page
for more detailed information about this operation.
-readonly_strings
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.
-feedback file
Specifies that the compiler should use the profile information
contained 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 compilation 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 procedures
to reduce cache thrashing, spike is typically more effective. When
employing both -feedback and spike, use the second (executable) form of
file, which allows both the compiler and spike to use data derived from
a single profile training run.
-[no]fp_reorder
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.
-ifo
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 compiler will issue diagnostics
about conflicting external declarations 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.
-[no]inline keyword
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 considers 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:
none
No inlining is done, even if requested by a #pragma inline
preprocessor directive. This is the default when compiling with
the -O0 option.
manual
Inlines only those function calls explicitly requested for inlining
by a #pragma inline directive. This is the default when compiling
with the -O1 option.
size
Inlines all of the function calls in the manual category, plus any
additional 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.
speed
Inlines all of the function calls in the manual category, plus any
additional calls that the compiler determines would improve run-
time performance, even where it may significantly increase the size
of the program.
all Inlines every call that can be inlined while still generating
correct code. Recursive routines, however, will not cause an
infinite loop at compile 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.
-[no]intrinsics
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 intrinsic. If not, a diagnostic is issued and calls
are treated as ordinary external function calls.
When the compiler identifies a function as an intrinsic function, it is
then free to make code optimizations (transformations) 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 particular function.
The optimization level determines which functions can be treated as
intrinsics:
-O0 or -O1
No intrinsic functions. The -intrinsics option has no effect at
this optimization level.
-O2 (or -O)
Memory and string functions: alloca, bcopy, bzero, memcpy, memmove,
memset, strcpy, strlen
Math functions: abs, fabs, labs, atan, atan2, atan2f, atand,
atand2, atanf, ceil, ceilf, cos, cosd, cosf, floor, floorf, sin,
sind, sinf.
-O3 fprintf, printf, snprintf, sprintf
-fast (due to its supplying -assume nomath_errno and -O3)
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 function 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 compilation must include
and also specify both -D_INTRINSICS and -D_INLINE_INTRINSICS on the
command line.
-mp 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
directives 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.
-O[n]
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
subexpressions. 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
multiplication 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,
vectorization 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 recommended to determine if
-O4 is better than -O3 for your particular application, as this is not
always true.
-om Performs code optimization after linking, including nop (no operation)
removal, .lita removal, and reallocation of common symbols. This option
also positions the $gp register so that the maximum number 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:
-WL,-om_compress_lita
Removes unused .lita entries after optimization, and then
compresses the .lita section.
-WL,-om_dead_code
Removes dead code (unreachable instructions) generated after
applying optimizations. The .lita section is not compressed by
this option.
-WL,-om_feedback
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.
-WL,-om_Gcommon,num
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 probability that
the symbol can be accessed directly from the $gp register.
(Normally, om tries to collect all "common" symbols together, not
just symbols that conform to certain size constraints.)
-WL,-om_ireorg_feedback,file
Uses the pixie-produced information in file.Counts and file.Addrs
to reorganize the instructions to reduce cache thrashing.
-WL,-om_no_inst_sched
Turns off instruction scheduling.
-WL,-om_no_align_labels
Turns off alignment of labels. Normally, the -om option will align
the targets of all branches on quadword boundaries to improve loop
performance.
-WL,-om_split_procedures
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 produced by a
representative run of the program. The hot segments are stored near
other parts of the program that are also executed 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-
techreports@decwrl.dec.com, specifying help on the subject line. Then,
follow the instructions in the reply you receive to obtain report
number 94/1.
-omp
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 programming directives enabled by the -mp option are
ignored. See also the -mp and -check_omp options.
-preempt_module
Supports symbol preemption on a module-by-module basis. During
optimization, inlining is performed 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 proceeding 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.
-preempt_symbol
Preserves full symbol preemption; that is, supports symbol preemption
on a symbol-by-symbol basis within a module as well as between modules.
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.
-speculate all
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 available sooner than it would
have been without speculative execution. If the flow of control does
not reach that operation, the result will simply be ignored.
Since unsuccessful speculative operations can generate exceptions, all
exceptions are dismissed when any module that contributes 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).
-speculate by_routine
Specifies 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 modules 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
exceptions, 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 execution than
the -speculate all option, but does not restrict trap and fault
handling in other modules with which it is linked.
-spike
Invokes the spike tool to perform code optimization after linking 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.
-tune option
Instructs the optimizer to tune the application for a specific version
of the Alpha hardware. This will not prevent the application from
running 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):
generic
All Alpha processors. This is the default.
host
The processor on which the code is compiled.
ev4 The 21064, 21064A, and 21068 processors.
ev5,ev56
The 21164 processor. (Both EV5 and EV56 are numbered 21164.)
ev6 The 21264 processor.
ev67
The 21264A processor.
pca56
The 21164PC processor.
See also the -arch option for an explanation of the differences between
-tune and -arch.
-unroll n
Controls the loop-unrolling optimization (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
-gen_feedback
Generates accurate profile information to be used with -feedback
optimizations, as follows:
1. Compile the source code with the -gen_feedback option.
2. Run pixie on the executable file.
3. Execute the pixie version of the program to generate execution
statistics on the program.
4. Use prof to create a feedback file from the execution statistics.
5. Recompile 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.
-prof_gen
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 .non_pixie. See also the descriptions of the
-prof_use_om_feedback, -prof_dir, and -pids options.
-prof_gen_noopt
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:
1. Compile the source code with -prof_gen_noopt.
2. Run the program.
3. 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.
-prof_use_feedback
Uses profiling feedback to improve compiler 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.
-prof_use_om_feedback
Uses profiling feedback to rearrange the resulting image to reduce
cache conflicts of the program text. This option uses the -om postlink
optimizer, and is equivalent to using the -om -WL,-om_ireorg_feedback
options. If the -pids option is also specified, this option merges the
.Counts performance data files using the prof -pixie -merge command.
To use the -prof_use_om_feedback option, first compile your program
with the -prof_gen option and then run the program to generate the
profiling data.
-prof_dir
Specifies a location to which the profiling data files (.Counts and
.Addrs) are written. Use this option in conjunction with the -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.
-[no]pids
[Disables] or enables the addition of the process-id to the filename of
the basic block counts file (.Counts). This facilitates 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
-g[n]
Produces symbol table information for debugging. When no value is
specified for n, the compiler produces symbol table information for
full symbolic debugging and suppresses optimizations that limit full
symbolic debugging (same as -g2).
The value of n can be one of the following (-g is the same as -g2):
0 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 procedure traceback and all
instruction-level commands. However, line-oriented commands do not
work. No symbol types are available, and the names of stack-frame
and static variables are not available. All optimizations are
supported.
1 Produces limited symbol table information. Profiling and debugging
tools provide line numbers, source file names, and the names of
local procedures, 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.
2 Produces symbol table information for full symbolic debugging and
suppresses some optimizations. Symbol types and stack-frame
variables names are available. Optimization is suppressed (-g2
implies -O0).
3 Produces symbol table information for fully optimized code. This
level of debugging supplies the same information 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
-p[n]
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
routine (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:
0 Do not permit any profiling. This is the default. If linking
occurs, the standard run-time startup routine (crt0.o) is used, and
no profiling library is searched.
1 Same as -p.
-[no]pg
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
-assume [no]aligned_objects
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 systems, 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 generate
longer code sequences to perform indirect load and store operations in
order to avoid hardware alignment faults for arbitrarily 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 specified #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; otherwise, 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.
-assume [no]trusted_short_alignment
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.
-[no]misalign
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 discussed earlier in this
reference page.
-[no]member_alignment
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 boundaries
(that is, on the next boundary appropriate to the type of the member)
instead of the next byte. For example, an int variable 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_alignment, or
#pragma pack directives within the source code overrides 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.
-Zp[n]
Aligns structure members and entire structures 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 structure,
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
-strong_volatile
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.
-weak_volatile
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 longword and accessed asynchronously).
C Language Options
-double
Promotes expressions of type float to double. This is the default when
-std0 is used.
-float
Prevents the compiler from promoting expressions of type float to type
double. This is the default except in -std0 mode.
-float_const
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.
-readonly_strings
Allows the compiler 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 segmentation
fault).
-signed
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.
-unsigned
Causes all char declarations to have the same representation and range
of values as unsigned char declarations.
-varargs
Prints warnings for all lines that may require the <varargs.h> macros.
-volatile
Causes all variables to be treated as volatile.
-writable_strings
Causes all string literals to be writable. This is the default.
This option overrides -readonly_strings.
Stack-handling and Pointer-handling Options
-trapuv
Forces all uninitialized stack variables to be initialized with
0xfff58005fff58005. When this value is used as a floating-point
variable, 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
violation usually occurs.
-xtaso
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 conjuction
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.
-xtaso_short
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 pragmas.
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.
-framepointer
Makes all procedures in the source file use $fp (register 15) as the
frame pointer.
IEEE Floating-point Support Options
-fprm c
Specifies chopped rounding mode (round toward zero).
-fprm d
Dynamically sets rounding mode for IEEE floating-point instructions.
The dynamic rounding 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 floating-point rounding mode defaults to round to nearest.
-fprm n
Specifies normal rounding mode (unbiased round to nearest). This is the
default.
-fprm m
Specifies round toward minus infinity mode.
-fptm n
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.
-fptm u
Generates traps on floating-point underflow as well as overflow,
divide-by-zero, and invalid operation.
-ieee
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 numbers, 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.
-scope_safe
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 occurring 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)
-Hc 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 .T, and the file is always retained after the
compilation is halted.
-Wc[c...],arg1[,arg2...]
Passes the argument, or arguments (argi), to the compiler pass, or
passes (c[c...]). Each c character can be one of the following: [
ablLzpfy ] (see the -t option for an explanation). The c selects the
compiler pass in the same way as the -t option.
-tc[c...]
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_TARGET_ROOT/usr/include/string. This directory is to contain
the header files for the string release of the compiler. The
standard 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.
-hpath
Specifies the directory where the tool (or other component) 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 (/).
-Bstring
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.
-K 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, replacing its suffix with the
conventional suffix for the type of file (for example, .B 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 created 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 .c 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 .o substituted
for .c. The .o file is deleted only when a single source program is
compiled and loaded all at once.
· Arguments whose names end with .s are assumed to be symbolic assembly
language source programs. They are assembled, producing a .o file.
· Arguments whose names end with .i are assumed to be C source files
after being processed by the C preprocessor.
· Arguments whose names do not end with .c, .s, or .i 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 command
or the ld command (linker). When the compiler recognizes position-sensitive
linker options (-L, -all, -exclude, -exported_symbol, -hidden,
-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 command.
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 conformance
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 variable 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 environment 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 compilation:
1. comp.config prologue options
2. DEC_CC prologue options
3. command line options
4. DEC_CC epilogue options
5. 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
1. 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.
2. In this example, the -v option displays the name of each compilation
pass--and its arguments--as it executes.
cc -v helloworld.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_LONGLONG -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__LANGUAGE_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:
DEC_CC
Allows C users to establish a set of compilation options that are
applied to subsequent compilation on a per-user basis. See the
DESCRIPTION section for more information.
DRV_DUMP
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.
DRV_SKIP_COMMAND
If set, causes the compiler driver to display all the commands that
would be invoked, but to not actually execute those commands.
LANG
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.
LC_ALL
If set to a non-empty string, this variable overrides values in all
locale variables, including LANG.
LC_CTYPE
Determines the locale for the interpretation of sequences of bytes of
text data as characters (for example, single- as opposed to multi-byte
characters in arguments and input files).
LC_MESSAGES
Determines the locale used for diagnostic messages.
NLSPATH
Determines the locale of message catalogs for the processing of
LC_MESSAGES.
TMPDIR
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
file.c
Input file
file.o
Object file
a.out
Loaded output
/tmp/ctm?
Temporary
/usr/lib/cmplrs/cc/comp.config
Compiler configuration file (optional)
/usr/lib/cmplrs/cc/cpp
C macro preprocessor
/usr/lib/cmplrs/cc/gemc_cc
HP C compiler
/usr/lib/cmplrs/cc/om
Post-link optimizer
/usr/lib/cmplrs/cc/as0
Symbolic to binary assembly language translator
/usr/lib/cmplrs/cc/as1
Binary assembly language assembler and reorganizer
/usr/lib/cmplrs/cc/crt0.o
Run-time startup
/usr/lib/cmplrs/cc/mcrt0.o
Startup for prof profiling
/usr/lib/cmplrs/cc/gcrt0.o
Startup for gprof profiling
/usr/ccs/lib/libc.a
Standard library, see intro(3)
/usr/lib/cmplrs/cc/libprof1.a
Level 1 profiling library
/usr/lib/cmplrs/cc/libprof1_r.a
Reentrant level 1 profiling library for code compiled with -pthread or
-threads
/usr/include
Standard directory for header files
/usr/lib/cmplrs/cc/ftoc
Interface between prof and cord
/usr/lib/cmplrs/cc/cord
Procedure-rearranger
mon.out
File produced for analysis by prof
gmon.out
File produced for analysis by gprof
SEE ALSO
as(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),
protect_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
|
Index for
Section 1 |
|
|
Alphabetical
listing for C |
|
 |
Top of
page |
|