Content-type: text/html
Man page of cc
cc
Section: User Commands (1)
Index
Return to Main Contents
NAME
cc - C compiler
SYNOPSIS
cc [option...] file...
Default Options:
cc -newc -assume aligned_objects -assume math_errno -cpp -call_shared -double -fprm n -fptm n -g0 -I/usr/include -inline manual -intrinsics
-member_alignment -no_fp_reorder -no_misalign -O1 -oldcomment -p0 -no_pg -preempt_symbol -signed -archgeneric -std0 -tune generic -weak_volatile
-writable_strings
OPTIONS
Options described in this section are divided into the following categories:
Compiler selection options
Language mode options
Overall compiler behavior options
Compiler diagnostic controls options
C preprocessor options
Linker or loader options
Optimization options
Feedback-directed optimization options
Source-code debugging options
Program profiling options
Data alignment options
Data volatility options
C language options
Rounding-mode options (IEEE floating-point)
Stack-handling and pointer-handling options
IEEE floating-point support options
Compiler development options (not generally used)
Compiler Selection Options
This is the default.
Invokes the compiler with a set of optimization settings that
are slightly different from those associated with
-newc. These
settings are consistent with the
cc
-migrate
settings for versions of the DEC OSF/1 operating system that preceded DIGITAL
UNIX Version 4.0. This option is provided for backwards compatibility only,
and its use is strongly discouraged.
Invokes the older, ucode-based implementation of the C compiler
that was the default for versions of the DEC OSF/1 operating system preceding
DIGITAL UNIX Version 4.0. It can be invoked only after the OSFOBSOLETE subset
has been installed.
See
cc(1old)
for details on the
-newc,
-migrate, and
-oldc
options and their effects.
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
-std0.
Selects the relaxed ANSI language mode. Enforces the ANSI
C standard, but allows some common programming practices disallowed by the
standard.
-
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 C reserved names are visible from the ANSI C header files,
use the
_ANSI_C_SOURCE
macro. See
standards(5)
for
more details.
-
This option causes the macro
__STDC_
to be defined to 0.
Selects the K & R language mode. This is the default.
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 C programs and produces expected results.
The
-std0
option causes the
__STDC__
macro to be undefined.
Selects the strict ANSI language mode. Strictly enforces the
ANSI C 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 C reserved names are visible from the ANSI C header files,
use the
_ANSI_C_SOURCE
macro. See
standards(5)
for
more details.
-
This option causes the macro
__STDC_
to be defined to 1. Note that this option also affects linker-defined symbols.
See
ld(1)
for more information.
-
This option turns on ANSI aliasing rules (-ansi_alias
option).
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.
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
-
Selects the K & R language mode. This option is equivalent
to
-std0.
Selects the K & R language mode. This option is equivalent
to
-std0.
Selects the VAX C language mode. This is similar to
-std
(relaxed
ANSI mode) but extends the language semantics in ways that are incompatible
with ANSI C. It provides close compatibility with the vaxc compiler.
Overall Compiler Behavior Options
Causes the compiler to recognize additional keywords. The following
options are available:
The default compilation mode on OpenVMS systems includes recognition
of the following keywords that are not available on Tru64 UNIX except
in
-vaxc
mode:
_align,
globaldef,
globalref,
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.
Cause the compiler to recognize the
restrict
keyword (from the C9X review draft).
Specifies which version of the Alpha architecture to generate
instructions for. All Alpha 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:
Generate instructions that are appropriate for all Alpha processors.
This option is the default.
Generate instructions for the processor that the compiler
is running on (for example, EV6 instructions on an EV6 processor).
Generate instructions for the EV4 processor (21064, 20164A,
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.
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.
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, FIX, and
CIX.
-
Applications compiled with this option may incur emulation overhead
on EV4, EV5, EV56, and PCA56 processors.
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.
Suppresses the loading phase of the compilation and forces
the creation of an object file.
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.
Sets a limit on the number of error-level diagnostics that
the compiler will emit. The default is 30.
Specifies a file that is to be included before the first line
in a source file is actually compiled. This enables users to develope include
files containing sets of pragmas that control a particular aspect of a compilation
(for example, optimizations or diagnostics).
Causes the macro
__STDC_VERSION__
to be passed to the preprocessor and enables recognition of the
digraph forms of various operators. Note that the
-isoc94
option has no influence on
-stdn
options and vice versa.
Sets the nesting-level limit for include files. The default
is 50.
Includes the generated machine code in the listing file.
By default, machine code is not listed. To produce the listing file, you
must also specify
-source_listing.
Suppresses 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.
-
This option is not available when you use the
-oldc
option.
Names the final output file
output.
Ensures that the compiler's assumptions about pointer sizes
and data alignments are not in conflict with the default values that were
in effect when the system libraries were created.
-
The keywords for the
-protect_headers
option are as
follows:
Enables the protect headers feature. This is the default
if the file being compiled is a C source file.
Disables the protect headers feature. This is the default
if the file being compiled is a non-C source file.
Cancels any previous
-protect_headers
options
and places the compiler's default behavior in effect.
-
If more than one
-protect_headers
option appears on
the command line, only the last one is applied. See
protect_headers_setup(8)
for details.
Compiles the specified source files and generates symbolic
assembly language output in corresponding files suffixed with
.s.
Specifies one or more items to be included in the listing
file. When specifying multiple keywords, separate them by commas and no intervening
blanks. To use any of the
-show
keywords, you must also specify
the
-source_listing
option.
-
The keywords for the
-show
option are as follows:
Turns off all show options.
Turns on all show options.
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.
Produces header lines at the top of each page of listing.
Places contents of header files in program listing.
Places source program statements in program listing.
Places compile-time performance statistics in the program
listing.
-
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).
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.
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
(for
-newc
and
-migrate
only).
Prints the version of the compiler driver and, when the
-oldc
option is specified, the versions of all passes in the same
format as the
what
command.
Compiler Diagnostic Controls Options
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).
Causes the compiler to dump, to stdout, all messages enabled
by any given
cc
command line. The compiler then exits,
without doing a compilation.
Provides users with the ability to control the diagnostic
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:
Enable a specific message or group of messages.
Disable a specific message or group of messages. (Note that
messages with error or fatal severity cannot be disabled; only warning and
informational messages can be disabled.)
Always emit the messages identified by the
msg_list
argument.
Emit the identified messages only once.
Change the identified messages to be fatal, compilation-ending
errors.
Change the identified messages to be warnings. (Note that
error- or fatal-severity messages cannot be changed to warning-severity messages.)
Change the identified messages to be informational messages.
(Note that error- or fatal-severity messages cannot be changed to informational-severity
messages.)
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:
Very important messages that are enabled by default. Level
0 messages cannot be disabled as a class (level0), but
individual level 0 messages can be disabled if they are warning- or informational-severity
messages. (Error- or fatal-severity messages cannot be disabled.)
-
Messages at this level correspond to messages covered by
pragma
nostandard. These include all messages that
should be displayed for code in header files.
Important messages, but less 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.
Moderately important messages. Level 2 is the default for
the DIGITAL UNIX V4.0E and later versions.
Less important messages. (The
-w0
option enables
level 3 messages.)
Useful messages associated with the
-check
and
-portable
options.
Less useful
-check
and
-portable
messages than the messages associated with level 4. The
-check
option is equivalent to
-msg_enable level5.
All messages, including all messages not in any of the lower
levels. Disabling level 6 messages does not affect the lower-level messages;
it affects only the messages added by level 6.
-
Message Groups:
Messages reporting code or practices that may have unintended
consequences on 64-bit architectures.
Messages reporting unusual or inefficient data alignment.
Messages reporting the use of C features that would be invalid
or have a different meaning if compiled by a C++ compiler.
Messages reporting code or practices that, although correct
and perhaps portable, are sometimes considered ill-advised because they can
be confusing or fragile to maintain (for example, assignment as the test expression
in an
if
statement).
Messages reporting the use of obsolete features, features
that were
accepted by early C compilers but were subsequently removed from the language.
Messages reporting the use of non-ANSI C features.
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.
Messages reporting assignments and/or casts that may cause
overflow or other loss of data significance.
Messages reporting code that might result in poor run-time
performance.
Messages reporting the use of language extensions or other
constructs that might not be portable to other compilers or platforms.
-msg_enable portable
is equivalent to
-portable.
Messages reporting questionable or non-portable use of preprocessing
constructs.
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.
Messages relating to function return values.
Messages reporting expressions, declarations, and code paths
that are not used.
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.
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.)
Produces longer error and warning messages. Messages in this
form may give the user more hints about why the compilation failed.
Controls the display of messages as well as the actions that
occur as a result of the messages. The value of
n
can be one of the following:
Displays all levels of compiler messages (warning, error,
fatal, and informational). This is the default.
Suppresses warning and informational messages and displays
error and fatal messages. This is equivalent to specifying
-w.
If the compiler encounters an error that generates a warning-level
diagnostic message, the compiler displays the message and then aborts.
Does not print warning messages. However, when warnings occur,
exits with nonzero status.
Causes the 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
Passes all comments directly to the preprocessor output, except
comments on preprocessor directive lines.
Determines whether to call the C macro preprocessor on C and
assembly source files before compiling.
-
-cpp
is the default.
Defines the
name
as if with a
#define
statement. If no definition is given, the name is defined
as
1.
Runs only the C macro preprocessor on the files and sends
the result to the standard output device.
Specifies a search path for header files whose names do not
indicate a specific 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.
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.
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).
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.
Directs the preprocessor to delete comments (replacing them
with nothing at all). This allows traditional token concatenation.
-
This is the default in
-std0
mode. In
-std
and
-std1
mode, the default is to replace comments with a
single space.
Runs only the C preprocessor and puts the result for each
.c
or
.s
source file in a corresponding
.i
file. The
.i
file has no
#line_number
preprocessor directives in it.
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.
Directs the preprocessor to use single quotes in
__FILE__
expansions instead of double quotes. See
cpp(1)
for details.
Removes any macro definition of
name
at the start of the compilation.
name
could have
been defined with a
-D
option or predefined by the 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.)
Linker or Loader Options
Produces a dynamic executable file that uses shareable objects
during run time. This is the default. The loader uses shareable objects to
resolve undefined symbols. The run-time loader (/sbin/loader)
is invoked to bring in all required shareable objects and to resolve any symbols
that remained undefined during static link time.
Passes the
-compress
option to the compilation
phase (if the
-c
option is present) or passes the
-compress_r
option to
ld
(if the
-r
option is present). Use of this option causes the output object file to be
produced in compressed object file format, resulting in a substantially smaller
object file.
Runs the procedure rearranger,
cord, on
the resulting file after linking. The rearrangement is done to reduce the
cache conflicts 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.
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.
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).
Makes the procedure represented by the symbol into a termination
routine. A termination routine is a routine that is called without an argument
when either the file that contains the routine is unloaded or the program
that contains the routine exits.
Makes the procedure represented by the symbol into an initialization
routine. An initialization routine is a routine that is called without an
argument when either the file that contains the routine is loaded or the program
that contains the routine is started.
Directs the linker to read the contents of file
filename
as if the 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.
Prevents the linker from using archive libraries to resolve
symbols. This option is used in conjunction with
-call_shared.
The
-no_archive
option is position sensitive; it affects only
those options and variables that follow it on the command line. This option
can also be used more than once on the command line.
Directs the linker to produce a static executable. The output
object created by the linker will not use any shared objects during execution.
Produce 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:
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.
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.
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.
Sets DT_SONAME for a shared object. The name can be a single
component name (for example,
libc.a), a full pathname (starting
with a slash), or a relative pathname (containing a slash). The default DT_SONAME
used for shared objects is the filename component of the output file name.
Specify the output file name using the
-o
option as described
previously.
Registers the location of this shared object's segments and
makes sure they stay out of the way of others in the
location_file.
Location_file
is updated if it
is writable.
Directs the linker to 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.
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 addresses 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).
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
Directs the compiler to assume the ANSI C aliasing rules,
and thus allows the optimizer to be more aggressive in its optimizations.
The
-noansi_alias
option turns off ANSI C aliasing rules.
-
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 default is to assume no ANSI C aliasing rules when compiling with
the
-vaxc,
-std, or
-std0
option. The default is
-ansi_alias
when compiling with the
-std1
option.
-
The
-noansi_alias
option turns off ANSI C aliasing rules.
-
The
-[no]ansi_alias
option is not available when you
use the
-oldc
option.
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
-no_ansi_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
-no_ansi_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,
-no_ansi_args
is the default.
Note that it is safe to specify
-ansi_args
if you use ANSI-style
function prototypes at all call sites.
-
Specifying
-ansi_args
means that your code meets the
ANSI C requirements, so no special argument cleaning code is generated. This
is a performance gain. When
-std1
is specified,
-ansi_args
is the default.
Specifies the assumption that all array parameters are restricted.
In the following code, for example, only
b
will be considered
a restricted pointer when this option is not specified, even though for all
other purposes parameters
a
and
b
have
identical type:
-
extern int foo(char * a, char b[]);
-
When this option is specified, both
a
and
b
are treated as restricted pointers.
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.
Specifies the assumption that all pointer parameters are restricted.
Specifies the assumption that all pointers are restricted.
-
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.
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.
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.
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.
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.
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.
Specifies that any
short
accessed through
a pointer is naturally aligned. This generates the fastest code, but can
silently generate the wrong results if any of the
short
objects cross a quadword boundary.
-
See the description of this option elsewhere in this reference page
for more detailed information about this operation.
This option affects the compilation of a number of system
header files, causing them to compile
#pragma intrinsic
directives for certain functions that they declare. The exact functions affected
may vary depending on the language mode and other macro definitions. See
the header files
math.h,
stdio.h,
stdlib.h,
string.h, and
strings.h
for details. The exact effect of each
#pragma intrinsic
varies by function, by optimization options, and by other compile-time options.
The basic effect is to inform the compiler that the function specified in
the pragma is the one by that name whose behavior is known to the compiler
(that is, it is a standard C or commonly-used library function rather than
a user-written external function). This gives the compiler license to perform
additional checks on the usage of the function and issue diagnostics, and
to optimize and/or 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.
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.
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.
Tells the compiler that it is not necessary to promote expressions
of type
float
to type
double.
-
See the description of this option elsewhere in this reference page
for more detailed information about this operation.
Allows floating-point operations to be reordered during optimization.
-
See the description of this option elsewhere in this reference page
for more detailed information about this operation.
Performs inter-file optimizations.
-
See the description of this option elsewhere in this reference page
for more detailed information about this operation.
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.
Sets the optimization level.
-
See the description of this option elsewhere in this reference page
for more detailed information about this operation.
Makes string literals read-only for improved performance.
-
See the description of this option elsewhere in this reference page
for more detailed information about this operation.
Specifies the name of a feedback file (produced by
prof
after running a
pixie
version of the program).
The feedback file contains information that the compiler can use when performing
optimizations.
-
You can also use a feedback file as input to the
cord
utility, using
-feedback
and the
-cord
options
to link the program.
Specifies whether certain code transformations that affect
floating-point operations are allowed. These changes can affect the accuracy
of the program's results.
-
The
-no_fp_reorder
option, the default, directs the
compiler to use only certain scalar rules for calculations. This setting can
prevent some optimizations. The
-fp_reorder
option frees
the compiler to reorder floating-point operations based on algebraic identities
(inverses, associativity, and distribution). For instance, this allows the
compiler to move divide operations outside of loops, thus improving performance.
-
If you specify
-fp_reorder
and the compiler reorders
code to improve performance, the results can differ from the default, for
example, due to the way intermediate results are rounded. However, the
-fp_reorder
results are not categorically less accurate than those
gained by the default.
Provide improved optimization (inter-file optimization) and
code generation across file boundaries that would not be possible if the files
were compiled separately.
-
When you specify
-ifo
on the command line in conjunction
with a series of file specifications, the compiler does not concatenate each
of the specified source files. Instead, each file is treated separately for
purposes of parsing, except that the 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.
Specifies whether to provide inline expansion of functions.
This is the default for
-O2,
-O3,
-O4. The
-no_inline
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:
No inlining is done, even if requested by a
#pragma
inline
preprocessor directive. This is the default when compiling
with the
-O0
option.
Inlines only those function calls explicitly requested for
inlining by a
#pragma inline
directive. This is the default
when compiling with the
-O1
option.
Inlines all of the function calls in the manual category,
plus any 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.
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.
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.
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:
No intrinsic functions. The
-intrinsics
option
has no effect at this optimization level.
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.
fprintf,
printf,
snprintf,
sprintf
acos,
acosf,
asin,
asinf,
cosh,coshf,
exp,
expf,
log,
log10,
log10f,
logf,
log2,
pow,
powf,
sqrt,
sqrtf,
sinh,
sinhf,
tan,
tand,
tanf,
tanh.
-
The effects of the various optimization levels are cumulative; for example,
-fast
causes the functions at the
-02
(or
-O) and
-O3
optimization levels to be treated as intrinsics--in
addition to the intrinsic function treatment that is triggered by
-fast
itself.
-
The
-intrinsics
option is in effect by default. To disable
the default, specify the
-no_intrinsics
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.
Enables the compiler to process parallel decomposition pragmas
(directives) in C source code. It also triggers the link phase to link with
the appropriate thread and compiler support libraries that are needed to run
the generated multiprocessor code.
-
A correctly coded program that makes use of the parallel decomposition
pragmas can be compiled either with or without
-mp. With
-mp, the pragmas cause the program to run in several concurrent threads
that may execute in a significantly shorter elapsed time on a Tru64 UNIX
multiprocessor system. Without
-mp, the compiler will ignore
the pragmas and the program will run sequentially as a normal C program.
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.
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. The
-om
option is supported
only for programs compiled with the
-non_shared
option. The
following options can be passed directly to
-om
by using the
-WL
compiler option:
Removes unused
.lita
entries after optimization,
and then compresses the
.lita
section.
Removes dead code (unreachable instructions) generated after
applying optimizations. The
.lita
section is not compressed
by this option.
Sets the size threshold of ``common'' symbols. Every ``common''
symbol whose size is less than or equal to
num
will be allocated close to each other. This option can be used to improve
the 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.)
Uses the pixie-produced information in
file.Counts
and
file.Addrs
to reorganize the instructions to reduce cache thrashing.
Turns off instruction scheduling.
Turns off alignment of labels. Normally, the
-om
option will quadword align the targets of all branches to improve loop performance.
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.
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.
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.
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).
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.
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):
All Alpha processors. This is the default.
The processor on which the code is compiled.
The 21064, 21064A, and 21068 processors.
The 21164 processor. (Both EV5 and EV56 are numbered 21164.)
The 21264 processor.
-
See also the
-arch
option for an explanation of the
differences between
-tune
and
-arch.
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
Generates accurate profile information to be used with
-feedback
optimizations, as follows:
Compile the source code with the
-gen_feedback
option.
Run
pixie
on the executable file.
Execute the
pixie
version of the program
to generate execution statistics on the program.
Use
prof
to create a feedback file from
the execution statistics.
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.
-
This option is not available when you use the
-oldc
option.
Generates an executable image that has profiling code added
to it. Using this option is equivalent to running the
pixie(5)
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.
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.
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.
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.
[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
-no_pids.
Source-code Debugging Options
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):
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.
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.
Produces symbol table information for full symbolic debugging
and suppress some optimizations. Symbol types and stack-frame variables names
are available. Optimization is suppressed (-g2
implies
-O0).
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
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:
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.
Same as
-p.
Turns
gprof
profiling on or off when compiling
and linking the file immediately following this option. The
gprof
profiler produces a call graph showing the execution of a C program.
-
When this option is turned on, the standard run-time startup routine
is replaced by the
gcrt0.o
routine. Programs that are
linked with the
-pg
option and then run will produce, in file
gmon.out, a dynamic call graph and profile. You then run
gprof
on the
gmon.out
file to display the output.
When you use the
-pg
option together with either the
-pthread
option or the
-threads
option, the profiling
library
libprof1_r.a
is used.
-
For more information, see the
gprof(1)
reference page.
Data Alignment Options
Controls the alignment assumptions for code generated for
indirect load and store instructions.
-
The
-assume aligned_objects
option causes the compiler
to assume that a dereferenced object's alignment matches or exceeds the alignment
indicated by the pointer to the object. On Alpha 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
-assume aligned_objects
and
-assume noaligned_objects
are not available when you use the
-oldc
option.
However, the
-misalign
option is a synonym for
-assume
noaligned_objects
and the
-no_misalign
option is
a synonym for
-assume aligned_objects.
Controls the compiler's assumptions about the alignment of
short
types accessed through a pointer.
-
Specifying
-assume trusted_short_alignment
indicates
that the compiler should assume any
short
accessed through
a pointer is naturally aligned. This generates the fastest code, but can
silently generate the wrong results if any of the
short
objects cross a quadword boundary.
-
Specifying
-assume notrusted_short_alignment
tells the
compiler that
short
objects may not be naturally aligned.
The compiler generates slightly larger (and slower) code that will give the
correct result, regardless of the actual alignment of the data. This is the
default.
-
Note that
-assume notrusted_short_alignment
does not
override the
__unaligned
type qualifier, the
-misalign
option, or the
-assume noaligned_objects
option.
Controls the alignment assumptions for code generated for
indirect load and store instructions.
-
The
-misalign
option is a synonym for
-assume
noaligned_objects
and the
-no_misalign
option is
a synonym for
-assume aligned_objects. The
-assume
[no]aligned_objects
option is discussed earlier in this reference
page.
Directs the compiler to byte-align data structure members
(with the exception of bit-field members).
-
By default, data structure members are aligned on natural 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.
Aligns structure members based on the integer
n, where
n
can be 1, 2, 4, or 8.
This option specifies packing so that each structure member after the first
is stored on
n-byte boundaries. When you specify
the
-Zp
option without an
n
value,
structure members are packed on 1-byte boundaries.
-
The use of the
-Zpn
option
(where n!=8) can cause conflicts between the compiler's assumptions about
data layouts and the default values that were in effect when the system libraries
were created. See
protect_headers_setup(8)
for details on how to avoid this
conflict.
Data Volatility Options
Affects the generation of code for assignments to objects
that are less than or equal to 16 bits in size (for instance
char,
short) that have been declared as volatile.
The generated code includes a load-locked instruction for the enclosing longword
or quadword, an insertion of the new value of the object, and a store-conditional
instruction for the enclosing longword or quadword. By using this locked instruction
sequence for byte and word stores, the
-strong_volatile
option
allows byte and word access of data at byte granularity. This means that
assignments to adjacent volatile small objects by different threads in a multithreaded
program will not cause one of the objects to receive an incorrect value.
Affects the generation of code for assignments to objects
that are less than or equal to 16 bits in size (for instance
char,
short) that have been declared as volatile.
The generated code includes a read of the enclosing longword or quadword,
an insertion of the new value of the object, and a store of the enclosing
longword or quadword.
This is the default.
-
The
-weak_volatile
option does not generate locked instructions
for this sequence. This allows byte or word access to memory-like I/O devices
for which larger accesses will not cause read or write side effects. Because
the sequence does not access byte or word data independently directly in memory
(that is, ensure byte granularity), adjacent volatile data can be corrupted
when such byte or word accesses are performed in a multithreaded environment
(for example, two volatile
shorts stored in a longword
and accessed asynchronously).
C Language Options
Promotes expressions of type
float
to
double. This is the default when
-std0
is used.
Prevents the compiler from promoting expressions of type
float
to type
double.
This is the default except in
-std0
mode.
Causes the compiler to assign floating-point constants the type float (rather
than double) if their values can be represented in single precision. This
option is not available in
-std1
mode.
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).
Causes all
char
declarations to have the
same representation and range of values as
signed char
declarations. This is used to override a previous
-unsigned
option. This is the default.
Causes all
char
declarations to have the
same representation and range of values as
unsigned char
declarations.
Prints warnings for all lines that may require the
<varargs.h>
macros.
Causes all variables to be treated as
volatile.
Causes all string literals to be writable. This is the default.
-
This option overrides
-readonly_strings.
Stack-handling and Pointer-handling Options
Forces all uninitialized stack variables to be initialized
with 0xfff58005fff58005. When this value is used as a floating-point 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.
Causes the compiler to respect the
#pragma pointer_size
directives, which control the size of pointers. These directives are ignored
otherwise.
-
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
-xtaso
or
-taso
option in order to run correctly.
See the
Programmer's Guide
for information on
#pragma pointer_size.
Directs the compiler to allocate 32-bit pointers by default.
You can still use 64-bit pointers, but only by the use of pragmas.
The
-xtaso_short
option also implies
-xtaso;
that is,
-xtaso_short
also causes the compiler to respect
the
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.
Makes all procedures in the source file use
$fp
(register 15) as the frame pointer.
IEEE Floating-point Support Options
Specifies chopped rounding mode (round toward zero).
Dynamically sets rounding mode for IEEE floating-point instructions.
The dynamic 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.
Specifies normal rounding mode (unbiased round to nearest).
This is the default.
Specifies round toward minus infinity mode.
Generates instructions that do not trigger floating-point
underflow or inexact trapping modes. Any floating point overflow, divide-by-zero,
or invalid operation will unconditionally generate a trap. The
-fptm
n
option is the default.
Generates traps on floating-point underflow as well as overflow,
divide-by-zero, and invalid operation.
Ensure support of all portable features of the
IEEE Standard for Binary Floating-Point Arithmetic
(ANSI/IEEE
Std 754-1985), including the treatment of denormalized 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.
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)
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: [
fjusmoca
]. 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.
Passes the argument, or arguments (argi),
to the compiler pass, or passes (c[c...]). Each
c
character can
be one of the following:
[ pfjusdqmocablyz ]. The
c
selects the compiler pass in the same way as the
-t
option.
The options from the set
-t[hpfjusmocablyzrntLCD],
-hpath, and
-Bstring
select a name to use for a particular pass, startup routine,
or standard library. These arguments are processed from left to right, so
their order is significant. When the
-B
option is encountered,
the selection of names takes place using the last
-h
and
-t
options. Therefore, the
-B
option is always required
when using
-h
or
-t. Sets of these options
can be used to select any combination of names.
All
-B
options must be preceded by
-p
options. The
-p
option provides the location of startup routines
and the profiling library.
Use the
-t [hpfjusmocablyzrntLCD]
suboptions to select
the names. The names selected are those designated by the characters following
the
-t
option, according to the following table:
|
Name | Character
|
|
| h (see note following table)
|
gemc_cc | p, f
|
as0 | a
|
as1 | b
|
ld | l
|
cord | z
|
[m]crt0.o | r
|
libprof1.a | n
|
om | L
|
pixie | C
|
prof | D
|
|
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.
Use
path
instead of the directory
where the name is normally found.
Append
string
to all names specified
by the
-t
option. If no
-t
option has been
processed before the
-B, the
-t
option is
assumed to be
hpfjusmocablyzrntL. This list designates
all names.
-
If no
-t
argument has been processed before the
-B, then a
-Bstring
is
passed to the loader to use with its
-lx
arguments.
Invoking the compiler with a name of the form
ccstring
has the same effect as using a
-Bstring
option on the command line.
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,
-kl,
-l,
-none,
-non_hidden, and
-no_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.
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
|
_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 DEC 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:
comp.config
options
DEC_CC
prologue
options
command line options
DEC_CC
epilogue
options
If
-v
is specified on the command line, the contents
of
DEC_CC
and
comp.config, if present, are displayed.
EXAMPLES
To compile the file
helloworld.c
using
the compiler's defaults use the following command:
cc helloworld.c
-
Because no output file is named in the command line, the result of the
compilation is written to the executable file named
a.out.
In this example, the
-v
option displays the
name of each compilation pass--and its arguments--as it executes.
cc -v helloworld.c
/usr/lib/cmplrs/cc/gemc_cc -D__LANGUAGE_C__ -D__unix__
-D__osf__ -D__alpha -D_SYSTYPE_BSD -D_LONGLONG
-DLANGUAGE_C -Dunix -DSYSTYPE_BSD -I/usr/include -v
-preempt_module -intrinsics -g0 -O2 -std0
-o helloworld.o helloworld.c
These macros are in effect at the start of the compilation.
----- ------ --- -- ------ -- --- ----- -- --- ------------
-D__DECC -D__osf__ -D__PRAGMA_ENVIRONMENT -D_LONGLONG
-D__X_FLOAT=0 -D__DATE__="Sep 2 1998" -D__DECC_VER=50890008
-DLANGUAGE_C -DSYSTYPE_BSD -D_SYSTYPE_BSD -D__DECC_MODE_COMMON
-D__ALPHA -D__IEEE_FLOAT -D__unix__ -D__TIME__="10:37:01"
-D__Alpha_AXP -D__INITIAL_POINTER_SIZE=0 -Dunix -D__LANGUAGE_C__
-D__alpha
/usr/lib/cmplrs/cc/gemc_cc:
0.01u 0.01s 0:00 50% 0+8k 0+2io 0pf+0w 8stk+1048mem
/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 16% 0+9k 0+12io 0pf+0w 9stk+1192mem
-
ENVIRONMENT VARIABLES
The following environment variables can affect compiler operation:
Provides a default value for locale variables that are not
set. If any of these variables contains an invalid setting, the compiler behaves
as if none were set.
If set to a non-empty string, this variable overrides values
in all locale variables, including
LANG.
Determines the locale for the interpretation of sequences
of bytes of text data as characters (for example, single- as opposed to multi-byte
characters in arguments and input files).
Determines the locale used for diagnostic messages.
Determines the locale of message catalogs for the processing
of
LC_MESSAGES.
Provides a pathname that overrides the default directory for
temporary files, if any.
For more information on these environment variables, see
i18n_intro(5)
and
l10n_intro(5).
FILES
Input file
Object file
Loaded output
Temporary
Compiler configuration file (optional)
C macro preprocessor
DEC C compiler
Post-link optimizer
Symbolic to binary assembly language translator
Binary assembly language assembler and reorganizer
Run-time startup
Startup for
prof
profiling
Startup for
gprof
profiling
Standard library, see
intro(3)
Level 1 profiling library
Reentrant level 1 profiling library for code compiled with
-pthread
or
-threads
Standard directory for header files
Interface between
prof
and
cord
Procedure-rearranger
File produced for analysis by
prof
File produced for analysis by
gprof
SEE ALSO
as(1),
atom(1),
cc(1old),
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
DEC C Language Reference Manual
Index
- NAME
-
- SYNOPSIS
-
- Default Options:
-
- OPTIONS
-
- Compiler Selection Options
-
- Language Mode Options
-
- Overall Compiler Behavior Options
-
- Compiler Diagnostic Controls Options
-
- C Preprocessor Options
-
- Linker or Loader Options
-
- Optimization Options
-
- Feedback-directed Optimization Options
-
- Source-code Debugging Options
-
- Program Profiling Options
-
- Data Alignment Options
-
- Data Volatility Options
-
- C Language Options
-
- Stack-handling and Pointer-handling Options
-
- IEEE Floating-point Support Options
-
- Compiler Development Options (Not Generally Used)
-
- DESCRIPTION
-
- EXAMPLES
-
- ENVIRONMENT VARIABLES
-
- FILES
-
- SEE ALSO
-
This document was created by
man2html,
using the manual pages.
Time: 02:42:57 GMT, October 02, 2010