Man Page cc.1
NAME
cc - C compiler
SYNOPSIS
cc [ -# ] [ -### ] [ -A name[(tokens)] ]
[ -B[static|dynamic] ] [ -C ] [ -c ]
[ -Dname[= tokens] ] [ -d [y|n] ] [ -dalign] [ -E]
[ -erroff[=t[,t...] ] ] [ -errtags= a ]
[ -errwarn[=t[,t...] ] ] [ -fast ] [ -fd ] [ -flags ]
[ -fnonstd ] [ -fns= [yes|no]] [ -fprecision= p ]
[ -fround= r ] [ -fsimple[= n ] ] [ -fsingle ]
[ -fstore] [ -ftrap[=t[,t...] ] ] [ -G ] [ -g ] [ -H ]
[ -h name ] [ -I [-|dir] ] [ -i ] [ -KPIC ] [ -Kpic ]
[ -keeptmp ] [ -L dir ] [ -l name ] [ -mc ]
[ -misalign ] [ -misalign2 ] [ -mr[,string] ] [ -mt ]
[ -native ] [ -nofstore ] [ -noqueue ] [ -O ]
[ -o filename ] [ -P ] [ -p ] [ -Q [y|n] ] [ -qp ]
[ -Rdir[:dir...] ] [ -S ] [ -s ] [ -Uname ] [ -V]
[ -v ] [ -Wc,arg ] [ -w ] [ -X[c|a|t|s] ] [ -x386 ]
[ -x486 ] [ -xa ] [ -xalias_level[=a] ] [ -xarch= a ]
[ -xautopar] [ -xbuiltin[=a] ] [ -xcache= c ] [ -xCC ]
[ -xcg89 ] [ -xcg92 ] [ -xchar_byte_order= o ]
[ -xchip= c ] [ -xcode= v ] [ -xcrossfile[= n] ]
[ -xcsi ] [ -xdepend ] [ -xe ] [ -xexplicitpar ]
[ -xF ] [ -xhelp= f ] [ -xildoff ] [ -xildon ]
[ -xinline=[v[,v...] ] ] [ -xipo[=a] ] [ -xlibmieee ]
[ -xlibmil ] [ -xlic_lib_=sunperf ] [ -xlicinfo ]
[ -xloopinfo ] [ -xM ] [ -xM1 ] [ -xMerge ]
[-xmaxopt[=v] ] [ -xmemalign=ab ] [ -xnolib ]
[ -xnolibmil ] [ -xOn ] [ -xopenmp[=i] ] [ -xP ]
[ -xparallel ] [ -xpentium ] [ -xpg ]
[ -xprefetch[=val[,val ] ] ] [ -xprofile= p ]
[ -xreduction ] [ -xregs=r[,r...] ] [ -xrestrict[=f] ]
[ -xs ] [ -xsafe=mem ] [ -xsb ] [ -xsbfast ]
[ -xsfpconst] [ -xspace ] [ -xstrconst ]
[ -xtarget= t ] [ -xtemp= dir ] [ -xtime ]
[ -xtransition ] [ -xtrigraphs[= [yes|no] ]
[ -xunroll= n ] [ -xvector[= {yes|no} ] ] [ -xvpara ]
[ -Y c,dir ] [ -YA ,dir ] [ -YI ,dir ]
[ -YP ,dir ] [ -YS ,dir ] [ -Zll ]
DESCRIPTION
The cc(1) manual page describes the ANSI/ISO C compiler
options that are SVID compliant under Solaris 2.6, Solaris
7, and Solaris 8. cc uses getopt to parse command-line
options. Options are treated as a single letter or as a sin-
gle letter followed by an argument. See getopt(3c).
cc is the interface to the C compilation system. The compi-
lation process incorporates a preprocessor, compiler, code
generator, optimizer, assembler, and link editor. cc
processes the supplied options and then executes the various
components with the proper arguments. cc accepts several
types of files as arguments.
Files with .c suffix are taken to be C source files and may
be preprocessed, compiled, optimized, instrumented for pro-
filing, assembled, and link edited. Although the preproces-
sor can be used as a macro processor, this is not recom-
mended, as its output is geared toward that which would be
acceptable as input to a valid C compiler. The compilation
process may be stopped after the completion of any pass if
the appropriate options are supplied. If the compilation
process runs through the assembler, then an object file is
produced with .o suffix substituted for .c. However, the .o
file is normally deleted if a single C file is compiled and
then immediately link edited. Files with .s suffix are
taken to be assembly source files; they may be assembled and
link edited. Files with a .S suffix are treated as -Xs mode
of the compiler and passed to /usr/ccs/lib/cpp for prepro-
cessing before being passed to the assembler. Files with an
.i are taken to be preprocessed C source files, and may be
compiled, optimized, instrumented for profiling, assembled,
and link edited. Files whose names do not end in .c, .s, .S
or .i are passed to the link editor, which produces a dynam-
ically linked executable whose name by default is a.out.
Incremental Link Editor (ild) is used in place of linker ld
for incremental linking. See -xildon and -xildoff for more
information.
See option -Yc, dir to change the default directories used
for finding libraries. dir is a colon-separated path list.
The default library search order for cc is:
/opt/SUNWspro/SC5.0/lib
/usr/ccs/lib
/usr/lib
COMPILING FOR 64-BIT SOLARIS 7:
This version of the compiler can produce 64-bit object
binaries on 32-bit or 64-bit Solaris 7 SPARC Platform Edi-
tion. The resulting executable will run only on 64-bit
SPARC or UltraSPARC processors under Solaris 7 with the 64-
bit kernel. Compilation, linking, and execution of 64-bit
objects can only take place in a Solaris 7 environment.
Compiling for 64-bit Solaris 7 is indicated by the -xarch=v9
and -xarch=v9a options. Note that one of these options must
be specified even if -xtarget or -fast are also specified.
In such a case, the -xarch=v9 (or -xarch=v9a) option must
appear AFTER any -xtarget or other option that sets -xarch.
For example:
-xtarget=ultra -xarch=v9
Note that -xtarget=ultra and -xtarget=ultra2 imply -xarch=v8
and do not automatically signal -xarch=v9 or v9a.
When building shared dynamic libraries with -xarch=v9 or v9a
on 64-bit Solaris 7, the -xcode=pic13 or -xcode=pic32 option
MUST also be specified.
See also the new -xcode=abs32|abs64|pic13|pic32 option for
specifying code address sizes.
64-bit Solaris 7 not only enables 64-bit integer and pointer
data, but also support for large files. For more details,
see the README file:
<install-directory>/SUNWspro/READMEs/64bit_Compilers
(where <install-directory> is usually /opt in a standard
install.)
For general information on 64-bit Solaris for software
developers, see the "Solaris 64-bit Developer's Guide" on
http://docs.sun.com .
OPTIONS
All platform-specific options are "silently accepted" on all
platforms. Any exceptions to this rule are noted under the
specific option.
The following options are interpreted by cc:
-# Show each component as it is invoked (verbose mode).
-### Show each component as it is invoked, but, unlike the
-# option, do not actually execute.
-Aname[(tokens)]
Associate name as a predicate with the specified tokens
as if by a #assert preprocessing directive.
Preassertions:system(unix)
machine(sparc) (SPARC)
machine(i386) (x86)
cpu(sparc) (SPARC)
cpu(i386) (x86)
The above are not predefined in -Xc mode.
If -A is followed by a dash (-) only, it causes all
predefined macros (other than those that begin with __)
and predefined assertions to be forgotten.
-B [static|dynamic]
Specifies whether bindings of libraries for linking are
static or dynamic, indicating whether libraries are
non-shared or shared, respectively. -B dynamic causes
the link editor to look for files named libx.so and
then for files named libx.a when given the -lx option.
-B static causes the link editor to look only for files
named libx.a. This option may be specified multiple
times on the command line as a toggle. This option and
its argument are passed to ld.
-C Prevents the C preprocessor from removing comments,
other than those on preprocessing directive lines.
-c Directs the C compiler to suppress linking with ld and
to produce a .o file for each source file. You can
explicitly name a single object file by using the -o
option. When the compiler produces object code for each
or input file, it always creates an object file in the
current working directory. If you suppress the linking
step, you also suppress the removal of the object
files.
-Dname[=token]
Associates name with the specified token as if by a
#define preprocessing directive. If no =token is
specified, the token 1 is supplied.
Predefinitions:unix
sparc (SPARC)
i386 (x86)
sun
The above are not predefined in -Xc mode.
These predefinitions are valid in all modes:
__sun
__unix
__SUNPRO_C=0x530
__`uname -s`_`uname -r`
__sparc (SPARC)
__sparcv9 (SPARC with -xarch=v9|v9a)
__i386 (x86)
__BUILTIN_VA_ARG_INCR
__SVR4
The following is predefined in -Xa and -Xt modes only:
__RESTRICT
The compiler also predefines the object-like macro
__PRAGMA_REDEFINE_EXTNAME,
to indicate the pragma will be recognized.
-d [y|n]
-dy specifies dynamic linking, which is the default, in
the link editor. -dn specifies static linking in the
link editor.
This option and its argument are passed to ld.
-dalign
(SPARC) -dalign is equivalent to -xmemalign=8s. For
more information, see -xmemalign.
-E Preprocesses only the named C files and sends the
result to the standard output. The output contains
preprocessing directives for use by the next pass of
the compilation system. See also -P option.
-erroff[=t[,t...] ]
Suppresses cc warning messages. Has no effect on error
messages.
The -erroff values are members of a comma-separated
list that consists of one or more of the following:
tag Suppresses the warning message specified by
this tag. You can display the tag for a mes-
sage by using the -errtags=yes option.
no%tag Enables the warning message specified by this
tag.
%all Suppresses all warning messages.
%none Enables all warning messages. This is the
default.
Order is important; for example, %all,no%tag suppresses
all warning messages except tag.
The default is -erroff=%none. Specifying -erroff is
equivalent to specifying -erroff=%all.
Finer control over messages can be achieved with the
use of the error_messages pragma.
-errtags=a
Displays the message tag for each warning message. a
can be either yes or no. The default is -errtags=no.
Specifying -errtags is equivalent to specifying
-errtags=yes.
-errwarn[=t[,t...] ]
If the indicated warning message is issued, cc exits
with a failure status. t is a comma-separated list that
consists of one or more of the following:
tag Cause cc to exit with a fatal status if the
message specified by tag is issued as a
warning message. Has no effect if tag in not
issued.
no%tag Prevent cc from exiting with a fatal status if
the message specified by tag is issued only as
a warning message. Has no effect if tag is not
issued. Use this option to revert a warning
message that was previously specified by this
option with tag or %all from causing cc to
exit with a fatal status when issued as a
warning message.
%all Cause cc to exit with a fatal status if any
warning messages are issued. %all can be fol-
lowed by no%tag to exempt specific warning
messages from this behavior.
%none Prevents any warning messages from causing cc
to exit with a fatal status should any warning
tag be issued. This is the default.
-fast
Selects the optimum combination of compilation options
for speed. This should provide close to the maximum
performance for most realistic applications. Modules
compiled with -fast, must also be linked with -fast.
The -fast option is unsuitable for programs that are
intended to run on a different target than the compila-
tion machine. In such cases, follow -fast with the
appropriate -xtarget option. For example:
% cc -fast -xtarget=ultra
For C modules depending on exception handling specified
by SUID, follow -fast by -xnolibmil The -fast option
acts like a macro expansion on the command line. There-
fore, you can override any of the expanded optionsby
following -fast with the desired option.
If you combine -fast with other options, the last
specification applies. The code generation option, the
optimization level and using inline template files can
be overridden by subsequent switches. For example,
although the optimization part of -fast is -xO4, the
optimization part of -fast -xO1 is -xO1.
Note:-fast sets the optimization level at -xO5 instead
of -xO4.
These options are turned on for -fast:
-dalign (SPARC)
-fns
-fsimple=2 (SPARC)
-fsingle
-ftrap=%none
-nofstore (x86)
-xbuiltin=%all
-xlibmil
-xtarget=native
-xO5
Do not use this option for programs that depend on IEEE
standard exception handling; you can get different
numerical results, premature program termination, or
unexpected SIGFPE signals.
The -fast command expands to include the macro
__MATHERR_ERRNO_DONTCARE. This macro causes math.h to
assert performance related pragmas for some of the math
routines prototyped in math.h.
-fd Reports K&R function declarations and definitions.
-flags
Prints a one-line summary of available options.
-fnonstd
Causes nonstandard initialization of floating-point
arithmetic hardware. In addition, the -fnonstd option
causes hardware traps to be enabled for floating-point
overflow, division by zero, and invalid operations
exceptions. These are converted into SIGFPE signals;
if the program has no SIGFPE handler, it terminates
with a memory dump (see ieee_handler(3m)). By default,
IEEE 754 floating-point arithmetic is nonstop, and
underflows are gradual.
-fnonstd is a macro for -fns and -ftrap=common.
-fns [=[yes|no]]
Select SPARC nonstandard floating point (SPARC Only).
Select the SPARC nonstandard floating-point mode. The
default, -fns=no, is SPARC standard floating-point
mode.
Optional use of =yes or =no provides a way of toggling
the -fns flag following some other macro flag that
includes -fns, such as -fast.
-fns is the same as -fns=yes.
-fns=yes selects non-standard floating-point.
-fns=no selects standard floating-point.
This flag causes the nonstandard floating point mode to
be enabled when a program begins execution. By
default, the nonstandard floating point mode will not
be enabled automatically.
On some SPARC systems, the nonstandard floating point
mode disables "gradual underflow", causing tiny results
to be flushed to zero rather than producing subnormal
numbers. It also causes subnormal operands to be
silently replaced by zero. On those SPARC systems that
do not support gradual underflow and subnormal numbers
in hardware, use of this option can significantly
improve the performance of some programs.
Warning: When nonstandard mode is enabled, floating
point arithmetic may produce results that do not con-
form to the requirements of the IEEE 754 standard. See
the Numerical Computation Guide for more information.
This option is effective only on SPARC systems and only
if used when compiling the main program. On x86 sys-
tems, the option is ignored.
-fprecision=p
(x86) Initializes the rounding precision mode bits in
the Floating-point Control Word to p, which is one of
single (24 bits), double (53 bits), or extended (64
bits) respectively. The default floating-point
rounding-precision mode is extended.
Note that on Intel, only the precision, not exponent,
range is affected by the setting of floating-point
rounding precision mode.
This option is effective only on x86 systems and only
if used when compiling the main program. On SPARC sys-
tems, the option is ignored.
-fround=r
Sets the IEEE 754 rounding mode that is established at
runtime during the program initialization.
r must be one of: nearest, tozero, negative, positive.
The default is -fround=nearest.
The meanings are the same as those for the ieee_flags
subroutine.
When r is tozero, negative, or positive, this flag
causes the rounding direction mode to be set to round-
to-zero, round-to-negative-infinity, or round-to-
positive-infinity respectively when a program begins
execution. When r is nearest or the -fround flag is
not used, the rounding direction mode is not altered
from its initial value (round-to-nearest by default).
This option is effective only if used when compiling
the main program.
-fsimple[=n]
Allows the optimizer to make simplifying assumptions
concerning floating-point arithmetic. If n is present,
it must be 0, 1, or 2.
The defaults are:
o With no -fsimple[=n], the compiler uses -fsimple=0.
o With only -fsimple, no =n, the compiler uses -fsim-
ple=1.
-fsimple=0
Permits no simplifying assumptions. Preserves strict
IEEE 754 conformance.
-fsimple=1
Allows conservative simplifications. The resulting code
does not strictly conform to IEEE 754, but numeric
results of most programs are unchanged.
With -fsimple=1, the optimizer can assume the follow-
ing:
o The IEEE 754 default rounding/trapping modes do not
change after process initialization.
o Computations producing no visible result other than
potential floating- point exceptions may be deleted.
o Computations with Infinity or NaNs as operands need
not propagate NaNs to their results. For example, x*0
may be replaced by 0.
o Computations do not depend on sign of zero.
With -fsimple=1, the optimizer is not allowed to optim-
ize completely without regard to roundoff or
exceptions. In particular, a floating-point computation
cannot be replaced by one that produces different
results with rounding modes held constant at run time.
-fast implies -fsimple=1.
-fsimple=2
Permits aggressive floating point optimizations that
may cause many programs to produce different numeric
results due to changes in rounding. For example, -fsim-
ple=2 permits the optimizer to attempt replacing compu-
tations of x/y in a given loop where y and z are known
to have constant values, with x*z, where z=1/y is com-
puted once and saved in a temporary, thereby eliminat-
ing costly divide operations.
Even with -fsimple=2, the optimizer still is not per-
mitted to introduce a floating point exception in a
program that otherwise produces none.
-fsingle
(-Xt and -Xs modes only) Causes the compiler to evalu-
ate float expressions as single precision, rather than
double precision. (This option has no effect if the
compiler is used in either -Xa or -Xc modes, as float
expressions are already evaluated as single precision.)
-fstore
(x86) Causes the compiler to convert the value of a
floating-point expression or function to the type on
the left-hand side of an assignment, when that expres-
sion or function is assigned to a variable, or when the
expression is cast to a shorter floating-point type,
rather than leaving the value in the register. Due to
roundoffs and truncation, the results may be different
from those generated from the register value. This is
the default mode.
-ftrap[=t[,t...] ]
Sets the IEEE 754 trapping mode in effect at startup.
t is a comma-separated list that consists of one or
more of the following: %all, %none, common,
[no%]invalid, [no%]overflow, [no%]underflow,
[no%]division, [no%]inexact.
The default is -ftrap=%none.
This option sets the IEEE 754 trapping modes that are
established at program initialization. Processing is
left-to-right. The common exceptions, by definition,
are invalid, division by zero, and overflow.
Example: -ftrap=%all,no%inexact means set all traps,
except inexact.
The meanings are the same as for the ieee_flags subrou-
tine, except that:
o %all turns on all the trapping modes.
o %none, the default, turns off all trapping modes.
o A no% prefix turns off that specific trapping mode.
If you compile one routine with -ftrap=t, compile all
routines of the program with the same -ftrap=t option;
otherwise, you can get unexpected results.
-G Directs the link editor to produce a shared object
rather than a dynamically linked executable. This
option is passed to ld. It cannot be used with the -dn
option.
-g Produces additional symbol table information for dbx
(1).
Compile with the -g option to use the full capabilities
of the Sun WorkShop 6 Performance Analyzer. While some
performance analysis features do not require -g, you
must compile with -g to view annotated source, some
function level information, and compiler commentary
messages. See the analyzer(1) man page and "Compiling
Your Program for Data Collection and Analysis" in
Analyzing Program Performance with Sun WorkShop for
more information.
The commentary messages that are generated with -g
describe the optimizations and transformations that the
compiler made while compiling your program. Use the
er_src(1) command to display the messages, which IP The
-g option causes the invocation of the incremental
linker option. See -xildon. Invoke ild in place of ld
unless any of the following are true: -G option is
present, -xildoff option is present, source files are
named on the command line.
If you issue -g, and the optimization level is -x03 or
lower, the compiler provides best-effort symbolic
information with almost full optimization. Tail-call
optimization and back-end inlining are disabled.
If you issue -g and the optimization level is -x04, the
compiler provides best-effort symbolic information with
full optimization.
-H Prints, one per line, the path name of each file
included during the current compilation to standard
error.
-h name
Assigns a name to a shared dynamic library; allows you
to keep different versions of a library.
In general, the name after -h should be the same as the
file name given in the -o option. The space between -h
and name is optional.
The linker assigns the specified name to the library
and records the name in the library file as the intrin-
sic name of the library. If there is no -h name option,
then no intrinsic name is recorded in the library file.
When the runtime linker loads the library into an exe-
cutable file, it copies the intrinsic name from the
library file into the executable, into a list of needed
shared library files. Every executable has such a list.
If there is no intrinsic name of a shared library, then
the linker copies the path of the shared library file
instead.
-I[-|dir]
-I- changes the include-file search rules to the fol-
lowing:
o The compiler never searches the current directory,
unless the directory is listed explicitly in a -I
directive. This effect applies even for include
statements of the form #include "foo.h".
o For include files of the form #include "foo.h",
search the directories in the following order:
1. The directories named with -I options (both
before and after -I-)
2. The /usr/include directory.
o For include files of the form #include <foo.h>,
search the directories in the following order:
1. The directories named with the -I options
that appear after -I-.
2. The /usr/include directory.
Warnings:
Only the first -I- option on the command line works as
described above.
-Idir looks in dir, prior to /usr/include, for included
files whose names do not begin with slash (/). Direc-
tories for multiple -I options are searched in the
order specified.
-i Ignores the LD_LIBRARY_PATH and LD_LIBRARY_PATH_64 set-
tings.
-KPIC
(SPARC) The -KPIC command is equivalent to
-xcode=pic32.
See also -xcode.
(x86) -KPIC is identical to -Kpic .
-Kpic
(SPARC) The -Kpic command is equivalent to
-xcode=pic13.
See also -xcode.
(x86) Generate position-independent code for use in
shared libraries (small model). Permits references to,
at most, 2**11 unique external symbols
-keeptmp
Retains temporary files created during compilation,
instead of deleting them automatically.
-Ldir
Adds dir to the list of directories searched for
libraries by ld. This option and its arguments are
passed to ld.
-lname
Links with object library libname.so or libname.a (for
ld(1)). The order of libraries in the command line is
important, as symbols are resolved from left to right.
This option must follow the sourcefile.
-mc Removes duplicate strings from the .comment section of
an object file. When you use the -mc flag, -mcs -c is
invoked.
-misalign
(SPARC) -misalign is equivalent to -xmemalign=1i. For
more information, see -xmemalign.
-misalign2
(SPARC) -misalign2 is equivalent to -xmemalign=2i. For
more information, see -xmemalign.
-mr[,string]
-mr removes all strings from the .comment section of an
object file. When you use the -mr flag, mcs -d is
invoked.
-mr,string removes all strings from the .comment sec-
tion and inserts string in the .comment section of the
object file. If string contains embedded blanks, it
must be enclosed in quotation marks. If string is null,
the .comment section will be empty. When you use this
flag, mcs -d -a is invoked.
-mt Passes D_REENTRANT to preprocessor. Appends -lthread
after all other user-specified libraries on the command
line. If you are doing your own multithread coding,
you must use this option in the compile and link steps.
To obtain faster execution, this option requires a mul-
tiprocessor system. On a single-processor system, the
resulting executable usually runs more slowly with this
option.
-native
This option is a synonym for -xtarget=native.
-nofstore
(x86) Does not convert the value of a floating-point
expression or function to the type on the left-hand
side of an assignment, when that expression or function
is assigned to a variable, or is cast to a shorter
floating-point type; rather, it leaves the value in a
register.
-noqueue
Disables queueing of compiler license requests.
-O Equivalent to -xO2 .
-o filename
Names the output file filename, instead of the default
a.out. filename cannot be the same as sourcefile since
cc does not overwrite the source file. This option and
its argument are passed to ld.
-P Preprocesses only the named C files and leaves the
result in corresponding files suffixed .i. The output
will not contain any preprocessing line directives,
unlike -E.
-p Prepares the object code to collect data for profiling
with prof(1); also, if link editing takes place, use
profiled versions of system libraries. A mon.out file
will then be produced at normal termination of execu-
tion of the object program. An execution profile can
then be generated by use of prof.
-Q[y|n]
Emits or does not emit identification information to
the output file. If y is used, identification informa-
tion about each invoked compilation tool will be added
to the output files (the default behavior). This can
be useful for software administration. -Qn suppresses
this information.
-qp Same as -p.
-Rdir[:dir...]
A colon-separated list of directories used to specify
library search directories to the runtime linker. If
present and not null, it is recorded in the output
object file and passed to the runtime linker.
If both LD_RUN_PATH and the -R option are specified,
the -R option takes precedence.
-S Compiles, but does not assemble or link edit the named
C files. The assembler-language output is left in
corresponding files suffixed .s.
-s Removes all symbolic debugging information from the
output object file. This option is passed to ld(1).
This option cannot be specified with -g.
-Uname
Causes any definition of name to be undefined. This
option removes any initial definition of the preproces-
sor symbol name created by -D on the same command line
including those placed by the command-line driver.
-U has no effect on any preprocessor directives in
source files. You can supply multiple -U options on the
command line.
If the same name is specified for both -D and -U, name
is not defined, regardless of the order of the options.
-V Causes each invoked tool to print its version informa-
tion on the standard error output.
-v Causes the compiler to perform more and stricter seman-
tic checks, and to enable certain lint-like checks on
the named C files.
-Wc,arg
Passes the argument arg to c. Each argument must be
separated from the preceding by only a comma. (A comma
can be part of an argument by escaping it by an immedi-
ately preceding backslash (\) character; the backslash
is removed from the resulting argument.) All -W argu-
ments are passed after the regular command-line argu-
ments.
c can be one of the following:
a Assembler: (fbe), (gas)
c C code generator: (cg)(SPARC)
d cc driver (1)
h Intermediate code translator (ir2hf)(Intel)
i Inter-procedure analysis (ube_ipa)(Intel)
l Link editor (ld)
m mcs
o Postoptimizer (SPARC)
p Preprocessor (cpp)
u C code generator (ube), (Intel)
0 Compiler (acomp)
2 Optimizer: (iropt) (SPARC)
(1) Note: You cannot use -Wd to pass the cc options
listed in this man page to the C compiler.
For example, -Wa,-o,objfile passes -o and objfile to
the assembler, in that order; also -Wl,-I,name causes
the linking phase to override the default name of the
dynamic linker, /usr/lib/ld.so.1.
The order in which the argument(s) are passed to a tool
with respect to the other specified command line
options may change.
-w Suppress compiler warning messages.
The option overrides the error_messages pragma.
-X[c|a|t|s]
Specifies the degree of conformance to the ANSI/ISO C
standard. Specifies one of the following:
c (conformance)
Strictly conformant ANSI/ISO C, without K&R C com-
patibility extensions. The compiler will issue
errors and warnings for programs that use non-
ANSI/ISO C constructs. The predefined macro
__STDC__ has a value of one with the -Xc option.
a (ANSI)
ANSI C plus K&R C compatibility extensions, with
semantic changes required by ANSI C. Where K&R C
and ANSI C specify different semantics for the
same construct, the compiler uses the ANSI C
interpretation. If the -Xa option is used in con-
junction with the -xtransition option, the com-
piler issues warnings about the different seman-
tics. This is the default compiler mode. The
predefined macro __STDC__ has a value of zero with
the -Xa option.
t (transition)
This option uses ANSI/ISO C plus K&R C compatibil-
ity extensions without semantic changes required
by ANSI/ISO C. Where K&R C and ANSI/ISO C specify
different semantics for the same construct, the
compiler uses the K&R C interpretation. If you use
the -Xt option in conjuction with the -xtransition
option, the compiler issues warnings about the
different semantics. The predefined macro __STDC__
has a value of zero with the -Xt option.
s (K&R C)
The compiled language includes all features compa-
tible with (pre-ANSI) K&R C. The compiler tries
to warn about all language constructs that have
differing behavior between Sun ANSI/ISO C and the
K&R C. Invokes cpp for processing. __STDC__ is not
defined in this mode. (See the C Transition Guide
for differences between ANSI/ISO and K&R C.)
The predefined macro __STDC__ has the value 0 for -Xt
and -Xa, and 1 for -Xc. (It is not defined for -Xs.)
All warning messages about differing behavior can be
eliminated through appropriate coding; for example, use
of casts can eliminate the integral promotion change
warnings.
-x386
(x86) Optimizes for the 80386 processor.
-x486
(x86) Optimizes for the 80486 processor.
-xa Inserts code to count how many times each basic block
is executed. This is the old style of basic block pro-
filing for tcov. See -xprofile=tcov for information on
the new style of profiling and the tcov(1) man page for
more details.
Invokes a runtime recording mechanism that creates a .d
file for every .c file (at normal termination). The .d
file accumulates execution data for the corresponding
source file. The tcov(1) utility can then be run on
the source file to generate statistics about the pro-
gram. This option is incompatible with -g .
If set at compile-time, the TCOVDIR environment vari-
able specifies the directory where the .d files are
located. If this variable is not set, the .d files
remain in the same directory as the .c files.
The -xprofile=tcov and the -xa options are compatible
in a single executable. That is, you can link a program
that contains some files which have been compiled with
-xprofile=tcov, and others with -xa. You cannot compile
a single file with both options.
-xalias_level[=a]
where a must be one of: any, basic, weak, layout,
strict, std, strong. Use this flag to place the indi-
cated alias level into effect for the whole translation
unit. In other words, the alias level you select is
applied to all of the memory references in the transla-
tion unit. If you do not supply -xalias_level, the com-
piler assumes -xalias_level=basic. If you supply
-xalias_level without any value, the compiler assumes
-xalias_level=layout.
o any
At this level everything may alias. There is no type-
based alias anaylysis.
o basic
At this level it is forbidden to alias among different
C basic types. For example, it is not allowed to use a
pointer variable of type int * to pick up a float
object.
o weak
At this level any structure pointer may point to any
structure type. This allows the compiler to perform
offset-based alias optimization.
o layout
At this level things with the same sequence of basic
types in memory may alias each other. This means that
the compiler can assume that two references with types
that do not look the same in memory will not alias.
This level allows access to the front part of a
structure so long as this front part looks the same in
memory. However, at this level you should not use a
pointer to a struct to access some field of a dissimi-
lar struct that is past any common initial portion, but
that happens to have the same offset and the same type.
o strict
At this level types need to be the same when tags are
removed, in order to alias. This rule is very similar
to the layout rule, except that access is not permitted
for the common, initial-portion case.
o std
At this level the types and tags need to be the same to
alias. This rule is the same as the restrictions on the
dereferencing of pointers that are found in the 1999
ISO C standard. Programs that properly use this rule
will be very portable and should see good performance
gains under optimization.
o strong
At this level the same restrictions apply as at the std
level, but additionaly, this level forbids char *
exception pointers and char * interior pointers. This
rule prohibits the use of pointers to members of a
structure object. It does not allow a char pointer to
access other types of objects.
-xarch=isa
Specifies the target architecture instruction set
(ISA).
This option limits the code generated by the compiler
to the instructions of the specified instruction set
architecture by allowing only the specified set of
instructions. This option does not guarantee use of any
target-specific instructions. However, use of this
option may affect the portability of a binary program.
See the Notes and Warnings sectino at the end of this
entry.
Values:
For SPARC platforms:
Value Meaning
generic Set the parameters for the best performance
over most 32-bit platform architectures.
This is the default. This option uses the
best instruction set for good performance on
most processors without major performance
degradation on any of them. With each new
release, the definition of "best" instruction
set may be adjusted, if appropriate.
generic64 Set the parameters for the best performance
over most 64-bit platform architectures.
This option uses the best instruction set for
good performance on most processors without
major performance degradation on any of them.
With each new release, the definition of
"best" instruction set may be adjusted, if
appropriate.
native Set the parameters for the best performance
on the host environment (assumes a 32-bit
architecture).
This is the default for the -fast option. The
compiler chooses the appropriate setting for
the current system processor it is running
on.
native64 Set the parameters for the best performance
on the host environment (assumes a 64-bit
architecture).
v7 Compile for the SPARC-V7 ISA.
Enables the compiler to generate code for
good performance on the V7 ISA. This is
equivalent to using the best instruction set
for good performance on the V8 ISA, but with-
out integer mul and div instructions, and the
fsmuld instruction.
Examples: SPARCstation 1, SPARCstation 2
v8a Compile for the V8a version of the SPARC-V8
ISA.
By definition, V8a means the V8 ISA, but
without the fsmuld instruction. This option
enables the compiler to generate code for
good performance on the V8a ISA.
Example: Any system based on the microSPARC I
chip architecture
v8 Compile for the SPARC-V8 ISA.
Enables the compiler to generate code for
good performance on the V8 architecture.
Example: SPARCstation 10
v8plus Compile for the V8plus version of the SPARC-
V9 ISA.
By definition, V8plus means the V9 ISA, but
limited to the 32-bit subset defined by the
V8plus ISA specification, without the Visual
Instruction Set (VIS), and without other
implementation- specific ISA extensions.
This option enables the compiler to generate
code for good performance on the V8plus ISA.
The resulting object code is in SPARC-V8+
ELF32 format and only executes in a Solaris
UltraSPARC environment -- it does not run on
a V7 or V8 processor.
Example: Any system based on the UltraSPARC
chip architecture
v8plusa Compile for the V8plusa version of the
SPARC-V9 ISA.
By definition, V8plusa means the V8plus
architecture, plus the Visual Instruction Set
(VIS) version 1.0, and with UltraSPARC exten-
sions. This option enables the compiler to
generate code for good performance on the
UltraSPARC architecture, but limited to the
32-bit subset defined by the V8plus specifi-
cation. The resulting object code is in
SPARC-V8+ ELF32 format and only executes in a
Solaris UltraSPARC environment -- it does not
run on a V7 or V8 processor.
Example: Any system based on the UltraSPARC
chip architecture
v8plusb Compile for the V8plusb version of the
SPARC-V8plus ISA with UltraSPARC-III exten-
sions.
Enables the compiler to generate object code
for the UltraSPARC architecture, plus the
Visual Instruction Set (VIS) version 2.0, and
with UltraSPARC-III extensions. The resulting
object code is in SPARC-V8+ ELF32 format and
executes only in a Solaris UltraSPARC-III
environment. Compiling with this option uses
the best instruction set for good performance
on the UltraSPARC-III architecture.
v9 Compile for the SPARC-V9 ISA.
Enables the compiler to generate code for
good performance on the V9 SPARC architec-
ture. The resulting .o object files are in
ELF64 format and can only be linked with
other SPARC-V9 object files in the same for-
mat. The resulting executable can only be run
on an UltraSPARC processor running a 64-bit
enabled Solaris operating environment with
the 64-bit kernel.
-xarch=v9 is only available when compiling in
a 64-bit enabled Solaris environment.
v9a Compile for the SPARC-V9 ISA with UltraSPARC
extensions.
Adds to the SPARC-V9 ISA the Visual Instruc-
tion Set (VIS) and extensions specific to
UltraSPARC processors, and enables the com-
piler to generate code for good performance
on the V9 SPARC architecture. The resulting
.o object files are in ELF64 format and can
only be linked with other SPARC-V9 object
files in the same format. The resulting exe-
cutable can only be run on an UltraSPARC pro-
cessor running a 64-bit enabled Solaris
operating environment with the 64-bit kernel.
-xarch=v9a is only available when compiling
in a 64-bit enabled Solaris operating
environment.
v9b Compile for the SPARC-V9 ISA with
UltraSPARC-III extensions.
Adds UltraSPARC-III extensions and VIS ver-
sion 2.0 to the V9a version of the SPARC-V9
ISA. Compiling with this option uses the best
instruction set for good performance in a
Solaris UltraSPARC-III environment. The
resulting object code is in SPARC-V9 ELF64
format and can only be linked with other
SPARC-V9 object files in the same format. The
resulting executable can only be run on an
UltraSPARC-III processor running a 64-bit
enabled Solaris operating environment with
the 64-bit kernel.
-xarch=v9b is only available when compiling
in a 64-bit enabled Solaris operating
environment.
Notes
o SPARC instruction set architectures V7, V8, and V8a
are all upwardly binary compatible.
o Object binary files (.o) compiled with v8plus and
v8plusa can be linked and can execute together, but
only on a SPARC V8plusa compatible platform.
o Object binary files (.o) compiled with v8plus,
v8plusa, and v8plusb can be linked and can execute
together, but only on a SPARC V8plusb compatible
platform.
o -xarch values v9, v9a, and v9b are only available on
UltraSPARC 64-bit Solaris environments.
o Object binary files (.o) compiled with v9 and v9a can
be linked and can execute together, but will run only
on a SPARC V9a compatible platform.
o Object binary files (.o) compiled with v9, v9a, and
v9b can be linked and can execute together, but will
run only on a SPARC V9b compatible platform.
For any particular choice, the generated executable may
run much more slowly on earlier architectures. Also,
although quad-precision (REAL*16 and long double)
floating-point instructions are available in many of
these instruction set architectures, the compiler does
not use these instructions in the code it generates.
For IA platforms:
Value Meaning
generic Compile for good performance on most systems.
This is the default. This option uses the
best instruction set for good performance on
most proces- sors without major performance
degradation on any of them. With each new
release, the definition of "best" instruction
set may be adjusted, if appropriate.
386 generic and 386 are equivalent in this
release.
486 Compile for the Intel PentiumPro chip.
pentium_pro
486 and pentium_pro are equivalent in this
release.
Defaults:
If -xarch=isa is not specified, -xarch=generic is
assumed.
Interactions:
Although this option can be used alone, it is part of
the expansion of the -xtarget option and may be used to
override the -xarch value that is set by a specific
-xtarget option. For example, -xtarget=ultra2 expands
to -xarch=v8 -xchip=ultra2 -xcache=16/32/1:512/64/1. In
the following command -xarch=v8plusb overrides the
-xarch=v8 that is set by the -xtarget=ultra2.
example% cc -xtarget=ultra2 -xarch=v8plusb ...
Warnings:
If this option is used with optimization, the appropri-
ate choice can provide good performance of the execut-
able on the specified architecture. An inappropriate
choice, however, might result in serious degradation of
performance or in in a binary program that is not exe-
cutable on all intended target platforms.
-xautopar
(SPARC) Turns on automatic parallelization for multiple
processors. Does dependence analysis (analyze loops for
inter- iteration data dependence) and loop restructur-
ing. If optimization is not at -xO3 or higher, optimi-
zation is raised to -xO3 and a warning is emitted.
Avoid -xautopar if you do your own thread management.
The Sun Workshop includes the license required to use
multiprocessor C. To get faster execution, this option
requires a multiple processor system. On a single-
processor system, the resulting binary usually runs
slower.
To determine how many processors you have, use the
psrinfo command.
To request a number of processors, set the PARALLEL
environment variable. The default is 1.
o Do not request more processors than are available.
o If N is the number of processors on the machine, then
for a one-user, multiprocessor system, try
PARALLEL=N-1.
If you use -xautopar and compile and link in one step,
then linking automatically includes the microtasking
library and the threads-safe C runtime library. If you
use -xautopar and compile and link in separate steps,
then you must link with cc -xautopar as well.
-xbuiltin[=a]
Use the -xbuiltin[=(%all|%none)] command when you want
to improve the optimization of code that calls standard
library functions. Many standard library functions,
such as the ones defined in math.h and stdio.h, are
commonly used by various programs. This command lets
the compiler substitute intrinsic functions or inline
system functions where profitable for performance.
a stands for (%all|%none).
The first default of this command is -xbuiltin=%none,
which means no functions from the standard libraries
are substituted or inlined. The first default applies
when you do not specify -xbuiltin.
The second default of this command is -xbuiltin=%all,
which means the compiler substitutes intrinsics or
inlines standard library functions as it determines the
optimization benefit. The second default applies when
you specify -xbuiltin but do not provide an argument.
If you compile with -fast, then -xbuiltin is set to
%all.
-xcache=c
Defines the cache properties for use by the optimizer.
c must be one of the following:
o generic
o native
o s1/l1/a1
o s1/l1/a1:s2/l2/a2
o s1/l1/a1:s2/l2/a2:s3/l3/a3
The si/li/ai are defined as follows:
si
The size of the data cache at level i, in kilobytes
li
The line size of the data cache at level i, in bytes
ai
The associativity of the data cache at level i
Although this option can be used alone, it is part of
the expansion of the -xtarget option; its primary use
is to override a value supplied by the -xtarget option.
This option specifies the cache properties that the
optimizer can use. It does not guarantee that any par-
ticular cache property is used.
The -xcache values are:
generic
Set the parameters for the best performance over
most 32-bit platform architectures.
native
Set the parameters for the best performance on
the host environment (assumes a 32-bit architec-
ture).
s1/l1/a1
Defines level 1 cache properties.
s1/l1/a1:s2/l2/a2
Defines levels 1 and 2 cache properties.
s1/l1/a1:s2/l2/a2:s3/l3/a3
Defines levels 1, 2, and 3 cache properties.
Example:-xcache=16/32/4:1024/32/1 specifies the following:
Level 1 cache has: Level 2 cache has:
16K bytes
1024K bytes
32 bytes line size
32 bytes line size
4-way associativity
Direct mapping associativity.
-xCC Accepts the C++-style comments. In particular, the "//"
can be used to indicate the start of a comment.
-xcg89
(SPARC) This option is a macro for:
-xarch=v7 -xchip=old -xcache=64/32/1.
-xcg92
(SPARC) This option is a macro for:
-xarch=v8 -xchip=super -xcache=16/32/4:1024/32/1.
-xchar_byte_order=o
Produce an integer constant by placing the characters
of a multi-character character-constant in the speci-
fied byte order. You can substitute one of the follow-
ing values for o:
o low: place the characters of a multi-character
character-constant in low-to-high byte order.
o high: place the characters of a multi-character
character-constant in high-to-low byte order.
o default: place the characters of a multi-character
character-constant in an order determined by the com-
pilation mode -X[a|c|s|t].
-xchip=c
Specifies the target processor for use by the optim-
izer.
c must be one of: generic, generic64, native, native64,
old, super, super2, micro, micro2, hyper, hyper2,
powerup, ultra, ultra2, ultra2e, ultra2i, ultra3, 386,
486, pentium, pentium_pro, 603, 604.
Although this option can be used alone, it is part of
the expansion of the -xtarget option; its primary use
is to override a value supplied by the -xtarget option.
This option specifies timing properties by specifying
the target processor.
Some effects are:
o The ordering of instructions, that is, scheduling
o The way the compiler uses branches
o The instructions to use in cases where semantically
equivalent alternatives are available
The -xchip values are:
generic
Set the parameters for the best performance over
most 32-bit platform architectures.
generic64
Set the parameters for the best performance over
most 64-bit platform architectures.
native Set the parameters for the best performance on
the host environment (assumes a 32-bit architec-
ture).
native64
Set the parameters for the best performance on
the host environment (assumes a 64-bit architec-
ture).
old Optimize for pre-SuperSPARC(TM) processors.
super Optimize for the SuperSPARC processor.
super2 Optimize for the SuperSPARC II processor.
micro Optimize for the microSPARC(TM) processor.
micro2 Optimize for the microSPARC II processor.
hyper Optimize for the hyperSPARC(TM) processor.
hyper2 Optimize for the hyperSPARC II processor.
powerup
Optimize for the Weitek(R) PowerUp(TM) proces-
sor.
ultra Optimize for the UltraSPARC(TM) processor.
ultra2 Optimize for the UltraSPARC II processor.
ultra2e
Optimize for the UltraSPARC IIe processor.
ultra2i
Optimize for the UltraSPARC IIi processor.
ultra3 Optimize for the UltraSPARC(TM) III processor.
386 Optimize for the Intel 386 architecture.
486 Optimize for the Intel 486 architecture.
pentium
Optimize for the Intel pentium architecture.
pentium_pro
Optimize for the Intel pentium_pro architecture.
-xcode=v
Specify code address space (SPARC Only).
The values for -xcode are:
abs32 Generate 32-bit absolute addresses.
Code + data + bss size is limited to 2**32
bytes. This is the default on 32-bit architec-
tures: arch=generic,v7,v8,v8a,v8plus,v8plusa
abs44 Generate 44-bit absolute addresses.
Code + data + bss size is limited to 2**44
bytes. Available only on 64-bit architectures:
-xarch=v9,v9a
abs64 Generate 64-bit absolute addresses.
Available only on 64-bit architectures:
-xarch=v9,v9a
pic13 Generate position-independent code for use in
shared libraries (small model).
Equivalent to -Kpic. Permits references to at
most 2**11 unique external symbols on 32-bit
architectures, 2**10 on 64-bit.
pic32 Generate position-independent code for use in
shared libraries (large model).
Equivalent to -KPIC. Permits references to at
most 2**30 unique external symbols on 32-bit
architectures, 2**29 on 64-bit.
The default is -xcode=abs32 for SPARC V8 and V7. The
default is -xcode=abs64 for SPARC and UltraSPARC V9
(with -xarch=v9|v9a).
When building shared dynamic libraries with -xarch=v9
or v9a on 64-bit Solaris 7, a -xcode=pic13 or
-xcode=pic32 option MUST also be specified.
-xcrossfile[=n]
Enable optimization and inlining across source files
(SPARC Only).
If specified, n may be 0, or 1.
Normally, the scope of the compiler's analysis is lim-
ited to each separate file on the command line. For
example, -xO4's automatic inlining is limited to sub-
programs defined and referenced within the same source
file.
With -xcrossfile, the compiler analyzes all the files
named on the command line as if they had been con-
catenated into a single source file.
-xcrossfile is only effective when used with -xO4 or
-xO5.
The files produced from this compilation are inter-
dependent (due to possible inlining) must be used as a
unit when linking into a program. If any one routine is
changed and the files recompiled, they must all be
recompiled.
As a result, use of this option will affect how
makefiles are constructed.
The default, if not specified on the command line, is
-xcrossfile=0 and no cross file optimizations are per-
formed. -xcrossfile is equivalent to -xcrossfile=1.
-xcsi
-xcsi allows the C compiler to accept source code writ-
ten in locales that do not conform to the ISO C source
character code requirements. These locales include
ja_JP.PCK.
Note, the compiler translation phases required to han-
dle such locales may result in significantly longer
compile times. You should only use this option when
you compile source files that contain source characters
from one of these locales.
The compiler does not recognize source code written in
locales that do not conform to the ISO C source charac-
ter code requirements unless you issue -xcsi.
-xdepend
(SPARC) Analyzes loops for inter-iteration data depen-
dencies and does loop restructuring.
Loop restructuring includes loop interchange, loop
fusion, scalar replacement, and elimination of "dead"
array assignments. If optimization is not at -xO3 or
higher, optimization is raised to -xO3 and a warning is
issued.
Dependency analysis is included in
-xautoparor-xparallel. The dependency analysis is done
at compile time.
Dependency analysis may help on single-processor sys-
tems. However, if you try -xdepend on single-processor
systems, you should not use either -xautopar or -xex-
plicitpar. If either of them is on, the -xdepend optim-
ization is done for multiple-processor systems.
-xe Performs only syntax and semantic checking on the
source file, but does not produce any object or execut-
able file.
-xexplicitpar
(SPARC) Parallelizes the loops that are specified. You
do the dependency analysis: analyze and specify loops
for inter-iteration and data dependencies. The software
parallelizes the specified loops. If optimization is
not at -xO3 or higher, then it is raised to -xO3 and a
warning is issued.
Avoid -xexplicitpar if you do your own thread manage-
ment.
To get faster code, use this option on a multiprocessor
system. On a single-processor system, the generated
code usually runs slower.
If you identify a loop for parallelization, and the
loop has dependencies, you can get incorrect results,
possibly different ones with each run, and with no
warnings. Do not apply an explicit parallel pragma to
a reduction loop. The explicit parallelization is
done, but the reduction aspect of the loop is not done,
and the results can be incorrect.
If you use -xexplicitpar and compile and link in one
step, then linking automatically includes the micro-
tasking library and the threads-safe C runtime library.
If you use -xexplicitpar and compile and link in
separate steps, then you must also link with cc -xex-
plicitpar.
Do not issue -xexplicitpar and -xopenmp together.
-xF Allow function reordering by the WorkShop Performance
Analyzer. (See analyzer(1) man pages.) If you compile
with the -xF option, and then run the WorkShop Perfor-
mance Analyzer, you can generate a map file that shows
an optimized order for the functions. The subsequent
link to build the executable file can be directed to
use that map file by using the linker -Mmapfile option.
It places each function from the executable file into a
separate section.
-xhelp=f
Displays on-line help information.
f must be either flags or readme.
-xhelp=flags displays a summary of the compiler
options;
-xhelp=readme displays the readme file;
-xildoff
Turns off the incremental linker and forces the use of
ld. This option is the default if you do not use the
-g option, or if you do use the -G option, or any
source files are present on the command line. Override
this default by using the -xildon option.i For more
information on ild, see the C User's Guide.
-xildon
Turns on the incremental linker and forces the use of
ild in incremental mode. This option is the default if
you use the -g option, and you do not use the -G
option, and there are no source files present on the
command line. Use the -xildoff option to override this
default. For more information on ild, see the C User's
Guide.
-xinline=[{%auto,func_name,no%func_name}[,{%auto,func_name,no%func_name}]...]
Tries to inline only those functions specified in the
list. The list is comprised of either a comma-separated
list of function names, or a comma separated list of
no%func_name values, or the value %auto. If you issue
%nofunc_name, the compiler is not to inline the named
function. If you issue %auto, the compiler is to
attempt to automatically inline all functions in the
source files.
If you are compiling with -x03, you can use -xinline to
increase optimization by inlining some or all func-
tions. The -x03 level of optimization does not include
inlining.
If you are compiling with -x04, -xinline can decrease
optimization by restricting inlining to only those rou-
tines in the list. With -x04, the compiler normally
tries to inline all references to functions defined in
the source file. When you specify -xinline= but do not
name any functions or %auto, this indicates that none
of the routines in the source file are inlined.
A function is not inlined if any of the following apply
(no warning is issued):
o Optimization is less than -xO3
o The routine cannot be found
o Inlining the routine does not look profitable or
safe to iropt
o The source for the routine is not in the file being
compiled (however, see -xcrossfile).
-xipo[=a]
a is either 0 or 1. -xipo without any arguments is
equivalent to -xipo=1. -xipo=0 is the default setting
and turns off -xipo.
Performs whole-program optimizations by invoking an
interprocedural analysis pass. Unlike -xcrossfile,
-xipo performs optimizations across all object files in
the link step, and is not limited to just the source
files on the compile command.
Analysis and optimization is limited to the object
files compiled with -xipo, and does not extend to
object files on libraries. -xipo is multiphased, so
you need to specify -xipo for each step if you compile
and link in separate steps.
The -xipo option generates significantly larger object
files due to the additional information needed to per-
form optimizations across files. However, this addi-
tional information does not become part of the final
executable binary file. Any increase in the size of the
executable program is due to the additional optimiza-
tions performed. The object files created in the compi-
lation steps have additional analysis information com-
piled within them to permit crossfile optimizations to
take place at the link step.
Here are some important considerations for -xipo:
o It requires an optimization level of at least -xO4.
o It conflicts with -xcrossfile. If you use these
together, the result is a compilation error.
o Objects that are compiled without -xipo can be linked
freely with objects that are compiled with -xipo.
In this example, compilation and linking occur in a
single step:
cc -xipo -xO4 -o prog part1.c part2.c part3.c
In this example, compilation and linking occur in
separate steps:
cc -xipo -xO4 -c part1.c part2.c
cc -xipo -xO4 -c part3.c
cc -xipo -xO4 -o prog part1.o part2.o part3.o
The object files created in the compilation steps have
additional analysis information compiled within them to
permit crossfile optimizations to take place at the link
step.
A restriction is that libraries, even if compiled with
-xipo do not participate in crossfile interprocedural
analysis, as shown in this example:
cc -xipo -xO4 one.c two.c three.c
ar -r mylib.a one.o two.o three.o
cc -xipo -xO4 -o myprog main.c four.c mylib.a
Here interprocedural optimizations are performed between
one.c, two.c and three.c, and between main.c and four.c,
but not between main.c or four.c and the routines on
mylib.a. (The first compilation may generate warnings
about undefined symbols, but the interprocedural
optimizations are performed because it is a compile and
link step.)
-xlibmieee
Forces IEEE 754 style return values
for math routines
in exceptional cases.
In such cases, no exeception message
will be printed, and
errno
should not be relied on.
-xlibmil
Inlines some library routines for faster execution.
-xlic_lib_=sunperf
(SPARC)
Links in the Sun supplied performance libraries.
-xlicinfo
Returns information about the licensing system.
This option does not request a compilation nor
check out a license.
-xloopinfo
(SPARC) Shows which loops are parallelized
and which are not. This option is normally for use with the
-xautopar
and
-xexplicitpar
options. The Sun WorkShop includes the license required
to use multiprocessor C options.
-xM
Runs the ANSI/ISO preprocessor
on the named C programs,
generates makefile dependencies
and sends the result to the standard output (see
make(1)
for details about makefiles and dependencies).
Specifying
-xM
with
-Xs
runs the pre-ANSI/ISO
preprocessor,
/usr/ccs/lib/cpp .
-xM1
Same as
-xM
except that
-xM1
is not supported in
-Xs
mode nor does
-xM1
report dependencies for
/usr/include
header files.
For example:
more hello.c
#include <stdio.h>
main()
{
(void) printf ("hello\n");
}
cc -xM hello.c
hello.o: hello.c
hello.o: /usr/include/stdio.h
Compiling with -xM1 does not report header file dependencies:
cc -xM1 hello.c
hello.o: hello.c
-xMerge
(SPARC) Directs cc to merge the data segment with the
text segment. Data initialized in the object file pro-
duced by this compilation is read-only and (unless
linked with ld -N) is shared between processes.
-xmaxopt[=v]
This command limits the level of pragma opt to the
level specified. The default value is -xmaxopt=off
which causes pragma opt to be ignored. If you specify
-xmaxopt without supplying an argument, that is the
equivalent of specifying -xmaxopt=5.
-xmemalign=ab
This command specifes the maximum assumed memory align-
ment and the behavior of misaligned data accesses.
For memory accesses where the alignment is determinable
at compile time, the compiler generates the appropriate
load/store instruction sequence for that alignment of
data.
For memory accesses where the alignment cannot be
determined at compile time, the compiler must assume an
alignment to generate the needed load/store sequence.
Use the -xmemalign flag to specify the maximum memory
alignment of data to be assumed by the compiler in
these indeterminable situations. You can also specify
the error behavior to be followed at run-time when a
misaligned memory access does take place.
Values
Accepted values for a are:
1 Assume at most 1 byte alignment.
2 Assume at most 2 byte alignment.
4 Assume at most 4 byte alignment.
8 Assume at most 8 byte alignment.
16 Assume at most 16 byte alignment.
Accepted values for b are:
i Interpret access and continue execution.
s Raise signal SIGBUS.
f Raise signal SIGBUS for alignments less than
or equal to 4, otherwise interpret access and
continue execution.
Defaults
The first default, which applies when no -xmemalign
flag appears, is:
-xmemalign=4s for -xarch=generic,v7,v8,v8a,
v8plus,v8plusa
-xmemalign=8s for -xarch=v9,v9a
The second default, which applies when -xememalign
appears without a value is:
-xmemalign=1i for all platforms
-xnolib
Does not link any libraries by default; that is, no -l
options are passed to ld . Normally, the cc driver
passes -lc to ld .
When you use -xnolib , you have to pass all -l options
yourself. For example:
cc test.c -xnolib -Bstatic -lm -Bdynamic -lc
links libm statically and the other libraries dynami-
cally.
-xnolibmil
Does not inline math library routines. Use -xnolibmil
after the -fast option:
cc -fast -xnolibmil ...
-xOn Specifies optimization level (n). (Note the uppercase
letter O, followed by a digit 1, 2, 3, 4, or 5)
If the -xO option is not specified, only a very basic
level of optimization, limited to local common subex-
pression elimination and dead code analysis, is per-
formed. Compiling with an optimization level can
improve a program's performance significantly.
Generally, the higher the level of optimization with
which a program is compiled, the better runtime
performance obtained. However, higher optimization lev-
els may result in increased compilation time and larger
executable files.
There are five levels that you can use with -xOn. The
following sections describe each level for SPARC plat-
forms and for IA platforms. The actual optimizations
performed by the compiler at each level may change with
each compiler release.
If the optimizer runs out of memory, it attempts to
proceed over again at a lower level of optimization,
resuming compilation of subsequent routines at the ori-
ginal level.
Values:
On SPARC Platforms:
-xO1 Does basic local optimization (peephole).
-xO2 Does basic local and global optimization. This
includes induction variable elimination, local and
global common subexpression elimination, algebraic
simplification, copy propagation, constant propa-
gation, loop-invariant optimization, register
allocation, basic block merging, tail recursion
elimination, dead code elimination, tail call
elimination and complex expression expansion.
This level does not optimize references or defini-
tions for external or indirect variables.
-O and -xO2 are equivalent.
-xO3 In addition to optimizations performed at the -xO2
level, also optimizes references and definitions
for external variables. This level does not trace
the effects of pointer assignments. When compil-
ing either device drivers that are not properly
protected by volatile, or programs that modify
external variables from within signal handlers,
use -xO2.
In general, this level, and -xO4, usually result
in the minimum code size when used with the
-xspace option.
-xO4 Does automatic inlining of functions contained in
the same file in addition to performing -xO3
optimizations. This automatic inlining usually
improves execution speed, but sometimes makes it
worse. In general, this level results in
increased code size unless combined with -xspace.
-xO5 Does the highest level of optimization, suitable
only for the small fraction of a program that uses
the largest fraction of computer time. Uses optim-
ization algorithms that take more compilation time
or that do not have as high a certainty of improv-
ing execution time. Optimization at this level is
more likely to improve performance if it is done
with profile feedback. See -xprofile=collect|use.
On IA platforms:
-xO1 Does basic optimization. This includes algebraic
simplification, register allocation, basic block
merging, dead code and store elimination, peephole
optimization.
-xO2 In addition to optimizations performed at the -x01
level, also performs local common subexpression
elimination, local copy and constant propagation,
tail recursion elimination.
-O and -xO2 are equivalent.
-xO3 In addition to optimization performed at the -x02
level, also performs global common subexpression
elimination, global copy and constant propagation,
loop strength reduction, induction variable elimi-
nation, loop-variant optimization.
-xO4 Does automatic inlining of functions contained in
the same file in addition to performing -xO3
optimizations. This automatic inlining usually
improves execution speed, but sometimes makes it
worse. This level also frees the frame pointer
registration (ebp) for general purpose use. In
general, this level results in increased code
size.
-xO5 Generates the highest level of optimization. Uses
optimization algorithms that may take more compi-
lation time and may not have as high a certainty
of improving execution time.
Interactions:
If you use -g or -g0 and the optimization level is -xO3
or lower, the compiler provides best-effort symbolic
information with almost full optimization. Tail-call
optimization and back-end inlining are disabled.
If you use -g or -g0 and the optimization level is -xO4
or higher, the compiler provides best-effort symbolic
information with full optimization.
Debugging with -g does not suppress -xOn, but -xOn lim-
its -g in certain ways. For example, the optimization
options reduce the utility of debugging so that you
cannot display variables from dbx, but you can still
use the dbx where command to get a symbolic traceback.
For more information, see Debugging a Program With dbx.
The -xcrossfile option is effective only if it is used
with -xO4 or -xO5.
See also:
-fast, -xprofile=p, csh(1) man page
Analyzing Program Performance With Sun WorkShop
discusses the effects of the different levels of optim-
ization on the Analyzer's data.
-xopenmp[=i]
where i is one of parallel, stubs, or none. If you
specify -xopenmp but do not include a value, the com-
piler assumes -xopenmp=parallel. If you do not specify
-xopenmp, the compiler assumes -xopenmp=none.
-xopenmp=parallel enables recognition of OpenMP pragmas
and applies to SPARC only. The optimization level under
-xopenmp=parallel is -xO3. The compiler issues a warn-
ing if the optimization level of your program is
changed from a lower level to -xO3. -xopenmp=parallel
predefines the _OPENMP preprocessor token.
-xopenmp=stubs links with the stubs routines for the
OpenMP API routines. Use this option if you need to
compile your application to execute serially.
-xopenmp=stubs also predefines the _OPENMP preprocessor
token.
-xopenmp=none does not enable recognition of OpenMP
pragmas, makes no change to the optimization level of
your program, and does not predefine any preprocessor
tokens.
Do not issue -xopenmp, -xparallel or -xexplicitpar
together.
-xP Prints prototypes for K&R C function definitions.
-xparallel
(SPARC) Parallelizes loops both automatically (by the
compiler) and explicitly (as specified by the program-
mer). This option is a macro and is equivalent to
specifying all three of -xautopar, -xdepend, and
-xexplicitpar. With explicit parallelization, there is
a risk of producing incorrect results.
If optimization is not at -xO3 or higher, optimization
is raised to -xO3 and a warning is issued.
Avoid -xparallel if you do your own thread management.
Do not issue -xparallel if you are issuing -xopenmp.
-xparallel sets -xexplicitpar which should not be
issued if you specify -xopenmp.
To get faster code, use this option on a multiprocessor
SPARC system. On a single-processor system, the gen-
erated code usually runs more slowly.
If you compile and link in one step, -xparallel links
with the microtasking library and the threads-safe C
runtime library. If you compile and link in separate
steps, and you compile with -xparallel, then link with
-xparallel.
-xpentium
(x86) Generates code for the Pentium processor.
-xpg Prepares the object code to collect data for profiling
with gprof(1). Invokes a runtime recording mechanism
that produces a gmon.out file (at normal termination).
-xprefetch[=val[,val]]
(SPARC) Enable prefetch instructions on those architec-
tures that support prefetch, such as UltraSPARC II.
(-xarch=v8plus, v9plusa, v9, or v9a)
Explicit prefetching should only be used under special
circumstances that are supported by measurements.
val must be one of the following:
auto Enable automatic generation of prefetch
instructions
no%auto Disable automatic generation
explicit Enable explicit prefetch macros
no%explicit Disable explicit prefectch macros
latx:factor Adjust the compiler's assumed prefetch-
to-load and prefetch-to-store latencies
by the specified factor. The factor
must be a positive number of the form
n.n .
The prefetch latency is the hardware
delay between the execution of a pre-
fetch instruction and the time the data
being prefetched is available in the
cache.
The compiler assumes a prefetch latency
value when determining how far apart to
place a prefetch instruction and the
load or store instruction that uses the
prefetched data. Note - the assumed
latency between a prefetch and a load
may not be the same as the assumed
latency between a prefetch and a store.
The compiler tunes the prefetch mechan-
ism for optimal performance across a
wide range of machines and applications.
This tuning may not always be optimal.
For memory-intensive applications, espe-
cially applications intended to run on
large multiprocessors, you may be able
to obtain better performance by increas-
ing the prefetch latency values. To
increase the values, use a factor that
is greater than 1 (one). A value
between .5 and 2.0 will most likely pro-
vide the maximum performance.
For applications with datasets that
reside entrely within the external
cache, you may be able to obtain better
performance by decreasing the prefetch
latency values. To decrease the values,
use a factor that is less than one.
To use the latx:factor suboption, start
with a factor value near 1.0 and run
performance tests against the applica-
tion. Then increase or decrease the fac-
tor, as appropriate, and run the perfor-
mance tests again. Continue adjusting
the factor and running the performance
tests until you achieve optimum perfor-
mance. When you increase or decrease the
factor in small steps, you will see no
performance difference for a few steps,
then a sudden difference, then it will
level off again.
yes Same as -xprefetch=auto,explicit
no Same as -xprefetch=no%auto,no%explicit
If -xprefetch is not specified, the default is
-xprefetch=no%auto,explicit. Specifying -xprefetch
without a value is equivalent to
-xprefetch=auto,explicit.
Interactions
The sun_prefetch.h header file provides the macros that
you can use to specify explicit prefetch instruction.
The prefetches will be approximately at the place in
the executable that corresponds to where the macros
appear.
-xprofile=p
Collects data for a profile or use a profile to optim-
ize.
p must be collect[:name], use[:name], or tcov.
This option causes execution frequency data to be col-
lected and saved during execution, then the data can be
used in subsequent runs to improve performance. This
option is only valid when a level of optimization is
specified.
If compilation and linking are performed in separate
steps, the same -xprofile option must appear on the
compile as well as the link step.
collect[:name]
Collects and saves execution frequency for later
use by the optimizer with -xprofile=use. The
compiler generates code to measure statement
execution-frequency.
The name is the name of the program that is being
analyzed. This name is optional. If name is not
specified, a.out is assumed to be the name of the
executable.
You can set the environment variables SUN_PROFDATA
and SUN_PROFDATA_DIR to control where a program
compiled with -xprofile=collect stores the profile
data. If set, the -xprofile=collect data is writ-
ten to SUN_PROFDATA_DIR/SUN_PROFDATA.
These environment variables similarly control the
path and names of the profile data files written
by tcov , as described in the tcov(1) man page.
If these environment variables are not set, the
profile data is written to name.profile/feedback
in the current directory, where name is the name
of the executable or the name specified in the
-xprofile=collect:name flag. -xprofile does not
append .profile to name if name already ends in
.profile. If you run the program several times,
the execution frequency data accumulates in the
feedback file; that is, output from prior execu-
tions is not lost.
use[:name]
Uses execution frequency data to optimize strateg-
ically. The name is the name of the executable
that is being analyzed. This name is optional. If
name is not specified, a.out is assumed to be the
name of the executable.
The program is optimized by using the execution
frequency data previously generated and saved in
the feedback files written by a previous execution
of the program compiled with -xprofile=collect.
The source files and other compiler options must
be exactly the same as those used for the compila-
tion that created the compiled program that gen-
erated the feedback file If compiled with
-xprofile=collect:name, the same program name name
must appear in the optimizing compilation:
-xprofile=use:name.
tcov
Basic block coverage analysis using "new" style
tcov.
The -xprofile=tcov option is the new style of
basic block profiling for tcov. It has similar
functionality to the -xa option, but correctly
collects data for programs that have source code
in header files. See also -xa for information on
the old style of prfiling, the tcov(1) man page,
and the Analyzing Program Performance With Sun
WorkShop manual for more details.
Code instrumentation is performed similarly to
that of the -xa option, but .d files are no longer
generated. instead, a single file is generated,
the name of which is based on the final execut-
able. for example, if the program is run out of
/foo/bar/myprog.profile, the data file is stored
in /foo/bar/myprog.profile/myprog.tcovd.
The -xprofile=tcov and the -xa options are compa-
tible in a single executable, that is, you can
link a program that contains some files that have
been compiled with -xprofile=tcov, and others with
-xa. You cannot compile a single file with both
options.
When running tcov, you must pass it the -x option
to make it use the new style of data. If not, tcov
uses the old .d files, if any, by default for
data, and produces unexpected output.
Unlike the -xa option, the TCOVDIR environment
variable has no effect at compile-time. However,
its value is used at program runtime. See
tcovf1(1) and the Analyzing Program Performance
With Sun WorkShop manual for more details.
Note: tcov's code coverage report can be unreli-
able if functions are inlined due to the use of
-xO4 or higher optimization or -xinline.
-xreduction
(SPARC) Analyzes loops for reduction in automatic
parallelization. This option is valid only if one of
-xautopar or -xparallel is also specified. Otherwise
the compiler issues a warning.
Parallelization options require a WorkShop license.
When a reduction recognition is enabled, the compiler
parallelizes reductions such as dot products, maximum
and minimum finding. These reductions yield different
roundoffs from those obtained by unparallelized code.
-xregs=r[,r...]
Specify register usage (SPARC Only).
Specify usage of registers in generated code.
r is a comma-separated list of one or more of the fol-
lowing: [no%]appl, [no%]float.
Example: -xregs=appl,no%float
The -xregs values are for specific -xarch values):
appl Allow using registers g2, g3, and g4. (v8,
v8a)
Allow using registers g2, g3, and g4.
(v8plus, v8plusa, v8plusb)
Allow using registers g2, g3. (v9, v9a, v9b)
no%appl Do not use appl registers.
float Allow using floating-point registers as speci-
fied in the SPARC ABI.
no%float Do not use floating-point registers.
The default is: -xregs=appl,float.
-xrestrict[=f]
(SPARC) Treats pointer-valued function parameters as
restricted pointers. f is %all, %none or a comma-
separated list of one or more function names. This
command-line option can be used on its own, but is best
used with optimization of -xO3 or greater.
The default is %none. Specifying -xrestrict is
equivalent to specifying -xrestrict=%all.
-xs Disables Auto-Read for dbx. Use this option in case you
cannot keep the .o files around. It passes the -s
option to the assembler.
No Auto-Read is the older way of loading symbol tables.
It places all symbol tables for dbx in the executable
file. The linker links more slowly and dbx initializes
more slowly.
Auto-Read is the newer and default way of loading sym-
bol tables. With Auto-Read, the information is distri-
buted in the .o files, so that dbx loads the symbol
table information only if and when it is needed. Hence,
the linker links faster, and dbx initializes faster.
With -xs, if you move the executables to another direc-
tory, then to use dbx, you can ignore the object (.o)
files.
Without -xs, if you move the executables, you must move
both the source files and the object (.o) files, or set
the path with the dbx pathmap or use command.
-xsafe=mem
(SPARC platform) Allow the compiler to assume that no
memory protection violations occur.
This option allows the compiler to use the non-faulting
load instruction in the SPARC V9 architecture.
Warnings:
Because non-faulting loads do not cause a trap when a
fault such as address misalignment or segmentation vio-
lation occurs, you should use this option only for pro-
grams in which such faults cannot occur. Because few
programs incur memory-based traps, you can safely use
this option for most programs. Do not use this option
for programs that explicitly depend on memory-based
traps to handle exceptional conditions.
Interactions:
This option takes effect only when used with optimiza-
tion level -xO5 and one of the following -xarch values:
v8plus, v8plusa, v8plusb, v9, v9a, or v9b.
-xsb Generates data for the WorkShop browser directory for
the sbrowser(1) program, part of the SourceBrowser.
This option is not valid with the -Xs mode of the com-
piler.
-xsbfast
Generates data for the Workshop browser directory for
the sbrowser(1) program, part of the SourceBrowser.
Does not compile source into an object file. This
option is not valid with the -Xs mode of the compiler.
-xsfpconst
Represents unsuffixed floating-point constants as sin-
gle precision, instead of the default mode of double
precision. Not valid with -Xc.
-xspace
Does no optimizations that increase code size. Does not
parallelize loops if it increases code size. Example:
Does not unroll loops.
-xstrconst
Inserts string literals into the read-only data section
of the text segment instead of the default data seg-
ment.
-xtarget=t
Specifies the target system for the instruction set and
optimization.
t must be one of: native, native64, generic, generic64,
system-name.
The -xtarget option permits a quick and easy specifica-
tion of the -xarch, -xchip, and -xcache combinations
that occur on real systems. The only meaning of -xtar-
get is in its expansion.
-xtarget=native is equivalent to -xarch=native,
-xchip=native, -xcache=native.
-xtarget=native64 is equivalent to -xarch=native64,
-xchip=native64, -xcache=native.
-xtarget=generic is equivalent to -xarch=generic,
-xchip=generic, -xcache=generic.
-xtarget=generic64 is equivalent to -xarch=generic64,
-xchip=generic64, -xcache=generic.
The -fast macro option includes -xtarger=native in its
expansion.
The -xtarget command itself is a macro option which
acts like a macro expansion on the command line for the
-xarch -xchip and -xcache options. Therefore, you can
override any of the expanded options by following
-xtarget with the desired option.
The -xtarget values are:
native Set the parameters for the best performance on
the host environment (assumes a 32-bit archi-
tecture).
native64 Set the parameters for the best performance on
the host environment (assumes a 64-bit archi-
tecture).
generic Set the parameters for the best performance
over most 32-bit platform architectures. This
is the default.
generic64
Set the parameters for the best performance
over most 64-bit platform architectures.
system-name
Get the best performance for the specified
system.
Valid system names on SPARC are: sun4/15,
sun4/20, sun4/25, sun4/30, sun4/40, sun4/50,
sun4/60, sun4/65, sun4/75, sun4/110, sun4/150,
sun4/260, sun4/280, sun4/330, sun4/370,
sun4/390, sun4/470, sun4/490, sun4/630,
sun4/670, sun4/690, sselc, ssipc, ssipx, sslc,
sslt, sslx, sslx2, ssslc, ss1, ss1plus, ss2,
ss2p, ss4, ss4/85, ss4/110, ss5, ss5/85,
ss5/110, ssvyger, ss10, ss10/hs11, ss10/hs12,
ss10/hs14, ss10/20, ss10/hs21, ss10/hs22,
ss10/30, ss10/40, ss10/41, ss10/50, ss10/51,
ss10/61, ss10/71, ss10/402, ss10/412,
ss10/512, ss10/514, ss10/612, ss10/712, ss20,
ss20/hs11, ss20/hs12, ss20/hs14, ss20/hs21,
ss20/hs22, ss20/50, ss20/51, ss20/61, ss20/71,
ss20/151, ss20/152, ss20/502, ss20/512,
ss20/514, ss20/612, ss20/712, ss600/41,
ss600/51, ss600/61, ss600/120, ss600/140,
ss600/412, ss600/512, ss600/514, ss600/612,
ss1000, sc2000, cs6400, solb5, solb6, ultra,
ultra2, ultra2e, ultra2i, ultra1/140,
ultra1/170, ultra1/200, ultra2/1170,
ultra2/1200, ultra2/1300, ultra2/2170,
ultra2/2200, ultra2/2300, ultra3, entr2,
entr2/1170, entr2/2170, entr2/1200,
entr2/2200, entr150, entr3000, entr4000,
entr5000, entr6000.
Compiling for 64-bit Solaris 7 on SPARC or UltraSPARC
V9 is indicated by the -xarch=v9 or -xarch=v9a flag.
Setting -xtarget=ultra or ultra2 is not necessary or
sufficient.
On Intel:
-xtarget= accepts
o generic or native.
o 386 (equivalent to -386 option) or
486 (equivalent to -486 option).
o pentium (equivalent to -pentium option) or
pentium_pro.
See the section on
-xtarget= t in the C User's Guide for the
-xtarget expansions that show the mnemonic
encodings of the actual system names and
numbers.
-xtemp=dir
Sets directory for temporary files used by cc to dir.
No space is allowed within this option string. Without
this option, temporary files go to /tmp. -xtemp has
precedence over the TMPDIR environment variable.
-xtime
Reports the time and resources used by each compila-
tion.
-xtransition
Issues warnings for differences between K&R C and ANSI
C. The -xtransition options issues messages in conjunc-
tion with with the -Xa and -Xt options. All warning
messages about differing behavior can be eliminated
through appropriate coding.
-xtrigraphs[=[yes|no)]]
Enables or disables recognition of trigraph sequences
as defined by the ISO/ANSI C standard.
-xtrigraphs=yes enables recognition of trigraph
sequences in the source code.
-xtrigraphs=no disables recognition of trigraph
sequences in the source code.
Defaults:
If the -xtrigraphs option is not specified,
-xtrigraphs=no is assumed.
If only -xtrigraphs is specified -xtrigraphs=yes is
assumed.
-xunroll=n
Specifies whether or not the compiler optimizes
(unrolls) loops. n is a positive integer. When n is
1, it is a command and the compiler unrolls no loops.
When n is greater than 1, -xunroll=n merely suggests to
the compiler that it unroll loops n times.
-xvector[={yes|no}]
Enable automatic generation of calls to the vector
library functions.
-xvector=yes permits the compiler to transform math
library calls within loops into single calls to the
equivalent vector math routines when such transforma-
tions are possible. Such transformations could result
in a performance improvement for loops with large loop
counts.
If you do not issue -xvector, the default is
-xvector=no. -xvector=no undoes a previously specified
-xvector=yes. If you specify -xvector but do not sup-
ply a value, the default is -xvector=yes.
If you use -xvector on the command line without previ-
ously specifying -xdepend, -xvector triggers -xdepend.
The -xvector option also raises the optimization level
to -O3 if optimization is not specified or optimization
is set lower than -O3.
The compiler includes the libmvec libraries in the load
step. If you compile and link with separate commands,
be sure to use -xvector in the linking cc command.
-xvpara
(SPARC) Issues warnings about loops that have #pragma
MP directives specified when the loop may not be prop-
erly specified for parallelization. For example, when
the compiler detects data dependencies between loop
iterations, it issues a warning.
Use the -xexplicitpar or the -xparallel option and the
#pragma MP directive.
The Sun WorkShop includes the license required to use
multiprocessor C options.
-Yc, dir
Specifies a new directory dir for the location of com-
ponent c. c can consist of any of the characters
representing tools listed under the -W option.
If the location of a tool is being specified, then the
new path name for the tool will be dir/tool. If more
than one -Y option is applied to any one item, then
the last occurrence holds.
-YA, dir
Specifies a directory dir to search for all compiler
components. If a component is not found in dir, the
search reverts to the directory where the compiler is
installed.
-YI, dir
Changes default directory searched for include files.
-YP, dir
Changes default directory for finding libraries files.
-YS, dir
Changes default directory for startup object files.
-Zll (SPARC) Creates the lock_lint database files (.ll
files), one per each .c file compiled for the
lock_lint(1) program, which is included in the iMPact
product. Does not actually compile.
cc recognizes -a, -e, -r, -t, -u, and -z and passes these
options and their arguments to ld. cc also passes any
unrecognized options to ld with a warning.
PRAGMAS
The following #pragmas are recognized by the compilation
system:
#pragma align
#pragma does_not_read_global_data
#pragma does_not_return
#pragma does_not_write_global_data
#pragma error_messages
#pragma fini
#pragma ident
#pragma init
#pragma inline
#pragma int_to_unsigned
#pragma no_inline
#pragma opt
#pragma pack
#pragma rarely_called
#pragma redefine_extname
#pragma returns_new_memory
#pragma unknown_control_flow
#pragma weak
SPARC Only:
#pragma MP serial_loop
#pragma MP serial_loop_nested
#pragma MP taskloop
#pragma nomemorydepend
#pragma no_side_effect
#pragma pack
#pragma pipeloop
#pragma unroll
Refer to the C User's Guide for more information on these
pragmas.
ENVIRONMENT
PARALLEL Set the PARALLEL environment variable if you can
take advantage of multiprocessor execution. The
PARALLEL environment variable specifies the number
of processors available to the program. If the
target machine has multiple processors, the
threads can map to independent processors. Running
the program leads to the creation of two threads
that execute the parallelized portions of the pro-
gram.
TMPDIR cc normally creates temporary files in the direc-
tory /tmp. You may specify another directory by
setting the environment variable TMPDIR to your
chosen directory. (If TMPDIR isn't a valid direc-
tory, then cc will use /tmp). The -xtemp option
has precedence over the TMPDIR environment vari-
able.
SUNPRO_SB_INIT_FILE_NAME
The absolute path name of the directory that con-
tains the .sbinit(5) file. This variable is used
only if the -xsb or -xsbfast flag is used.
SUNPROF_DATA
Controls the name of the file in which the
-xprofile=collect command stores execution-
frequency data.
SUNPROF_DATA_DIR
Controls in which directory the -xprofile=collect
command places the execution-frequency data-file.
SUNW_MP_THR_IDLE
Use the SUNW_MP_THR_IDLE environment variable to
control the status of each thread after it fin-
ishes its share of a parallel job. You can set
SUNW_MP_THR_IDLE to either spin or sleep [ n s| n
ms]. The default is spin, which means the thread
goes spin-waiting. The other choice, sleep [ n s|
n ms] puts the thread to sleep after spin-waiting
for n units. The wait can be seconds (s, the
default unit) or milliseconds (ms), where 1s means
one second, 10ms means ten milliseconds. If a new
job arrives before n units is reached, the thread
stops spin-waiting and starts doing the new job.
If SUNW_MP_THR_IDLE contains an illegal value or
isn't set, spin is used as the default.
SUNW_MP_WARN
Set this environment variable to print warning
messages from the libmtsk library. The libmtsk
library supports OpenMP parallelization. If you
registered a function by using
sunw_mp_register_warn() to handle warning mes-
sages, then SUNW_MP_WARN prints no warning mes-
sages, even if you set it to TRUE. If you did not
register a function and set SUNW_MP_WARN to TRUE,
SUNW_MP_WARN prints the warning messages to
stderr. If you do not register a function and you
do not set SUNW_MP_WARN, you will not see the
warning messages even if they are sent by libmtsk.
For more informationon sunw_mp_register_warn() see
the C User's Guide.
FILES
a.out executable output file
file.a library of object files
file.c C source file
file.d tcov(1) test coverage input file
file.i C source file after preprocessing
file.il inline(1) expansion file
file.o object file
file.s assembler source file
file.tcov output from tcov(1)
acomp compiler front end
cc compiler command line driver
cg code generator (SPARC)
cg386 optimizer (Intel)
codegen code generator (Intel)
crt1.o runtime startup code
crti.o runtime startup code
crtn.o runtime startup code
fbe assembler
gcrt1.o startup for profiling with gprof(1)
gmon.out default profile file for -xpg
iropt global optimizer
mcrt1.o start-up for profiling with prof(1) and
intro(3)
mon.out default profile file for -p
mwinline optimizer (Intel)
SunWS_cache The directory used to store sbrowser(1) data
when the -xsb or -xsbfast flag is used.
sbcleanup deletes obsolete files in the .sb directory
and creates an up-to-date .sb/Index file
SEE ALSO
as(1), dbx(1), ild(1), ld(1), lint(1), prof(1), tmpnam(3S)
The C User's Guide.
Debugging a Program With dbx manual
American National Standard for Programming Language--C,
ANSI/ISO 9899-1990.
The math_libraries README file in
<install_path>/SUNWspro/READMEs
where <install_path> is usually /opt .