 |
Click this button to go to the index for this section. |
cc(1old)
NAME
cc - C compiler (outdated)
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 -member_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"
compiler 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 versions of the DEC OSF/1 operating system preceding
DIGITAL UNIX Version 4.0.
The ability to access the "newc" compiler with the -migrate flag was
retained in the DIGITAL UNIX system's compilation environment so that prior
users of -migrate 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 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.
When you use the -oldc flag, the compiler accepts the following additional
file arguments:
- Arguments whose names end with .c are compiled into ucode object files
when -oldc's highest level of optimization 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 compiler development and are not generally used.
- Files that are assumed to be binary ucode, symbolic ucode, or binary
assembly language by the suffix conventions are also assumed to have
their corresponding symbol table in a file with a .T suffix.
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,
-hidden_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 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 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 reference 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 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 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 processing of
LC_MESSAGES.
TMPDIR
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).
To facilitate setting default compiler flags, 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 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 comp.config file should be stored in the compiler target
directorey, /usr/lib/cmplrs/cc.
- 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 prologue 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 following categories:
- Compiler selection flags
- Overall compiler behavior flags
- C preprocessor flags
- Linker or loader flags
- Optimization flags
- Feedback-directed optimization flags
- Source-code debugging flags
- Program profiling 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 compiler. 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
relying on the -migrate flag provided in previous implementations 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-manipulation extension), MVI (multimedia extension), FIX
(square root and floating-point extension), and CIX (count extension).
(The Alpha Architecture Reference Manual describes the extensions in
detail.)
The option specified by the -arch flag determines which instructions
the compiler can generate:
generic
Generate instructions that are appropriate for all Alpha
processors. This option is the default.
host
Generate instructions for the processor that the compiler is
running on (for example, EV6 instructions on an EV6 processor).
ev4,ev5
Generate instructions for the EV4 processor (21064, 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 emulation overhead
on EV4 and EV5 processors.
ev6 Generate instructions for EV6 processors (21264 chips).
This option permits the compiler to generate any EV6 instruction,
plus any instructions contained in the following extensions: BWX,
MVI, FIX, and CIX.
Applications compiled with this option may incur emulation overhead
on EV4, EV5, EV56, and PCA56 processors.
pca56
Generate instructions for PCA56 processors (21164PC chips).
This option permits the compiler to generate any EV4 instruction,
plus any instructions contained in the BWX and MVI extensions.
Applications compiled with this option may incur emulation overhead
on EV4, EV5, and EV56 processors.
A program compiled with any of the options will run on any Alpha
processor. Beginning with DIGITAL UNIX V4.0 and continuing with
subsequent versions, the operating system kernel includes an
instruction emulator. This capability allows any Alpha chip to execute
and produce correct results from Alpha instructions - even if the some
of the instructions are not implemented on the chip. Applications
using emulated instructions will run correctly, but may incur
significant emulation overhead at run time.
The psrinfo -v command can be used to determine which type of processor
is installed on any given Alpha system.
-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 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 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 compile 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 containing sets of pragmas that control a particular
aspect of a compilation (for example, optimizations or diagnostics).
[The -FIfilename flag is not available when you use the -oldc flag.]
-msg_actiontype msg_list
Provides users with the ability to control the diagnostic messages
issued by the compiler. The message output can be tuned in groups
(based on message level or message group) or individually (based on the
message ID strings enclosed in parentheses at the end of message text
strings).
The -msg_actiontype 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 messages. (Note
that error- or fatal-severity messages cannot be changed to
informational-severity messages.)
-msg_error
Change the identified messages to be error messages. (Note that
fatal-severity messages cannot be changed to error-severity
messages.)
The msg_list argument to the -msg_actiontype flag is a comma-separated
list of one or more message levels, message groups, or message IDs.
Enabling a message level also enables all lower levels, and disabling a
level also disables all higher levels. For example, disabling level 3
messages disables levels 3 - 6. Operations other than enabling or
disabling apply only to the specified (or default) level, not to lower
levels.
The following message levels and message groups are supported:
Message Levels:
level0
Very important messages that are enabled by default. Level 0
messages cannot be disabled as a class (level0), but individual level
0 messages can be disabled if they are warning- or informational-
severity messages. (Error- or fatal-severity messages cannot be
disabled.)
Messages at this level correspond to messages covered by pragma
nostandard. These include all messages that should be displayed for
code in header files.
level1
Important messages, but less important than level 0 messages. These
messages are not displayed if pragma nostandard is active. Level 1
is the default for DIGITAL UNIX releases prior to V4.0E.
level2
Moderately important messages. Level 2 is the default for 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 messages
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 messages added by level 6.
Message Groups:
alignment
Messages reporting unusual or inefficient data alignment.
c_to_cxx
Messages reporting the use of C features that would be invalid or
have a different meaning if compiled by a C++ compiler.
check
Messages reporting code or practices that, although correct and
perhaps portable, are sometimes considered ill-advised because they
can be confusing or fragile to maintain (for example, assignment as
the test expression in an if statement).
defunct
Messages reporting the use of obsolete features, features that were
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 language in a future version of the standard.
overflow
Messages reporting assignments and/or casts that may cause overflow
or other loss of data significance.
performance
Messages reporting code that might result in poor run-time
performance.
portable
Messages reporting the use of language extensions or other constructs
that might not be portable to other compilers or platforms.
preprocessor
Messages reporting questionable or non-portable use of preprocessing
constructs.
guestcode
Messages reporting questionable coding practices. Similar to check,
but messages in this group are more likely to indicate a programming
error, not just a non-robust style.
returnchecks
Messages relating to function return values.
unused
Messages reporting expressions, declarations, and code paths that are
not used.
-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 follows:
all Enables the protect headers feature. This is the default if the
file being compiled is a C source file.
none
Disables the protect headers feature. This is the default if the
file being compiled is a non-C source file.
default
Cancels any previous -protect_headers flags and places 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_headers_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 symbolic assembly
language output in corresponding files suffixed with .s.
-show keyword[,keyword,...]
Specifies one or more items to be included in the listing file. When
specifying multiple keywords, separate them by commas and no
intervening blanks. To use any of the -show keywords, you must also
specify the -source_listing option.
The keywords for the -show 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 substitutions that occur on each line.
[no]header
Produces header lines at the top of each page of listing.
[no]include
Places contents of header files in program listing.
[no]source
Places source program statements in program listing.
[no]statistics
Places compile-time performance statistics in the program listing.
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).
[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 extension. You must specify this qualifier to
get a listing. The default is to not produce a listing file.
[The urce_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 specified, 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 displays the message and then
aborts.
3 Does not print warning messages. However, when warnings occur,
exits with nonzero status.
If no -w flag is specified (the default), only warning, 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
indicated by the -I flag, 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 flag, and then in the standard directory, /usr/include.
You can specify multiple iterations of the -I[dir] flag in the cc
command line; each instance of the -[dir] flag appends locations to the
previously established -I[dir] 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 definitions and puts them
in a .H suffixed file. The suboption i includes identifiers in the
prototype, and the suboption s generates prototypes for static
functions as well.
-Q Directs the preprocessor to use single quotes in __FILE__ expansions
instead of double quotes. See cpp(1) for details.
-Uname
Removes any 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
command with the -v flag.)
Linker or Loader FLags
-call_shared
Produces a dynamic executable file that uses shareable objects during
run time. This is the default. The loader uses shareable objects to
resolve undefined symbols. The run-time loader (/sbin/loader) is
invoked to bring in all required shareable objects and to resolve any
symbols that remained undefined during static link time.
-compress
Passes the -compress 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 compressed object file format, resulting in a substantially
smaller object file.
-cord
Runs the procedure rearranger, cord, on the resulting file after
linking. The rearrangement is done to reduce the cache conflicts
associated with accessing the program's text. The output of cord is
left in the file specified by the -o output flag or a.out by default.
At least one -feedback file must be specified. See prof(1) for
information on creating feedback files.
-exact_version
Used in conjunction with -call_shared to request strict dependency
testing for the executable file produced. Executable files built in
this manner can be executed only if the shared libraries that they use
were not modified after the executable was built.
-expect_unresolved pattern
Causes any unresolved symbols matching pattern to be ignored. Such
symbols are not displayed and are not treated as errors or warnings.
You can enter this option multiple times on a command line. The
patterns use shell wildcard characters (?, *, [, ]). The wildcard
characters must be properly quoted to prevent them from being expanded
by the shell. For more information, see sh(1).
-fini symbol
Makes the procedure represented by the symbol into a termination
routine. A termination routine is a routine that is called without an
argument when either the file that contains the routine is unloaded or
the program that contains the routine exits.
-init symbol
Makes the procedure represented by the symbol into an initialization
routine. An initialization routine is a routine that is called without
an argument when either the file that contains the routine is loaded or
the program that contains the routine is started.
-input_to_ld filename
Directs the linker to read the contents of file filename as if the
contents had been supplied on the ld command line.
Inside file filename, lines ending with \ are treated as continuation
lines, and lines starting with # are treated as comment lines and
ignored. The -v flag can be used to display the expansion of files
specified in a -input file. The files can be nested up to 20 levels.
-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 sensitive; 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 executables can use at run time.
The following options are used with -shared:
-check_registry location_file
Checks the location of this shared object's segments and make sure
they stay out of the way of other object's segments in the
location_file. Multiple instances of this option are allowed.
-rpath path
Creates an rpath record containing the specified path string. The
path string is a colon-separated list of directories that is
meaningful only when creating an executable with shared linkage.
If an item in the path supplied to -rpath is of the form $VARNAME
or ${VARNAME}, the linker interprets it as an environment variable.
Additional rpath directories found in shared objects on the link
command line are appended to path. Duplicate entries are excluded.
The loader uses the rpath record to search for shared libraries at
run time.
-set_version version-string
Establishes the version identifier (or identifiers) associated with
a shared library. The string version-string is either a single
version identifier or a colon-separated list of version
identifiers. No restrictions are placed on the names of version
identifiers; however, it is highly recommended that UNIX directory
naming conventions be followed.
If a shared library is built with this option, any executable built
against it will record a dependency on the specified version or, if
a list of version identifiers is specified, the rightmost version
specified in the list. If a shared library is built with a list of
version identifiers, the loader will allow any executable to run
that has a shared library dependency on any of the listed versions.
-soname shared_object_name
Sets DT_SONAME for a shared object. The name can be a single
component name (for example, libc.a), a full pathname (starting
with a slash), or a relative pathname (containing a slash). The
default DT_SONAME used for shared objects is the filename component
of the output file name. Specify the output file name using the -o
option as described previously.
-update_registry location_file
Registers the location of this shared object's segments and makes
sure they stay out of the way of others in the location_file.
Location_file is updated if it is writable.
-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 segments addresses are loaded into low memory.
The -taso flag, 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 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
interfaces. 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, 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 of a
different type (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 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 argument 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 b will be considered a restricted
pointer when this flag 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 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.
-assume whole_program
Specifies that no occurrences of the address-of operator (&) are being
applied outside the current compilation unit to extern variables that
are declared inside the current compilation unit. Making this
assertion allows the compiler to perform better optimizations.
This 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 differences.
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 reference page
for more detailed information about this operation.
-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 generate faster code that
provides the same function behavior (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 support IEEE exceptional behavior.
-float
Tells the compiler that it is not necessary to promote expressions
of type float to type double.
See the description of this flag elsewhere in this reference page
for more detailed information about this operation.
-fp_reorder
Allows floating-point operations to be reordered during
optimization.
See the description of this 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
Controls whether the compiler recognizes certain functions as
intrinsic functions.
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 performance.
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 compiler 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 compiler to use only
certain scalar rules for calculations. This setting can prevent some
optimizations. The -fp_reorder flag 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.
-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
interpreted 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 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.
[The -ifo flag is not available when you use the -oldc flag.]
-[no_]inline keyword
Specifies whether to provide inline expansion of functions. 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 executed, how many registers the
inline expansion will require, and other factors.
You can specify one of the following as the keyword to control
inlining:
none
No inlining is done, even if requested by a #pragma inline
preprocessor directive. This is the default when compiling with the
-O0 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 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
flag under -newc, or the -O, -O4, or -O5 flag under -migrate.
speed
Inlines all of the function calls in the manual category, plus any
additional calls that the compiler determines would improve run-
time performance, even where it may significantly increase the size
of the program.
all Inlines every call that can be inlined while still generating
correct code. Recursive routines, however, will not cause an
infinite loop at compile time.
For optimization level 0 (-O0), the -inline 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 functions as intrinsic
functions - even if the appropriate header file is not included and the
function names are not specified in a pragma intrinsic directive.
Recognition is based on the function name and the call signature
(arguments and return types).
When the compiler identifies a function as an intrinsic function, it is
then free to make code optimizations (transformations) based on what it
knows about the operations performed by the standardized version of
that function - given an optimization level (-On) that enables the
intrinsic treatment of that particular function.
The optimization level determines which functions can be treated as
intrinsics:
-O0 or -O1
No intrinsic functions. The -intrinsics flag has no effect at this
optimization level.
-O2 (or -O)
Memory and string functions: alloca, bcopy, bzero, memcpy, memmove,
memset, strcpy, strlen
Math functions: abs, fabs, labs, atan, atan2, atan2f, atand, atand2,
atanf, ceil, ceilf, cos, cosd, cosf, floor, floorf, sin, sind, sinf.
-O3
fprintf, printf, snprintf, sprintf
-fast (due to its supplying -assume nomath_errno and -O3)
acos, acosf, asin, asinf, cosh, coshf, exp, expf, log, log10, log10f,
logf, log2, pow, powf, sqrt, sqrtf, sinh, sinhf, tan, tand, tanf,
tanh.
The effects of the various optimization levels are cumulative; for
example, -fast causes the functions at the -02 (or -O) and -O3
optimization levels to be treated as intrinsics - in addition to the
intrinsic function treatment that is triggered by -fast itself.
The -intrinsics flag is in effect by default. To disable the default,
specify the -no_intrinsics flag. 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
flag ("file include" flag).
-mp 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 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
performed 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
analysis, and code
scheduling.
-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
eliminate branches.
-O2, -O -O3 -O4
Inline expansion of
static procedures.
-O3 -O3 -O4
Inline expansion of
global procedures.
-O4 N/A -O5
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.
_____________________________________________________
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
symbols, so it should not be used for shared libraries.)
-Olimit num
Specifies the maximum size, in basic blocks, of a routine 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 reallocation 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 compressed by this
flag.
-WL,-om_Gcommon,num
Sets the size threshold of "common" symbols. Every "common" symbol
whose size is less than or equal to num will be allocated close to
each other. This flag can be used to improve the probability that
the symbol can be accessed directly from the $gp register.
(Normally, om tries to collect all "common" symbols together, not
just symbols that conform to certain size constraints.)
-WL,-om_ireorg_feedback,file
Uses the pixie-produced information in file.Counts and file.Addrs
to reorganize the instructions to reduce cache thrashing.
-WL,-om_no_inst_sched
Turns off instruction scheduling.
-WL,-om_no_align_labels
Turns off alignment of labels. Normally, the -om 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
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.
-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
- When -ifo is used
- When the compilation is proceeding directly to an a.out executable
file, that is, when none of the following 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 optimization, if inlining is requested, only static functions
are eligible.
The default taken for a compilation is either -preempt_symbol or
-preempt_module. See the description of the -preempt_module flag for
details on the conditions that determine which option is taken as the
default.
-speculate all
Specifies that speculation may occur anywhere in the executable image.
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 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 all flag is not available when you use the -oldc flag.]
-speculate by_routine
Specifies that speculation is allowed only in the code in the source
module that is being compiled.
A module compiled with -speculate by_routine cannot use any form of
local exception handling, but can be linked with other modules that do.
The run-time system checks each exception to see if it occurred in a
speculative routine. It dismisses exceptions from routines that are
speculatively executed, but signals exceptions from other routines.
(Note, though, that floating-pointing instructions specifying software
completion [/S] are still given normal exception handling.) As a
result, you should use the -speculate by_routine 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 generated code will
run correctly on all Alpha processors. 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, 21066, and 21068
chips.
ev5,ev56
Selects instruction tuning for the 21164 chip. (Chip number 21164
is used for both EV5 and EV56 processors.)
ev6 Selects instruction tuning for the 21264 chip.
-unroll n
Controls loop unrolling done by the optimizer at levels -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_feedback,
-prof_dir, and -pids flags.
-prof_use_feedback
Uses profiling feedback to improve runtime performance. 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 program.
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 your program with
the -prof_gen flag and then run the program to generate the profiling
data.
-prof_dir
Specifies a location to which the profiling data files (.Counts and
.Addrs) are written. Use this 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 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:
0 Produces only enough symbol table information for linking. Names
and addresses of external symbols, and the addresses and basic
layout of the stack-frame are available. Profiling tools work, but
the names of local procedures, source lines, and source file names
are not available. The debugger allows procedure traceback and all
instruction-level commands. However, line-oriented commands do not
work. No symbol types are available, and the names of stack-frame
and static variables are not available. All optimizations are
supported.
1 Produces limited symbol table information. Profiling and debugging
tools provide line numbers, source file names, and the names of
local procedures, when appropriate. Line-oriented debugging
commands work, but symbol types and the names of stack-frame
variables are not available. Most profiling tools work to their
fullest ability, but some advanced Atom tools may provide more
information at higher debug levels. All optimizations are
supported.
2 Produces symbol table information for full symbolic debugging and
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 prepares for profiling
by periodically sampling the value of the program counter. This flag
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 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 monstartup (see
monitor(3)) and produces, in file mon.out, execution-profiling data for
use with the postprocessor prof(1).
The value n can be one of the following:
0 Do not permit any profiling. This is the default. If linking
occurs, the standard run-time startup routine (crt0.o) is used, and
no profiling library is searched.
1 Same as -p.
-[no_]pg
Turns gprof profiling on or off when compiling and linking the file
immediately following this flag. The gprof profiler produces a call
graph showing the execution 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 keywords that are not
accepted in K&R mode. Without this option, a user program will stop
compiling if it contains a variable with the same name as one of the
VAX C keywords. The following options are available:
[no]vaxc_keywords
Determines whether certain VAX C keywords can be used as 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 specified.
-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 according to certain
language rules followed by the C compiler 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, suppressing 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. */
- 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 flag
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;
- 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 nonportable coding
that it encounters.
[The -portable flag is not available when you use the -oldc flag.]
-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 encounters 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 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 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 passed to the
preprocessor. Note that the -std1 flag also affects linker-defined
symbols. See ld(1) for more information.
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 standard 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 compatibility
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,
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 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 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 flag 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 flag 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 flags can be
used in the same cc command, 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 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. 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 flag, or the -assume
noaligned_objects flag.
[The -assume [no]trusted_short_alignment flag is not available when you
use the -oldc flag.]
-[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 synonym 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 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 flag.
The use of the -nomember_alignment flag 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.
[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 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 Flags
-strong_volatile
Affects the generation of code for assignments to objects that are less
than or equal to 16 bits in size (for instance char, short) that have
been declared as volatile. The generated code includes a load-locked
instruction for the enclosing longword or quadword, an insertion of the
new value of the object, and a store-conditional instruction for the
enclosing longword or quadword. By using this locked instruction
sequence for byte and word stores, the -strong_volatile flag 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.
[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
performed 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
Prevents the compiler from promoting expressions of type float to type
double. This is the default for all -std levels other than 0.
-float_const
Causes the C front end to inspect the floating-point value and treat
the value as a float if it can be represented as a single precision
value. By default, all floating-point constants are treated as double
precision.
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 compile 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 representation and range
of values as signed char declarations. This is used to override a
previous -unsigned flag. This is the default.
-unsigned
Causes all char declarations to have the same representation and range
of values as unsigned char declarations.
-varargs
Prints warnings for all lines that may require the varargs.h macros.
-volatile
Causes all variables to be treated as volatile.
-writable_strings
Causes all string literals to be writable. This is the default.
This flag overrides -readonly_strings.
Rounding-mode Flags (IEEE Floating Point)
-fprm c
Specifies chopped rounding mode (round toward zero).
-fprm d
Dynamically sets rounding mode for IEEE floating-point instructions.
The dynamic rounding mode is determined from the contents of the
floating-point control register and can be changed or read at execution
time by a call to write_rnd(3) or read_rnd(3). If you specify -fprm d,
the IEEE floating-point rounding mode defaults to round to nearest.
-fprm n
Specifies normal rounding mode (unbiased round to nearest). This is
the default.
-fprm m
Specifies round toward minus infinity mode.
Stack-handling and Pointer-handling Flags
-trapuv
Forces all uninitialized stack variables to be initialized with
0xfff58005fff58005. When this value is used as a floating-point
variable, it is treated as a floating-point NaN and causes a floating-
point trap. When it is used as a pointer, an address or segmentation
violation usually occurs.
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 compiler to respond
to the #pragma pointer_size preprocessor 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 program. 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.
-xtaso_short
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 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 (register 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 floating point overflow, divide-by-zero,
or invalid operation 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 implementations, 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 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.
Ucode Generation Flags (Enabled by -oldc)
-j Compiles the specified source programs and leaves the ucode object file
output in corresponding files suffixed 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 output. 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 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 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 purposes. Each file is given the name of
the last component of the source file, replacing its suffix with the
conventional suffix for the type of file (for example, .B 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 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 flag.
The flags 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 flag is encountered, the selection of names
takes place using the last -h and -t flags. Therefore, 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 profiling 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 following 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.
-hpath
Use path instead of the directory where the name is 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 command 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__digital__ -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__INITIAL_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
This example invokes the C compiler with the -newc flag. The -v option
displays the name of each compilation 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
Code generator
/usr/lib/cmplrs/cc/as0
Symbolic to binary assembly language translator
/usr/lib/cmplrs/cc/as1
Binary assembly language assembler and reorganizer
/usr/lib/cmplrs/cc/crt0.o
Run-time startup
/usr/lib/cmplrs/cc/mcrt0.o
Startup for prof profiling
/usr/lib/cmplrs/cc/gcrt0.o
Startup for gprof profiling
/usr/ccs/lib/libc.a
Standard library, see intro(3)
/usr/lib/cmplrs/cc/libprof1.a
Level 1 profiling library
/usr/lib/cmplrs/cc/libprof1_r.a
Reentrant level 1 profiling library for code compiled with
-pthread or -threads
/usr/include
Standard directory for header files
/usr/lib/cmplrs/cc/ftoc
Interface between prof and cord
/usr/lib/cmplrs/cc/cord
Procedure-rearranger
/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 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
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)