cc
SYNOPSIS
cc [-newc] [flag ...] file ...
cc -oldc [flag ...] file ...
cc -migrate [flag ...] file ...
Default Flags:
cc -newc -assume aligned_objects -cpp -call_shared -double
-fprm n -fptm n -g0 -I/usr/include -inline manual -mem
ber_alignment -no_fp_reorder -no_misalign -O1 -oldcomment
-p0 -no_pg -preempt_symbol -signed -arch generic -std0
-tune generic -writable_strings
DESCRIPTION
Note
This manpage is outdated. It is being retained only for
the purpose of documenting the -oldc and -migrate flags.
These flags were provided in previous versions of DIGITAL
UNIX to support the transition to the new C compiler.
That transition is now complete and we do not encourage
the continued use of these flags.
This manpage will not be updated to reflect changes to the
system C compiler. It should only be referenced to gain an
understanding of the effects of -oldc and -migrate. For
documentation on the system C compiler, see cc(1).
The cc command invokes the C compiler. The -newc and
-oldc flags invoke different compiler implementations
(where the implementation invoked by -newc is upwardly
compatible with that invoked by -oldc). The "newc" com
piler offers improved optimization, additional features,
and greater compatibility with Digital compilers provided
on other platforms. The "newc" compiler implementation is
the default.
You can access the "newc" compiler with either the -newc
flag or the -migrate flag; however, the default flags
associated with these two flags are different:
- The default flags associated with the -newc flag are
similar to the defaults associated with the -oldc flag.
- The default flags associated with the -migrate flag are
the same as those previously associated with the
-migrate flag in the compilation environment for ver
sions of the DEC OSF/1 operating system preceding DIGI
TAL UNIX Version 4.0.
can continue to use the compiler in the same way that they
did previously (that is, the same command line accesses
the same compiler with the same defaults).
The cc command can accept any of the following file argu
ments:
- Arguments whose names end with .c are assumed to be C
source programs. They are compiled, and each object pro
gram 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 sym
bolic 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 preproces
sor.
- Arguments whose names do not end with .c, .s, or .i are
assumed to be either C-compatible object files, typi
cally produced by an earlier cc run, or libraries of C-
compatible routines.
When you use the -oldc flag, the compiler accepts the fol
lowing additional file arguments:
- Arguments whose names end with .c are compiled into
ucode object files when -oldc's highest level of opti
mization is specified (-O3 flag) or when only ucode
object files are to be produced (-j flag). The ucode
object file is left in a file whose name consists of the
last component of the source with .u substituted for .c.
- Arguments whose names end with .B, .O, .S, and .M are
assumed to be binary ucode, produced by the front end,
optimizer, ucode object file splitter, and ucode merger,
respectively. Arguments whose names end with .U are
assumed to be symbolic ucode. Arguments whose names end
with .G are assumed to be binary assembly language,
which is produced by the code generator and the symbolic
to binary assembler. These files primarily aid in com
piler development and are not generally used.
- Files that are assumed to be binary ucode, symbolic
The cc command can accept flags that are specific to
either the cc command or the ld command (linker). When
the compiler recognizes position-sensitive linker flags
(-L, -all, -exclude, -exported_symbol, -hidden, -hid
den_symbol, -kl, -l, -none, -non_hidden, and -no_archive),
it maintains their relative order for the linker. This
reference page describes the flags that are specific to
the cc command. See ld(1) for a description of the linker
flags.
All of the input files, plus the results of the compila
tions, are loaded in the order given to produce an exe
cutable program with the default name a.out. The compiler
can produce object files in extended COFF format (the nor
mal result). It can also produce object files in symbolic
assembly language format when invoked with the -S flag.
When invoked with the -oldc flag, it can also produce
binary assembly language code, binary ucode, or symbolic
ucode.
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 ref
erence these macros in #ifdef statements to isolate code
that applies to a particular language or environment. The
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 Flag
-------------------------------------------------------------------------
__DECC (-newc and -migrate only) .c
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
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 flag to con
trol which functions are declared in header files and to
obtain standards conformance checking. See for a list of
While the -D flag controls which functions are declared in
header files, the -stdn flags 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 flag.
The following environment variables can affect compiler
operation:
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 pro
cessing of LC_MESSAGES.
TMPDIR
Provides a pathname that overrides the default direc
tory for temporary files, if any.
For more information on these environment variables, see
i18n_intro(5) and l10n_intro(5).
To facilitate setting default compiler flags, you can cre
ate 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 flags that are applied to
compilations on a system-wide basis. The compiler flags
in comp.config must be specified on a single line, and
- The DEC_CC environment variable allows DEC C users to
establish a set of compilation flags that are applied to
subsequent compilation on a per-user basis.
The DEC_CC environment variable can contain two distinct
sets of compilation flags separated by a single vertical
bar (|). The flags before the vertical bar are known as
prologue flags and the flags after the bar are know as
epilogue flags.
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 flags are treated as pro
logue flags by default. Any vertical bar found after
the first vertical bar is treated as whitespace and a
warning is issued.
Compiler flags are processed in the following order during
a compilation:
1. comp.config flags
2. DEC_CC prologue flags
3. command line flags
4. DEC_CC epilogue flags
If -v is specified on the command line, the contents of
DEC_CC and comp.config, if present, are displayed.
FLAGS
Flags described in this section are divided into the fol
lowing categories:
- Compiler selection flags
- Overall compiler behavior flags
- C preprocessor flags
- Linker or loader flags
- Optimization flags
- Feedback-directed optimization flags
- Code portability flags
- Data alignment flags
- Data volatility flags
- C language flags
- Rounding-mode flags (IEEE floating-point)
- Stack-handling and pointer-handling flags
- IEEE floating-point support flags
- Ucode generation flags (enabled by -oldc)
- Compiler development flags (not generally used)
Compiler Selection Flags
-newc
Invokes the new implementation of the C compiler, with
defaults that make it compatible with the -oldc com
piler. This is the default.
-migrate
Invokes the new implementation of the C compiler, but
with a slightly different set of compiler flags and
default optimizations. These flags and optimizations
provide backward compatibility for applications rely
ing on the -migrate flag provided in previous imple
mentations of the cc command.
-oldc
Invokes the older, ucode-based implementation of the C
compiler.
Overall Compiler Behavior Flags
-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-manip
ulation extension), MVI (multimedia extension), FIX
(square root and floating-point extension), and CIX
(count extension). (The Alpha Architecture Reference
generic
Generate instructions that are appropriate for all
Alpha processors. This option is the default.
host
Generate instructions for the processor that the com
piler is running on (for example, EV6 instructions on
an EV6 processor).
ev4,ev5
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.
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 emu
lation 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, FIX, and CIX.
Applications compiled with this option may incur emu
lation overhead on EV4, EV5, EV56, and PCA56 proces
sors.
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 emu
and continuing with subsequent versions, the operating
system kernel includes an instruction emulator. This
capability allows any Alpha chip to execute and pro
duce 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 emula
tion overhead at run time.
The psrinfo -v command can be used to determine which
type of processor is installed on any given Alpha sys
tem.
-c Suppresses the loading phase of the compilation and
forces the creation of an object file.
-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 compi
lation 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 flag 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 com
pile job has to be in the foreground for this flag to
take effect. When compiling on a workstation, this
flag takes effect whether it is in the foreground or
background.
-[no]error_limit nn
Sets a limit on the number of errors that the compiler
will flag. 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 develope include files contain
ing sets of pragmas that control a particular aspect
of a compilation (for example, optimizations or diag
nostics).
-msg_actiontype msg_list
Provides users with the ability to control the diag
nostic 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 mes
sage ID strings enclosed in parentheses at the end of
message text strings).
The -msg_actiontype flag 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 flags 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 mes
sages. (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.)
sage 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 spec
ified (or default) level, not to lower levels.
The following message levels and message groups are sup
ported:
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 mes
sages. These messages are not displayed if pragma nos
tandard 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 the DIGITAL UNIX V4.0E and later versions.
level3
Less important messages. (The -w0 flag enables level 3
messages.)
level4
Useful messages associated with the -check and -portable
flags.
level5
Less useful -check and -portable messages than the mes
sages associated with level 4. (The -check flag enables
level 5 messages.)
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
alignment
Messages reporting unusual or inefficient data align
ment.
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 cor
rect 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, fea
tures that were commonly accepted by early C compilers
but were subsequently removed from the language.
noansi
Messages reporting the use of non-ANSI C features.
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 lan
guage 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.
preprocessor
Messages reporting questionable or non-portable use of
preprocessing constructs.
guestcode
Messages reporting questionable coding practices. Simi
lar to check, but messages in this group are more likely
to indicate a programming error, not just a non-robust
unused
Messages reporting expressions, declarations, and code
paths that are not used.
-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.
[The -machine_code flag is not available when you use
the -oldc flag.]
-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 flag when you need only a listing of
a program or when you want the compiler to check a
source file for errors.
[The -noobject flag is not available when you use the
-oldc flag.]
-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 flag are as fol
lows:
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
the compiler's default behavior in effect.
If more than one such switch appears on the command
line, only the last one is applied. See protect_head
ers_setup(8) for details.
[The -protect_headers flag is not available when you
use the -oldc flag.]
-S Compiles the specified source files and generates sym
bolic 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, sep
arate 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 flag are as follows:
none
Turns off all show options.
all Turns on all show options.
[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 substitu
tions that occur on each line.
[no]header
Produces header lines at the top of each page of list
ing.
[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 pro
gram listing.
If you specify -source_listing but do not specify
[The -show flag is not available when you use the
-oldc flag.]
-source_listing
Produces a source program listing file with the same
name as the source file and with a .lis file exten
sion. You must specify this qualifier to get a list
ing. The default is to not produce a listing file.
[The rce_listing flag is not available when you use
the -oldc flag.]
-v Prints the compiler passes as they execute with their
arguments and their input and output files. Also
prints resource usage in the C-shell time format. If
specified more than once, the passes are printed but
not executed.
When specified with -newc or -migrate, the -v flag
also directs the compiler to display the macros
defined at the start of the compilation.
-V Prints the version of the compiler driver and, when
the -oldc flag is specified, the versions of all
passes in the same format as the what command.
-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 all levels of compiler messages (warnings,
errors, fatals, and, when -newc or -migrate is speci
fied, informational messages).
1 Suppresses warning messages. The -w1 flag displays
error and fatal messages and, when -newc or -migrate
is specified, informational messages. Specifying -w
is the equivalent of specifying -w1.
2 If the compiler encounters an error that generates a
warning-level diagnostic message, the compiler dis
plays the message and then aborts.
If no -w flag is specified (the default), only warn
ing, error, and fatal messages are displayed.
-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 Flags
-C Passes all comments directly to the preprocessor,
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 indi
cated by the -I flag, and finally in the standard direc
tory, /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 flag, and then in
the standard directory, /usr/include.
search path. If no dir is specified in any instance of
the -I[dir] flag, the C macro preprocessor never
searches the standard directory, /usr/include, for
header files.
The -nocurrent_include flag can also modify the search
path.
-M Requests a dependency list. This flag is passed
directly to the preprocessor. See cpp(1) for details.
-MD Requests a dependency file. This flag is passed
directly to the preprocessor and linker. For more
information, see cpp(1) and ld(1).
-nocurrent_include
Controls the search order for header files. This flag
is passed directly to the preprocessor. For more
information, see cpp(1).
-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 macro
lines in it.
-proto[is]
Extracts prototype declarations for function defini
tions and puts them in a .H suffixed file. The subop
tion 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 definition of name, where name is either a
symbol previously defined with the -D flag or a
reserved symbol that is predefined by the compiler.
If no name is specified, the -U flag is ignored. (To
display a list of predefined symbols, enter the cc
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 flag to the compilation phase (if
the -c flag is present) or passes the -compress_r flag
to ld (if the -r flag is present). Use of this flag
causes the output object file to be produced in com
pressed object file format, resulting in a substan
tially 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 flag or a.out by
default. At least one -feedback file must be speci
fied. See prof(1) for information on creating feed
back files.
-exact_version
Used in conjunction with -call_shared to request
strict dependency testing for the executable file pro
duced. 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.
-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 wild
card characters must be properly quoted to prevent
them from being expanded by the shell. For more infor
mation, see sh(1).
-fini symbol
Makes the procedure represented by the symbol into a
termination routine. A termination routine is a rou
tine 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
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 file
name 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 flag can
be used to display the expansion of files specified in
a -input file. The files can be nested up to 20 lev
els.
-no_archive
Prevents the linker from using archive libraries to
resolve symbols. This flag is used in conjunction with
-call_shared. The -no_archive flag is position sensi
tive; it affects only those flags and variables that
follow it on the command line. This flag 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.
-shared
Produce dynamic shareable objects. The loader will
produce a shareable object that other dynamic executa
bles 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.
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 iden
tifiers; 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 speci
fied 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 path
name (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 seg
ments and makes sure they stay out of the way of oth
ers in the location_file. Location_file is updated if
it is writable.
-pthread
Directs the linker to use the threadsafe version of
any library specified with the -l flag when linking
programs. This flag also tells the linker to include
the POSIX 1003.1c-conformant DECthreads interfaces in
libpthread when linking the program.
-taso
Directs the linker to load the executable file in the
lower 31-bit addressable virtual address range. The -T
and -D flags to the ld command can also be used,
respectively, to ensure that the text and data seg
ments addresses are loaded into low memory.
The -taso flag, however, in addition to setting
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 flag
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 flag when linking
programs. This flag also tells the linker to include
the POSIX 1003.4a Draft 4 conformant DECthreads inter
faces. It is supported only for compatibility with
earlier releases of Digital UNIX. New designs should
use the -pthread flag.
Optimization Flags
-[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 -noansi_alias
flag turns off ANSI C aliasing rules.
The aliasing rules are explained in Section 3.3, para
graphs 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
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 point
ers of a different type (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 flag. The
default is -ansi_alias when compiling with the -std1
flag.
The -noansi_alias flag turns off ANSI C aliasing rules.
The -[no]ansi_alias flag is not available when you use
the -oldc flag.
-[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 -no_ansi_args means that the argument type
may not match the expected parameter type. This flag
is important, for example, when the caller passes a
parameter of type long and the called routine expects
an int. The -no_ansi_args flag forces the compiler to
generate argument cleaning code to convert the argu
ment to the appropriate type. Except when the -std1
flag 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.
[The -[no_]ansi_args flag is not available when you
use the -oldc flag.]
-assume array_parameter_restricted_pointers
Specifies the assumption that all array parameters are
restricted. In the following code, for example, only
extern int foo(char * a, char b[]);
When this flag is specified, both a and b are treated
as 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.
[The -assume [no]math_errno flag is not available when
you use the -oldc flag.]
-assume parameter_restricted_pointers
Specifies the assumption that all pointer parameters
are restricted.
-assume [no]restricted_pointers
Specifies the assumption that all pointers are
restricted.
The -assume norestricted_pointers flag 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.
tor (&) are being applied outside the current compila
tion unit to extern variables that are declared inside
the current compilation unit. Making this assertion
allows the compiler to perform better optimizations.
This flag is often suitable for use with the -ifo
flag, which presents a group of source files to the
compiler as a single compilation unit.
-fast
Provides a single method for turning on a collection
of optimizations for increased performance.
Note that the -fast flag can produce different results
for floating-point arithmetic and math functions,
although most programs are not sensitive to these dif
ferences.
The -fast flag defines the following compiler flags
and symbols to improve run-time performance. You can
adjust the optimizations by specifying the negation of
any given flag.
-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 flag 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 flag 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 flag elsewhere in this
-assume trusted_short_alignment
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 flag elsewhere in this
reference page for more detailed information about
this operation.
-D_INTRINSICS
Declares certain functions to be intrinsic. When a
function is intrinsic, the compiler is free to gener
ate faster code that provides the same function behav
ior (but may not actually call the function).
-D_INLINE_INTRINSICS
Directs the compiler to inline some of the intrinsic
functions, avoiding the overhead of a function call.
-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 sup
port 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 flag elsewhere in this
reference page for more detailed information about
this operation.
-fp_reorder
Allows floating-point operations to be reordered dur
ing optimization.
See the description of this flag elsewhere in this
reference page for more detailed information about
this operation.
-ifo
Performs inter-file optimizations.
See the description of this flag elsewhere in this
reference page for more detailed information about
this operation.
-intrinsics
See the description of this flag elsewhere in this
reference page for more detailed information about
this operation.
-O3 or -O4
The -newc and -oldc flags set the optimization level
to -O3.
The -migrate flag sets the optimization level to -O4.
See the description of these flags elsewhere in this
reference page for more detailed information about
this operation.
-readonly_strings
Makes string literals read-only for improved perfor
mance.
See the description of this flag elsewhere in this
reference page for more detailed information about
this operation.
-feedback file
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 com
piler can use when performing optimizations.
You can also use a feedback file as input to the cord
utility, using -feedback and the -cord flags to link
the program.
-[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 -no_fp_reorder flag, the default, directs the com
piler to use only certain scalar rules for calcula
tions. This setting can prevent some optimizations.
The -fp_reorder flag frees the compiler to reorder
floating-point operations based on algebraic identi
ties (inverses, associativity, and distribution). For
instance, this allows the compiler to move divide
operations outside of loops, thus improving perfor
mance.
If you specify -fp_reorder and the compiler reorders
code to improve performance, the results can differ
rate than those gained by the default.
-G num
Specifies the maximum size, in bytes, of a data item
that is to be put in one of the small data sections.
Data items in the small data sections are more likely
to be candidates for global pointer optimizations by
link-time optimizations. The num argument is inter
preted as a decimal number. The default value for num
is 8 bytes. This value cannot be changed when using
the -newc or -migrate flag.
-ifo
Provide improved optimization (inter-file optimiza
tion) and code generation across file boundaries that
would not be possible if the files were compiled sepa
rately.
When you specify -ifo on the command line in conjunc
tion with a series of file specifications, the com
piler does not concatenate each of the specified
source files. Instead, each file is treated sepa
rately for purposes of parsing, except that the com
piler will issue diagnostics about conflicting exter
nal 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.
[The -ifo flag is not available when you use the -oldc
flag.]
-[no_]inline keyword
Specifies whether to provide inline expansion of func
tions. The -no_inline flag disables the inlining
optimization that would otherwise be performed by
default under the following compiler optimization
-O[n] flags:
- When -O2, -O3, or -O4 is specified under -newc
- When -O4 or -O5 is specified under -migrate
- When -O3 is specified under -oldc
When choosing calls to expand inline, the compiler also
considers the function size, how often the call is exe
cuted, how many registers the inline expansion will
require, and other factors.
none
No inlining is done, even if requested by a #pragma
inline preprocessor directive. This is the default
when compiling with the -O0 optimization level.
manual
Inlines only those function calls explicitly requested
for inlining by a #pragma inline directive. This is
the default when compiling with the -O1 flag under
-newc.
size
Inlines all of the function calls in the manual cate
gory, 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
flag under -newc, or the -O, -O4, or -O5 flag under
-migrate.
speed
Inlines all of the function calls in the manual cate
gory, plus any additional calls that the compiler
determines would improve run-time performance, even
where it may 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 flag is
ignored and no inlining is done. The #pragma noinline
preprocessor directive can also prevent inlining of
any function.
[The -inline flag is not available when you use the
-oldc flag.]
-[no_]intrinsics
Controls whether the compiler recognizes certain func
tions as intrinsic functions - even if the appropriate
header file is not included and the function names are
not specified in a pragma intrinsic directive. Recog
nition is based on the function name and the call sig
nature (arguments and return types).
When the compiler identifies a function as an intrin
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 flag has no
effect at this optimization level.
-O2 (or -O)
Memory and string functions: alloca, bcopy, bzero, mem
cpy, 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 cumu
lative; 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 flag is in effect by default. To dis
able the default, specify the -no_intrinsics flag. To
disable the intrinsic treatment of individual functions,
specify the function names in a pragma function direc
tive in either your source code or a file associated
with a -FI flag ("file include" flag).
-mp Enables the compiler to process parallel decomposition
pragmas (directives) in C source code. It also trig
gers the link phase to link with the appropriate
thread and compiler support libraries that are needed
to run the generated multiprocessor code.
or without -mp. With -mp, the pragmas cause the pro
gram to run in several concurrent threads that may
execute in a significantly shorter elapsed time on a
DIGITAL UNIX multiprocessor system. Without -mp, the
compiler will ignore the pragmas and the program will
run sequentially as a normal C program.
[The -ifo flag is not available when you use the -oldc
flag.]
-O[n]
Determines the level of optimization. The following
table lists the types of optimizations that can be
performed. The default optimization level is -O1.
Note, however, that different optimizations are per
formed at each level, depending on whether you invoke
the compiler with the -newc, -oldc, or -migrate flag.
------------------------------------------------------
-newc -oldc -migrate Optimization
------------------------------------------------------
-O0 -O0 -O0 None
-O1 -O1 -O1 Local optimizations
and recognition of
common subexpressions.
-O1 -O2, -O -O2, -O Global optimization,
including code motion,
strength reduction and
test replacement,
split lifetime analy
sis, and code schedul
ing.
-O2, -O -O2, -O -O3 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 elimi
nate branches.
-O2, -O -O3 -O4 Inline expansion of
static procedures.
-O3 -O3 -O4 Inline expansion of
global procedures.
ysis, vectorization of
some loops on 8-bit
and 16-bit data (char
and short), and inser
tion of NOP instruc
tions to improve
scheduling.
------------------------------------------------------
To determine whether using -O4 with -newc benefits
your program, you should compare program execution
times for the same program compiled at levels -O3 and
-O4.
If you are using the -O (or -O2) optimization level
when compiling code that will never end up in a shared
library, you should consider changing to the -O3 level
because it provides additional compiler optimizations.
(The -O3 level may inhibit the ability to preempt sym
bols, so it should not be used for shared libraries.)
-Olimit num
Specifies the maximum size, in basic blocks, of a rou
tine that will be optimized by the global optimizer.
If a routine has more than this number of basic
blocks, it will not be optimized and a message will be
printed. A flag specifying that the global optimizer
is to be run (-O2 or -O3) must also be specified. The
num is assumed to be a decimal number. The default
value for num is 500 basic blocks.
[The -Olimit flag is not available with the -newc or
-migrate flags.]
-om Performs code optimization after linking, including
nop (no operation) removal, .lita removal, and reallo
cation of common symbols. This flag also positions the
$gp register so that the maximum number of addresses
fall in the $gp-accessible window. The -om flag is
supported only for programs compiled with the
-non_shared flag. The following options can be passed
directly to -om by using the -WL compiler flag:
-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
"common" symbol whose size is less than or equal to
num will be allocated close to each other. This flag
can be used to improve the probability that the symbol
can be accessed directly from the $gp register. (Nor
mally, 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 flag
will quadword align the targets of all branches 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 representa
tive 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.
-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 -newc is used
- At optimization levels -O4 and -O5 when -migrate is used
flags 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. During optimiza
tion, if inlining is requested, only static functions
are eligible.
The default taken for a compilation is either -pre
empt_symbol or -preempt_module. See the description
of the -preempt_module flag for details on the condi
tions that determine which option is taken as the
default.
-speculate all
Specifies that speculation may occur anywhere in the
executable image.
A conditionally-executed operation is speculated by
beginning the operation's execution prior to testing
the condition that guards the use of the value of that
operation. If execution reaches the conditionally-
executed use of the operation's value, then that value
will be available for immediate use. If execution
does not reach the conditionally executed use of the
operation's value, then the speculatively computed
value is ignored.
If any module in a program is compiled with -speculate
all, all exceptions throughout the entire program are
dismissed on the assumption that the execution is
caused by an unsuccessful speculative instruction.
(Note, though, that floating-pointing instructions
specifying software completion [/S] are still given
normal exception handling.) Code compiled with the
-speculate all flag cannot use any form of local
exception handling nor be linked with any routines
that do. As a result, you should use the -speculate
all flag only in programs that are known to be error-
free and that do not depend on fault and trap han
dling. 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 all flag is not available when you use
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 spec
ulative routine. It dismisses exceptions from rou
tines 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 han
dling.) As a result, you should use the -speculate
by_routine flag 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 flag yields somewhat slower
execution than the -speculate all flag, but does not
restrict trap and fault handling in other modules with
which it is linked.
[The -speculate by_routine flag is not available when
you use the -oldc flag.]
-tune option
Selects processor-specific instruction tuning for a
specific implementation of the Alpha architecture.
Tuning for a specific implementation can provide
improvements in run-time performance.
Regardless of the setting of the -tune flag, the gen
erated code will run correctly on all Alpha proces
sors. Note that code tuned for a specific target may
run more slowly on another target than generically-
tuned code.
The option keyword can be one of the following:
generic
Selects instruction tuning that is appropriate for all
Alpha processors. This option is the default.
host
Selects instruction tuning that is appropriate for the
processor on which the code is being compiled.
ev4 Selects instruction tuning for the 21064, 21064A,
number 21164 is used for both EV5 and EV56 proces
sors.)
ev6 Selects instruction tuning for the 21264 chip.
-unroll n
Controls loop unrolling done by the optimizer at lev
els -O2 and above for -newc. Specifying -unroll n
unrolls loop bodies n times. Specifying -unroll 0
means the optimizer uses its own default unroll
amount. Specifying -unroll 1 means no unrolling. The
default is -unroll 0.
[The -unroll flag is not available when you use the
-oldc flag.]
Feedback-directed Optimization Flags
-prof_gen
Generates an executable image that has profiling code
added to it. Using this flag is equivalent to running
the pixie(5) command on an existing image, except the
resulting image will not have the .pixie extension.
See also the descriptions of the -prof_use_om_feed
back, -prof_dir, and -pids flags.
-prof_use_feedback
Uses profiling feedback to improve runtime perfor
mance. Using this flag is equivalent to using the
prof(1) command to produce a feedback file, and then
using the cc -feedback command to recompile the pro
gram.
To use the -prof_use_feedback flag, first compile your
program with the -prof_gen and -gen_feedback flags 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 flag uses the -om postlink optimizer, and is
equivalent to using the -om -WL,-om_ireorg_feedback
flags. If the -pids flag is also specified, this flag
merges the .Counts performance data files using the
prof -pixie -merge command.
To use the -prof_use_om_feedback flag, first compile
-prof_dir
Specifies a location to which the profiling data files
(.Counts and .Addrs) are written. Use this flag in
conjunction with the -prof_gen flag and the
-prof_use_feedback or -prof_use_om_feedback flag to
specify a location for the profiling data files. If
you do not specify this flag, the profiling files are
written to the current directory.
Specifying the -prof_dir flag also enables the -pids
flag.
-[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 flag is specified, the default is
-no_pids.
Source-code Debugging Flags
-g[n]
Determines the production of symbol table information.
When no value is specified for n, the compiler pro
duces 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:
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. How
ever, 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 appro
priate. Line-oriented debugging commands work, but
symbol types and the names of stack-frame variables
optimizations are supported.
2 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).
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 Flags
-gen_feedback
Generates accurate profile information to be used with
-feedback optimizations, as follows:
1.
Compile the source code with the -gen_feedback flag.
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 flag and either
the -O2 or -O3 flag (for -newc) or the -O2, -O3, -O4, or
-O5 flag (for -migrate). This provides the compiler
with execution information that the compiler can use to
improve certain optimizations.
[The -gen_feedback flag is not available when you use
the -oldc flag.]
-p[n]
Determines the level of profiling. The -p flag pre
pares for profiling by periodically sampling the value
time startup routine (mcrt0.o) and the level 1 profil
ing library (libprof1.a) is searched. When you use the
-p flag together with either the -pthread flag or the
-threads flag, the profiling library libprof1_r.a is
used.
When profiling begins, the startup routine calls mon
startup (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 flag. The
gprof profiler produces a call graph showing the exe
cution of a C program.
When this flag is turned on, the standard run-time
startup routine is replaced by the gcrt0.o routine.
Programs that are linked with the -pg flag 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 flag
together with either the -pthread flag or the -threads
flag, the profiling library libprof1_r.a is used.
For more information, see the gprof(1) reference page.
Code Portability Flags
-accept option1[,option2,...]
Overcomes the problem of DEC C's relaxed ANSI mode
(-std, the default option) accepting many VAX C key
words that are not accepted in K&R mode. Without this
option, a user program will stop compiling if it con
tains a variable with the same name as one of the VAX
C keywords. The following options are available:
names of variables in programs being compiled. If
vaxc_keywords is specified, the compiler will recognize
the VAX C keywords no matter what standard option is
specified.
[no]restrict_keyword
Cause the compiler to recognize the restrict keyword
(C9X standard) no matter what standard mode is speci
fied.
-check
Performs compile-time code checking. With this flag,
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. This flag is available for
-newc and -migrate only.
-isoc94
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
flag has no influence on -stdn flags and vice versa.
-ms Directs the compiler to interpret source code accord
ing to certain language rules followed by the C com
piler provided with the Microsoft Visual C++ compiler
product. Compatibility with this implementation is
not complete; however, the compiler recognizes the
following extensions and responds to them by relaxing
a standard behavior and, in most instances, suppress
ing a diagnostic message:
- 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. */
typedef int typedefname;
typedef int typedefname;
- Allow typedef declarations that are redeclared to a com
patible type. For example:
typedef enum {a,b,c} typedefname;
typedef enum {d,e,f} typedefname;
- Allow declaration of a structure with a trailing incom
plete array. This is useful if you are dealing with
counted arrays, where the first element of the structure
is used to hold a count of the array elements, the sec
ond 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;
}
a pointer to char can be assigned to a pointer to signed
char, assuming that the -signed flag is in effect:
signed char *a;
- Suppress warning messages for declarations that contain
two semicolons; that is, allow completely empty declara
tions at file scope. For example:
int a;;
- Suppress warning messages for declarations that contain
a variable name but no type. For example:
b;
- 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
The -stdn flag and the -ms flags are mutually
exclusive. When both of these flags are specified,
the last one seen by the driver program is placed
in effect. (When -ms is in effect, -std is the
default.)
-portable
Directs the compiler to issue diagnostics for any non
portable coding that it encounters.
-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 flags 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.)
-std[n]
Directs the compiler to issue warnings when it encoun
ters language constructs that are not standard in the
language. The default is -std.
The following values are accepted:
-std
Enforces the ANSI C standard, but allows some common
programming practices disallowed by the standard. The
-std flag causes the macro __STDC__=0 to be passed to
the preprocessor.
-std0
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 flag causes the __STDC__ macro to
be undefined.
-std1
Strictly enforces the ANSI C standard and all its pro
hibitions (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 modifi
cation of rvalues). This flag does not, however,
restrict the name space defined by the DIGITAL UNIX
implementation to only reserved names as specified by
ANSI C.
The -std1 flag causes the macro __STDC__=1 to be
None of the -std* flags restrict or expand the name
space defined by the DIGITAL UNIX implementation (for
example, items declared in system header files). To
restrict the name space so that only ANSI C reserved
names are made visible from the system header files
listed in the ANSI C standard, use the _ANSI_C_SOURCE
macro. For details on _ANSI_C_SOURCE and other stan
dard macros, see standards(5).
-vaxc
Places the compiler in VAX C compatibility mode. In
addition to supporting the ANSI C language, this mode
of compilation also supports VAX C extensions that are
incompatible with the ANSI C standard and that change
the language semantics. This mode provides compatibil
ity for programs that depend on old VAX C behavior.
This flag is not available when you use the -oldc
flag.
Data Alignment Flags
-assume [no]aligned_objects
Controls the alignment assumptions for code generated
for indirect load and store instructions.
The -assume aligned_objects flag 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, dereferenc
ing 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 flag 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 flag may gener
ate 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 flag is the default. The
- 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 flag to compile the mod
ule; otherwise, your program may get alignment faults
during execution, which will degrade performance.
The -assume aligned_objects and -assume
noaligned_objects flags can be used in the same cc com
mand, allowing you to turn this flag 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 flag. However, the -misalign flag is a synonym
for -assume noaligned_objects and the -no_misalign flag
is a synonym for -assume aligned_objects.
-assume [no]trusted_short_alignment
Controls the compiler's assumptions about the align
ment 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 gener
ates the fastest code, but can silently generate the
wrong results if any of the short objects cross a
quadword boundary. This is the behavior when -oldc is
specified.
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 when -newc or -migrate is specified.
Note that -assume notrusted_short_alignment does not
override the __unaligned type qualifier, the -misalign
-[no_]misalign
Controls the alignment assumptions for code generated
for indirect load and store instructions.
The -misalign flag is a synonym for -assume
noaligned_objects and the -no_misalign flag is a syn
onym for -assume aligned_objects. The -assume
[no]aligned_objects flag is discussed earlier in this
reference page.
-[no]member_alignment
Directs the compiler to byte-align data structure mem
bers (with the exception of bit-field members).
By default, data structure members are aligned on nat
ural boundaries (that is, on the next boundary appro
priate 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 flag.
The use of the -nomember_alignment flag can cause con
flicts between the compiler's assumptions about data
layouts and the default values that were in effect
when the system libraries were created. See pro
tect_headers_setup(8) for details on how to avoid this
conflict.
[The -[no]member_alignment flag is not available when
you use the -oldc flag.]
-Zp[n]
Aligns structure members based on the integer n, where
n can be 1, 2, 4, or 8. This flag specifies packing so
that each structure member after the first is stored
on n-byte boundaries. When you specify the -Zp flag
without an n value, structure members are packed on
1-byte boundaries.
The use of the -Zpn flag (where n!=8) can cause con
flicts between the compiler's assumptions about data
layouts and the default values that were in effect
when the system libraries were created. See pro
tect_headers_setup(8) for details on how to avoid this
conflict.
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 flag
allows byte and word access of data at byte granular
ity. 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.
[The -strong_volatile flag is not available when you
use the -oldc flag.]
-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.
The -weak_volatile flag 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 per
formed in a multithreaded environment (for example,
two volatile shorts stored in a longword and accessed
asynchronously).
[The -weak_volatile flag is not available when you use
the -oldc flag.]
C Language Flags
-double
Promotes expressions of type float to double. This is
the default when -std0 is used.
-float
-float_const
Causes the C front end to inspect the floating-point
value and treat the value as a float if it can be rep
resented as a single precision value. By default, all
floating-point constants are treated as double preci
sion.
To ensure that this change has no impact on standards
conformance, the -float_const flag is disabled when
-std1 (strict ANSI mode) is also specified on the com
pile command line. When this situation occurs, the
compiler issues a warning message indicating that the
-float_const flag is being ignored.
-readonly_strings
Causes all string literals to be read-only. This is
the default.
This flag overrides -writable_strings. If you attempt
to write to a string literal when -readonly_strings is
specified, you might experience unpredictable results,
such as a segmentation fault.
-signed
Causes all char declarations to have the same repre
sentation and range of values as signed char declara
tions. This is used to override a previous -unsigned
flag. This is the default.
-unsigned
Causes all char declarations to have the same repre
sentation and range of values as unsigned char decla
rations.
-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 flag overrides -readonly_strings.
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 regis
ter 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.
Stack-handling and Pointer-handling Flags
-trapuv
Forces all uninitialized stack variables to be ini
tialized 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 segmenta
tion violation usually occurs.
For programs compiled without the -trapuv switch, the
debugger stops only on executable statements in which
the value of a specified variable changes. With the
-trapuv switch, the debugger stops on these statements
and also stops on all local variable declarations.
(The debugger treats the local variable declarations
as assignment statements because the variables are
initialized by the compiler.)
-xtaso
Controls pointer size allocation by directing the com
piler to respond to the #pragma pointer_size prepro
cessor directives. This flag allows you to specify
32-bit pointers when used in conjunction with the
pragma pointer_size directive. To use 32-bit pointers,
you must place pragmas where appropriate in your pro
gram. Images built with this flag must be linked with
the -xtaso or -taso flag in order to run correctly.
See the Programmer's Guide for information on #pragma
pointer_size.
default. You can still use 64-bit pointers, but only
by the use of pragmas.
The use of the -xtaso_short flag 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 (reg
ister 15) as the frame pointer.
IEEE Floating-point Support Flags
-fptm n
Generates instructions that do not trigger floating-
point underflow or inexact trapping modes. Any float
ing point overflow, divide-by-zero, or invalid opera
tion will unconditionally generate a trap. -fptm n 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 flag also sets the
_IEEE_FP C preprocessor macro.
If your program must use IEEE signaling features that
are not portable across different IEEE implementa
tions, see the ieee(3) reference page for a discussion
of how to access them under the DIGITAL UNIX operating
system.
-scope_safe
Ensures that any trap (such as floating-point over
flow) is reported to have occurred in the procedure or
guarded scope that caused the trap. Any trap occur
ring outside that scope is not reported to have
occurred in the procedure or guarded scope, with the
exception of well-defined trapb instructions following
jsr instructions.
ucode object file output in corresponding files suf
fixed with .u. This flag is not available with the
-newc and -migrate flags.
-k Passes flags that start with a -k to the ucode loader.
This flag is used to specify ucode libraries (with -kl
filename) and other ucode loader flags.
-ko output
Names the output file created by the ucode loader as
output. This file is not removed. If this file is
compiled, the object file is left in a file whose name
consists of output with the suffix changed to .o. If
output has no suffix, a .o suffix is appended to out
put. This flag is not available with the -newc and
-migrate flags.
Compiler Development Flags (Not Generally Used)
-Hc Halts compiling after the pass specified by the char
acter 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 flag. If this flag 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.
-K Directs the compiler to give recognizable names to
intermediate files and retain them for debugging pur
poses. Each file is given the name of the last compo
nent of the source file, replacing its suffix with the
conventional suffix for the type of file (for example,
.B file 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 flag 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.
-Wc[c...],arg1[,arg2...]
Passes the argument, or arguments (argi), to the com
piler 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
startup routine, or standard library. These arguments are
processed from left to right, so their order is signifi
cant. When the -B flag is encountered, the selection of
names takes place using the last -h and -t flags. There
fore, the -B flag is always required when using -h or -t.
Sets of these flags can be used to select any combination
of names.
All -B flags must be preceded by -p flags. The -p flag
provides the location of startup routines and the profil
ing library.
Use the -t [hpfjusmocablyzrntLCD] suboptions to select the
names. The names selected are those designated by the
characters following the -t flag, according to the follow
ing table. Note that the -newc and -migrate flags accept
the same set of suboptions.
-------------------------------------------------------
-oldc Name -newc Name Character
-------------------------------------------------------
include h (see note following table)
cfe gemc_cc p, f
ujoin j
uld u
usplit s
umerge m
uopt o
ugen c
as0 as0 a
as1 as1 b
ld ld l
ftoc y
cord cord z
[m]crt0.o [m]crt0.o r
libprof1.a libprof1.a n
btou, utob t
om om L
pixie pixie C
prof 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.
normally found.
-Bstring
Append string to all names specified by the -t flag.
If no -t flag has been processed before the -B, the -t
flag 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 flag on the command
line.
EXAMPLES
1.
cc helloworld.c
Compiles the file helloworld.c using the compiler's
defaults. Because no output file is named in the com
mand line, the result of the compilation is written to
the executable file named a.out.
2.
cc -newc -v helloworld.c
/usr/lib/cmplrs/cc/gemc_cc -D__LANGUAGE_C__ -D__unix__
-D__osf__ -D__alpha -D_S YSTYPE_BSD -D_LONGLONG -D__dig
ital__ -D__arch64__ -I/usr/include -v -preempt_module
-intrinsics -g0 -O2 -std -noansi_alias -o hello.o
hello.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__="Jan 28
1998" -D__DECC_MODE_RELAXED -D__DECC_VER=50760700
-D_SYSTYPE_BSD -D__ALPHA -D__IEEE_FLOAT -D__unix__
-D__TIME__="15:23:28" -D__Alpha_AXP -D__INI
TIAL_POINTER_SIZE=0 -D__STDC__=0 -D__LANGUAGE_C__
-D__alpha /usr/lib/cmplrs/cc/gemc_cc:
0.00u 0.02s 0:00 16% 0+9k 0+8io 0pf+0w 9stk+1032mem
/usr/lib/cmplrs/cc/ld -g0 -O1 -call_shared
/usr/lib/cmplrs/cc/crt0.o hello.o -lc
/usr/lib/cmplrs/cc/ld:
0.01u 0.02s 0:00 17% 0+8k 0+15io 0pf+0w 8stk+1224mem
pass, and its arguments, as it executes.
ERRORS
The diagnostics produced by cc are intended to be self-
explanatory. Occasional messages may be produced by the
assembler or loader.
FILES
file.c Input file
file.o Object file
a.out Loaded output
err.english.cc
Compiler error messages in English
/tmp/ctm? Temporary
/usr/lib/cmplrs/cc/comp.config
Compiler configuration file (optional)
/usr/lib/cmplrs/cc/cfe
C front end
/usr/lib/cmplrs/cc/cpp
C macro preprocessor
/usr/lib/cmplrs/cc/gemc_cc
DEC C compiler
/usr/lib/cmplrs/cc/ujoin
Binary ucode and symbol table joiner
/usr/bin/uld
Ucode loader
/usr/lib/cmplrs/cc/usplit
Binary ucode and symbol table splitter
/usr/lib/cmplrs/cc/umerge
Procedure integrator
/usr/lib/cmplrs/cc/uopt
Optional global ucode optimizer
/usr/lib/cmplrs/cc/om
Post-link optimizer
/usr/lib/cmplrs/cc/ugen
/usr/lib/cmplrs/cc/as1
Binary assembly language assembler and reorga
nizer
/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
/usr/bin/btou
Binary to symbolic ucode translator
/usr/bin/utob
Symbolic to binary ucode translator
mon.out File produced for analysis by prof
gmon.out File produced for analysis by gprof
RELATED INFORMATION
ANSI X3.159-1989
B. W. Kernighan and D. M. Ritchie, The C Programming Lan
guage
B. W. Kernighan, Programming in C -- a tutorial
Programmer's Guide
Assembly Language Programmer's Guide
DEC C Language Reference Manual
as(1), atom(1), cc(1), c89(1), cord(1), dbx(1), ftoc(1),
gprof(1), hiprof(5), ieee(3), ladebug(1), ld(1), ld(1old),
monitor(3), pixie(5), prof(1), protect_headers_setup(8),
standards(5), third(5), what(1) delim off