NAME
cc - C compiler
SYNOPSIS
cc [-#] [-###] [-Aname[(tokens)]] [-B[static|dynamic]]
[-C] [-c] [-D] [-d[y|n]] [-dalign] [-E]
[-errfmt[=[no%]error]] [-errhdr[=h]]
[-erroff[=t[,t...]]] [-errshort[=i]] [-errtags=a]
[-errwarn[=t[,t...]]] [-fast] [-fd] [-features=[a]]
[-flags] [-flteval[={any|2}]] [-fma[={none|fused}]]
[-fnonstd] [-fns=[no|yes]] [-fprecision=p] [-fround=r]
[-fsimple[=n]] [-fsingle] [-fstore] [-ftrap[=t[,t...]]]
[-G] [-g] [-H] [-hname] [-I[-|dir]] [-i] [-include]
[-KPIC] [-Kpic] [-keeptmp] [-Ldir] [-lname] [-m32|-m64]
[-mc] [-misalign] [-misalign2] [-mr[,string]] [-mt]
[-native] [-nofstore] [-O] [-On] [-ofilename] [-P] [-p]
[-Q[y|n]] [-qp] [-Rdir[:dir...]] [-S] [-s]
[-traceback[=list]] [-Uname] [-V] [-v] [-Wc,arg] [-w]
[-X[c|a|t|s]] [-xaddr32[={yes|no}]] [-xalias_level[=a]]
[-xannotate] [-xarch=a] [-xautopar] [-xbinopt={a}]
[-xbuiltin[=a]] [-xCC] [-xc99[=o]] [-xcache=c]
[-xcg{89|92}] [-xchar[=o]] [-xchar_byte_order[=o]]
[-xcheck=n] [-xchip=c] [-xcode=v] [-xcrossfile[=n]]
[-xcsi] [-xdebugformat=[stabs|dwarf]]
[-xdepend[={yes|no}]] [-xdryrun] [-xe] [-xF[=v]]
[-xhelp=f] [-xhwcprof[={enable|disable}]]
[-xinline=[v[,v...]]] [-xinstrument=[no%]datarace]
[-xipo[=n]] [-xipo_archive[=a]] [-xjobs=n]
[-xldscope=[v]] [-xlibmieee] [-xlibmil] [-xlibmopt]
[-xlic_lib=sunperf] [-xlicinfo] [-xlinkopt[=level]]
[-xloopinfo] [-xM] [-xM1] [-xMD] [-xMF] [-xMMD]
[-xMerge] [-xmaxopt[=v]] [-xmemalign=ab] [-xmodel=[a]]
[-xnolib] [-xnolibmil] [-xnolibmopt] [-xnorunpath]
[-xOn] [-xopenmp[=i]] [-xP] [-xpagesize=n]
[-xpagesize_heap=n] [-xpagesize_stack=n] [-xpec]
[-xpch=v] [-xpchstop] [-xpentium] [-xpg]
[-xprefetch[=val[,val]]] [-xprefetch_auto_type=[a]
[-xprefetch_level=l] [-xprofile=p]
[-xprofile_ircache[=path]]
[-xprofile_pathmap=collect_prefix:use_prefix] [-xreduc-
tion] [-xregs=r[,r...]] [-xrestrict[=f]] [-xs]
[-xsafe=mem] [-xsb] [-xsbfast] [-xsfpconst] [-xspace]
[-xstrconst] [-xtarget=t] [-xtemp=dir] [-xthreadvar[=o]
[-xtime] [-xtransition] [-xtrigraphs[=[yes|no]]
[-xunroll=n] [-xustr={ascii_utf16_ushort|no}]
[-xvector[=a]] [-xvis] [-xvpara] [-Yc,dir] [-YA,dir]
[-YI,dir] [-YP,dir] [-YS,dir] [-Zll]
DESCRIPTION
Oracle Solaris Studio 12.2 C Compiler
This man page details the options or flags that are avail-
able for the C compiler in the Solaris Studio 12.2 release.
For the complete description of all new features and func-
tionality in the Solaris Studio suite, see the readmes at
http://developers.sun.com/sunstudio. The information in the
readmes supercede the information in this man page.
A man page, 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.
COMPILING FOR 64-BIT PLATFORMS:
The way to specify compilation of a 32-bit or 64-bit binary
has changed in this release. The -xarch option no longer
carries an implicit memory model, 32-bit ILP32 or 64-bit
LP64, with each definition, and is now used only to specify
the instruction set of the target processor.
Use the new -m32 and -m64 options to specify the memory
model of the target compilation.
The ILP32 model specifies that C-language int, long, and
pointer data types are all 32-bits wide. The LP64 model
specifies that long and pointer data types are all 64-bits
wide. The Solaris and Linux OS also support large files and
large arrays under the LP64 memory model.
When compiling with -m64, the resulting executable will work
only on 64-bit UltraSPARC(R) or x86 processors under Solaris
OS or Linux OS running a 64-bit kernel. Compilation, link-
ing, and execution of 64-bit objects can only take place in
a Solaris or Linux OS that supports 64-bit execution.
SPECIAL x86 NOTES
There are some important issues to be aware of when compil-
ing for x86 Solaris platforms.
The legacy Sun-style parallelization pragmas are no longer
supported on any platform. Use OpenMP instead. See the
OpenMP API User's Guide for information on converting legacy
parallelization directives to OpenMP.
Programs compiled with -xarch set to sse, sse2, sse2a, or
sse3 must be run only on platforms that provide these exten-
sions and features.
If you compile and link in separate steps, always link using
the compiler and with same -xarch setting to ensure that the
correct startup routine is linked.
Numerical results on x86 might differ from results on SPARC
due to the x86 80-bit floating-point registers. To minimize
these differences, use the -fstore option or compile with
-xarch=sse2 if the hardware supports SSE2.
Numerical results can also differ between Solaris and Linux
because the intrinsic math libraries (for example, sin(x))
are not the same.
Binary Compatibility Verification
Starting with Sun Studio 11 and the Solaris 10 OS, program
binaries compiled and built using these specialized -xarch
hardware flags are verified that they are being run on the
appropriate platform.
On systems prior to Solaris 10, no verification is done and
it is the user's responsibility to ensure objects built
using these flags are deployed on suitable hardware.
Running programs compiled with these -xarch options on plat-
forms that are not enabled with the appropriate features or
instruction set extensions could result in segmentation
faults or incorrect results occurring without any explicit
warning messages.
This warning extends also to programs that employ .il inline
assembly language functions or __asm() assembler code that
utilize SSE, SSE2, SSE2a, and SSE3 instructions and exten-
sions.
Overview of the C Compiler
The cc (1) manual page describes the ISO C compiler options
that are SVID compliant under Solaris 9 and Solaris 10
operating environments. Take note that the C compiler recog-
nizes by default some of the constructs of the 1999 ISO/IEC
C standard. 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 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 in the current working directory
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 .S suffix are taken to be assembly source files;
they may be assembled and link edited. Such files are passed
to the preprocessor (/usr/ccs/lib/cpp on Solaris), and then
to the assembler.
Files with an .i are taken to be preprocessed C source
files, and may be compiled, optimized, instrumented for pro-
filing, 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 dynamically linked executable whose name by
default is a.out.
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 can be seen by using the
-### or -xdryrun option and examining the -Y option of the
ld invocation.
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.
Note: Many system libraries, such as libc, are only
available as dynamic libraries in the Solaris 64-bit
compilation environment. Therefore, do not use -Bstatic
as the last toggle on the command line.
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 remo-
val of the object files.
-Dname[(arg[,arg])] [=expansion]
Define a macro with optional arguments as if the macro
is defined by a #define preprocessing directive. If no
=expansion is specified, the compiler assumes =1.
Predefinitions:unix
sparc (SPARC)
sun
The above are not predefined in -Xc mode.
These predefinitions are valid in all modes:
__BUILTIN_VA_ARG_INCR
__SUNPRO_C=0x5110
__SVR4 (Solaris)
__SunOS_OSversion _OSversion (Solaris)
__amd64 (x86 -m64)
__gnu__linux (linux)
__i386 (x86)
__linux (linux)
__linux__ (linux)
__sparc (SPARC)
__sparcv9 (SPARC -m64)
__sun (Solaris)
__unix
__`uname -s`_`uname -r | tr . _`
__x86_64 (x86 -m64)
linux (x86, linux)
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: This option causes fatal errors if you use it in
combination with dynamic libraries. Most system
libraries are only available as dynamic libraries.
-dalign
(SPARC) Obsolete. You should not use this option. Use
-xmemalign=8s instead. For a complete list of obsolete
options and flags, see the C User's Guide. Ignored on
x64/x86 platforms.
-E Runs the source file through the preprocessor only and
sends the output to stdout. The preprocessor is built
directly into the compiler, except in -Xs mode, where
/usr/ccs/lib/cpp is invoked. Includes the preprocessor
line numbering information. 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.
-errhdr [=h]
Use this option to limit the warnings from header files
to the group of header files indicated by the following
flags:
Value Meaning
%all Check all used header files.
%none Check none of the header files.
%user Default. Checks all the user header files
except those in /usr/include and its sub-
directories. Also checks all the header files
supplied by the compiler.
-erroff[=t[,t...] ]
Suppresses compiler warning messages but has no effect
on error messages. This option applies to all warning
messages whether or not they have been designated by
-errwarn to cause a non-zero exit status.
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
This option is a macro that you can effectively use as
a starting point for tuning an executable for maximum
run-time performance. The expansion of -fast can change
from one release of the compiler to the next and
includes options that are target platform specific. Use
the -# or the -xdryrun options to examine the expansion
of -fast, and incorporate the appropriate options of
-fast into the ongoing process of tuning the execut-
able.
The expansion of -fast now includes the new -xlibmopt
option. This option enables the compiler to use a
library of optimized math routines. For more informa-
tion, see the description of -xlibmopt in this man
page.
The -fast option impacts the value of errno. See the
NOTES section at the end of this man page for more
information.
Modules that are compiled with -fast must also be
linked with -fast. For a complete list of compiler
options that must be specified at both compile time and
at link time, see the C User's Guide.
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=generic
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.
These options are turned on for -fast:
-fns (SPARC, x86)
-fsimple=2 (SPARC, x86)
-fsingle (SPARC, x86)
-nofstore (x86)
-xalias_level=basic (SPARC, x86)
-xbuiltin=%all (SPARC, x86)
-xdepend (SPARC, x86)
-xlibmil (SPARC, x86)
-xlibmopt (SPARC)
-xmemalign=8s (SPARC)
-xO5 (SPARC, x86)
-xprefetch=auto,explicit (SPARC)
-xregs=frameptr (x86)
-xtarget=native (SPARC, x86)
Note that this selection of component option flags is
subject to change with each release of the compiler.
For details on the options set by -fast, see the C
User's Guide.
To determine the expansion of -fast on a running sys-
tem, execute the command cc -fast -xdryrun |& grep ###
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.
Do not use this option for programs that depend on IEEE
standard exception handling; you can get different
numerical results, premature program termination, or
unexpected SIGFPE signals.
The -fast option on x86 includes -xregs=frameptr. Be
sure to read the discussion of -xregs=frameptr espe-
cially when compiling mixed C, Fortran, and C++ source
codes.
-fd Reports K&R function declarations and definitions.
-features=[a]
The compiler's treatment of extern inline functions
conforms by default to the behavior specified by the
ISO/IEC 9899:1999 C standard. Compile new codes with
-features=no%extinl to obtain the same treatment of
extern inline functions as provided by versions 5.5, or
older, of the C and C++ compilers.
Old C and C++ objects (pre C/C++ 5.6) can be linked
with new C and C++ objects with no change of behavior
for the old objects. To get standard conforming
behavior, old code must be recompiled using the current
compiler.
If you do not specify a flag for -features, the com-
piler sets it to -features=extinl.
The following table lists the possible values for a:
Value Meaning
[no%]conststrings
Enables or disables the placement of
string literals in read-only memory. The
default is -features=conststrings which
replaces the deprecated -xstrconst
option. Note that your program will fail
to write to a string literal under the
default compilation mode just as if you
had specified -xstrconst on the command
line.
extensions Allows zero-sized struct/union declara-
tions and void function with return
statements returning a value to work.
extinl Generates extern inline functions as
global functions. This is the default,
which conforms with the 1999 C standard.
[no%]extinl Generates extern inline functions as
static functions.
[no%]typeof Enables/disables recognition of the
typeof operator. The typeof operator
returns the type of its argument (either
an expression or a type). It is speci-
fied syntactically like the sizeof
operator, but it behaves semantically
like a type defined with typedef.
Accordingly, it can be used anywhere a
typedef can be used. For example, it can
be used in a declaration, a cast, or
inside of a sizeof or typeof. The
default is -features=typeof.
%none The option is disabled.
Examples
typeof(int) i;/* declares variable "i" to be type int*/
typeof(i+10) j;/* declares variable "j" to be type int,
the type of the expression */
i = sizeof(typeof(j)); /* sizeof returns the size of
the type associated with variable "j" */
int a[10];
typeof(a) b;/* declares variable "b" to be array of
size 10 */
The typeof operator can be especially useful in macro
definitions, where arguments may be of arbitrary type.
For example, #define SWAP(a,b) { typeof(a) temp; temp =
a; a = b; b = temp; }
-flags
Prints a one-line summary of available options.
-flteval[={any|2}]
(x86) Use this option to control how floating point
expressions are evaluated.
2 Floating point expressions are evaluated as
long double.
any Floating point expressions are evaluated
depending on the combination of the types of
the variables and constants that make up an
expression.
If you do not specify -flteval, the compiler sets it to
-flteval=any. If you do specify -flteval, but do not
provide a value, the compiler sets it to -flteval=2.
You must not specify the following options in combina-
tion with -flteval=2:
o -fprecision
o -nofstore
o -xarch=sse2
For more information, see 'Precision of Floating Point
Evaluators' in appendix E of the C User's Guide.
-fma [= { none|fused}]
(SPARC) Enables automatic generation of floating-point,
fused, multiply-add instructions. -fma=none disables
generation of these instructions. -fma=fused allows the
compiler to attempt to find opportunities to improve
the performance of the code by using floating-point,
fused, multiply-add instructions.
The default is -fma=none.
The minimum requirements are -xarch=sparcfmaf and an
optimization level of at least -xO2 for the compiler to
generate fused multiply-add instructions. The compiler
marks the binary program if fused multiply-add instruc-
tions are generated in order to prevent the program
from executing on platforms that do not support them.
Fused multiply-adds eliminate the intermediate rounding
step between the multiply and the add. Consequently,
programs may produce different results when compiled
with -fma=fused, although precision will tend to be
increased rather than decreased.
-fnonstd
-fnonstd is a macro for -fns and -ftrap=common.
-fns[=[no|yes]]
For SPARC, selects the SPARC nonstandard floating-point
mode.
For x86, selects SSE flush-to-zero mode and, where
available, denormals-are-zero mode. This option causes
subnormal results to be flushed to zero on x86. Where
available, this option also causes subnormal operands
to be treated as zero. This option has no effect on
traditional x86 floating-point operations that do not
utilize the SSE or SSE2 instruction set.
The default, -fns=no, is 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.
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.
When nonstandard mode is enabled, floating point arith-
metic may produce results that do not conform to the
requirements of the IEEE 754 standard. See the Numeri-
cal Computation Guide for more information.
On SPARC systems, this option is effective only if used
when compiling the main program.
-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 x86, 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, but is ignored
if compiling for 64-bit platforms (-m64), or SSE2-
enabled processors (-xarch=sse2). -fprecision is
ignored on SPARC platforms.
-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.
The compiler defaults to -fsimple=0. Specifying -fsim-
ple is equivalent to -fsimple=1.
If n is present, it must be 0, 1, or 2.
-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
Includes all the functionality of -fsimple=1, and also
enables use of SIMD instructions to compute reductions
when -xvector=simd is in effect.
Also permits aggressive floating point optimizations
that may cause many programs to produce different
numeric results due to changes in rounding. For exam-
ple, -fsimple=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.
See Also:
Techniques for Optimizing Applications: High Perfor-
mance Computing written by Rajat Garg and Ilya Sharapov
for a more detailed explanation of how optimization can
impact precision.
-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. To turn off this option, use the
-nofstore option.
-ftrap[=t[,t...] ]
Sets the IEEE 745 trapping mode in effect at startup
but does not install a SIGFPE handler. You can use
ieee_handler(3M) or fex_set_handling(3M) to simultane-
ously enable traps and install a SIGFPE handler. If you
specify more than one value, the list is processed
sequentially from left to right.
Value Meaning
[no%]division [Do not] Trap on division by zero.
[no%]inexact [Do not] Trap on inexact result.
[no%]invalid [Do not] Trap on invalid operation.
[no%]overflow [Do not] Trap on overflow.
[no%]underflow [Do not] Trap on underflow.
%all Trap on all the above.
%none Trap on none of the above.
common Trap on invalid, division by zero, and
overflow.
The default is -ftrap=%none.
Note that the [no%] form of the option is used only to
modify the meanings of the %all or common value and
must be used with one of these values, as shown in the
example. The [no%] form of the option by itself does
not explicitly cause a particular trap to be disabled.
Example: -ftrap=%all,no%inexact means set all traps,
except inexact.
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.
Use the -ftrap=inexact trap with caution, as it will
result in the trap being issued whenever a floating-
point value cannot be represented exactly. For example,
the following statement may generate this condition:
x = 1.0 / 3.0;
-G Produce a shared object rather than a dynamically
linked executable. This option is passed to ld and
cannot be used with the -dn option.
When you use the -G option, the compiler does not pass
any default -l options to ld. If you want the shared
library to have a dependency on another shared library,
you must pass the necessary -l option on the command
line.
If you are creating a shared object by specifying -G
along with other compiler options that must be speci-
fied at both compile time and link time, make sure that
those same options are also specified when you link
with the resulting shared object.
When you create a shared object, all the object files
that are compiled with -xarch=v9 must also be compiled
with an explicit -xcode value as documented under the
description of -xcode.
-g Produces additional symbol table information for dbx(1)
and the Performance Analyzer analyzer(1).
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.
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 the Performance Analyzer
manual 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 are
interleaved with the source code.
Note: In previous releases, this option forced the com-
piler to use the incremental linker (ild) by default
instead of the linker (ld) for link-only invocations of
the compiler. That is, with -g, the compiler's default
behavior was to automatically invoke ild in place of ld
whenever you used the compiler to link object files,
unless you specified -G or source files on the command
line. This is no longer the case. The incremental
linker is no longer available.
-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.
o For include statements of the form #include
<foo.h>, the preprocessor searches for the header
file in the following order:
1. The directories named with the -I option, if
any.
2. The compiler and system standard directories,
usually /usr/include.
o For include statements of the form #include
"foo.h", the compiler searches the directories in
the following order:
1. The current directory (that is, the directory
that contains the file which contains the
include statement itself.
2. The directories named with -I options, if
any.
3. The compiler and system standard directories,
usually /usr/include.
-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 fol-
lowing order:
o The directories named with -I options
(both before and after -I-).
o The compiler and system standard direc-
tories, usually /usr/include.
o For include files of the form #include
<foo.h>, search the directories in the fol-
lowing order:
o The directories named with the -I
options that appear after -I- (that is,
the compiler does not search the -I
directories that appear before -I-).
o The compiler and system standard direc-
tories, usually /usr/include.
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.
Warnings
Never specify the compiler installation area,
/usr/include, /lib, /usr/lib, as search directories.
-i Ignores the LD_LIBRARY_PATH and LD_LIBRARY_PATH_64 set-
tings.
-include filename
This option causes the compiler to treat filename as if
it appears in the first line of a primary source file
as a #include preprocessor directive.
The first directory the compiler searches for filename
is the current working directory and not the directory
containing the main source file, as is the case when a
file is explicitly included. If the compiler cannot
find filename in the current working directory, it
searches the normal directory paths. If you specify
multiple -include options, the files are included in
the order they appear on the command line.
-KPIC
(SPARC) Obsolete. You should not use this option. Use
-xcode=pic32 instead. For a complete list of obsolete
options and flags, see the C User's Guide.
(x86) -KPIC is identical to -Kpic on x86 architectures.
-Kpic
(SPARC) Obsolete. You should not use this option. Use
-xcode=pic13 instead. For a complete list of obsolete
options and flags, see the C User's Guide.
(x86) Produces position-independent code. Use this
option to compile source files when building a shared
library. Each reference to a global datum is generated
as a dereference of a pointer in the global offset
table. Each function call is generated in pc-relative
addressing mode through a procedure linkage table.
-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.
Warnings
Never specify the compiler installation area,
/usr/include, /lib, /usr/lib, as search directories.
-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.
-m32|-m64
Specifies the memory model for the compiled binary
object.
Use -m32 to create 32-bit executables and shared
libraries. Use -m64 to create 64-bit executables and
shared libraries.
The ILP32 memory model (32-bit int, long, pointer data
types) is the default on all Solaris platforms and on
Linux platforms that are not 64-bit enabled. The LP64
memory model (64-bit long, pointer data types) is the
default on Linux platforms that are 64-bit enabled.
-m64 is permitted only on platforms that are enabled
for the LP64 model.
Object files or libraries compiled with -m32 cannot be
linked with object files or libraries compiled with
-m64.
When compiling applications with large amounts of
static data using -m64, -xmodel=medium may also be
required. Be aware that some Linux platforms do not
support the medium model.
Modules that are compiled with -m32|-m64 must also be
linked with -m32|-m64. For a complete list of compiler
options that must be specified at both compile time and
at link time, see the C User's Guide.
Note that in previous compiler releases, the memory
model, ILP32 or LP64, was implied by the choice of the
instruction set with -xarch. Starting with the Sun Stu-
dio 12 compilers, this is no longer the case. On most
platforms, just adding -m64 to the command line is suf-
ficient to create 64-bit objects.
On Solaris, -m32 is the default. On Linux systems sup-
porting 64-bit programs, -m64 -xarch=sse2 is the
default.
See also -xarch.
-mc Removes duplicate strings from the .comment section of
an object file. When you use the -mc flag, -mcs -c is
invoked.
-misalign
(SPARC) Obsolete. You should not use this option. Use
the -xmemalign=1i option instead. For a complete list
of obsolete options and flags, see the C User's Guide.
-misalign2
(SPARC) Obsolete. You should not use this option. Use
the -xmemalign=2i option instead. For a complete list
of obsolete options and flags, see the C User's Guide.
-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[={yes|no}]
Use this option to compile and link multithreaded code
using the Solaris threads or POSIX threads API. The
-mt=yes option assures that libraries are linked in the
appropriate order.
This option passes -D_REENTRANT to the preprocessor.
To use Solaris threads, include the thread.h header
file and compile with the -mt=yes option. To use POSIX
threads on Solaris platforms, include the pthread.h
header file and compile with the -mt=yes option.
On Linux platforms, only the POSIX threads API is
available. (There is no libthread on Linux platforms.)
Consequently, -mt=yes on Linux platforms adds -lpthread
instead of -lthread. To use POSIX threads on Linux
platforms, compile with -mt.
Note that when compiling with -G,neither -ltread nor
-lpthread are automatically included by -mt=yes. You
will need to explicitly list these libraries when
building a shared library.
The -xopenmp option (for using the OpenMP shared-memory
parallelization API) includes -mt=yes automatically.
If you compile with -mt=yes and link in a separate
step, you must use the -mt=yes option in the link step
as well as the compile step. If you compile and link
one translation unit with -mt=yes, you must compile and
link all units of the program with -mt=yes
-mt=yes is the default behavior of the compiler. If
this behaviour is not desired use the option -mt=no.
The option -mt is equivalent to -mt=yes.
See also: -xnolib
-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 Use default optimization level -xO3. This macro now
expands to -xO3 instead of -xO2.
The change in default yields higher run-time perfor-
mance. However, -x03 may be inappropriate for programs
that rely on all variables being automatically con-
sidered volatile. Typical programs that might have this
assumption are device drivers and older multi-threaded
applications that implement their own synchronization
primitives. The work around is to compile with -xO2
instead of -O.
-On The same as -xOn.
-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 Obsolete See -xpg.
-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.
-traceback[={%none|common|signals_list}]
Issue a stack trace if a severe error occurs in execu-
tion.
The -traceback option causes the executable to issue a
stack trace to stderr, dump core, and exit if certain
signals are generated by the program. If multiple
threads generate a signal, a stack trace will only be
produced for the first one.
To use traceback, add the -traceback option to the com-
piler command line when linking. The option is also
accepted at compile-time but is ignored unless an exe-
cutable binary is generated. Using -traceback with -G
to create a shared library is an error.
%none or none
disables traceback
common
specifies that a stack trace should be issued if
any of a set of common signals is generated --
sigill, sigfpe, sigbus, sigsegv, and sigabrt.
signals_list
specifies a comma-separated list of names of sig-
nals which should generate a stack trace, in lower
case. The following signals (those that cause the
generation of a core file) can be caught:
sigquit, sigill, sigtrap, sigabrt, sigemt, sigfpe,
sigbus, sigsegv, sigsys, sigxcpu, sigxfsz
Any of these can be preceeded with no% to disable
catching the signal.
For example: -traceback=sigsegv,sigfpe will pro-
duce a stack trace and core dump if either sigsegv
or sigfpe is generated.
If the option is not specified, the default is
-traceback=%none
-traceback without any = sign implies -traceback=common
Note: If the core dump is not wanted, users may set the
coredumpsize limit to zero using:
% limit coredumpsize 0
The -traceback option has no effect on runtime perfor-
mance.
-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)(x86)
l Link editor (ld)
m mcs
0 (Captial letter 'o') Interprocedural optim-
izer
o Postoptimizer
p Preprocessor (cpp)
u C code generator (ube), (x86)
0 (The number zero) Compiler (acomp) (ssbd
SPARC)
2 Optimizer: (iropt)
(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.
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 con-
structs. 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 conjunction 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
Solaris Studio 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.
-xaddr32[={yes|no}]
(x86/x64 only) The -xaddr32=yes compilation flag res-
tricts the resulting executable or shared object to a
32-bit address space.
An executable that is compiled in this manner results
in the creation of a process that is restricted to a
32-bit address space.
When -xaddr32=no is specified a usual 64 bit binary is
produced.
If the -xaddr32 option is not specified, -xaddr32=no is
assumed.
If only -xaddr32 is specified -xaddr32=yes is assumed.
This option is only applicable to -m64 compilations and
only on Solaris platforms supporting SF1_SUNW_ADDR32
software capability.
Since Linux kernel does not support addres space limi-
tation this option is not available on Linux. The
-xaddr32 option is ignored on Linux.
When linking, if a single object file was compiled with
-xaddr32=yes the whole output file is assumed to be
compiled with -xaddr32=yes.
A shared object that is restricted to a 32-bit address
space must be loaded by a process that executes within
a restricted 32-bit mode address space.
For more information refer to the SF1_SUNW_ADDR32
software capabilities definition, described in the
Linker and Libraries Guide.
-xalias_level[=a]
where a must be one of:any, basic, weak, layout,
strict, std, strong. Use this flag to place the indi-
cated alias level into effect for the whole translation
unit. In other words, the alias level you select is
applied to all of the memory references in the transla-
tion unit. If you do not supply -xalias_level, the com-
piler assumes -xalias_level=any. If you supply
-xalias_level without a 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.
See Also: -xprefetch_auto_type
-xannotate[={yes|no}]
(Solaris) Instructs the compiler to create binaries
that can later be transformed by binary modification
tools like binopt(1). Future binary analysis, code cov-
erage and memory error detection tools will also work
with binaries built with this option.
Use the -xannotate=no option to prevent the modifica-
tion of the binary file by these tools.
The -xannotate=yes option must be used with optimiza-
tion level -xO1 or higher to be effective, and it is
only effective on systems with the new linker support
library interface - ld_open(). If the compiler is used
on a system without this linker interface (for example
Solaris 9), it silently will revert to -xannotate=no.
The new linker interface is available in Solaris 10
patch 127111-07, Solaris 10 Update 5 and OpenSolaris.
The default is -xannotate=yes, but if either of the
above conditions is not met, the default reverts to
-xannotate=no.
This option is not available on Linux systems.
-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 can affect the portability of a binary program.
See the Notes and Warnings sections at the end of this
entry.
Note: Use the -m64 or -m32 option to specify the
intended memory model, LP64 (64-bits) or ILP32 (32-
bits) respectively. The -xarch flag no longer indi-
cates the memory model, except for compatibility with
previous releases, as indicated below.
If you compile and link in separate steps, make sure
you specify the same value for -xarch in both steps.
Values for all platforms:
Value Meaning
generic This option uses the instruction set common
to most processors.
generic64 Compile for good performance on most 64-bit
platforms. (Solaris only)
This option is equivalent to
-m64 -xarch=generic
and is provided for compatibility with ear-
lier releases. Use -m64 to specify 64-bit
compilation instead of -xarch=generic64
native Compile for good performance on this system
The compiler chooses the appropriate setting
for the current system processor it is run-
ning on.
native64 Compile for good performance on this system
(Solaris only)
This option is equivalent to
-m64 -xarch=native and is provided for compa-
tibility with earlier releases.
Values specific to SPARC platforms:
sparc Compile for the SPARC-V9 ISA.
Compile for the V9 ISA, but 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 V9 ISA.
sparcvis Compile for the SPARC-V9 ISA plus VIS.
Compile for SPARC-V9 plus the Visual Instruc-
tion Set (VIS) version 1.0, and with
UltraSPARC extensions. This option enables
the compiler to generate code for good per-
formance on the UltraSPARC architecture.
sparcvis2 Compile for the SPARC-V9 ISA with UltraSPARC
III extensions.
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.
sparcvis3 Compile for the SPARC-V9 ISA with UltraSPARC
III and VIS 3 extensions.
Enables the compiler to use instructions from
the SPARC-V9 instruction set, plus the
UltraSPARC extensions, including the Visual
Instruction Set (VIS) version 1.0, the
UltraSPARC-III extensions, including the
Visual Instruction Set (VIS) version 2.0, the
fused multiply-add instructions, and the
Visual Instruction Set (VIS) version 3.0
sparcfmaf Compile for the sparcfmaf version of the
SPARC-V9 ISA.
Enables the compiler to use instructions from
the SPARC-V9 instruction set, plus the
UltraSPARC extensions, including the Visual
Instruction Set (VIS) version 1.0, the
UltraSPARC-III extensions, including the
Visual Instruction Set (VIS) version 2.0, and
the SPARC64 VI extensions for floating-point
multiply-add.
Note that you must use -xarch=sparcfmaf in
conjunction with -fma=fused and some optimi-
zation level to get the compiler to attempt
to find opportunities to use the multiply-add
instructions automatically.
sparcima Compile for the sparcima version of the
SPARC-V9 ISA.
Enables the compiler to use instructions from
the SPARC-V9 instruction set, plus the
UltraSPARC extensions, including the Visual
Instruction Set (VIS) version 1.0, the
UltraSPARC-III extensions, including the
Visual Instruction Set (VIS) version 2.0, the
SPARC64 VI extensions for floating-point
multiply-add, and the SPARC64 VII extensions
for integer multiply-add.
v9 Is equivalent to -m64 -xarch=sparc
Legacy makefiles and scripts that use
-xarch=v9 to obtain the 64-bit memory model
need only use -m64.
v9a Is equivalent to -m64 -xarch=sparcvis and is
provided for compatibility with earlier
releases.
v9b Is equivalent to -m64 -xarch=sparcvis2 and
is provided for compatibility with earlier
releases.
Notes:
o Legacy 32-bit SPARC instruction set architectures V7
and V8 imply -m32 and cannot be combined with -m64.
o Object binary files (.o) compiled with sparc and
sparcvis can be linked and can execute together, but
only on a sparcvis compatible platform.
o Object binary files (.o) compiled with sparc,
sparcvis, and sparcvis2 can be linked and can execute
together, but only on a sparcvis2 compatible plat-
form.
For any particular choice, the generated executable
could run much more slowly on earlier architectures.
Also, although quad-precision floating-point instruc-
tions are available in many of these instruction set
architectures, the compiler does not use these
instructions in the code it generates.
Values specific to x86 platforms:
Value Meaning
pentium_pro
Limits the instruction set to the pentium_pro
architecture.
sse Adds the SSE instruction set to the
pentium_pro instruction set.
sse2 Supplements the pentium_pro and SSE instruc-
tion sets with the SSE2 instruction set.
sse3 Supplements the pentium_pro, SSE, and SSE2
instruction sets with the SSE3 instruction
set.
ssse3 Supplements the pentium_pro, SSE, SSE2, and
SSE3 instruction sets with the SSSE3 instruc-
tion set.
sse4_1 Supplements the pentium_pro, SSE, SSE2, SSE3,
and SSSE3 instruction sets with the SSE4.1
instruction set.
sse4_2 Supplements the pentium_pro, SSE, SSE2, SSE3,
SSSE3, and SSE4.1 instruction sets with the
SSE4.2 instruction set.
amdsse4a Uses the AMD SSE4a Instruction set.
amd64 Is equivalent to -m64 -xarch=sse2 (Solaris
only)
Legacy makefiles and scripts that use
-xarch=amd64 to obtain the 64-bit memory
model need only use -m64.
pentium_proa
Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the
pentium_pro architecture.
ssea Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the 32-bit
SSE architecture.
sse2a Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the SSE2
architecture.
amd64a Is equivalent to -m64 -xarch=sse2a (Solaris
only)
Note: If any part of a program is compiled or
linked on an x86 platform with -m64, then all
parts of the program must be compiled with
one of these options as well.
For details on the various Intel instruction
set architectures (SSE, SSE2, SSE3, SSSE3,
and so on) refer to the Intel-64 and IA-32
Intel Architecture Software Developer's
Manual
(http://developer.intel.com/products/processor/manuals/)
Defaults:
If -xarch=isa is not specified, the defaults are:
-xarch=generic on SPARC platforms
-xarch=generic on x86/x64 platforms
Interactions:
Although this option can be used alone, it is part of
the expansion of the -xtarget option and can be used
to override the -xarch value that is set by a
specific -xtarget option.
For example, -xtarget=ultra4 expands to
-xarch=sparcvis2 -xcache=64/32/4:8192/128/2
-xchip=ultra4
Warnings:
If this option is used with optimization, the
appropriate choice can provide good performance of
the executable on the specified architecture. An
inappropriate choice, however, might result in seri-
ous degradation of performance or in in a binary pro-
gram that is not executable on all intended target
platforms.
-xautopar
Turns on automatic parallelization for multiple proces-
sors. 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 issued.
Note that -xautopar does not accept OpenMP paralleliza-
tion directives.
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 run a parallelized program in a multithreaded
environment, you must set the OMP_NUM_THREADS environ-
ment variable prior to execution. See the OpenMP API
User's Guide for more information.
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. For a
complete list of all compiler options that must be
specified at both compile time and at link time, see
the C User's Guide.
-xbinopt={prepare|off}
(SPARC) Instructs the compiler to prepare the binary
for later optimizations, transformations and analysis
(see binopt(1)). This option may be used for building
executables or shared objects. This option must be used
with optimization level -xO1 or higher to be effective.
There is a modest increase in size of the binary when
built with this option..
If you compile in separate steps, -xbinopt must appear
on both compile and link steps:
example% cc -c -xO1 -xbinopt=prepare a.c b.c
example% cc -o myprog -xbinopt=prepare a.o
If some source code is not available for compilation,
this option may still be used to compile the remainder
of the code. It should then be used in the link step
that creates the final binary. In such a situation,
only the code compiled with this option can be optim-
ized, transformed or analyzed.
Compiling with -xbinopt=prepare and -g increases the
size of the executable by including debugging informa-
tion. The default is -xbinopt=off.
-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. See
the er_src(1) man page for an explanation of how to
read compiler commentary in object files to determine
for which functions the compiler actually makes a sub-
sitution.
However, these substitutions can cause the setting of
errno to become unreliable. If your program depends on
the value of errno, avoid this option. See the NOTES
section at the end of this man page for more informa-
tion.
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 a comma separated list comprised of the fol-
lowing:
Value Meaning
[no]_lib [Do not] Enable the 1999 C standard
library semantics of routines that
appeared in both the 1990 and 1999 C
standard.
all Turn on recognition of supported C99
language features and enable the 1999 C
standard library semantics of routines
that appear in both the 1990 and 1999 C
standard.
none Turn off recognition of C99 language
features, and do not enable the 1999 C
standard library semantics of routines
that appeared in both the 1990 and 1999
C standard.
If you do not specify -xc99, the compiler defaults to
-xc99=all,no_lib.
If you specify -xc99 without any values, the option is
set to -xc99=all.
NOTE:
Though the compiler support-level defaults to the
language features of the C99 standard, the standard
headers provided by Solaris 9 in /usr/include do not
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 1999 C standard library semantics of routines that
appeared in both the 1990 and 1999 C standard are not
available and therefore cannot be enabled on Solaris 9.
The compiler issues an error message when -xc99=lib has
been specified directly or indirectly on Solaris 9.
-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
This is the default. Sets the parameters for the
best performance over most architectures.
native
Sets the parameters for the best performance on
the host environment.
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.
-xcg{89|92}
(SPARC) Obsolete. You should not use this option.
Current Solaris operating systems no longer support
SPARC V7 architecture. Compiling with this option gen-
erates code that runs slower on current SPARC plat-
forms. Use -O instead to take advantage of defaults for
-xarch, -xchip, and -xcache.
-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
particular, 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. The Solaris ABI specifies type char as signed,
and system libraries behave accordingly. The effect of
making char unsigned has not been extensively tested
with system libraries. Instead of using this option,
modify your code that it does not depend on whether
type char is signed or unsigned. The sign of type char
varies among compilers and operating systems.
-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]
Performs a runtime check for stack overflow of the main
thread in a singly-threaded program 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 SIGSEGV caused by a stack
overflow differently than it handles other address-
space violations, see sigaltstack(2).
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.
init_local Initialize local variables. See the C
User's Guide description of this option
for a list of the predefined values used
by the compiler to initialize variables.
no%init_local Do not initialize local variables.
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.
The -xcheck option does not accumulate on the command
line. The compiler sets the flag in accordance with the
last occurrence of the command.
-xchip=c
Specifies the target processor for use by the optim-
izer.
c must be one of the values listed below.
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 for SPARC platforms are:
generic
Set the parameters for the best performance over
most SPARC platform architectures. This is the
default.
native Set the parameters for the best performance on
the host environment.
old Uses the timing properties of the pre-SuperSPARC
processors.
sparc64vi
Optimize for the SPARC64 VI processor.
sparc64vii
Optimize for the SPARC64 VII processor.
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.
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 III processor.
ultra3cu
Optimize for the UltraSPARC IIIcu processor.
ultra3i
Optimize for the UltraSPARC IIIi processor.
ultra4 Optimize for the UltraSPARC IV processor.
ultra4plus
Optimize for the UltraSPARC IVplus processor.
ultraT1
Optimize for the UltraSPARC T1 processor.
ultraT2
Optimize for the UltraSPARC T2 processor.
ultraT2plus
Optimize for the UltraSPARC T2+ processor.
ultraT3
Optimize for the UltraSPARC T3 processor.
The -xchip values for x86 platforms are:
generic
Optimize for most x86 platforms.
native Optimize for this host processor.
core2 Optimize for the Intel Core2 processor.
nehalem
Optimize for the Intel Nehalem processor.
opteron
Optimize for the AMD Opteron processor.
penryn Optimize for the Intel Penryn processor.
pentium
Optimize for the pentium architecture.
pentium_pro
Optimize for the pentium_pro architecture.
pentium3
Optimize for Pentium 3 style processor
pentium4
Optimize for Pentium 4 style processor
-xcode=v
(SPARC) Specify code address space
Note: It is highly recommended that you build shared
objects by specifying -xcode=pic13 or -xcode=pic32. It
is possible to build workable shared objects with
-xarch=v9 -xcode=abs64, but these will be inefficient.
Shared objects built with -xarch=v9 -xcode=abs32 or
-xarch=v9 -xcode=abs44 will not work.
The values for -xcode are:
abs32 This is the default for 32-bit systems. Gen-
erates 32-bit absolute addresses.
Code + data + bss size is limited to 2**32
bytes.
abs44 This is the default for 64-bit systems. Gen-
erates 44-bit absolute addresses.
Code + data + bss size is limited to 2**44
bytes. Available only on 64-bit architectures.
abs64 Generates 64-bit absolute addresses.
Available only on 64-bit architectures.
pic13 Generates 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 Generates 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 32-bit architectures.
The default is -xcode=abs44 for 64-bit architectures.
When building shared dynamic libraries, the default
-xcode value of abs44 (not abs32) will not work with
64-bit architectures. Specify -xcode=pic13 or
-xcode=pic32 instead.
To determine whether to use -xcode=pic13 or
-xcode=pic32, check the size of the Global Offset Table
(GOT) by using elfdump -c (see the elfdump(1) man page
for more information) and to look for the section
header, sh_name: .got. The sh_size value is the size of
the GOT. If the GOT is less than 8,192 bytes, specify
-xcode=pic13, otherwise specify -xcode=pic32.
In general, use the following guidelines to determine
how you should use -xcode:
o If you are building an executable you should not use
-xcode=pic13 or -xcode=pic32.
o If you are building an archive library only for
linking into executables you should not use
-xcode=pic13 or -xcode=pic32.
o If you are building a shared library, start with
-xcode=pic13 and once the GOT size exceeds 8,192 bytes,
use -xcode=pic32.
o If you are building an archive library for linking
into shared libraries you should just use -xcode=pic32.
-xcrossfile[=n]
Obsolete - do not use. Use -xipo instead.
-xcsi
This option allows the C compiler to accept source code
written 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.
-xdebugformat=[stabs|dwarf]
Specify -xdebugformat=dwarf if you maintain software
which reads debugging information in the dwarf format.
This option causes the compiler to generate debugging
information by using the dwarf standard format and is
the default
-xdebugformat=stabs generates debugging information
using the stabs standard format.
If you do not specify -xdebugformat, the compiler
assumes -xdebugformat=dwarf. This option requires an
argument.
This option affects the format of the data that is
recorded with the -g option. Some small amount of
debugging information is recorded even without -g, and
the format of that information is also controlled with
this option. So -xdebugformat has a an effect even
when -g is not used.
The dbx and Performance Analyzer software understand
both stabs and dwarf format so using this option does
not have any effect on the functionality of either
tool.
See also the dumpstabs(1) and dwarfdump(1) man pages
for more information.
-xdepend[=[yes|no] ]
Analyzes loops for inter-iteration data dependencies
and performs loop restructuring. Loop restructuring
includes loop interchange, loop fusion, scalar replace-
ment, and elimination of "dead" array assignments.
On SPARC, -xdepend is turned on for all optimization
levels -xO3 and above, and is off for lower opt levels.
Also, an explicit setting of -xdepend overrides any
implicit setting.
On x86, if optimization is not at -xO3 or higher, the
compiler raises the optimization to -xO3 and issues a
warning.
If you do not specify -xdepend, the default is
-xdepend=no which means the compiler does not analyze
loops for data dependencies. If you specify -xdepend
but do not specify an argument, the compiler sets the
option to -xdepend=yes which means the compiler
analyzes loops for data dependencies.
Dependency analysis is included in -xautopar. 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 also specify -xautopar , other-
wise the -xdepend optimization is done for multiple-
processor systems.
See Also: -xprefetch_auto_type
-xdryrun
This option is a macro for -###.
-xe Performs only syntax and semantic checking on the
source file, but does not produce any object or execut-
able file.
-xF[=v]
The -xF option enables the optimal reordering of func-
tions and variables by the linker.
This option instructs the compiler to place functions
and/or data variables into separate section fragments,
which enables the linker, using directions in a mapfile
specified by the linker's -M option, to reorder these
sections to optimize program performance. Generally,
this optimization is only effective when page fault
time constitutes a significant fraction of program run
time.
Reordering functions and variables for optimal perfor-
mance requires the following operations:
1. Compiling and linking with -xF.
2. Following the instructions in the Performance
Analyzer manual regarding how to generate a mapfile for
functions or following the instructions in the Linker
and Libraries Guide regarding how to generate a mapfile
for data.
3. Relinking with the new mapfile by using the linker's
-M option.
4. Re-executing under the Analyzer to verify improve-
ment.
v can be one of the following values:
Value Meaning
[no%]func [Do not] fragment functions into
separate sections.
[no%]gbldata [Do not] fragment global data (variables
with external linkage) into separate
sections.
%all Fragment functions and global data.
%none Fragment nothing.
If you do not specify -xF, the default is -xF=%none. If
you specify -xF without any arguments, the default is
-xF=%none,func.
See Also:
analyzer(1), ld(1)
-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;
-xhwcprof[={enable|disable}]
(SPARC) Use the -xhwcprof option to enable compiler
support for dataspace profiling.
When -xhwcprof is enabled, the compiler generates
information that helps tools associate profiled load
and store instructions with the data-types and struc-
ture members (in conjunction with symbolic information
produced with -g) to which they refer. It associates
profile data with the data space of the target, rather
than the instruction space, and provides insight into
behavior that is not easily obtained from only instruc-
tion profiling.
You can compile a specified set of object files with
-xhwcprof however, -xhwcprof is most useful when
applied to all object files in the application. This
will provide coverage to identify and correlate all
memory references distributed in the application's
object files.
If you are compiling and linking in separate steps, use
-xhwcprof at link time as well. Future extensions to
-xhwcprof may require its use at link time. For a com-
plete list of compiler options that must be specified
at both compile time and at link time, see the C User's
Guide.
An instance of -xhwcprof=enable or -xhwcprof=disable
overrides all previous instances of -xhwcprof in the
same command line.
-xhwcprof is disabled by default. Specifying -xhwcprof
without any arguments is the equivalent to
-xhwcprof=enable.
-xhwcprof requires that optimization be turned on and
that the debug data format be set to dwarf
(-xdebugformat=dwarf).
The combination of -xhwcprof and -g increases compiler
temporary file storage requirements by more than the
sum of the increases due to -xhwcprof and -g specified
alone.
The following command compiles example.c and specifies
support for hardware counter profiling and symbolic
analysis of data types and structure members using
DWARF symbols:
example% cc -c -O -xhwcprof -g -xdebugformat=dwarf
example.c
For more information on hardware counter-based profil-
ing, see the Performance Analyzer manual.
-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 inlined if any of the following apply:
o Optimization is set at -xO3 or higher
o Inlining the funciton is judged to be profitable and
safe
o The source for the function is in the file being
compiled or the function is in a file that was compiled
with -xipo[=1|2].
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.
See also -xldscope.
-xinstrument=[no%]datarace]
Specify this option to compile and instrument your pro-
gram for analysis by the Thread Analyzer. For more
information on the Thread Analyzer, see tha(1) for
details.
You can then use the Performance Analzyer to run the
instrumented program with collect -r races to create a
data-race-detection experiment. You can run the instru-
mented code standalone but it runs more slowly.
You can specify -xinstrument=no%datarace to turn off
preparation of source code for the thread analyzer.
This is the default.
It is illegal to specify -xinstrument without an argu-
ment.
If you compile and link in seperate steps, you must
specify -xinstrument=datarace in both the compilation
and linking steps.
This option defines the preprocessor token
__THA_NOTIFY. You can specify #ifdef __THA_NOTIFY to
guard calls to libtha(3) routines.
This option also sets -g.
-xipo[=n]
The compiler performs partial-program optimizations by
invoking an interprocedural analysis pass. It performs
optimizations across all object files in the link step,
and is not limited to just the source files on the com-
pile command. However, whole-program optimizations per-
formed with -xipo do not include assembly (.s) source
files.
You must specify -xipo both at compile time and at link
time. For a complete list of compiler options that
must be specified at both compile time and at link
time, see the C User's Guide.
Analysis and optimization is limited to the object
files compiled with -xipo, and does not extend to
object files or 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.
n is 0, 1, or 2. -xipo without any arguments is
equivalent to -xipo=1. -xipo=0 is the default setting
and turns off -xipo.
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.
Here are some important considerations for -xipo:
o It requires an optimization level of at least -xO4.
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 gen-
erate warnings about undefined symbols, but the inter-
procedural optimizations are performed because it is a
compile and link step.)
When Not To Use -xipo=2 Interprocedural Analysis
The compiler tries to perform whole-program analysis
and optimizations as it works with the set of object
files in the link step. The compiler makes the follow-
ing two assumptions for any function (or subroutine)
foo() defined in this set of object files:
(1) foo() is not called explicitly by another routine
that is defined outside this set of object files at
runtime.
(2) The calls to foo() from any routine in the set of
object files are not interposed upon by a different
version of foo() defined outside this set of object
files.
Do not compile with -xipo=2 if assumption (1) is not
true for the given application.
Do not compile with either -xipo=1 or -xipo=2 if
assumption (2) is not true.
As an example, consider interposing on the function
malloc() with your own version and compiling with
-xipo=2. Consequently, all the functions in any library
that reference malloc() that are linked with your code
have to be compiled with -xipo=2 also and their object
files need to participate in the link step. Since this
might not be possible for system libraries, do not com-
pile your version of malloc() with -xipo=2.
As another example, suppose that you build a shared
library with two external calls, foo() and bar() inside
two different source files. Furthermore, suppose that
bar() calls foo(). If there is a possibility that foo()
could be interposed at runtime, then do not compile the
source file for foo() or for bar() with -xipo=1 or
-xipo=2. Otherwise, foo() could be inlined into bar(),
which could cause incorrect results.
See also -xjobs and -xipo_archive
-xipo_archive[=a]
The -xipo_archive option enables the compiler to optim-
ize object files that are passed to the linker with
object files that were compiled with -xipo and that
reside in the archive library (.a) before producing an
executable. Any object files contained in the library
that were optimized during the compilation are replaced
with their optimized version.
a is one of the following:
writeback
The compiler optimizes object files passed to the
linker with object files compiled with -xipo that
reside in the archive library (.a) before producing an
executable. Any object files contained in the library
that were optimized during the compilation are
replaced with an optimized version.
For parallel links that use a common set of archive
libraries,each link should create its own copy of
archive libraries to be optimized before linking.
readonly
The compiler optimizes object files passed to the
linker with object files compiled with -xipo that
reside in the archive library (.a) before producing an
executable.
The option -xipo_archive=readonly enables cross-module
inlining and interprocedural data flow analysis of
object files in an archive library specified at link
time. However, it does not enable cross-module optim-
ization of the archive library's code except for code
that has been inserted into other modules by cross
module inlining.
To apply cross-module optimization to code within an
archive library, -xipo_archive=writeback is required.
Note that doing so modifies the contents of the
archive library from which the code was extracted.
none
Default. There is no processing of archive files. The
compiler does not apply cross-module inlining or other
cross-module optimizations to object files compiled
using -xipo and extracted from an archive library at
link time. To do that, both -xipo and either
-xipo_archive=readonly or -xipo_archive=writeback must
be specified at link time.
It is illegal to specify -xipo_archive without a flag.
-xjobs=n
Compile with multiple processors.
Specify the -xjobs option to set how many processes the
compiler creates to complete its work. This option can
reduce the build time on a multi-cpu machine.
Currently, -xjobs works only with the -xipo option.
When you specify -xjobs=n, the interprocedural optim-
izer uses n as the maximum number of code generator
instances it can invoke to compile different files.
Generally, a safe value for n is 1.5 multiplied by the
number of available processors. Using a value that is
many times the number of available processors can
degrade performance because of context switching over-
heads among spawned jobs. Also, using a very high
number can exhaust the limits of system resources such
as swap space.
You must always specify -xjobs with a value. Otherwise
an error diagnostic is issued and compilation aborts.
Multiple instances of -xjobs on the command line over-
ride each other until the rightmost instance is
reached.
The following example compiles more quickly on a system
with two processors than the same command without the
-xjobs option.
example% cc -xipo -xO4 -xjobs=3 t1.c t2.c t3.c
-xldscope={v}
Changes the default linker scoping for the definition
of extern symbols. Changing the default can result in
faster and safer shared libraries because the implemen-
tation will be better hidden.
v must be one of the following:
Value Meaning
global Global linker scoping is the least res-
trictive linker scoping. All references
to the symbol bind to the definition in
the first dynamic module that defines
the symbol. This linker scoping is the
current linker scoping for extern sym-
bols.
symbolic Symbolic linker scoping and is more res-
trictive than global linker scoping. All
references to the symbol from within the
dynamic module being linked bind to the
symbol defined within the module. Out-
side of the module, the symbol appears
as though it were global. This linker
scoping corresponds to the linker option
-Bsymbolic.
hidden Hidden linker scoping is more restric-
tive than symbolic and global linker
scoping. All references within a dynamic
module bind to a definition within that
module. The symbol will not be visible
outside of the module.
If you do not specify -xldscope, the compiler assumes
-xldscope=global. It is not legal to specify -xldscope
without any arguments. The compiler issues an error if
you specify -xldscope without an argument. Multiple
instances of this option on the command line override
each other until the rightmost instance is reached.
If you intend to allow a client to override a function
in a library, you must be sure that the function is not
generated inline during the library build. The compiler
inlines a function if you specify the function name
with -xinline, if you use #pragma inline, if you com-
pile at -xO4 or higher in which case inlining can hap-
pen automatically, if you use the inline specifier, or
if you are using cross-file optimization.
For example, suppose library ABC has a default alloca-
tor function that can be used by library clients, and
is also used internally in the library:
void* ABC_allocator(size_t size) { return malloc(size);
}
If you build the library at -xO4 or higher, the com-
piler inlines calls to ABC_allocator that occur in
library components. If a library client wants to
replace ABC_allocator with a customized version, the
replacement will not occur in library components that
called ABC_allocator. The final program will include
different versions of the function.
Library functions declared with the __hidden or __sym-
bolic specifiers can be generated inline when building
the library. They are not supposed to be overridden by
clients. For more information, see chapter 2 "C-
Compiler Implementation Specific Information" in the C
User's Guide.
Library functions declared with the __global specifier,
should not be declared inline, and should be protected
from inlining by use of the -xinline compiler option.
See Also
-xinline, -xO, ld(1).
-xlibmieee
Forces IEEE 754 style return values for math routines
in exceptional cases. In such cases, no exception mes-
sage 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.
However, these substitutions can cause the setting of
errno to become unreliable. If your program depends on
the value of errno, avoid this option. See the NOTES
section at the end of this man page for more informa-
tion.
-xlibmopt
Enables the compiler to use a library of optimized math
routines. You must use default rounding mode by speci-
fying -fround=nearest when you use this option.
The math routine library is optimized for performance
and usually generates faster code. The results may be
slightly different from those produced by the normal
math library. If so, they usually differ in the last
bit.
However, these substitutions can cause the setting of
errno to become unreliable. If your program depends on
the value of errno, avoid this option. See the NOTES
section at the end of this man page for more informa-
tion.
The order on the command line for this library option
is not significant.
Interactions:
This option is implied by the -fast option.
See also:
-fast
-xnolibmopt
-xlic_lib=sunperf
Links in the Sun Performance Library.
-xlicinfo
This option is silently ignored by the compiler.
-xlinkopt[=level]
(SPARC) Instructs the compiler to perform link-time
optimizations on relocatable object files.
The post-optimizer performs a number of advanced per-
formance optimizations on the binary object code at
link-time. The value level sets the level of optimiza-
tions performed, and must be 0, 1, or 2.
The optimization levels are:
0 The post-optimizer is disabled. (This is the
default.)
1 Perform optimizations based on control flow
analysis, including instruction cache coloring
and branch optimizations, at link time.
2 Perform additional data flow analysis, includ-
ing dead-code elimination and address computa-
tion simplification, at link time.
Specifying -xlinkopt without the level parameter
implies -xlinkopt=1.
These optimizations are performed at link time by
analyzing the object binary code. The object files are
not rewritten but the resulting executable code may
differ from the original object codes.
This option is most effective when you use it to com-
pile the whole program, and with profile feedback.
If you compile in separate steps, -xlinkopt must appear
on both compile and link steps:
example% cc -c -xlinkopt a.c b.c
example% cc -o myprog -xlinkopt=2 a.o
For a complete list of compiler options that must be
specified at both compile time and at link time, see
the C User's Guide.
Note that the level parameter is only used when the
compiler is linking. In the example above, the post-
optimization level used is 2 even though the object
binaries were compiled with an implied level of 1.
Do not use the -zcombreloc linker option when you com-
pile with -xlinkopt.
You must use -xlinkopt on at least some of the compila-
tion commands for -xlinkopt to be useful at link time.
The optimizer can still perform some limited optimiza-
tions on object binaries not compiled with -xlinkopt.
-xlinkopt optimizes code coming from static libraries
that appear on the compiler command line, but it skips
and does not optimize code coming from shared (dynamic)
libraries that appear on the command line. You can also
use -xlinkopt when you build shared libraries (compil-
ing with -G ).
The link-time post-optimizer is most effective when you
use it with run-time profile feedback. Profiling
reveals the most and least used parts of the code and
directs the optimizer to focus its effort accordingly.
This is particularly important with large applications
where optimal placement of code performed at link time
can reduce instruction cache misses. Typically, this
would be compiled as follows:
example% cc -o progt -xO5 -xprofile=collect:profdir file.c
example% progt
example% cc -o prog -xO5 -xprofile=use:profdir -xlinkopt file.c
For details on using profile feedback, see -xprofile.
Note that compiling with this option increases link
time slightly. Object file sizes also increase, but
the size of the executable remains the same. Compiling
with -xlinkopt and -g increases the size of the
excutable by including debugging information.
-xloopinfo
Shows which loops are parallelized and which are not.
This option is normally for use with the -xautopar
option.
-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).
-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
-xMD Generates makefile dependencies like -xM but compila-
tion continues. -xMD generates an output file for the
makefile-dependency information derived from the -o
output filename, if specified, or the input source
filename, replacing (or adding) the filename suffix
with .d . If you specify -xMD and -xMF, the preproces-
sor writes all makefile dependency information to the
file specified with -xMF. Compiling with -xMD -xMF or
-xMD -o filename with more than one source file is not
allowed and generates an error. The dependency file is
overwritten if it already exists.
-xMF filename
Use this option to specify a file for the makefile-
dependency output. There is no way to specify indivi-
dual filenames for multiple input files with -xMF on
one command line. Compiling with -xMD -xMF or -xMMD
-xMF with more than one source file is not allowed and
generates an error. The dependency file is overwritten
if it already exists.
-xMMD
Use this option to generate makefile dependencies
excluding system header files. This is the same func-
tionality as -xM1, but compilation continues. -xMMD
generates an output file for the makefile-dependency
information derived from the -o output filename, if
specified, or the input source filename, replacing (or
adding) the filename suffix with .d . If you specify
-xMF, the compiler uses the filename you provide
instead. Compiling with -xMMD -xMF or -xMMD -o
filename with more than one source file is not allowed
and generates an error. The dependency file is
overwritten if it already exists.
-xMerge
Directs cc to merge the data segment with the text seg-
ment. Data initialized in the object file produced by
this compilation is read-only and (unless linked with
ld -N) is shared between processes.
-xMerge -ztext -xprofile=collect should not be used
together. While -xMerge forces statically initialized
data into read-only storage, -ztext prohibits
position-dependent symbol relocations in read-only
storage, and -xprofile=collect generates statically
initialized, position-dependent symbol relocations in
writable storage.
-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.
If you specify both -xO and -xmaxopt, the optimization
level set with -xO must not exceed the -xmaxopt value.
-xmemalign=ab
(SPARC) Use the -xmemalign option to control the
assumptions the compiler makes about the alignment of
data. By controlling the code generated for potentially
misaligned memory accesses and by controlling program
behavior in the event of a misaligned access, you can
more easily port your code to SPARC.
Specify the maximum assumed memory alignment and
behavior of misaligned data accesses. There must be a
value for both a (alignment) and b (behavior). a speci-
fies the maximum assumed memory alignment and b speci-
fies the behavior for misaligned memory 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.
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.
If actual data alignment at runtime is less than the
specified alignment, the misaligned access attempt (a
memory read or write) generates a trap. The two possi-
ble responses to the trap are as follows:
o The OS converts the trap to a SIGBUS signal. If the
program does not catch the signal, the program aborts.
Even if the program catches the signal, the misaligned
access attempt will not have succeeded.
o The OS handles the trap by interpreting the
misaligned access and returning control to the program
as if the access had succeeded normally.
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 For variants of -xarch=v9 only. Raise signal
SIGBUS for alignments less than or equal to
4, otherwise interpret access and continue
execution. For all other -xarch values, the f
flag is equivalent to i.
You must also specify -xmemalign whenever you want to
link to an object file that was compiled with the value
of b set to either i or f. For a complete list of com-
piler options that must be specified at both compile
time and at link time, see the C User's Guide.
Defaults
The default for all SPARC v9 architectures is
-xmemalign=8s. Specifying -xmemalign is equivalent to
specifying -xmemalign=1i.
-xmodel=[a]
(x86) The -xmodel option determines the data address
model for shared objects on the Solaris x64 platforms
and should only be specified for the compilation of
such objects.
This option is valid only when -m64 is also specified
on 64-bit enabled x64 processors.
a is one of the following:
small
This option generates code for the small model in
which the virtual address of code executed is
known at link time and all symbols are known to be
located in the virtual addresses in the range from
0 to 2^31 - 2^24 - 1.
kernel
Generates code for the kernel model in which all
symbols are defined to be in the range from 2^64 -
2^31 to 2^64 - 2^24.
medium
Generates code for the medium model in which no
assumptions are made about the range of symbolic
references to data sections. Size and address of
the text section have the same limits as the small
code model. Applications with large amounts of
static data might require -xmodel=medium when com-
piling with -m64.
This option is not cumulative so the compiler sets the
model value according to the rightmost instance of
-xmodel on the command-line.
If you do not specify -xmodel, the compiler assumes
-xmodel=small. Specifying -xmodel without an argument
is an error.
It is not necessary to compile all translation units
with this option. You can compile select files as long
as you ensure the object you are accessing is within
reach.
Be aware that not all Linux system support the medium
model.
-xnolib
Does not link any libraries by default; that is, no -l
options are passed to the linker ld. Normally, the cc
driver passes -lc to ld.
When you use -xnolib, you must pass all -l options
explicitly yourself.
-xnolibmil
Does not inline math library routines. Use -xnolibmil
after the -fast option:
cc -fast -xnolibmil ...
-xnolibmopt
Do not link with the optimized math routine library by
turning off any previously specified -xlibmopt options.
Use this option after the -fast option on the command
line, as in:
example% cc -fast -xnolibmopt ...
-xnorunpath
Do not build a runtime search path for shared libraries
into the executable.
Normally cc does not pass any -R path to the linker.
There are a few options that do pass -R path to the
linker such as -xliclib=sunperf and -xopenmp. The
-xnorunpath option can be used to prevent this.
This option is recommended for building executables
that will be shipped to customers who may have a dif-
ferent path for the shared libraries that are used by
the program.
-xOn Specifies optimization level (n). (Note the uppercase
letter O, followed by a digit 1, 2, 3, 4, or 5)
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
actual optimizations performed by the compiler at each
level may change with each compiler release. They are
only summarized here.
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:
-xO1 Do only the basic local optimizations.
-xO2 Do basic local and global optimization. This level
usually gives minimum code size.
-xO3 Adds global optimizations at the function level.
In general, this level, and -xO4, usually result
in the minimum code size when used with the
-xspace option.
-xO4 Adds automatic inlining of functions in the same
file. In general, -xO4 results in larger code
unless combined with -xspace.
See -inline to control which routines are inlined.
-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.
The default is no optimization. However, this is only
possible if you do not specify an optimization level.
If you specify an optimization level, there is no
option for turning optimization off.
If you are trying to avoid setting an optimization
level, be sure not to specify any option that implies
an optimization level. For example, -fast is a macro
option that sets optimization at -xO5. All other
options that imply an optimization level give a warning
message that optimization has been set. The only way to
compile without any optimization is to delete all
options from the command line or make file that specify
an optimization level.
If you use -g 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 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.
If you specify both -xO and -xmaxopt, the optimization
level set with -xO must not exceed the -xmaxopt value.
See also:
-xldscope, -fast, -xprofile=p, csh(1) man page
Performance Analyzer discusses the effects of the dif-
ferent levels of optimization on the Analyzer's data.
-xopenmp[=i]
Use the -xopenmp option to enable explicit paralleliza-
tion with OpenMP directives. To run a parallelized
program in a multithreaded environment, you must set
the OMP_NUM_THREADS environment variable prior to exe-
cution. See the OpenMP API User's Guide for more infor-
mation.
To enable nested parallelism, you must set the
OMP_NESTED environment variable to TRUE. Nested paral-
lelism is disabled by default. See the Solaris Studio
OpenMP API User's Guide for details.
The following table details the -xopenmp values:
Value Meaning
parallel Enables recognition of OpenMP pragmas. The
optimization level under -xopenmp=parallel is
-x03. The compiler changes the optimization
level to -x03 if necessary and issues a warn-
ing. This flag also defines the preprocessor
token _OPENMP.
The _OPENMP token is defined to have the
decimal value yyyymm where yyyy and mm are the
year and month designations of the version of
the OpenMP API that the implementation sup-
ports. Refer to the Solaris Studio OpenMP API
User's Guide for the value of the _OPENMP
macro for a particular release.
noopt Enables recognition of OpenMP pragmas. The
compiler does not raise the optimization level
if it is lower than -O3. If you explicitly set
the optimization lower than -O3, as in cc -O2
-xopenmp=noopt, the compiler issues an error.
If you do not specify an optimization level
with -xopenmp=noopt, the OpenMP pragmas are
recognized, the program is parallelized
accordingly, but no optimization is done. This
flag also defines the preprocessor token
_OPENMP.
none This flag is the default and does not enable
recognition of OpenMP pragmas, makes no change
to the optimization level of your program, and
does not predefine any preprocessor tokens.
If you specify -xopenmp, but do not include an argu-
ment, the compiler assumes -xopenmp=parallel. This
default could change in future releases. If you do not
specify -xopenmp, the compiler assumes -xopenmp=none.
If you are debugging an OpenMP program with dbx, com-
pile with -g -xopenmp=noopt so you can breakpoint
within parallel regions and display the contents of
variables.
The default for -xopenmp might change in future
releases. You can avoid warning messages by explicitly
specifying an appropriate optimization.
If you compile and link in seperate steps, specify
-xopenmp in both the compilation step and the link
step. This is important if you are building a shared
object. The compiler which was used to compile the exe-
cutable must not be any older than the compiler that
built the .so with -xopenmp. This is especially impor-
tant when you compile libraries that contain OpenMP
directives.
Make sure that the latest patch of the OpenMP runtime
library, libmtsk.so, is installed on the system for
best performance.
For information that is specific to the C implementa-
tion of OpenMP, see the C User's Guide.
For a complete summary of the OpenMP Fortran 95, C, and
C++ application program interface (API) for building
multiprocessing applications, see the OpenMP API User's
Guide.
-xP Performs only syntax and semantic checking on the
source file in order to print prototypes for all K&R C
functions. This option does not produce any object or
executable code.
-xpagesize=n
Set the preferred page size for the stack and the heap.
The n value must be one of the following:
On SPARC: /br
4k 8K 64K 512K 2M 4M 32M 256M 2G 16G or default.
On x86/x64 platforms:
4K 2M 4M 1G or default.
You must specify a valid page size for the target plat-
form. If you do not specify a valid pagesize, the
request is silently ignored at run-time.
Note: 1G support on x86/x64 was added with Solaris 10
5/08. Compiler support on x86/x64 was introduced in Sun
Studio 12 patch 126498-02.
Use the getpagesize(3C) command on the Solaris operat-
ing environment to determine the number of bytes in a
page. The Solaris operating environment offers no
guarantee that the page size request will be honored.
You can use pmap(1) or meminfo(2) to determine page
size of the target platform.
The -xpagesize option has no effect unless you use it
at compile time and at link time. For a complete list
of compiler options that must be specified at both com-
pile time and at link time, see the C User's Guide.
If you specify -xpagesize=default, the operating
environment sets the page size.
Compiling with this option has the same effect as set-
ting the LD_PRELOAD environment variable to mpss.so.1
with the equivalent options, or running the Solaris
command ppgsz(1) with the equivalent options before
running the program. See the Solaris man pages for
details.
This option is a macro for -xpagesize_heap and
-xpagesize_stack. These two options accept the same
arguments as -xpagesize. You can set them both with the
same value by specifying -xpagesize=n or you can
specify them individually with different values.
-xpagesize_heap=n
Set the page size in memory for the heap.
The n value is the same as for -xpagesize.
You must specify a valid page size for the target plat-
form. If you do not specify a valid pagesize, the
request is silently ignored at run-time.
See -xpagesize for details.
-xpagesize_stack=n
Set the page size in memory for the stack.
The n value is the same as described for -xpagesize.
You must specify a valid page size for the Solaris
operating environment on the target platform. If you do
not specify a valid pagesize, the request is silently
ignored at run-time.
See -xpagesize for details.
-xpec[={yes|no}]
(Solaris) Generates a Portable Executable Code (PEC)
binary.
PEC binaries can be used with the Automatic Tuning Sys-
tem (ATS) which works by rebuilding the compiled PEC
binary for tuning and troubleshooting - the original
source code is not required. More information about the
ATS is available at
http://cooltools.sunsource.net/ats/index.html.
A binary that is built with -xpec is usually five to
ten times larger than if it is built without -xpec.
If you do not specify -xpec, the compiler sets it to
-xpec=no. If you specify -xpec, but do not supply a
flag, the compiler sets it to -xpec=yes.
-xpch=v
This compiler option activates the precompiled-header
feature. v can be auto, autofirst,
collect:pch_filename, or use:pch_filename. You can take
advantage of this feature through the -xpch and
-xpchstop options in combination with the #pragma
hdrstop directive.
Use the -xpch option to create a precompiled-header
file and improve your compilation time. The
precompiled-header file is designed to reduce compile
time for applications whose source files share a common
set of include files containing a large amount of
source code. A precompiled header works by collecting
information about a sequence of header files from one
source file, and then using that information when
recompiling that source file, and when compiling other
source files that have the same sequence of headers.
Creating a Precompiled-Header File Automatically
You can let the compiler generate the precompiled-
header file for you automatically. Choose between one
of the following two ways to do this. One way is for
the compiler to create the precompiled-header file from
the first include file it finds in the source file. The
other way is for the compiler to select from the set of
include files found in the source file starting with
the first include file and extending through a well-
defined point that determines which include file is the
last one. Use one of the following two flags to deter-
mine which method the compiler uses to automatically
generate a precompiled header:
-xpch=auto
The contents of the precompiled-header file is
based on the longest viable prefix (see the fol-
lowing section for an explanation of how a viable
prefix is identified) that the compiler finds in
the source file. This flag produces a precompiled
header file that consists of the largest possible
number of header files.
-xpch=autofirst
This flag produces a precompiled-header file that
contains only the first header found in the source
file.
Creating the Precompiled-Header File Manually
If you decide to create your precompiled-header file
manually, you must start by first using -xpch and
specifying the collect mode. The compilation command
that specifies -xpch=collect must only specify one
source file. In the following example, the -xpch option
creates a precompiled-header file called myheader.cpch
based on the source file a.c:
cc -xpch=collect:myheader a.c
A valid precompiled-header filename always has the suf-
fix .cpch. When you specify pch_filename, you can add
the suffix or let the compiler add it for you. For
example, if you specify cc -xpch=collect:foo a.c, the
precompiled-header file is called foo.cpch.
How the Compiler Handles an Existing Precompiled-Header
File
If the compiler cannot use the precompiled-header file,
under -xpch=auto and -xpch=autofirst, it will generate
a new precompiled-header file. If the compiler cannot
use the precompiled-header file under -xpch=use, a
warning is issued and the compilation is done using the
real headers.
Directing the Compiler to Use a Specific Precompiled-
Header File
You can also direct the compiler to use a specific
precompiled header. Specify -xpch=use:pch_filename to
do this. You can specify any number of source files
with the same sequence of include files as the source
file used to create the precompiled-header file. For
example, your command in use mode could look like this:
cc -xpch=use:foo.cpch foo.c bar.c foobar.c
You should only use an existing precompiled-header file
if the following is true. If any of the following is
not true, you should recreate the precompiled-header
file:
- The compiler that you are using to access the
precompiled-header file is the same as the compiler
that created the precompiled-header file. A
precompiled-header file created by one version of the
compiler may not be usable by another version of the
compiler.
- Except for the -xpch option, the compiler options you
specify with -xpch=use must match the options that were
specified when the precompiled-header file was created.
- The set of included headers you specify with
-xpch=use is identical to the set of headers that were
specified when the precompiled header was created.
- The contents of the included headers that you specify
with -xpch=use is identical to the contents of the
included headers that were specified when the precom-
piled header was created.
- The current directory (that is, the directory in
which the compilation is occurring and attempting to
use a given precompiled-header file) is the same as the
directory in which the precompiled-header file was
created.
- The initial sequence of pre-processing directives,
including #include directives, in the file you speci-
fied with -xpch=collect are the same as the sequence of
pre-processing directives in the files you specify with
-xpch=use.
The Viable Prefix
In order to share a precompiled-header file across mul-
tiple source files, those source files must share a
common set of include files as their initial sequence
of tokens. A token is a keyword, name or punctuation
mark. Comments and code that is excluded by #if direc-
tives are not recognized by the compiler as tokens.
This initial sequence of tokens is known as the viable
prefix. In other words, the viable prefix is the top
portion of the source file that is common to all source
files. The compiler uses this viable prefix as the
basis for creating a precompiled-header file and
thereby determining which header files from the source
are pre-compiled.
The viable prefix that the compiler finds during the
current compilation must match the viable prefix that
it used to create the precompiled-header file. In other
words, the viable prefix must be interpreted con-
sistently by the compiler across all the source files
that use the same precompiled-header file.
The viable prefix consists of any of the following
pre-processor directives:
#include
#if/ifdef/ifndef/else/elif/endif
#define/undef
#ident
#pragma
Any of these may reference macros. The #else, #elif,
and #endif directives must match within the viable
prefix. Comments are ignored.
The compiler determines the end point of the viable
prefix automatically when you specify -xpch=auto or
-xpch=autofirst and is defined as follows. For
-xpch=collect or -xpch=use, the viable prefix ends with
a #pragma hdrstop.
- The first declaration/definition statement
- The first #line directive
- A #pragma hdrstop directive
- After the named include file if you specify
-xpch=auto and -xpchstop
- The first include file if you specify -xpch=autofirst
Note: An end point within a conditional statement gen-
erates a warning and disables the automatic creation of
a precompiled-header file. Also, if you specify both
the #pragma hdrstop and the -xpchstop option, then the
compiler uses the earlier of the two stop points to
terminate the viable prefix.
Within the viable prefix of each file that shares a
precompiled-header file, each corresponding #define and
#undef directive must reference the same symbol (in the
case of #define, each one must reference the same
value). Their order of appearance within each viable
prefix must be the same as well. Each corresponding
pragma must also be the same and appear in the same
order across all the files sharing a precompiled
header.
Screening Header Files for Problems
What makes a header file precompileable? A header file
is precompileable when it is interpreted consistently
across different source files. Specifically, when it
contains only complete declarations. That is, a
declaration in any one file must stand alone as a valid
declaration. Incomplete type declarations, such as
struct S;, are valid declarations. The complete type
declaration can appear in some other file. Consider
these example header files:
file a.h
struct S {
#include "x.h" /* not allowed */
};
file b.h
struct T; // ok, complete declaration
struct S {
int i;
[end of file, continued in another file] /* not allowed
*/
A header file that is incorporated into a precompiled-
header file must not violate the following. The results
of compiling a program that violate any of these con-
straints is undefined.
- The header file must not use __DATE__ and __TIME__.
- The header file must not contain #pragma hdrstop.
The Precompiled-Header File Cache
When the compiler creates a precompiled-header file
automatically, the compiler writes it to the
SunWS_cache directory. This directory always resides in
the location where the object file is created. Updates
to the file are preformed under a lock so that it works
properly under dmake.
If you need to force the compiler to rebuild
automatically-generated precompiled-header files, you
can clear the precompiled-header file cache-directory
with the CCadmin tool. See the CCadmin(1) man page for
more information.
Warnings
o Do not specify conflicting -xpch flags on the command
line. For example, specifying both -xpch=collect and
-xpch=auto, or specifying both -xpch=autofirst with
-xpchstop=<include> generates an error.
o If you specify -xpch=autofirst or you specify
-xpch=auto without -xpchstop, any declaration, defini-
tion, or #line directive that appears prior to the
first include file, or appears prior to the include
file that is specified with -xpchstop for -xpch=auto,
generates a warning and disables the automatic genera-
tion of the precompiled-header file.
o A #pragma hdrstop before the first include file under
-xpch=autofirst or -xpch=auto disables the automatic
generation of the precompiled-header file.
Precompiled-Header File Dependencies and make Files
The compiler generates dependency information for
precompiled-header files when you specify
-xpch=collect. You need to create the appropriate rules
in your make files to take advantage of these dependen-
cies. Consider this sample make file:
%.o : %.c shared.cpch
$(cc) -xpch=use:shared -xpchstop=foo.h -c $<
default : a.out
foo.o + shared.cpch : foo.c
$(cc) -xpch=collect:shared -xpchstop=foo.h foo.c -c
a.out : foo.o bar.o foobar.o
$(c) foo.o bar.o foobar.o
clean :
rm -f *.o shared.cpch .make.state a.out
These make rules, along with the dependencies generated
by the compiler, force a manually created precompiled-
header file to be recreated if any source file you used
with -xpch=collect, or any of the headers that are part
of the precompiled-header file, have changed. This
prevents the use of an out of date precompiled-header
file.
For -xpch=auto or -xpch=autofirst, you do not have to
create any additional make rules in your makefiles.
See Also: -xpchstop
-xpchstop=[file|<include>]
where file is the last include file to be considered in
creating a precompiled-header file. Using -xpchstop on
the command line is equivalent to placing a hdrstop
pragma (See the C User's Guide) after the first
include-directive that references file in each of the
source files that you specify with the cc command.
Use -xpchstop=<include> with -xpch=auto to create a
precompiled-header file that is based on header files
up through and including <include>. This flag overrides
the default -xpch=auto behavior of using all header
files contained in the entire viable prefix.
See Also: -xpch, -xhelp=readme
-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).
Note: There is no advantage for -xprofile if you
specify -xpg. The two do not prepare or use data
provided by the other.
Profiles are generated by using prof or gprof on 64 bit
Solaris platforms or just gprof on 32 bit Solaris plat-
forms include approximate user CPU times. These times
are derived from PC sample data (see pcsample(2)) for
routines in the main executable and routines in shared
libraries specified as linker arguments when the exe-
cutable is linked. Other shared libraries (libraries
opened after process startup using dlopen(3DL)) are not
profiled.
On 32 bit Solaris systems, profiles generated using
prof(1) are limited to routines in the executable. 32
bit shared libraries can be profiled by linking the
executable with -xpg and using gprof(1).
The Solaris 10 software does not include system
libraries compiled with -p. As a result, profiles col-
lected on Solaris 10 platforms do not include call
counts for system library routines.
If you specify -xpg at compile time, you must also
specify it at link time. See the C User's Guide for a
complete list of options that must be specified at both
compile time and link time.
-xprefetch[=val[,val]]
Enables prefetch instructions on those architectures
that support prefetch. You must compile withoptimiza-
tion level 3 orgreater with this option.
val must be one of the following:
auto Enable automatic generation of prefetch
instructions.
no%auto Disable automatic generation
explicit Enable explicit prefetch macros
Explicit prefetching should only be used
under special circumstances that are
supported by measurements.
no%explicit Disable explicit prefetch macros
latx:factor (SPARC) You can only combine this option
with -xprefetch=auto. 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 pre-
fetch 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 entirely 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 Obsolete - do not use. Use
-xprefetch=auto,explicit instead.
no Obsolete - do not use. Use
-xprefetch=no%auto,no%explicit instead.
Defaults
If you do not specify -xprefetch, the default is now
-xprefetch=auto,explicit, not -xprefetch=yes. If you
specify -xprefetch without a value, it is also
equivalent to -xprefetch=auto,explicit. This change
adversely affects applications that have essentially
non-linear memory access patterns. To disable the
change, specify -xprefetch=no%auto,no%explicit.
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_auto_type=[a]
Where a is [no%]indirect_array_access.
Use this option to determine whether or not the com-
piler generates indirect prefetches for the loops indi-
cated by the option -xprefetch_level in the same
fashion the prefetches for direct memory accesses are
generated.
If you do not specify a setting for
-xprefetch_auto_type, the compiler sets it to
-xprefetch_auto_type=no%indirect_array_access.
Options such as -xdepend, -xrestrict, and -xalias_level
can affect the aggressiveness of computing the indirect
prefetch candidates and therefore the aggressiveness of
the automatic indirect prefetch insertion due to better
memory alias disambiguation information.
-xprefetch_level=l
Use this option to control the aggressiveness of
automatic insertion of prefetch instructions as deter-
mined with -xprefetch=auto.
l must be 1, 2, or 3.
Prefetch levels 2 and 3 may not be effective on older
SPARC and x86 platforms.
-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.
You must compile with optimization level 3 or greater
and generate code for a platform that supports pre-
fetch.
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[:profdir], use[:profdir], or
tcov[:profdir]
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. Profile
collection is safe for multithreaded applications. That
is, profiling a program that does its own multitasking
( -mt ) produces accurate results. This option is only
valid when you specify -xO2 or greater level of optimi-
zation.
If compilation and linking are performed in separate
steps, the same -xprofile option must appear on the
compile as well as the link step. See the C User's
Guide for a complete list of options that must be
specified at both compile time and link time.
collect[:profdir]
Collects and saves execution frequency for later
use by the optimizer with -xprofile=use. The com-
piler generates code to measure statement
execution-frequency.
-xMerge -ztext -xprofile=collect should not be
used together. While -xMerge forces statically
initialized data into read-only storage, -ztext
prohibits position-dependent symbol relocations in
read-only storage, and -xprofile=collect generates
statically initialized, position-dependent symbol
relocations in writable storage.
The profile directory name profdir, if specified,
is the pathname of the directory where profile
data are to be stored when a program or shared
library containing the profiled object code is
executed. If the pathname is not absolute, it is
interpreted relative to the current working direc-
tory when the program is compiled with the option
-xprofile=use:profdir.
If no profile directory name is specified, profile
data are stored in a directory named
program.profile where program is the basename of
the profiled process's main program.
Example[1]: to collect and use profile data in
the directory myprof.profile located in the same
directory where the program is built:
cc -xprofile=collect:myprof.profile -xO5 prog.c -o prog
./prog
cc -xprofile=use:myprof.profile -xO5 prog.c -o prog
Example[2]: to collect profile data in the direc-
tory /bench/myprof.profile and later use the col-
lected profile data in a feedback compilation at
optimization level -xO5:
cc -xprofile=collect:/bench/myprof.profile -xO5 prog.c -o prog
...run prog from multiple locations...
cc -xprofile=use:/bench/myprof.profile -xO5 prog.c -o prog
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 the directory
profdir.profile in the current directory, where
profdir is the name of the executable or the name
specified in the -xprofile=collect:profdir flag.
-xprofile does not append .profile to profdir if
profdir already ends in .profile. If you run the
program several times, the execution frequency
data accumulates in the profdir.profile directory;
that is, output from prior executions is not lost.
If you are compiling and linking in separate
steps, make sure that any object files compiled
with -xprofile=collect are also linked with
-xprofile=collect. For a complete list of compiler
options that must be specified at both compile
time and at link time, see the C User's Guide.
See also the ENVIRONMENT section of this man page
below for descriptions of environment variables
that control asynchronous profile collections.
use[:profdir]
Uses execution frequency data collected from code
compiled with -xprofile=collect[:profdir] to
optimize for the work performed when the profiled
code was executed. profdir is the pathname of a
directory containing profile data collected by
running a program that was compiled with
-xprofile=collect[:profdir].
The profdir is optional. If profdir is not speci-
fied, the name of the executible binary is used.
a.out is used if -o is not specified. The compiler
looks for profdir.profile/feedback, or
a.out.profile/feedback without profdir specified.
For example:
cc -xprofile=collect -o myexe prog.c
cc -xprofile=use:myexe -xO5 -o myexe prog.c
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:profdir, the
same profile directory name profdir must be used
in the optimizing compilation:
-xprofile=use:profdir.
See also -xprofile_ircache for speeding up compi-
lation between collect and use phases.
tcov[:profdir]
Instrument object files for basic block coverage
analysis using tcov(1).
If the optional :profdir argument is specified,
the compiler will create a profile directory at
the specified location. The data stored in the
profile directory can be used either by tcov(1) or
by the compiler with -xprofile=use:profdir .
If the optional :profdir argument is omitted, a
profile directory will be created when the pro-
filed program is executed. The data stored in the
profile directory can only be used by tcov(1).
The location of the profile directory can be con-
trolled using environment variables SUN_PROFDATA
and SUN_PROFDATA_DIR. See ENVIRONMENT below.
If the location specified by :profdir is not an
absolute pathname, it is interpreted at compila-
tion time relative to the directory in which the
current object file is to be written. If :profdir
is specified for any object file, the same loca-
tion must be specified for all object files in the
same program. The directory whose location is
specified by :profdir must be accessible from all
machines where the profiled program is to be exe-
cuted. The profile directory should not be
deleted until its contents are no longer needed,
because data stored there by the compiler cannot
be restored except by recompilation.
Example 1: if object files for one or more pro-
grams are compiled with
-xprofile=tcov:/test/profdata, a directory named
/test/profdata.profile will be created by the com-
piler and used to store data describing the pro-
filed object files. The same directory will also
be used at execution time to store execution data
associated with the profiled object files.
Example 2: if a program named "myprog" is compiled
with -xprofile=tcov and executed in the directory
/home/joe, the directory /home/joe/myprog.profile
will be created at run time and used to store run-
time profile data.
-xprofile_ircache[=path]
(SPARC) Use -xprofile_ircache[=path] with
-xprofile=collect|use to improve compilation time dur-
ing the use phase by reusing compilation data saved
from the collect phase.
With large programs, compilation time in the use phase
can improve significantly because the intermediate data
is saved. Note that the saved data could increase disk
space requirements considerably.
When you use -xprofile_ircache[=path], path overrides
the location where the cached files are saved. By
default, these files are saved in the same directory as
the object file. Specifying a path is useful when the
collect and use phases happen in two different direc-
tories.
Here's a typical sequence of commands:
example% cc -xO5 -xprofile=collect -xprofile_ircache
t1.c t2.c
example% a.out // run collects feedback data
example% cc -xO5 -xprofile=use -xprofile_ircache t1.c
t2.c
-xprofile_pathmap=collect_prefix:use_prefix
(SPARC) Use the -xprofile_pathmap option when you are
also specifying the -xprofile=use command. Use
-xprofile_pathmap when both of the following are true
and the compiler is unable to find profile data for an
object file that is compiled with -xprofile=use.
o You are compiling the object file with -xprofile=use
in a directory that is different from the directory
in which the object file was previously compiled
with -xprofile=collect.
o Your object files share a common basename in the profile
but are distinguished from each other by their loca-
tion in different directories.
The collect-prefix is the prefix of the UNIX pathname
of a directory tree in which object files were compiled
using -xprofile=collect.
The use-prefix is the prefix of the UNIX pathname of a
directory tree in which object files are to be compiled
using -xprofile=use.
If you specify multiple instances of -xprofile_pathmap,
the compiler processes them in the order of their
occurrence. Each use-prefix specified by an instance
of -xprofile_pathmap is compared with the object file
pathname until either a matching use-prefix is identi-
fied or the last specified use-prefix is found not to
match the object file pathname.
-xreduction
Analyzes loops for reduction in automatic paralleliza-
tion. This option is valid only if -xautopar 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.
r is a comma-separated list of one or more of the fol-
lowing suboptions: appl, float, frameptr.
Prefixing a suboption with no% disables that suboption.
Example: -xregs=appl,no%float
Note that -xregs suboptions are restricted to specific
hardware platforms.
appl (SPARC)
Allow the compiler to generate code using the
application registers as scratch registers.
The application registers are:
g2, g3, g4 (on 32-bit platforms)
g2, g3 (on 64-bit platforms)
It is strongly recommended that all system
software and libraries be compiled using
-xregs=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.
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.
For more information on SPARC instruction
sets, see -xarch.
float (SPARC)
Allow the compiler to generate code by using
the floating-point registers as scratch regis-
ters for integer values. Use of floating-point
values may use these registers regardless of
this option. To generate binary code free of
all references to floating point registers,
use -xregs=no%float and make sure your source
code does not in any way use floating point
types.
frameptr (x86)
Allow the compiler to use the frame-pointer
register (%ebp on IA32, %rbp on x86 64-bit
platforms) as a general-purpose register.
The default is -xregs=no%frameptr.
The C++ compiler ignores -xregs=frameptr
unless exceptions are also disabled with
-features=no%except. Note also that
-xregs=frameptr is part of -fast, but is
ignored by the C++ compiler unless
-features=no%except is also specified.
With -xregs=frameptr the compiler is free to
use the frame-pointer register to improve pro-
gram performance. However, some features of
the debugger and performance measurement tools
may be limited. Stack tracing, debuggers, and
performance analyzers cannot report on func-
tions compiled with -xregs=frameptr.
Also, C++ calls to Posix pthread_cancel() will
fail trying to find cleanup handlers.
Mixed C, Fortran, and C++ code should not be
compiled with -xregs=frameptr if a C++ func-
tion, called directly or indirectly from a C
or Fortran function, can throw an exception.
If compiling such mixed source code with
-fast, add -xregs=no%frameptr after the -fast
option on the command line.
With more available registers on 64-bit plat-
forms, compiling with -xregs=frameptr has a
better chance of improving 32-bit code perfor-
mance than 64-bit code.
Note: -xregs=frameptr is ignored and a warning
is issued by the compiler if you also specify
-xpg.
The SPARC default is -xregs=appl,float.
The x86 default is -xregs=no%frameptr.
-xregs=frameptr is included in the expansion of -fast
on x86.
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 are aware of these
register assignments.
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]
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 optimiza-
tion 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.
See Also: 'Restricted Pointers' in the C User's Guide
-xs Allows debugging by dbx without object files.
This option causes all the debug information to be
copied into the executable. This has little impact on
dbx performance or the run-time performance of the pro-
gram, but it does take more disk space.
-xsafe=mem
(SPARC) 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.
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.
This option takes effect only when used with optimiza-
tion level -xO5 and one of the following -xarch values:
sparc, sparcvis, sparcvis2, or sparcvis3 for both -m32
and -m64.
-xsb Deprecated - do not use. The source browser functional-
ity is obsolete.
-xsbfast
Deprecated - do not use. The source browser functional-
ity is obsolete.
-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
This option may be deprecated in a future release, use
-features=[no%]conststrings instead.
The -xstrconst option inserts string literals into the
read-only data section of the text segment instead of
the default data segment. Duplicate strings will be
eliminated and the remaining copy shared amongst refer-
ences in the code.
-xtarget=t
Specifies the target system for the instruction set and
optimization.
t must be one of: native, native64, generic, generic64,
or 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. See the -xdryrun explanation
for details on how to see the expansion of macro
options such as -xtarget.
-xtarget=native is equivalent to -m32, -xarch=native,
-xchip=native, -xcache=native.
-xtarget=native64 is equivalent to -m64,
-xarch=native64, -xchip=native64, -xcache=native.
-xtarget=generic is equivalent to -m32,
-xarch=generic, -xchip=generic, -xcache=generic.
-xtarget=generic64 is equivalent to -m64,
-xarch=generic64, -xchip=generic64, -xcache=generic.
The -fast macro option includes -xtarger=native in its
expansion.
The -xtarget command itself is a macro option which
acts like a macro expansion on the command line for the
-xarch -xchip and -xcache options. Therefore, you can
override any of the expanded options by following
-xtarget with the desired option. Use the -xdryrun
option to determine the expansion of -xtarget=native on
a running system.
Note: The expansion of -xtarget for a specific host
platform might not expand to the same -xarch, -xchip,
or -xcache settings as -xtarget=native when compiling
on that platform.
On SPARC platforms:
Compiling for 64-bit Solaris software on SPARC or
UltraSPARC V9 is indicated by the -m64 option. If you
specify -xtarget with a flag other than native64 or
generic64, you must also specify the -m64 option as
follows:
-xtarget=ultra4 ... -m64
otherwise the compiler uses a 32-bit memory model.
Value Meaning
native Set the parameters for the best performance
on the host environment (assumes a 32-bit
architecture).
native64 Set the parameters for the best performance
on the host environment (assumes a 64-bit
architecture).
generic This is the default and sets the parameters
for the best performance over most 32-bit
platform architectures.
generic64 Set the parameters for the best performance
over most 64-bit platform architectures.
system-name
Get the best performance for the specified
system.
Valid SPARC platform names are shown below.
Commonly used platform names:
ultra, ultra2, ultra2i, ultra1/140,
ultra1/170, ultra1/200, ultra2/1170,
ultra2/1200, ultra2/1300, ultra2/2170,
ultra2/2200, ultra2/2300, ultra2e, ultra2i,
ultra3, ultra3cu, ultra3i, ultra4,
ultra4plus, ultraT1, ultraT2, ultraT2plus,
ultraT3, sparc64vi, sparc64vii.
On x86 platforms
Compiling for 64-bit Solaris software on 64-bit x86
platforms is indicated by the -m64 option. If you
specify -xtarget with a flag other than native64 or
generic64, you must also specify the -m64 option as
follows:
-xtarget=opteron ... -m64
otherwise the compiler uses a 32-bit memory model.
Value Meaning
o generic This is the default and yields the best per-
formance for generic architecture, chip and
cache on most 32-bit systems.
o generic64
Gets the best performance for generic archi-
tecture, chip and cache on most 64-bit sys-
tems.
o native The compiler generates code for the best per-
formance on the host system. This flag deter-
mines the available architecture, chip, and
cache properties of the machine on which the
compiler is running and assumes a 32-bit
architecture.
o native64
Set the parameters for the best performance
on the host system. This flag determines the
available architecture, chip, and cache pro-
perties of the machine on which the compiler
is running and assumes a 64-bit architecture.
o barcelona
Directs the compiler to generate code for the
best performance on the AMD Barcelona
microprocessor.
o nehalem Directs the compiler to generate code for the
best performance on the Nehalem microproces-
sor.
o opteron Directs the compiler to generate code for the
best performance on the 32-bit AMD micropro-
cessor.
Note: The -xtarget=opteron option does not
automatically generate 64-bit code. You must
specify -m64 to compile 64-bit code.
o pentium Directs the compiler to generate code for the
best performance on the Pentium microproces-
sor.
o pentium_pro
Directs the compiler to generate code for the
best performance on the Pentium Pro micropro-
cessor.
o pentium3
Directs the compiler to generate code for the
best performance on the Pentium 3 micropro-
cessor.
o pentium4
Directs the compiler to generate code for the
best performance on the Pentium 4 micropro-
cessor.
o penryn Directs the compiler to generate code for the
best performance on the Penryn microproces-
sor.
o woodcrest
Directs the compiler to generate code for the
best performance on the Woodcrest
microprocessor.
Compiling for 64-bit Solaris software on SPARC or x86
platforms is indicated by the -m64 option. If you
specify -xtarget, the -m64 option must also appear, as
in:
-xtarget=ultra4 ... -m64
otherwise the compiler uses a 32-bit memory model.
See the section on -xtarget=t in the C User's Guide for
the -xtarget expansions that show the mnemonic encod-
ings of the actual system names and numbers.
-xtemp= dir
Sets the directory the compiler uses for temporary
files to dir. No space is allowed within this option
string. Without this option, temporary files go into
/tmp. -xtemp has precedence over the TMPDIR environment
variable.
-xthreadvar[=o]
Works in conjunction with the __thread declaration
specifier to take advantage of the compiler's thread-
local storage facility. After you declare the thread
variables with the __thread specifier, use -xthreadvar
to enable the use of thread-local storage with position
dependent code (non-PIC code) in dynamic (shared)
libraries. For more information on how to use __thread,
see the C User's Guide.
o must be the following:
Value Meaning
[no%]dynamic [[Do not] Compile variables for dynamic
loading. Access to thread variables is
significantly faster when
-xthreadvar=no%dynamic but you cannot
use the object file within a dynamic
library. That is, you can only use the
object file in an executable file.
If you do not specify -xthreadvar, the default used by
the compiler depends upon whether or not position-
independent code is enabled. If position-independent
code is enabled, the option is set to
-xthreadvar=dynamic. If position- independent code is
disabled, the option is set to -xthreadvar=no%dynamic.
If you specify -xthreadvar but do not specify any argu-
ments, the option is set to -xthreadvar=dynamic.
If there is non-position-independent code within a
dynamic library, you must specify -xthreadvar.
The linker cannot support the thread-variable
equivalent of non-PIC code in dynamic libraries. Non-
PIC thread variables are significantly faster, and
hence should be the default for executables.
If there is non-position-independent code within a
dynamic library, you must specify -xthreadvar.
Using thread variables on different versions of Solaris
software requires different options on the command
line.
On Solaris 9 software, objects that use __thread must
be compiled and linked with -mt.
See Also: -xcode, -KPIC, -Kpic
-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 allows the com-
piler to unroll loops n times.
-xustr={ascii_utf16_ushort|no}
Specify -xustr=ascii_utf16_ushort if you need to sup-
port an internationalized application that uses
ISO10646 UTF-16 string literals. In other words, use
this option if your code contains string literals that
you want the compiler to convert to UTF-16 strings in
the object file. Without this option, the compiler nei-
ther produces nor recognizes sixteen-bit character
string literals. This option enables recognition of the
U"ASCII_string" string literals as an array of unsigned
short int. Since such strings are not yet part of any
standard, this option enables recognition of non-
standard C.
You can turn off compiler recognition of
U"ASCII_string" string literals by specifying
-xustr=no. The rightmost instance of this option on the
command line overrides all previous instances.
The default is -xustr=no. If you specify -xustr without
an argument, the compiler won't accept it and instead
issues a warning. The default can change if the C or
C++ standards define a meaning for the syntax.
It is not an error to specify
-xustr=ascii_ustf16_ushort without also specifying a
U"ASCII_string" string literal.
Not all files have to be compiled with this option.
The following example shows a string literal in quotes
that is prepended by U. It also shows a command line
that specifies -xustr.
example% cat file.c
const unsigned short *foo = U"foo";
const unsigned short bar[] = U"bar";
const unsigned short *fun() { return
example% cc -xustr=ascii_utf16_ushort file.c -c
-xvector[=a]
Enables automatic generation of calls to the vector
library and/or the generation of the SIMD (Single
Instruction Multiple Data) instructions. You must use
default rounding mode by specifying -fround=nearest
when you use this option.
The -xvector option requires optimization level -xO3 or
greater. Compilation will not proceed if the optimiza-
tion level is unspecified or lower than -xO3, and a
message is issued.
a is the equivalent of the following:
[no%]lib
(SOLARIS Only) Does [not]enable the compiler to
transform math library calls within loops into
single calls to the equivalent vector math rou-
tines when such transformations are possible. This
could result in a performance improvement for
loops with large loop counts.
[no%]simd
Does [not]direct the compiler to use the native
x86 SSE SIMD instructions to improve performance
of certain loops. Streaming extensions are used on
x86 by default at optimization level 3 and above
where beneficial. The suboption no%simd can be
used to disable it.
The compiler will use SIMD only if streaming
extensions exist in the target architecture; that
is, if target ISA is at least SSE2. For example,
you can specify -xtarget=woodcrest,
-xarch=generic64, -xarch=sse2, -xarch=sse3, or
-fast on a modern platform to use it. If the tar-
get ISA has no streaming extensions, the suboption
will have no effect.
yes This option is deprecated, specify -xvector=lib
instead.
no This option is deprecated, specify -xvector=none
instead.
The default is -xvector=simd on x86 and -xvector=%none
on SPARC platforms. If you specify -xvector without a
suboption, the compiler assumes -xvector=simd,lib on
x86, -xvector=lib on SPARC (Solaris), and -xvector=simd
(Linux).
This option overrides previous instances so
-xvector=%none undoes a previously specified
-xvector=lib.
The compiler includes the libmvec libraries in the
load step.
If you compile and link with separate commands, be sure
to use the same -xvector option in the linking cc com-
mand. For a complete list of compiler options that must
be specified at both compile time and at link time, see
the C User's Guide.
-xvis
(SPARC) Use the -xvis=[yes|no] command when you are
using the assembly-language templates defined in the
VIS[tm] instruction set Software Developers Kit (VSDK).
The default is -xvis=no. Specifying -xvis is equivalent
to specifying -xvis=yes.
The VIS instruction set is an extension to the SPARC v9
instruction set. Even though the UltraSPARC processors
are 64-bit, there are many cases, especially in mul-
timedia applications, when the data are limited to
eight or 16 bits in size. The VIS instructions can pro-
cess four 16-bit data with one instruction so they
greatly improve the performance of applications that
handle new media such as imaging, linear algebra, sig-
nal processing, audio, video and networking.
For more information on the VSDK, see
http://www.sun.com/processors/vis/.
-xvpara
Issues warnings about potential parallel-programming
related problems that may cause incorrect results when
using OpenMP. Use with -xopenmp and OpenMP API direc-
tives.
The compiler issues warnings when it detects the fol-
lowing situations:
o Loops are parallelized using MP directives when there
are data dependencies between different loop iterations
o OpenMP data-sharing attributes-clauses are prob-
lematic. For example, declaring a variable "shared"
whose accesses in an OpenMP parallel region may cause
data race, or declaring a variable "private" whose
value in a parallel region is used after the parallel
region.
No warnings appear if all parallelization directives
are processed without problems.
Example:
cc -xopenmp -xvpara any.c
Note: Solaris Studio compilers support OpenMP 3.0 API
parallelization. Consequently, the MP pragmas are
deprecated. See the OpenMP API User's Guide for infor-
mation on migrating to the OpenMP API.
-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 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.
NOTES
errno
Certain floating-point math library routines will return
error status in the errno variable (defined in errno.h).
With options -fast, -xbuiltin, -xlibmieee, -xlibmil, -xlib-
mopt the compiler is free to replace calls to floating point
functions with equivalent optimized code that does not set
the errno variable. Further, -fast also defines the macro
__MATHERR_ERRNO_DONTCARE, which allows the compiler to
assume that math functions need not set errno. As a result,
user code that relies on the value of errno after a floating
point function call could produce inconsistent results.
One way around this problem is to avoid compiling such codes
with -fast.
However, if -fast optimization is required and the code
depends on the value of errno being set properly after
floating-point library calls, you should compile with the
options
-xbuiltin=none -U__MATHERR_ERRNO_DONTCARE \
-xnolibmopt -xnolibmil
following -fast on the command line to inhibit the compiler
from optimizing out such library calls and to to ensure that
calls to math functions set errno as documented.
New Shared Libraries
For Solaris release 10, new shared libraries libxprof.so.1,
libxprof_audit.so.1, and libtdf.so.1 must be installed in
order to use the -xprofile option. These libraries are pre-
installed on the latest OpenSolaris and Solaris releases.
PRAGMAS
The following #pragmas are recognized by the compilation
system:
#pragma align
#pragma c99
#pragma does_not_read_global_data
#pragma does_not_return
#pragma does_not_write_global_data
#pragma error_messages
#pragma fini
#pragma hdrstop
#pragma ident
#pragma init
#pragma [no_]inline
#pragma [no_]warn_missing_parameter
#pragma int_to_unsigned
#pragma opt
#pragma pack
#pragma rarely_called
#pragma redefine_extname
#pragma returns_new_memory
#pragma struct_align
#pragma unknown_control_flow
#pragma weak
#pragma does_not_read_global_data
#pragma does_not_write_global_data
#pragma no_side_effect
See also the OpenMP API User's Guide for a list of supported
OpenMP 2.5 directives.
SPARC Only:
#pragma nomemorydepend
#pragma no_side_effect
#pragma pipeloop
#pragma unroll
Refer to the C User's Guide for more information on these
pragmas.
ENVIRONMENT
The following is a list of environment variables that you
can set along with a brief description of their function.
OMP_DYNAMIC
Enable or disable dynamic adjustment of the number
of threads.
OMP_NESTED
Enable or disable nested parallelism. See the
OpenMP API User's Guide.
OMP_NUM_THREADS
This variable tells the runtime system the maximum
number of threads the program can create. See the
OpenMP API User's Guide.
OMP_SCHEDULE
Set the run-time schedule type and chunk size. See
the OpenMP API User's Guide.
PARALLEL Same as OMP_NUM_THREADS.
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(1) 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 four megabytes for 32-bit applications and
eight megabytes for 64-bit applications by
default. The size is set with the STACKSIZE
environment variable.
Setting the thread stack size to a value larger
than the default may be necessary for some paral-
lelized code.
The syntax of the STACKSIZE environment variable
accepts a keyword for denoting the slave thread
stacksize: B for Bytes, K for Kilobytes, M for
Megabytes, G for Gigabytes.
For example, setenv STACKSIZE 8192 sets the slave
thread stack size to 8 MB. 1235B sets the slave
thread stack size for 1235 Bytes. 1235G sets it
for 1235 Gigabytes. The default for an integer
value without a suffix letter is still Kilobytes.
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
Obsolete - the source browser functionality is no
longer supported.
SUN_PROFDATA=profdir
If set, store profile data collected from a pro-
gram compiled with -xprofile=collect in a direc-
tory named profdir in the current working direc-
tory at the time that the program is executed. If
the optional argument :profdir was specified in
-xprofile=collect[:profdir] at compilation time,
SUN_PROFDATA as no effect.
SUN_PROFDATA_DIR=dirname If set, store profile
data collected from a program compiled with
-xprofile=collect in a directory whose UNIX dir-
name is dirname. If dirname is not absolute, it
is interpreted relative to the current working
directory at the time that the program is exe-
cuted. If the optional argument :profdir was
specified in -xprofile=collect[:profdir] at compi-
lation time, SUN_PROFDATA_DIR has no effect.
SUNW_MP_THR_IDLE
Controls end-of-task status of each helper thread
and can be set to spin or sleep ns. The default is
sleep. See the OpenMP API User's Guide for
details.
SUNW_MP_WARN
Set this environment variable to TRUE to print
warning messages from the OpenMP and other paral-
lelization runtime-systems. If you registered a
function by using sunw_mp_register_warn() to han-
dle warning messages, then SUNW_MP_WARN prints no
warning messages, 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, no
warning messages are issued. For more information
on sunw_mp_register_warn() see the C User's Guide.
SUN_PROFDATA_REPLACE={objfile,program,all}
The value of the environment variable
SUN_PROFDATA_REPLACE indicates the scope of pro-
file data to be reset when a changed version of an
object file is detected at runtime. Use
SUN_PROFDATA_REPLACE to ensure that profile data
are consistent with the profiled program within
the specified unit of program scope.
The values of SUN_PROFDATA_REPLACE and their mean-
ings are as follows:
objfile
reset profile data of changed object file
program
reset profile data of all object files in
program containing changed object file
all reset entire contents of profile directory if
any object file has changed
The default setting of SUN_PROFDATA_REPLACE is
SUN_PROFDATA_REPLACE=objfile .
Example:
% setenv SUN_PROFDATA_REPLACE program (csh)
$ export SUN_PROFDATA_REPLACE=program (ksh)
With this setting, when a program containing a
changed object file is executed, all object files
in the program will have their profile data reset.
Relevant options include -xOn and -xipo=n.
SUN_PROFDATA_ASYNC_INTERVAL=async_interval
Set this environment variable to enable asynchro-
nous profile collection. In asynchronous profile
collection, profile data are collected from a run-
ning process at regular intervals whose duration
is specified in units of seconds.
SUN_PROFDATA_ASYNC_INTERVAL has no effect unless
one of the environment variables LD_AUDIT,
LD_AUDIT_32, or LD_AUDIT_64 is set to
/usr/lib/{,64}/libxprof_audit.so.1.
Asynchronous profile collection requires an MT-
safe, mmap based memory allocator, such as
libumem(3) with mmap-based allocation specified by
setting UMEM_OPTIONS to backend=mmap.
Example: to enable asynchronous profile collection
from a 64 bit process at 1 minute
intervals,specify the following environment vari-
ables:
$ env LD_AUDIT_64=/usr/lib/64/libxprof_audit.so.1 \
SUN_PROFDATA_ASYNC_INTERVAL=60 UMEM_OPTIONS=backend=mmap \
64-bit-program [program-args]
Asynchronous profile collection requires OpenSo-
laris 2009.06 or later.
SUN_PROFDATA_ASYNC_VERBOSE=verbose
If set nonzero, enables verbose messages from
asynchronous collector to stderr.
SUN_PROFDATA_ASYNC_VERBOSE has no effect unless
asynchronous profile collection is enabled.
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 Interprocedural optimizer (SPARC)
ir2hf intermediate code translator (x86)
iropt global optimizer
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 synchronization bug detection (Solaris
Operating Environment)
stack_grow.o stack overflow checking (SPARC)
SunWS_cache The directory used to store data when the
-xpch option is used.
ube optimizer, code generator (x86)
ube_ipa Interprocedural analyzer (x86)
values-xa.o -Xa support
values-xc.o -Xc support
values-xpg4.o xpg4 support
values-xpg6.o SUSv3 support
values-xs.o -Xs support
values-xt.o -Xt support
xprof_fini.o Initialization and finalization handlers for
programs compiled with -xprofile=collect
SEE ALSO
analyzer(1), as(1), c89(1), c99(1), cflow(1), cscope(1),
ctags(1), ctrace(1), dbx(1), er_src(1), indent(1),
inline(1), ld(1), lint(1), lock_lint(1), prof(1), sunstu-
dio(1), tmpnam(3S), version(1).
C User's Guide
OpenMP API User's Guide
The ISO/IEC 9899-1990 Programming Language - C standard,
The ISO/IEC 9899-1999 Programming Language - C standard,