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]
[ -errfmt[=[no%]error] ] [ -erroff[=t[,t...] ] ]
[ -errshort[=i] ] [ -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 ] [ -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] ] [ -xCC ] [ -xc99[=o] ] [ -xcache= c ]
[ -xcg89 ] [ -xcg92 ] [ -xchar[=o] ]
[ -xchar_byte_order[=o] ] [ -xcheck= n ] [ -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 ]
[ -xnativeconnect[=a[,a]...] ] [ -xnolib ]
[ -xnolibmil ] [ -xOn ] [ -xopenmp[=i] ] [ -xP ]
[ -xparallel ] [ -xpentium ] [ -xpg ]
[ -xprefetch[=val[,val ] ] ] [ -xprefetch_level= l ]
[ -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
Forte[tm] Developer 7 C compiler.
A manpage, by definition, is a quick reference. For more
detailed information on the C compiler and its options, see
the C User's Guide.
See the online readme file, viewable by calling
cc -xhelp=readme
for the latest important information on platforms, environ-
ments, new features, and software corrections.
A list of all Forte Developer documentation appears at the
end of this man page.
Access all the installed Forte Developer 7 documentation,
including readme files, user guides, and reference manuals
by pointing an HTML browser to
file:/opt/SUNWspro/docs/index.html
The cc(1) manual page describes the ISO C compiler options
that are SVID compliant under Solaris 7, Solaris 8, and
Solaris 9. Take note that the C compiler recognizes by
default some of the constructs of the 1999 ISO/IEC C stan-
dard. Specifically, the supported are detailed in the C
User's Guide. Use the -xc99=%none command if you want to
limit the compiler to the 1990 ISO/IEC C standard.
cc uses getopt to parse command-line options. Options are
treated as a single letter or as a single 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/prod/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 SPARC Platform Edition.
The resulting executable will run only on 64-bit SPARC or
UltraSPARC processors under Solaris with the 64-bit kernel.
Compiling for 64-bit Solaris by several variants of the
-xarch=v9 option. Note that one of these options must be
specified even if -xtarget or -fast are also specified. In
such a case, the -xarch=v9 option variant 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 any -xarch=v9 variant.
When building shared dynamic libraries with -xarch=v9 vari-
ant
on 64-bit Solaris environments, you can specify
-xcode=pic13 or -xcode=pic32 but are not required to do so.
See also the new -xcode=abs32|abs64|pic13|pic32 option for
specifying code address sizes.
64-bit Solaris not only enables 64-bit integer and pointer
data, but also support for large files.
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:
-# Turns on verbose mode, showing how command options
expand. Shows each component as it is invoked.
-### Shows each component as it would be invoked, but does
not actually execute it. Also shows how command options
would expand.
-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=0x540
__`uname -s`_`uname -r`
__sparc (SPARC)
__sparcv9 (SPARC with -xarch=v9|v9a|v9b)
__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.
Note: Many system libraries are only available as
dynamic libraries in the Solaris 64-bit compilation
environment. As a result, this option causes fatal
errors if you use it in combination with -xarch=v9.
-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.
-errfmt[=[no%]error]
Use this option if you want to prefix the string
"error:" to the beginning of error messages so they are
more easily distinguishable from warning messages. The
prefix is also attached to warnings that are converted
to errors by -errwarn.
error Add the prefix "error:" to all error messages.
no%error Do not add the prefix "error:" to any error
messages.
If you do not use this option, the compiler sets it to
-errfmt=no%error. If you use specify -errfmt, but do
not supply a value, the compiler sets it to
-errfmt=error.
-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.
Only warning messages from the C compiler front-end
that display a tag when the -errtags option is used can
be suppressed with the -erroff option. You can achieve
finer control over error message suppression by using
#pragma error_messages.
-errshort[=i]
Use this option to control how much detail is in the
error message produced by the compiler when it discov-
ers a type mismatch. This option is particularly useful
when the compiler discovers a type mismatch that
involves a large aggregate.
i can be one of the following:
short Error messages are printed in short form with
no expansion of types. Aggregate members are
not expanded, neither are function argument
and return types.
full Error messages are printed in full verbose
form showing the full expansion of the
mismatched types.
tags Error messages are printed with tag names for
types which have tag names. If there is no tag
name, the type is shown in expanded form.
If you do not use -errshort, the compiler sets the
option to -errshort=full. If you specify -errshort, but
do not provide a value, the compiler sets the option to
-errshort=tags.
This option does not accumulate, it accepts the last
value specified on the command line.
-errtags=a
Displays the message tag for each warning message of
the C compiler front-end that can be suppressed with
the -erroff option or made a fatal error with the
-errwarn option. Messages from the C compiler driver
and other components of the C compilation system do not
have error tags, and cannot be suppressed with -erroff
and made fatal with -errwarn.
a can be either yes or no. The default is -errtags=no.
Specifying -errtags is equivalent to specifying
-errtags=yes.
-errwarn[=t[,t...] ]
Use the -errwarn option to cause the C compiler to exit
with a failure status for the given warning messages.
t is a comma-separated list that consists of one or
more of the following: tag, no%tag, %all, %none. Order
is important; for example %all,no%tag causes the C com-
piler to exit with a fatal status if any warning except
tag is issued.
The warning messages generated by the C compiler change
from release to release as the compiler error checking
improves and features are added. Code that compiles
using -errwarn=%all without error may not compile
without error in the next release of the compiler.
Only warning messages from the C compiler front-end
that display a tag when the -errtags option is used can
be specified with the -errwarn option to cause the C
compiler to exit with a failure status.
The default is -errwarn=%none. If you specify -errwarn
alone, it is equivalent to -errwarn=%all.
The following table details the -errwarn values:
tag Cause cc to exit with a fatal status if the
message specified by tag is issued as a warn-
ing 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 a set of baseline options for optimizing bench-
mark applications. These optimizations may alter the
behavior of programs from that defined by the ISO C and
IEEE standards. Modules compiled with -fast, must also
be linked with -fast.
-fast is a macro option that can be effectively used as
a starting point for tuning an executable for maximum
runtime performance. -fast is a macro that can change
from one release of the compiler to the next and
expands to options that are target platform specific.
We suggest that you use the -# option to examine the
expansion of -fast, and incorporate the appropriate
options of -fast into the ongoing process of tunning
the executable.
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
% cc -fast -xnolibmil
The -fast option acts like a macro expansion on the
command line. Therefore, you can override any of the
expanded options by following -fast with the desired
option.
If you combine -fast with other options, the last
specification applies.
In previous releases, the -fast macro option included
-fnonstd, but now it includes -fns instead.
These options are turned on for -fast:
-dalign (x86)
-fns
-fsimple=2 (SPARC)
-fsingle
-ftrap=%none
-nofstore (x86)
-xalias_level=basic (SPARC)
-xarch
-xbuiltin=%all
-xdepend
-xlibmil
-xmemalign=8s (SPARC)
-xO5
-xprefetch=auto,explicit (SPARC)
Note: Some optimizations make certain assumptions about
program behavior. If the program does not conform to
these assumptions, the application may crash or produce
incorrect results. Please refer to the description of
the individual options to determine if your program is
suitable for compilation with -fast.
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.
#pragma does_not_read_global_data
#pragma does_not_write_global_data
#pragma no_side_effect
If your code relies on the return value of errno in
exceptional cases as documented in the matherr(3M) man
page, you must turn off the macro by issuing the
-U__MATHERR_ERRNO_DONTCARE macro after the -fast
option.
You can usually improve performance for most programs
with this option.
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.
-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 excep-
tions. In particular, a floating-point computation can-
not be replaced by one that produces different results
with rounding modes held constant at run time.
-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 replace all
computations of x/y in a given loop with x*z, where x/y
is guaranteed to be evaluated at least once in the
loop, z=1/y, and the values of y and z are known to
have constant values during execution of the loop.
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 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 Program Performance
Analysis Tools 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 specify -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 specify -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]
-Idir adds dir to the list of directories that are
searched for #include files. -I values accumulate from
left to right.
-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 compiler includes directory default:
/opt/SUNWspro/FD7/prod/include/cc
3. 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 compiler include directory default:
/opt/SUNWspro/FD7/prod/include/cc
3. 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.
-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 ISO C stan-
dard. The value of -xc99 affects which version of the
ISO C standard the -X option applies. The -xc99 option
defaults to -xc99=%all which supports a subset of the
1999 ISO/IEC C standard. -xc99=%none supports the 1990
ISO/IEC C standard.
c (conformance)
Strictly conformant ISO C, without K&R C compati-
bility extensions. The compiler issues errors and
warnings for programs that use non-ISO C
constructs. The predefined macro __STDC__ has a
value of 1 with the -Xc option.
a This is the default compiler mode. ISO C plus K&R
C compatibility extensions, with semantic changes
required by ISO C. Where K&R C and ISO C specify
different semantics for the same construct, the
compiler uses the ISO C interpretation. If the -Xa
option is used in conjunction with the -xtransi-
tion option, the compiler issues warnings about
the different semantics. The predefined macro
__STDC__ has a value of 0 with the -Xa option.
t (transition)
This option uses ISO C plus K&R C compatibility
extensions without semantic changes required by
ISO C. Where K&R C and 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 compiler tries to warn about all language con-
structs that have differing behavior between Sun
ISO C and the K&R C. Invokes cpp for processing.
__STDC__ is not defined in this mode.
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 This option is considered obsolete. Use -xprofile=tcov
instead.
-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
translation unit. If you do not supply -xalias_level,
the compiler assumes -xalias_level=basic. If you supply
-xalias_level without any value, the compiler assumes
-xalias_level=layout.
o any
The compiler assumes that all memory references can
alias at this level. There is no type-based alias anay-
lysis.
o basic
If you use the -xalias_level=basic option, the compiler
assumes that memory references that involve different C
basic types do not alias each other. The compiler also
assumes that references to all other types can alias
each other as well as any C basic type. The compiler
assumes that references using char * can alias any
other type.
o weak
If you use the -xalias_level=weak option, the compiler
assumes that any structure pointer can point to any
structure type. Any structure or union type that con-
tains a reference to any type that is either referenced
in an expression in the source being compiled or is
referenced from outside the source being compiled, must
be declared prior to the expression in the source being
compiled.
You can satisfy this restriction by including all the
header files of a program that contain types that
reference any of the types of the objects referenced in
any expression of the source being compiled.
At the level of -xalias_level=weak, the compiler
assumes that memory references that involve different C
basic types do not alias each other. The compiler
assumes that references using char * alias memory
references that involve any other type.
o layout
The compiler assumes that memory references that
involve types with the same sequence of types in memory
can alias each other. The compiler assumes that two
references with types that do not look the same in
memory do not alias each other. The compiler assumes
that any two memory accesses through different struct
types alias if the initial members of the structures
look the same in memory. However, at this level, you
should not use a pointer to a struct to access some
field of a dissimilar struct object that is beyond any
of the common initial sequence of members that look the
same in memory between the two structs. This is because
the compiler assumes that such references do not alias
each other.
At the level of -xalias_level=layout the compiler
assumes that memory references that involve different C
basic types do not alias each other. The compiler
assumes that references using char * can alias memory
references involving any other type.
o strict
The compiler assumes that memory references, that
involve types such as structs or unions, that are the
same when tags are removed, can alias each other. Con-
versely, the compiler assumes that memory references
involving types that are not the same even after tags
are removed do not alias each other. However, any
structure or union type that contains a reference to
any type that is part of any object referenced in an
expression in the source being compiled, or is refer-
enced from outside the source being compiled, must be
declared prior to the expression in the source being
compiled.
You can satisfy this restriction by including all the
header files of a program that contain types that
reference any of the types of the objects referenced in
any expression of the source being compiled.
At the level of -xalias_level=strict the compiler
assumes that memory references that involve different C
basic types do not alias each other. The compiler
assumes that references using char * can alias any
other type.
o std
The compiler assumes that types and tags need to be the
same to alias, however, references using char * can
alias any other type. This rule is the same as the res-
trictions on the dereferencing of pointers that are
found in the 1999 ISO C standard. Programs that prop-
erly use this rule will be very portable and should see
good performance gains under optimization.
o strong
The same restrictions apply as at the std level, but
additionally, the compiler assumes that pointers of
type char * are used only to access an object of type
char. Also, the compiler assumes that there are no
interior pointers. An interior pointer is defined as a
pointer that points to a member of a struct.
-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.
native Set the parameters for the best performance
on the host environment. This is the default
for the -fast option. The compiler chooses
the appropriate setting for the current sys-
tem processor it is running on.
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
without 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 Limits instruction set to the Intel x86
architecture and is the equivalent of the 386
option.
native Compile for good performance on this system.
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.
386 Limits the instruction set to the Intel
386/486 architecture.
pentium_pro
Limits the instruction set to the pentium_pro
architecture.
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.
To get faster execution, this option requires a multi-
ple 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).
Note: -xbuiltin only inlines global functions defined
in system header files, never static functions defined
by the user.
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.
-xCC When you specify -xc99=%none and -xCC, the compiler
accepts the C++-style comments. In particular, the "//"
can be used to indicate the start of a comment.
-xc99[=o]
The -xc99 flag controls compiler recognition of the
implemented features from the C99 standard (ISO/IEC
9899:1999, Programming Language - C).
o can be one of the following: %all, %none.
-xc99=%none turns off recognition of C99 features.
-xc99=%all turns on recognition of supported C99
features.
Specifying -xc99 without any arguments is the same as
-xc99=%all.
NOTE:
Though the compiler support-level defaults to the
features of C99 listed in the C User's Guide, the stan-
dard headers provided by Solaris in /usr/include do not
yet conform with the 1999 ISO/IEC C standard. If you
encounter error messages, try using -xc99=%none to
obtain the 1990 ISO/IEC C standard behavior for these
headers.
The following is a list of the implemented features of
the ISO/IEC 9899:1999, Programming Language - C stan-
dard. See the C User's Guide for a detailed explanation
of the compiler's support for these featuers:
o Idempotent Qualifiers
o _Pragma
o Mixed Declarations and Code
o static and Other Type Qualifiers Allowed in Array
Declarators
o Flexible Array Members
o Declarations Using Implicit int
o Disallowed Implicit int and Implicit Function
Declarations
o Declaration in for-Loop Statement
o C99 Keywords
o __func__ Support
o Macros With A Variable Number of Arguments
o Variable Length Arrays
o inline Specifier For Static Functions
o Commenting Code with //
-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.
-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=o
The option is provided solely for the purpose of easing
the migration of code from systems where the char type
is defined as unsigned. Unless you are migrating from
such a system, do not use this option. Only code that
relies on the sign of a char type needs to be rewritten
to explicitly specify signed or unsigned. You can sub-
stitute one of the following values for o:
o signed: Treat character constants and variables
declared as char as signed. This impacts the behavior
of compiled code, it does not affect the behavior of
library routines.
o s: equivalent to signed.
o unsigned: Treat character constants and variables
declared as char as unsigned. This impacts the
behavior of compiled code, it does not affect the
behavior of library routines.
o u: equivalent to unsigned.
If you do not specify -xchar, the compiler assumes
-xchar=s. If you specify -xchar, but do not specify a
value, the compiler assumes -xchar=s.
The -xchar option changes the range of values for the
type char only for code compiled with -xchar. This
option does not change the range of values for type
char in any system routine or header file. In particu-
lar, the value of CHAR_MAX and CHAR_MIN, as defined by
limits.h, do not change when this option is specified.
Therefore, CHAR_MAX and CHAR_MIN no longer represent
the range of values encodable in a plain char.
If you use -xchar, be particularly careful when you
compare a char against a predefined system macro
because the value in the macro may be signed. This is
most common for any routine that returns an error code
which is accessed through a macro. Error codes are
typically negative values so when you compare a char
against the value from such a macro, the result is
always false. A negative number can never be equal to
any value of an unsigned type.
It is strongly recommended that you never use -xchar to
compile routines for any interface exported through a
library. By default, the C compiler defines char as
signed as per the Solaris ABI and -xchar does not
change that. Therefore, any users of such a library
needs to be cautioned to also use this option or other-
wise deal with any char values being passed or
returned.
-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].
-xcheck[=n]
(SPARC Platform) Performs a runtime check for stack
overflow of the main thread in a singly-threaded pro-
gram as well as slave-thread stacks in a multithreaded
program. If a stack overflow is detected, a SIGSEGV is
generated. If your application needs to handle a SIG-
SEGV caused by a stack overflow differently than it
handles other address-space violations, see
sigaltstack(2).
Values:
n must be one of the following values.
Value Meaning
%all Perform all -xcheck checks.
%none Do not perform any of the -xcheck
checks.
stkovf Enables a runtime check for stack over-
flow.
no%stkovf Turns off stack-overflow checking.
If you do not specify -xcheck, the compiler defaults to
-xcheck=%none. If you specify -xcheck without any argu-
ments, the compiler defaults to -xcheck=%all which
turns on the runtime check for stack overflow.
The -xcheck option does not accumulate on the command
line. The compiler sets the flag in accordance with the
last occurance of the command.
-xchip=c
Specifies the target processor for use by the optim-
izer.
c must be one of: generic, old, super, super2, micro,
micro2, hyper, hyper2, powerup, ultra, ultra2, ultra2e,
ultra2i, ultra3, ultra3cu, 386, 486, pentium,
pentium_pro.
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.
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.
ultra3cu
Optimize for the UltraSPARC III Cu 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 or v9b on 64-bit Solaris environments, you can
specify -xcode=pic13 or -xcode=pic32 but are not
required to do so.
-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 specify -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 specify -xexplicitpar and -xopenmp together.
-xF Allow function reordering by the Performance Analyzer.
(See analyzer(1) man pages.) If you compile with the
-xF option, and then run the Performance 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 func-
tion 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[=v[,v]...]
v can be [{%auto,func_name,no%func_name}].
-xinline 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
specify %nofunc_name, the compiler is not to inline the
named function. If you specify %auto, the compiler is
to attempt to automatically inline all functions in the
source files.
The list of values accumulates from left to right. So
for a specification of -xinline=%auto,no%foo the com-
piler attempts to inline all functions except foo. For
a specification of -xinline=%bar,%myfunc,no%bar the
compiler only tries to inline myfunc.
When you compile with optimization set at -xO4 or
above, the compiler normally tries to inline all refer-
ences to functions defined in the source file. You can
restrict the set of functions the compiler attempts to
inline by specifying the -xinline option. If you
specify only -xinline=, that is you do not name any
functions or auto, this indicates that none of the rou-
tines in the source files are to be inlined. If you
specify a list of func_name and no%func_name without
specifying %auto, the compiler only attempts to inline
those functions specified in the list. If %auto is
specified in the list of values with the -xinline
option at optimization level set at -xO4 or above, the
compiler attempts to inline all functions that are not
explicitly excluded by no%func_name.
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).
If you specify multiple -xinline options on the command
line, they do not accumulate. The last -xinline on the
command line specifies what functions the compiler
attempts to inline.
-xipo[=a]
a is 0, 1, or 2. -xipo without any arguments is
equivalent to -xipo=1. -xipo=0 is the default setting
and turns off -xipo.
The compiler 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.
With -xipo=1, the compiler performs inlining across all
source files. At -xipo=2, the compiler performs inter-
procedural aliasing analysis as well as optimization of
memory allocation and layout to improve cache perfor-
mance.
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.
This option selects the appropriate assembly language
inline templates for the floating-point option and
platform for your system. -xlibmil inlines a
function regardless of any specification of the function
as part of the -xinline flag.
-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.
-xM
Runs only the preprocessor on the named C programs,
requesting that it generate makefile dependencies and
send the result to the standard output (see make (1)
for details about makefiles and dependencies). Specifying
-xM with -Xs runs the pre-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:
example% more hello.c
#include <stdio.h>
main()
{
(void) printf ("hello\n");
}
example% cc -xM hello.c
hello.o: hello.c
hello.o: /usr/include/stdio.h
Compiling with -xM1 does not report header file dependencies:
example% 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
-xnativeconnect[=a[,a]...] ]
Use the -xnativeconnect option when you want to include
interface information inside object files and subse-
quent shared libraries so that the shared library can
interface with code written in the Java[tm] programming
language (Java code). You must also include -xna-
tiveconnect when you build the shared library with the
cc -G command.
When you compile with -xnativeconnect, you are provid-
ing the maximum, external, visibility of the native
code interfaces. The Native Connector Tool (NCT)
enables the automatic generation of Java code and the
Java[tm] Native Interface (JNI) so that C shared
libraries can be called from Java code. For more infor-
mation on how to use the NCT, see the Forte Developer
online help.
a can be one of the following:
%all|%none|[no%]interfaces
If you do not specify -xnativeconnect, the compiler
sets the option to -xnativeconnect=%none. If you
specify only -xnativeconnect, the compiler sets the
option to -xnativeconnect=interfaces.
-xnativeconnect=interfaces forces the generation of
Binary Interface Descriptors (BIDS).
-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 perfor-
mance obtained. However, higher optimization levels may
result in increased compilation time and larger execut-
able 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
Program Performance Analysis Tools discusses the
effects of the different levels of optimization 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 specify -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 specify -xparallel if you are specifying
-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.
-xprefetch_level=l
Use this option to control the aggresiveness of
automatic insertion of prefetch instructions as deter-
mined with -xprefetch=auto.
l must be 1, 2, or 3.
You must compile with optimization level 3 or greater
and generate code for a platform that supports prefetch
(v8plus, v8plusa, v9, v9a, v9b, generic64, native64).
-xprefetch_level=1 enables automatic generation of pre-
fetch instructions. -xprefetch_level=2 enables addi-
tional generation beyond level 1 and -xprefetch=3
enables additional generation beyond level 2.
The default is -xprefetch_level=1 when you specify
-xprefetch=auto.
-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 you specify -xO2 or greater
level of optimization.
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 com-
piler 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.
Except for the -xprofile option, the source files
and other compiler options must be exactly the
same as those used for the compilation that
created the compiled program which in turn gen-
erated the feedback file. The same version of the
compiler must be used for both the collect build
and the use build as well. 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 Program Performance Analysis Tools 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 Program Performance Analysis
Tools 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.
When you use -xprofile=collect to compile a program for
profile collection and -xprofile=use to compile a pro-
gram for profile feedback, the source files and com-
piler options other than -xprofile=collect and
-xprofile=use must be identical in both compilations.
The profile feedback directory names specified by the
-xprofile=use:name option are accumulated from all
instances of the option in a single invocation of the
compiler. For example, assume that profile directories
a.profile, b.profile and c.profile are created as a
result of executing profiled binaries named a, b, and c
respectively.
cc -O -c foo.c -xprofile=use:a -xprofile=use:b
-xprofile=use:c
All three profile directories are used. Any valid pro-
file feedback data pertaining to a particular object
file is accumulated from the specified feedback direc-
tories when the object file is compiled.
If both -xprofile=collect and -xprofile=use are speci-
fied in the same command line, the rightmost -xprofile
option in the command line is applied as follows:
If the rightmost -xprofile option is -xprofile=use, all
profile feedback directory names specified by the
-xprofile=use options are used for feedback-directed
optimization, and the previous -xprofile=collect
options are ignored.
If the rightmost -xprofile option is -xprofile=collect,
all profile feedback directory names specified by
-xprofile=use options are ignored, and instrumentation
for profile generation is enabled.
-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.
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 the usage of registers for the generated code.
(SPARC Only).
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. (v8a,
v8, v8plus, v8plusa, v8plusb)
Allow using registers g2, g3. (v9, v9a, v9b)
In the SPARC ABI, these registers are
described as application registers. Using
these registers can increase performance
because fewer load and store instructions are
needed. However, such use can conflict with
some old library programs written in assembly
code.
no%appl Do not use appl registers.
It is strongly recommended that all system
software and libraries be compiled using
-xreg=no%appl. System software (including
shared libraries) must preserve these regis-
ters' values for the application. Their use is
intended to be controlled by the compilation
system and must be consistent throughout the
application.
float Allow using floating-point registers as speci-
fied in the SPARC ABI. You can use these
registers even if the program contains no
floating-point code.
no%float Do not use floating-point registers. With this
option, a source program cannot contain any
floating-point code.
The default is: -xregs=appl,float.
It is strongly recommended that you compile code
intended for shared libraries that will link with
applications, with -xregs=no%appl,float. At the very
least, the shared library should explicitly document
how it uses the application registers so that applica-
tions linking with those libraries know how to cope
with the issue.
For example, an application using the registers in some
global sense (such as using a register to point to some
critical data structure) would need to know exactly how
a library with code compiled without -xregs=no%appl is
using the application registers in order to safely link
with that library.
-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.
If a function list is specified with this option,
pointer parameters in the specified functions are
treated as restricted; if -xrestrict=%all is specified,
all pointer parameters in the entire C file are treated
as restricted.
The default is %none. Specifying -xrestrict is
equivalent to specifying -xrestrict=%all.
-xs Disables Auto-Read of .o files 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 Generate extra symbol table information for the Source
Browser. This option is not compatible with the -Xs
mode.
-xsbfast
Create the database for the Source Browser, but do not
actually compile. 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. Duplicate strings will be eliminated and the
remaining copy shared amoungst references in the code.
-xtarget=t
Specifies the target system for the instruction set and
optimization.
t must be one of: native, generic, 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=generic is equivalent to -xarch=generic,
-xchip=generic, -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).
generic Set the parameters for the best performance
over most 32-bit platform architectures. This
is the default.
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, ultra3cu,
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
o 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 ISO
C. The -xtransition option issues messages in conjunc-
tion with the -Xa and -Xt options. You can eliminate
all warning messages about differing behavior through
appropriate coding.
-xtrigraphs[=[yes|no)]]
Enables or disables recognition of trigraph sequences
as defined by the ISO 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 specify -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.
-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 program database for lock_lint, but
does not generate executable code.
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
OMP_DYNAMIC
Enable or disable dynamic adjustment of the number
of threads.
OMP_NESTED
Enable or disable nested parallelism.
OMP_NUM_THREADS
Set the number of threads to use during execution.
OMP_SCHEDULE
Set the run-time schedule type and chunk size.
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.
STACKSIZE The executing program maintains a main memory
stack for the master thread and distinct stacks
for each slave thread. Stacks are temporary memory
address spaces used to hold arguments and
automatic variables over subprogram invocations.
The default size of the main stack is about eight
megabytes. Use the limit command to display the
current main stack size as well as set it.
Each slave thread of a multithreaded program has
its own thread stack. This stack mimics the main
stack of the master thread but is unique to the
thread. The thread's private arrays and variables
(local to the thread) are allocated on the thread
stack.
All slave threads have the same stack size, which
is one megabyte for 32-bit applications and two
megabytes for 64-bit applications by default. The
size is set with the STACKSIZE environment vari-
able.
Setting the thread stack size to a value larger
than the default may be necessary for most paral-
lelized code.
Sometimes the compiler may generate a warning mes-
sage that indicates a bigger stack size is needed.
However, it may not be possible to know just how
large to set it, except by trial and error, espe-
cially if private/local arrays are involved. If
the stack size is too small for a thread to run,
the program will abort with a segmentation fault.
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
bb_link.o tcov support
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.ll lock_lint database
file.o object file
file.profile The directory for data used by -xprofile
file.s assembler source file
file.so dynamic library
file.tcov output from tcov(1)
acomp compiler front end
cc compiler command line driver
cg code generator (SPARC)
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
ipo Interprocudural optimizer (SPARC)
ir2hf intermediate code translator (Intel)
iropt global optimizer
lib_I_dbg_gen.so
debug symbol table generator
lib_I_dwarf.so dwarf generator/reader
libldstab_ws.so
sbfocus locator
libredblack.so bids support
mcrt1.o start-up for profiling with prof(1) and
intro(3)
misalign.o misalign data support (SPARC)
mon.out default profile file for -p
postopt postoptimizer (SPARC)
ssbd Static syncronization bug detection (SPARC)
stack_grow.o stack overflow checking (SPARC)
SunWS_cache The directory used to store sbrowser(1) data
when the -xsb or -xsbfast flag is used.
ube optimizer, code generater (Intel)
ube_ipa Interprocedural analyzer (Intel)
values-xa.o -Xa support
values-xc.o -Xc support
values-xpg4.o xpg4 support
values-xs.o -Xs support
values-xt.o -Xt support
SEE ALSO
analyzer(1), as(1), dbx(1), ild(1), ld(1), lint(1), prof(1),
sbquery(1), tmpnam(3S)
The C User's Guide.
The ISO/IEC 9899-1990 Programming Language - C standard,
The ISO/IEC 9899-1999 Programming Language - C standard,
The math_libraries README file in
<install_path>/SUNWspro/READMEs
where <install_path> is usually /opt .