NAME
CC - C++ compiler
SYNOPSIS
CC [-#] [-###] [-B{dynamic|static|symbolic}] [-c]
[-compat[={5|g}]] [+d] [-Dname[=def]] [-d{y|n}]
[-dalign] [-dryrun] [-E] [-erroff[=t[,t...]]]
[-errtags[=a]] [-errwarn[=t[,t...]]] [-fast]
[-features=a[,a...]] [-filt[=filter[,filter...]]
[-flags] [-fma[={none|fused}]] [-fnonstd]
[-fns[={yes|no}]] [-fprecision=a] [-fround=a]
[-fsimple[=n]] [-fstore] [-ftrap=a[,a...]] [-G] [-g]
[-g0] [-g3] [-H] [-h[ ]lname] [-help] [-Ipathname]
[-I-] [-i] [-include] [-inline] [-instances=i]
[-instlib=file] [-KPIC] [-Kpic] [-keeptmp] [-Lpath]
[-llib] [-libmieee] [-libmil] [-library=lib[,lib...]]
[-m32|-m64] [-mc] [-misalign] [-mr[,string]] [-mt]
[-native] [-noex] [-nofstore] [-nolib] [-nolibmil]
[-noqueue]
[-norunpath] [-O[n]] [-O[level]] [-o file] [+p] [-P]
[-p] [-pentium] [-pg] [-PIC] [-pic] [-pta] [-ptipath]
[-pto] [-ptv] [{-Qoption|-qoption} phase [,option...]]
[{-Qproduce|-qproduce}type] [-qp] [-Rpath[:path...]]
[-S] [-s] [-staticlib=l[,l...]] [-sync_stdio=[yes|no]]
[-temp=path] [-template=a[,a...]] [-time]
[-traceback[=list]] [-Uname] [-unroll=n] [-V] [-v]
[-verbose=a[,a...]] [-Wc,arg] [+w] [+w2] [-w]
[-Xlinker arg] [-Xm] [-xaddr32[={yes|no}]]
[-xalias_level[=n]] [-xanalyze={code|no}] [-xannotate]
[-xar] [-xarch=isa] [-xautopar] [-xbinopt={a}]
[-xbuiltin[={a}] [-xcache=c] [-xchar[=o]] [-xcheck[=n]]
[-xchip=c] [-xcode=v] [-xdebugformat=[stabs|dwarf]]
[-xdepend[={yes|no}]] [-xdumpmacros[=value[,value...]]
[-xe] [-xF[=v]] [-xhelp=flags]
[-xhwcprof[={enable|disable}]] [-xia]
[-xinline[=func_spec[,func_spec...]]
[-xinstrument=[no%]datarace] [-xipo[={0|1|2}]
[-xipo_archive[=a]] [-xivdep[=p]] [-xjobs=n]
[-xkeepframe[=p]] [-xlang=language[,language]]
[-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] [-xOn] [-xopenmp] [-xpagesize=n]
[-xpagesize_heap=n] [-xpagesize_stack=n] [-xpch=v]
[-xpchstop] [-xpec] [-xpg] [-xport64[=v]]
[-xprefetch[=a[,a]] [-xprefetch_auto_type=[a]
[-xprefetch_level[=l]] [-xprofile=p]
[-xprofile_ircache[=path]]
[-xprofile_pathmap=collect_prefix:use_prefix]
[-xreduction] [-xregs=r[,r...]] [-xrestrict[=f]] [-xs]
[-xsafe=mem] [-xspace] [-xtarget=t] [-xthreadvar[=o]]
[-xtime] [-xtrigraphs[={yes|no}]] [-xunroll=n]
[-xustr={ascii_utf16_ushort|no}] [-xvector[=a]] [-xvis]
[-xvpara] [-xwe] [-Yc,path] [-z arg] [file] ...
DESCRIPTION
Oracle Solaris Studio 12.3 C++ Compiler
This man page details the options or flags for the Oracle
Solaris Studio 12.3 C++ compiler.
Complete documentation for this release is available on the
Oracle Technical Network (OTN) Solaris Studio website:
http://oracle.com/technetwork/server-storage/solarisstudio
The OTN website is a complete resource for Oracle Solaris
Studio and includes many technical articles detailing best
practices and deep dives into various programming technolo-
gies and other topics.
For the complete description of all new features and func-
tionality in the Oracle Solaris Studio suite, see the What's
New in this Release guide.
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.
COMPILING FOR 64-BIT PLATFORMS:
Use the -m32 and -m64 options to specify the memory model of
the target compilation, ILP32 or LP64 respectively.
The -xarch option no longer carries an implicit memory model
definition, and should be used only to specify the instruc-
tion set of the target processor.
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 Oracle 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 SPARC or x86 processors under Oracle 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 Oracle 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 Oracle Solaris platforms.
Programs compiled with -xarch set to sse, sse2, sse2a, or
sse3 and beyond must be run only on platforms that provide
these extensions 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 Oracle Solaris and
Linux because the intrinsic math libraries (for example,
sin(x)) are not the same.
Binary Compatibility Verification
Program binaries compiled and built using specialized -xarch
hardware flags are verified that they are being run on the
appropriate platform. Running programs compiled with spe-
cialized -xarch options on platforms 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 (and beyond) instructions
and extensions.
Overview of the C++ Compiler
CC converts C++ and assembly source files to object files,
and links object files and libraries into executable pro-
grams.
Programs that contain C++ objects must be linked with CC.
CC takes arguments ending in .c, .C, .cc, .cxx, .c++, .cpp,
or .i to be C++ source programs. Arguments ending in .s are
presumed to be assembly source files. Arguments ending in
.o are presumed to be object files.
Files whose names do not end with the above suffixes are
treated as object programs or libraries and are handed over
to the link editor. Unless -c, -S, -E, or -P is specified,
these programs and libraries, together with the results of
any specified compilations or assemblies, are linked in the
order given to produce an output file named a.out. You can
specify a different name for the executable by using the -o
option.
If a single file is compiled and linked all at once, the
intermediate files are deleted.
Before you use the CC command, insert into your search path
the name of the directory in which you have chosen to
install the C++ compilation system. For instructions on set-
ting your search path, see the csh(1) or the sh(1) man page.
User-Supplied Default Compiler Options Startup File
The default compiler options file enables the user to
specify a set of default options that are applied to all
compiles, unless otherwise overridden. For example, the file
could specify that all compiles default at -xO2, or automat-
ically include the file setup.il.
At startup, the compiler searches for a default options file
listing default options it should include for all compiles.
The environment variable SPRO_DEFAULTS_PATH specifies a
colon-separated list of directories to search for the the
defaults file.
If the environment variable is not set, a standard set of
defaults is used. If the environment variable is set but is
empty, no defaults are used.
The defaults file name must be of the form
compiler.defaults, where compiler is one of the following:
cc, c89, c99, CC, ftn, or lint. For example, the defaults
for the C++ compiler would be CC.defaults
If a defaults file for the compiler is found in the direc-
tories listed in SPRO_DEFAULTS_PATH, the compiler will read
the file and process the options prior to processing the
options on the command line. The first defaults file found
will be used and the search terminated.
System administrators may create system-wide default files
in Studio-install-path/prod/etc/config. If the environment
variable is set, the installed defaults file will not be
read.
The format of a defaults file is similar to the command
line. Each line of the file may contain one or more com-
piler options separated by white space. Shell expansions,
such as wild cards and substitutions, will not be applied to
the options in the defaults file.
The value of the SPRO_DEFAULTS_PATH and the fully expanded
command line will be displayed in the verbose output pro-
duced by options -#, -###, and -dryrun.
Options specified by the user on the command line will usu-
ally override options read from the defaults file. For exam-
ple, if the defaults file specifies compiling with -xO4 and
the user specifies -xO2 on the command line, -xO2 will be
used.
Some options appearing in the default options file will be
appended after the options specified on the command line.
These are the preprocessor option -I, linker options -B, -L,
-R, and -l, and all file arguments, such as source files,
object files, archives, and shared objects.
The following is an example of how a user-supplied default
compiler option startup file might be used.
demo% cat /project/defaults/CC.defaults
-fast -I/project/src/hdrs -L/project/libs -llibproj -xvpara
demo% setenv SPRO_DEFAULTS_PATH /project/defaults
demo% CC -c -I/local/hdrs -L/local/libs -lliblocal tst.cc
The compiler command is now equivalent to:
CC -fast -xvpara -c -I/local/hdrs -L/local/libs -lliblocal \
tst.cc -I/project/src/hdrs -L/project/libs -llibproj
While the compiler defaults file provides a convenient way
to set the defaults for an entire project, it can become the
cause of hard to diagnose problems. Set the environment
variable SPRO_DEFAULTS_PATH to an absolute path rather than
the current directory to avoid such problems.
The interface stability of the default options file is
uncommitted. The order of option processing is subject to
change in a future release.
OPTIONS
All platform-specific options are silently accepted on all
platforms. Any exceptions to this rule are noted under the
specific option.
Options valid only on SPARC platforms are marked (SPARC).
Options valid only on x86/x64 platforms are marked (x86).
Deprecated options are marked (Obsolete) and should not be
used going forward. They are provided only for compatibility
with earlier releases. Use the indicated replacement option.
See ld(1) for linker options.
In the syntax of the command-line options, items shown in
square brackets ( [] ) are optional. Curly brackets enclose
a bar-separated list of literal items to be chosen, as in
{yes | no | maybe } . The first item in a list usually
indicates the default value when the flag appears without a
value.
For example, -someoption[={no|yes}] implies -someoption is
the same as -someoption=no .
In general, compiler options are processed from left to
right (with the exception that the -U options are processed
after all -D options), allowing selective overriding of
macro options (options that include other options). This
rule does not apply to linker options.
For a complete description of the C++ compiler options,
including examples, see the C++ User's Guide.
CC accepts the following options.
-# 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.
-Bbinding
Specifies whether a library binding for linking is sym-
bolic, dynamic (shared), or static (nonshared).
-Bdynamic is the default. You can use the -B option
several times on a command line.
For more information on the -Bbinding option, see the
ld(1) man page and the Oracle Solaris documentation.
-Bdynamic directs the link editor to look for liblib.so
files. Use this option if you want shared library bind-
ings for linking. If the liblib.so files are not
found, it looks for liblib.a files.
-Bstatic directs the link editor to look only for
liblib.a files. The .a suffix indicates that the file
is static, that is, nonshared. Use this option if you
want nonshared library bindings for linking.
-Bsymbolic forces symbols to be resolved within a
shared library if possible, even when a symbol is
already defined elsewhere. For an explanation of -Bsym-
bolic, see the ld(1) man page.
This option and its arguments are passed to the linker,
ld. If you compile and link in separate steps and are
using the -Bbinding option, you must include the option
in the link step.
Warning:
Never use -Bsymbolic with programs containing C++ code,
use linker scoping instead. See the C++ User's Guide
for more information on linker scoping. See also the
-xldscope option.
With -Bsymbolic, references in different modules can
bind to different copies of what is supposed to be one
global object.
The exception mechanism relies on comparing addresses.
If you have two copies of something, their addresses
won't compare equal, and the exception mechanism can
fail because the exception mechanism relies on compar-
ing what are supposed to be unique addresses.
-c Compile and produce a .o file for each source file
without linking. 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 direc-
tory. If you suppress the linking step, you also
suppress the removal of the object files.
For example:
o CC -c x.cc generates the object file x.o.
o CC -c -o y.o x.cc generates the object file y.o.
Warnings:
When the compiler produces object code for an input
file (for example, .cc, .c, or .i), the compiler always
produces a .o file in the working directory. If you
suppress the linking step, the .o files are not
removed.
See also:
-o filename.
-compat={5|g}
Sets the major release compatibility mode of the com-
piler. This option controls the __SUNPRO_CC_COMPAT
preprocessor symbol.
Standard mode, -compat=5, accepts constructs according
to the ANSI/ISO 1998 C++ standard as corrected in 2003
and is the default with the release of Oracle Solaris
Studio 12.3. ("Compatibility Mode", -compat=4, was
removed in this release.)
-compat=g adds compatibility with the gcc/g++ compiler
on x86 Oracle Solaris and Linux platforms.
Value Meaning
-compat=5
(Standard mode) Set the language and binary com-
patibility to ANSI/ISO standard mode and is the
default. Sets the __SUNPRO_CC_COMPAT preproces-
sor macro to 5).
-compat=g
(x86 Only) enables recognition of g++ language
extensions and causes the compiler to generate
code that is binary-compatible with g++ on x86
Oracle Solaris and Linux platforms.
The binary compatibility extends only to shared
(dynamic or .so) libraries, not to individual .o
files or archive (.a) libraries.
Sets the __SUNPRO_CC_COMPAT preprocessor macro
to 'G'.
Example 1, linking g++ shared library to x86
Oracle Solaris Studio C++ main program
% g++ -shared -o libfoo.so -fpic a.cc b.cc c.cc
% CC -compat=g main.cc -L. -lfoo
Example 2, linking x86 Oracle Solaris Studio C++
shared library to g++ main program
% CC -compat=g -G -o libfoo.so -Kpic a.cc b.cc c.cc
% g++ main.cc -L. -lfoo
Defaults:
If the -compat option is not specified, -compat=5 is
assumed.
Interactions:
See -features for additional information.
+d Prevents the compiler from expanding C++ inline
functions.
Under the C++ language rules, a C++ inline function is
a function for which one of the following statements is
true.
o The function is defined using the inline keyword.
o The function is defined (not just declared) inside a
class definition
o The function is a compiler-generated class member
function
Under the C++ language rules, the compiler can choose
whether actually to inline a call to an inline func-
tion. The C++ compiler inlines calls to an inline func-
tion unless:
o The function is too complex
o The +d option is selected
o The -g option is selected with no optimization option
Interactions:
This option is automatically turned on when you specify
-g, the debugging option, unless a -O or -xO optimiza-
tion level is also specified..
The -g0 debugging option does not turn on +d.
The +d option has no effect on the automatic inlining
that is performed when you use -xO4 or -xO5.
-Dname[=def]
Defines a macro symbol name to the preprocessor. Doing
so is equivalent to including a #define directive at
the beginning of the source. You can use multiple -D
options.
The following values are predefined.
SPARC and x86 platforms:
__ARRAYNEW
__BUILTIN_VA_ARG_INCR
__DATE__
__FILE__
__LINE__
__STDC__ = 0
__SUNPRO_CC = 0x5130
__SUNPRO_CC_COMPAT = 5 or G
__TIME__
__cplusplus
__sun
__unix
_BOOL if type bool is enabled
(see "-features=[no%]bool")
_WCHAR_T
sun
unix
__SVR4 (Oracle Solaris)
__SunOS_5_10 (Oracle Solaris)
__SunOS_5_11 (Oracle Solaris)
SPARC only:
sparc
sparcv8
__SUN_PREFETCH = 1
__sparc
SPARC V9 only:
__sparcv9 (with -m64)
x86 only:
linux
__amd64 (with -m64)
__gnu__linux__
__linux
__linux__
__x86_64 (with -m64)
Note that __sun is only defined on Oracle Solaris plat-
forms. Use __SUNPRO_CC to determine if the compiler is
the Oracle Solaris Studio CC compiler.
Defaults:
If you do not use [=def], name is defined as 1.
Interactions:
If +p is used, sun, unix, sparc and i386 are not
defined.
-d{y|n}
Allows or disallows dynamic libraries for the entire
executable.
-dy specifies dynamic linking, which is the default, in
the link editor.
-dn specifies static linking in the link editor.
This option and its arguments are passed to ld.
Interactions:
This option causes fatal errors if you use it in combi-
nation 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, see the C++ User's Guide.
This option is silently ignored on x86/x64 platforms.
-dryrun
Directs the CC driver to show, but not execute, the
commands constructed by the compilation driver.
-E Directs the CC driver to only preprocess the C++ source
files, and to send the result to stdout (standard out-
put). No compilation is done; no .o files are gen-
erated.
This option causes preprocessor-type line number infor-
mation to be included in the output.
To compile the output of the -E option when the source
code involves templates, you might need to use the -
template=no%extdef option with the -E option. If appli-
cation code uses the "definitions separate" template
source code model, the output of the -E option might
still not compile. Refer to the C++ Users Guide
chapters on templates for more information.
-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.
Values:
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
message 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.
Defaults:
The default is -erroff=%none. Specifying -erroff is
equivalent to specifying -erroff=%all.
Warnings:
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.
-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 -err-
off and made fatal with -errwarn.
Values and Defaults:
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 mes-
sages.
Values:
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++
compiler to exit with a fatal status if any warning
except tag is issued.
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.
Defaults:
The default is -errwarn=%none. If you specify -errwarn
alone, it is equivalent to -errwarn=%all.
Warnings:
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 com-
pile 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.
See Also:
-erroff, -errtags
-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 -dryrun option to examine the expansion of -fast,
and incorporate the appropriate options of -fast into
the ongoing process of tuning the executable.
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 expansion of -fast includes the -xlibmopt option,
which enables the compiler to use a library of optim-
ized math routines. For more information, see the
description of -xlibmopt in this man page.
This option provides near maximum performance for most
applications by expanding the following compilation
options:
-fns (SPARC, x86)
-fsimple=2 (SPARC, x86)
-nofstore (x86)
-xbuiltin=%all (SPARC, x86)
-xdepend (SPARC, x86)
-xlibmil (SPARC, x86)
-xlibmopt (SPARC, x86)
-xmemalign (SPARC)
-xO5 (SPARC, x86)
-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.
You can view an expansion of the -fast options by run-
ning the command
CC -fast -xdryrun |& grep ###
For details on the options set by -fast, see the C++
User's Guide.
Interactions:
You can override the values set by -fast by specifying
different values to the right of -fast on the command
line. For example, although the optimization level set
by -fast is -xO5, if you specify -fast, -xO3, the
optimization level becomes -xO3.
The -fast macro expands into compilation options that
may affect other specified options. For example, in the
following command, the expansion of the -fast macro
includes -xtarget=native which reverts -xarch to one of
the 32-bit architecture options.
Incorrect:
example% CC -xarch=sparcvis3 -fast test.cc
Correct:
example% CC -fast -xarch=sparcvis3 test.cc
See the description for each option to determine possi-
ble interactions.
Warnings:
Code compiled with the -fast option is not portable.
For example, compiling code using the following command
on an UltraSPARC(TM) III system will generate a binary
that will not execute on an UltraSPARC II system.
example% CC -fast test.cc
Do not use this option for programs that depend on IEEE
standard floating-point exception handling; different
numerical results, premature program termination, or
unexpected SIGFPE signals might occur.
The -fast option includes -fns -ftrap=%none; that is,
this option turns off all trapping.
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.
The expansion of the -fast option includes
-D_MATHERR_ERRNO_DONTCARE.
See also:
Numerical Computation Guide, ieee_sun(3m).
-features=a
Enables/disables various C++ language features.
The following table lists the -features suboption key-
words and their meanings. The prefix no% applied to a
suboption disables that suboption.
Value Meaning
%all Deprecated. Do not use %all. See warning below.
%none
Deprecated. Do not use %none. See warning below.
[no%]altspell
Recognize alternative token spellings (for exam-
ple, and for &&). The default is altspell.
[no%]anachronisms
Allow anachronistic constructs. When disabled
(that is -feature=no%anachronisms), no anachronis-
tic constructs are allowed. The default is
anachronisms.
[no%]bool
Allow the bool type and literals. When enabled,
the macro _BOOL = 1. When disabled, the macro is
not defined. The default is bool.
[no%]conststrings
Put literal strings in read-only memory. The
default is conststrings.
cplusplus_redef
Allow the normally pre-defined macro __cplusplus
to be redefined by a -D option on the command
line. Attempting to redefine __cplusplus with a
#define directive in source code is not allowed.
Example:
CC -features=cplusplus_redef -D__cplusplus=1 ...
The g++ compiler typically predefines the
__cplusplus macro to 1, and source code might
depend on this non-standard value. (The standard
value is 199711L for compilers implementing the
1998 C++ standard or the 2003 update. Future stan-
dards will require a larger value for the macro.)
Do not use this option unless you need to redefine
__cplusplus to 1 in order to compile code intended
for g++.
[no%]except
Allow C++ exceptions. When C++ exceptions are dis-
abled (that is, -features=no%except), a throw-
specification on a function is accepted but
ignored; the compiler does not generate exception
code. Note that the keywords try, throw, and catch
are always reserved. The default is except.
explicit
Recognizes the keyword explicit. no%explicit is
not allowed.
[no%]export
Recognize the keyword export. The default is
export.
[no%]extensions
Allow non-standard code that is commonly accepted
by other C++ compilers. See chapter 4 of the C++
User's Guide for an explanation of the invalid
code that is accepted by the compiler when you use
the -features=extensions option. The default is
-features=no%extensions.
[no%]iddollar
Allow $ as a non-initial identifier character.
The default is no%iddollar.
[no%]localfor
Use standard-conforming local-scope rules for the
for statement. The default is localfor.
[no%]mutable
Recognize the keyword mutable. The default is
mutable.
namespace
Recognize the keyword namespace. no%namespace is
not allowed.
[no%]nestedaccess
Allow nested classes to access private members of
the enclosing class.
Default: -features=nestedacces
[no%]rvalueref
Allow binding a non-const reference to an rvalue
or temporary.
Default: -features=no%rvalueref
The C++ compiler has traditionally been lax in
enforcing the rule that a non-const reference can-
not be bound to a temporary or rvalue. The C++
compiler accepts the invalid code by default. To
restore the old compiler behavior, use the option
-features=rvalueref.
rtti Allow runtime type identification (RTTI).
-features=no%rtti is not allowed.
[no%]split_init
Put initializers for nonlocal static objects into
individual functions. When you use
-features=no%split_init, the compiler puts all the
initializers in one function. Using
-features=no%split_init minimizes code size at the
possible expense of compile time. The default is
split_init.
[no%]strictdestorder
Follow the requirements specified by the C++ stan-
dard regarding the order of the destruction of
objects with static storage duration. The default
is strictdestrorder.
[no%]tmplife
Clean up the temporary objects that are created by
an expression at the end of the full expression,
as defined in the ANSI/ISO C++ Standard. (When
-features=no%tmplife is in effect, most temporary
objects are cleaned up at the end of their block.)
The default is tmplife.
[no%]tmplrefstatic
Allow function templates to refer to dependent
static functions or static function templates. The
default is the standard conformant
no%tmplrefstatic.
[no%]transitions
Allow ARM language constructs that are problematic
in standard C++ and that may cause the program to
behave differently than expected or that may be
rejected by future compilers. When you use
-features=no%transitions, the compiler issues
warnings about these constructs instead of error
messages.
Interactions:
This option accumulates instead of overrides.
Use of the following is not compatible with the stan-
dard libraries and headers:
o no%bool
o no%except
o no%mutable
Warnings:
Do not use -features=%all or -features=%none. These
suboptions are deprecated and might be removed in a
future release. Results can be unpredictable.
The behavior of a program might change when you use
-features=tmplife. Testing whether the program works
both with and without the -features=tmplife option is
one way to test the program's portability.
-filt[=filter[,filter...]]
Suppress the filtering that CC normally applies to
linker error messages.
The prefix no% applied to a suboption disables that
suboption.
filter must be one of the following values
[no%]errors Show the C++ explanations of the linker
error messages. The suppression of the
explanations is useful when the linker
diagnostics are provided directly to
another tool.
[no%]names Demangle the C++ mangled linker names.
[no%]returns Demangle the return types of functions.
Suppression of this demangling helps you
to identify function names more quickly,
but note that in the case of co-variant
returns, some functions differ only in
the return type.
[no%]stdlib Simplify names from the standard library
in both the linker and compiler error
messages. This makes it easier for you
to recognize the name of standard-
library functions.
%all Equivalent to
-filt=errors,names,returns,stdlib. This
is the default behavior.
%none Equivalent to
-filt=no%errors,no%names,no%returns,no%stdlib.
Defaults:
If you do not specify the -filt option, or if you
specify -filt without any values, then the compiler
assumes -filt=errors,names,returns,stdlib.
Interactions:
[no%]returns has no effect when used with no%names.
That is, the following options are equivalent:
-filt=no%names
-filt=no%names,no%returns
-filt=no%names,returns
See also c++filt(1).
-flags
Same as -xhelp=flags.
-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
This is a macro that expands to -ftrap=common on x86,
and -fns -ftrap=common on SPARC.
See -fns and -ftrap=common as well as the Numerical
Computation Guide for more information.
-fns[={no|yes}]
For SPARC, this option causes the nonstandard
floating-point mode to be enabled when a program begins
execution.
For x86, this option 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 opera-
tions that do not utilize the SSE or SSE2 instruction
set.
On some SPARC platforms, the nonstandard floating-point
mode disables "gradual underflow," causing tiny results
to be flushed to zero rather than to produce subnormal
numbers. It also causes subnormal operands to be
silently replaced by zero.
On those SPARC platforms that do not support gradual
underflow and subnormal numbers in hardware, use of
this option can significantly improve the performance
of some programs.
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.
Defaults:
If -fns is not specified, the nonstandard floating-
point mode is not enabled automatically. Standard IEEE
754 floating-point computation takes place, that is,
underflows are gradual.
If only -fns is specified -fns=yes is assumed.
Warnings:
When nonstandard mode is enabled, floating-point arith-
metic may produce results that do not conform to the
requirements of the IEEE 754 standard.
On SPARC systems, this option is effective only if used
when compiling the main program.
If you compile one routine with -fns, then compile all
routines of the program with the -fns option; otherwise
you can get unexpected results.
-fprecision=a
(x86 platform) Sets floating-point rounding precision
mode. a must be one of: single, double, extended.
The -fprecision flag sets the rounding precision mode
bits in the Floating Point Control Word. These bits
control the precision to which the results of basic
arithmetic operations (add, subtract, multiply, divide,
and square root) are rounded.
The following table shows the meanings of the values of
a.
Value Meaning
single Rounds to an IEEE single-precision value
double Rounds to an IEEE double-precision value
extended Rounds to the maximum precision available
When a is single or double, this flag causes the round-
ing precision mode to be set to single or double preci-
sion, respectively, when a program begins execution.
When p is extended or the -fprecision flag is not used,
the rounding precision mode remains as the extended
precision.
The single precision rounding mode causes results to be
rounded to 24 significant bits, and double precision
rounding mode causes results to be rounded to 53 signi-
ficant bits. In the default extended precision mode,
results are rounded to 64 significant bits. This mode
controls only the precision to which results in regis-
ters are rounded, and it does not affect the range. All
results in register are rounded using the full range of
the extended double format. Results that are stored in
memory are rounded to both the range and precision of
the destination format.
The nominal precision of the float type is single. The
nominal precision of the long double type is extended.
Defaults:
When the -fprecision flag is not specified, the round-
ing precision mode defaults to extended.
Warnings:
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=a
Sets the IEEE rounding mode in effect at startup.
a must be one of: nearest, tozero, negative, positive.
Value Meaning
nearest Rounds towards the nearest number and break-
ing ties to even numbers.
tozero Round-to-zero.
negative Round-to-negative-infinity.
positive Round-to-positive-infinity.
This option sets the IEEE 754 rounding mode that:
o Can be used by the compiler in evaluating constant
expressions.
o Is established at runtime during the program initial-
ization.
The meanings are the same as those for the ieee_flags
function, which may be used to change the mode at run-
time.
Defaults:
When the -fround option is not specified, the rounding
mode defaults to -fround=nearest.
Warnings:
If you compile one routine with -fround=a, compile all
routines of the program with the same -fround=a option;
otherwise, you can get unexpected results. This option
is effective only if used when compiling the main pro-
gram.
Note that compiling with -xvector or -xlibmopt require
default rounding. Programs that link with libraries
compiled with either -xvector or -xlibmopt or both must
ensure that default rounding is in effect.
-fsimple[=n]
Selects floating-point optimization preferences.
If n is present, it must be 0, 1 or 2.
The following table shows the -fsimple values.
Value Meaning
0 Permits no simplifying assumptions. Preserves
strict IEEE 754 conformance.
1 Allows conservative simplification. The
resulting code does not strictly conform to
IEEE 754, but numeric results of most pro-
grams are unchanged.
With -fsimple=1, the optimizer is not allowed
to optimize completely without regard to
roundoff or exceptions. In particular, a
floating point computation cannot be replaced
by one that produces different results with
rounding modes held constant at runtime.
With -fsimple=1, the optimizer can assume the
following:
o IEEE 754 default rounding/trapping modes do
not change after process initialization.
o Computation producing no visible result
other than potential floating-point excep-
tions may be deleted.
o Computation 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.
2 Includes all the functionality of -fsimple=1,
and also enables the use of SIMD instructions
to compute reductions when -xvector=simd is
in effect.
Also permits aggressive floating point optim-
ization that may cause many programs to pro-
duce different numeric results due to changes
in rounding. For example, permits the optim-
izer to 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.
Defaults:
If -fsimple is not designated, the compiler uses -fsim-
ple=0.
If -fsimple is designated but no value is given for n,
the compiler uses -fsimple=1.
Warnings:
This option can break IEEE 754 conformance.
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. See also articles on performance and
precision on the OTN Oracle Solaris Studio website:
oracle.com/technetwork/server-storage/solarisstudio/
-fstore
(x86 platform) Forces precision of floating-point
expressions.
This option causes the compiler to convert the value of
a floating-point expression or function to the type on
the left side of an assignment - when that expression
or function is assigned to a variable, or when that
expression is cast to a shorter floating-point type
rather than leaving the value in a register.
To turn off this option, use the -nofstore option.
Warnings:
Due to roundoffs and truncation, the results may be
different from those that are generated from the regis-
ter values.
-ftrap=a[,a...]
Sets the IEEE 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.
a must be one of the following values.
Value Meaning
[no%]division Trap on division by zero.
[no%]inexact Trap on inexact result.
[no%]invalid Trap on invalid operation.
[no%]overflow Trap on overflow.
[no%]underflow 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.
Note that the [no%] prefix 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%] prefix by itself does not explicitly cause a par-
ticular trap to be disabled.
Defaults:
If you do not specify -ftrap, the compiler assumes
-ftrap=%none.
Example: -ftrap=%all,no%inexact means to set all traps
except inexact.
Warnings:
If you compile one routine with -ftrap, compile all
routines of the program with the same -ftrap 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 Build a dynamic shared library instead of an executable
file; see the ld(1) man page and the C++ User's Guide.
All source files specified in the command line are com-
piled with -xcode=pic13 by default.
When building a shared library from files that involve
templates and were compiled with the -instances=extern
option, any template instances referenced by the .o
files will be included from the template cache automat-
ically.
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 at both compile
time and link time when you link with the resulting
shared object.
When you create a shared object, all the object files
that are compiled for 64-bit SPARC architectures must
also be compiled with an explicit -xcode value as docu-
mented under the description of -xcode.
The following options are passed to ld if -c is not
specified:
o -dy
o -G
o -R
Do not use ld -G to build shared libraries; use CC -G.
The CC driver automatically passes several options to
ld that are needed for C++.
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. For example, if you want the shared library to be
dependent upon libCrun, you must pass -lCrun on the
command line.
-g Instructs both the compiler and the linker to prepare
the file or program for debugging with dbx(1) or the
performance analyzer(1). The tasks include:
o Producing more detailed information in the symbol
table of the object files and the executable
o Producing some "helper functions," which the Debugger
can call to implement some of its features
o Disabling the inline generation of functions, if no
optimization level is specified; that is, using this
option implies the +d option if no optimization level
is also specified. -g with any -O or -xO level does
not disable inlining.
o Disabling certain levels of optimization
Interactions:
If you use this option with -xO[level] (or its
equivalent options, such as -O), you will get inlining
and limited debugging information. For more informa-
tion, see the entry for -xO.
If you specify -gO and the optimization level is -xO3
or lower, the compiler provides best-effort symbolic
information with almost full optimization. Tail-call
optimization is disabled.
If you use this option and the optimization level is
-xO4 or higher, the compiler provides best effort sym-
bolic information with full optimization.
When you specify this option, the +d option is speci-
fied automatically unless -O or -xO are also specified.
To use the full capabilities of the Performance
Analyzer, compile with the -g option. While some per-
formance 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.
Warnings
If you compile and link your program in separate steps,
then including the -g option in one step and excluding
it from the other step will not affect the correctness
of the program, but it will affect the ability to debug
the program. Any module that is not compiled with -g
(or -g0), but is linked with -g (or -g0) will not be
prepared properly for debugging. Note that compiling
the module that contains the function main with the -g
option (or the -g0 option) is usually necessary for
debugging.
See also:
For more information, see the explanations for -g0,
-xs, and +d, as well as the ld(1) man page.
-g0 Instructs the compiler to prepare the file or program
for debugging, but not to disable inlining. This option
is the same as -g, except that +d is disabled and dbx
cannot step into inlined functions.
See also:
+d
-g3 Produce additional debugging information.
-g3 is the same as -g0 with additional debugging symbol
table information so that dbx can display how macros in
the source code have been expanded. This added symbol
table information can result in an increase in the size
of the debug information in the resulting .o and exe-
cutable when compared to only using -g0.
-H On the standard error output (stderr), prints, one per
line, the path name of each #include file contained in
the current compilation.
-h[ ]lname
Assigns the name lname to the generated shared dynamic
library.
This is a loader option that is passed to ld. In gen-
eral, the name after -h should be exactly the same as
the one after -o. A space between the -h and lname is
optional.
The compile-time loader assigns the specified name to
the shared dynamic library you are creating. It
records the name in the library file as the intrinsic
name of the library. If there is no
-hlname option, then no intrinsic name is recorded in
the library file.
Every executable file has a list of needed shared
library files. When the runtime linker links the
library into an executable file, the linker copies the
intrinsic name from the library into that list of
needed shared library files. If there is no intrinsic
name of a shared library, then the linker copies the
path of the shared library file instead. This command
line is an example:
% CC -G -o libx.so.1 -h libx.so.1 a.o b.o c.o
Interactions:
This option accumulates instead of overrides.
-help
Same as -xhelp=flags.
-Ipathname
Adds pathname to the list of directories that are
searched for #include files with relative file names -
those that do not begin with a slash.
The compiler searches for quote-included files (of the
form #include "foo.h") in this order:
1. In the directory containing the source
2. In the directories named with -I options, if any
3. In the include directories for compiler-provided
C++ header files, ANSI C header files, and
special-purpose files
4. In /usr/include
The compiler searches for bracket-included files (of
the form #include <foo.h>) in this order:
1. In the directories named with -I options, if any
2. In the include directories for compiler-provided
C++ header files, ANSI C header files, and
special-purpose files
3. In /usr/include
Note - If the spelling matches the name of a standard
header file, also refer to "Standard Header Implementa-
tion" in the C++ User's Guide.
Interactions:
This option accumulates instead of overrides.
The -I- option allows you to override the default
search rules.
If -library=no%Cstd is specified, then the compiler-
provided Cstd header files are not searched.
Note - If -ptipath is not used, the compiler looks for
template files in -Ipathname. It is recommended that
you use -Ipathname instead of -ptipath.
Warnings
Never specify the compiler installation area,
/usr/include, /lib, /usr/lib, as search directories.
-I- Change the include-file search rules to the following:
o For include files of the form #include "foo.h",
search the directories in the following order:
1. The directories named with -I options (both
before and after -I-)
2. The directories for compiler-provided C++
header files, ANSI C header files, and
special-purpose files.
3. The /usr/include directory.
o For include files of the form #include <foo.h>,
search the directories in the following order:
1. The directories named with the -I options
that appear after -I-.
2. The directories for compiler-provided C++
header files, ANSI C header files, and
special-purpose files.
3. The /usr/include directory.
Warnings
Never specify the compiler installation area,
/usr/include, /lib, /usr/lib, as search directories.
Only the first -I- in a command line causes the
described behavior.
-i Tells the linker, ld(1), to ignore any LD_LIBRARY_PATH
or LD_LIBRARY_PATH_64 setting.
-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.
-inline
Same as -xinline.
-instances=a
Controls the placement and linkage of template
instances. The following table shows the meanings of
the values of a.
Value Meaning
extern Places all needed instances into the template
repository within comdat sections and gives
them global linkage. (If an instance in the
repository is out of date, it is reinstan-
tiated.)
Note: If you are compiling and linking in
separate steps and you specify
-instance=extern for the compilation step,
you must also specify it for the link step.
explicit Places explicitly instantiated instances into
the current object file within comdat sec-
tions and gives them global linkage. Does not
generate any other needed instances.
global Places all needed instances into the current
object file within comdat sections and gives
them global linkage.
semiexplicit
Places explicitly instantiated instances and
all instances needed by the explicit
instances into the current object file within
comdat sections and gives them global link-
age.
static Note: -instances=static is deprecated. There
is no longer any reason to use
-instances=static, because -instances=global
now gives you all the advantages of static
without the disadvantages. This option was
provided in earlier compilers to overcome
problems that do not exist in this version of
the compiler.
Places all needed instances into the current
object file and gives them static linkage.
Defaults:
If instances is not specified, -instances=global is
assumed.
Warnings:
static and semiexplicit values may produce invalid
results. See C++ User's Guide for more information.
-instlib=file
Use this option to inhibit the generation of a template
instances that are duplicated in a library, either
static or shared, and the current object. In general,
if your program shares large numbers of instances with
libraries, try -instlib=file and see whether compila-
tion time improves.
Values:
Use the file argument to specify the library that con-
tains template instances that could be generated by the
current compilation. The filename argument must con-
tain a forward slash '/' character. For paths relative
to the current directory, use dot-slash './'.
Defaults:
The -instlib=file option has no default and is only
used if you specify it. This option can be specified
multiple times and accumulates.
Example:
Assume that the libfoo.a and libbar.so libraries
instantiate many template instances that are shared
with your source file a.cc. Adding -instlib=file and
specifying the libraries helps reduce compile time by
avoiding the redundancy.
example% CC -c -instlib=./libfoo.a -instlib=./libbar.so
a.cc
Interactions:
When you compile with -g, if the library specified with
-instlib=file is not compiled with -g, those template
instances will not be debuggable. The workaround is to
avoid -instlib=file when you use -g.
The -L path is not searched to find file.
Warning
If you specify a library with -instlib, you must link
with that library.
See Also:
-template, -instances, -pti
-KPIC
(SPARC)(Obsolete) Use -xcode=pic32 instead.
(x86) Same as -Kpic on x86 architectures.
-Kpic
(SPARC)(Obsolete) Use -xcode=pic13 instead.
(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 the temporary files that are created during
compilation. Along with -verbose=diags, this option is
useful for debugging.
-Lpath
Adds path to the library search paths.
This option is passed to ld. The linker searches the
directory specified by path before it searches the
compiler-provided directories.
Interactions:
This option accumulates instead of overrides.
Warnings
Never specify the /usr/include, lib, /usr/lib, or the
compiler installation area as search directories.
-llib
Add library liblib.a or liblib.so to linker's list of
search libraries.
This option is passed to ld. Normal libraries have
names such as liblib.a or liblib.so where the lib and
.a or .so parts are required. You can specify the lib
part with this option. Put as many libraries as you
want on a single command line; they are searched in the
order specified with -Lpath.
Use this option after your object file names.
Interactions:
This option accumulates instead of overrides.
Warnings:
If you are building a multithreaded application or
linking your application to a multithreaded library,
you must compile and link your program with the -mt
option instead of linking your application directly
with -lthread. (See -mt)
-libmieee
Use -xlibmieee.
-libmil
Use -xlibmil.
-library=lib[,lib...]
Incorporates specified CC-provided libraries into com-
pilation and linking.
When the -library option is used to specify a CC-
provided library, the proper -I paths are set during
compilation and the proper -L, -Y, -P, and -R paths and
-l options are set during linking.
Values:
The prefix no% applied to a suboption disables that
suboption.
The following table shows the meanings of the values
for lib.
Value Meaning
[no%]f77 Deprecated. Do not use. Use
-xlang=f77.
[no%]f90 Deprecated. Do not use. Use
-xlang=f90.
[no%]f95 Deprecated. Do not use. Use
-xlang=f95.
[no%]rwtools7 Use classic-iostreams Tools.h++
version 7.
[no%]rwtools7_dbg Use debug-enabled Tools.h++ version
7.
[no%]rwtools7_std Use standard-iostreams Tools.h++
version 7.
[no%]rwtools7_std_dbg
Use debug_enabled standard-
iostreams Tools.h++ version 7.
[no%]interval Deprecated. Do not use. Use -xia.
[no%]iostream Use libiostream, the classic ios-
treams library.
[no%]Cstd Use libCstd, the C++ standard
library. include the compiler-
provided C++ standard library
header files.
[no%]stlport4 Use STLport's implementation of the
standard library. If you specify
-library=stlport4, the command
expands to
-library=no%Cstd,stlport4.
[no%]stlport4_dbg Use STLport's debug-enabled
library.
[no%]stdcxx4 Use the Apache stdcxx version 4
library installed as part of Oracle
Solaris, instead of the default
libCstd. This option also sets the
-mt option implicitly. The stdcxx
library requires multi-threading
mode. This option must be used
consistently on every compilation
and link command in the entire
application. Code compiled with
-library=stdcxx4 cannot be used in
the same program as code compiled
with the default -library=Cstd or
the optional -library=stlport4.
[no%]Crun Use libCrun, the C++ runtime
library
[no%]gc Use libgc, garbage collection.
[no%]sunperf Use the Sun Performance Library.
%none Use no C++ libraries except for
libCrun.
Note that -library=libC is not allowed.
Defaults:
The libCstd library is always included unless it is
specifically excluded by using -library=%none,
-library=no%Cstd, -library=stdcxx4, or
-library=stlport4.
Also, the libm and libc libraries are always included,
even if you specify -library=%none. libCrun is always
included.
Examples:
To link without any C++ libraries (except libCrun),
use:
example% CC -library=%none
To include the classic-iostreams Rogue Wave tools.h++
library use:
example% CC -library=rwtools7,iostream
To include the standard-iostreams Rogue Wave tools.h++
library use:
example% CC -library=rwtools7_std
When you include the classic-iostreams Rogue Wave tools
library you must also include libiostream (see the C++
Migration Guide for additional information). You can
use the standard-iostreams Rogue Wave tools library in
standard mode only. The following command examples show
both valid and invalid use of the Rogue Wave tools.h++
library options.
Valid:
example% CC -compat -library=rwtools7 foo.cc
Invalid:
example% CC -compat -library=rwtools7_std foo.cc
Valid, classic iostreams
example% CC -library=rwtools7,iostream foo.cc
Invalid
example% CC -library=rwtools7 foo.cc
Valid, standard iostreams
example% CC -library=rwtools7_std foo.cc
Invalid
example% CC -library=rwtools7_std,iostream foo.cc
If you include both libCstd and libiostream, you must
be careful to not use the old and new forms of ios-
treams (for example, cout and std::cout) within a pro-
gram to access the same file. Mixing standard iostreams
and classic iostreams in the same program is likely to
cause problems if the same file is accessed from both
classic and standard iostream code.
If -xnolib is specified, -library is ignored.
Interactions:
If a library is specified with -library, the proper -I
paths are set during compilation. The proper -L, -Y,
-P, -R, paths and -l options are set during linking.
This option accumulates instead of overrides.
Only one rwtool library can be used at a time and you
cannot use any rwtool library with -library=stlport4 or
-library=stdcxx4..
You can specify at most one of either
-library=stlport4, -library=stdcxx4, or -library=Cstd
on the same command line.
You cannot use -library=sunperf and -xlic_lib=sunperf
on the same command line.
Use of the -library option ensures that the -l options
for the specified libraries are emitted in the right
order. For example, the -l options are passed to ld in
the order -lrwtool -liostream for both
-library=rwtools7,iostream and
-library=iostream,rwtools7.
When you use the interval arithmetic libraries, you
must include one of the following libraries: libC,
libCstd, or libiostreams.
The specified libraries are linked before the system
support libraries are linked.
Warnings:
The so-called "Classic" iostreams is the original 1986
version of iostreams, which was replaced in the 1998
C++ standard. It is selected through the
-library=rwtools7,iostream option. No two implementa-
tions of "classic" iostreams are the same, so apart
from being obsolete, code using it is not portable.
Note that this library will be discontinued in future
Oracle Solaris Studio releases.
The RW Tools.h++ toolset provided with legacy Sun Stu-
dio and with Oracle Solaris Studio dates from the
1990's and has not been significantly updated since.
The time/date classes have serious issues regarding
daylight savings time that cannot be fixed. (The func-
tionality of this toolset is currently available in the
C++ Standard Library, and in open source libraries like
BOOST.) RW Tools.h++ is selected by the options
-library=rwtools7 or -library=rwtools7_std and will be
discontinued in future Oracle Solaris Studio releases.
Do not redefine or modify any of the configuration mac-
ros for STLport or Oracle Solaris Studio C++ libraries.
The libraries are configured and built in a way that
works with the C++ compiler. libCstd, libstdcxx4, and
Tool.h++ are configured to inter-operate so modifying
the configuration macros results in programs that will
not compile, will not link, or do not run properly.
If you compile and link in separate steps, the set of
-library options that appear in the compile command
must appear in the link command.
The set of libraries is not stable and might change
from release to release.
The stlport4, stdcxx4, Cstd and iostream libraries pro-
vide their own implementation of I/O streams. Specify-
ing more than one of these with the -library option can
result in undefined program behavior.
See also:
-I,-l,-R, -staticlib, -xia, -xlang, -xnolib,
C++ Interval Arithmetic Programming Reference,
Tools.h++ User's Guide,
Tools.h++ Class Library Reference,
C++ Standard Reference Library
-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 Oracle 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 Oracle Solaris, -m32 is the default. On Linux sys-
tems supporting 64-bit programs, -m64 -xarch=sse2 is
the default.
See also -xarch.
-mc Removes duplicate strings from the .comment section of
the object file. When you use the -mc option, the
mcs -c command is invoked. (See the mcs(1) man page.)
-misalign
(SPARC) Obsolete. You should not usethis option. Use
the -xmemalign=2i option instead.
-mr[,string]
Removes all strings from the .comment section of the
object file and, if string is supplied, places string
in that section. If the string contains blanks, the
string must be enclosed in quotation marks. When you
use this option, the command mcs -d [-a string] is
invoked.
Interactions:
This option is not valid when -S is specified.
-mt[={yes|no}]
Use this option to compile and link multithreaded code
using the Oracle 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 Oracle Solaris threads, include the thread.h
header file and compile with the -mt=yes option. To use
POSIX threads on Oracle 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 behavior is not desired use the option -mt=no.
The option -mt is equivalent to -mt=yes.
See also: -xnolib
-native
Use -xtarget=native.
-noex
Use -features=no%except.
-nofstore
(x86) Cancel -fstore on command line
Cancels forcing expressions to have the precision of
the destination variable invoked by -fstore.
-nofstore is invoked by -fast. -fstore is the usual
default.
-nolib
Use -xnolib.
-nolibmil
Use -xnolibmil.
-noqueue
(Obsolete). This option silently does nothing.
-norunpath
Does not build the path for shared libraries into the
executable.
If an executable file uses shared libraries, then the
compiler normally builds in a path that points the run-
time linker to those shared libraries. To do so, the
compiler passes the -R option to ld. The path depends
on the directory where you have installed the compiler.
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.
Interactions:
If you use any shared libraries under the compiler
installed area (default location <installpath>/lib )
and you also use -norunpath, then you should either use
the -R option at link time or set the environment vari-
able LD_LIBRARY_PATH at run time to specify the loca-
tion of the shared libraries. This will allow the run-
time linker to find the shared libraries.
-O The -O macro expands to -xO3. Compiling with this
option yields higher run-time performance. However,
optimization level -xO3 may be inappropriate for pro-
grams that rely on all variables being automatically
considered volatile. Typical programs that might have
this assumption are device drivers and older multi-
threaded applications that implement their own syn-
chronization primitives. The work around is to compile
with -xO2 instead of -O.
-O[level]
Use -xOlevel.
-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.
filename must have an appropriate suffix. When used
with -c, filename specifies the target .o object file;
with -G it specifies the target .so library file. This
option and its argument are passed to ld.
+p Ignore non-standard preprocessor asserts.
Defaults:
If +p is not present, the compiler recognizes nonstan-
dard preprocessor asserts.
Interactions:
If +p is used, the sun, unix, sparc, and i386 macros
are not defined.
-P Only preprocesses source: does not compile. (Outputs a
file with a .i suffix.)
This option does not include preprocessor-type line
number information in the output.
-p Obsolete See -xpg.
-pentium
(x86 platform) Use -xtarget=pentium.
-pg (Obsolete) Use -xpg.
-PIC SPARC: Same as -xcode=pic32.
x86: Same as -KPIC.
-pic SPARC: Same as -xcode=pic13.
x86: Same as -Kpic.
-pta Use -template=wholeclass.
-ptipath
Specifies an additional search directory for template
source.
This option is an alternative to the normal search path
set by -Ipathname. If the -ptipath flag is used, the
compiler looks for template definition files on this
path and ignores the -Ipathname flag.
Using the -Ipathname flag instead of -ptipath produces
less confusion.
Interactions:
This option accumulates instead of overrides.
-pto Use -instances=static.
-ptv Use -verbose=template.
-Qoption phase option[,option...]
Passes option to the compilation phase.
To pass multiple options, specify them in order as a
comma-separated list. Options that are passed to com-
ponents with -Qoption can be reordered. Options that
the driver recognizes are kept in the correct order. Do
not use -Qoption for options that the driver already
recognizes. For example, the C++ compiler recognizes
the -z option for the linker (ld). If you issue a com-
mand like this
CC -G -zallextract mylib.a -zdefaultextract ... //
correct
the -z options are passed in order to the linker. But
if you specify the command like this
CC -G -Qoption ld -zallextract mylib.a -Qoption ld
-zdefaultextract ... // error
the -z options can be reordered, giving incorrect
results.
The following table shows the possible values for
phase.
SPARC x86
ccfe ccfe
iropt iropt
cg ube
CClink CClink
ld ld
Examples:
When the CC driver invokes ld in the following command,
-Qoption passes the -i option to ld:
example% CC -Qoption ld -i test.cc
Warnings:
Be careful to avoid unintended effects. For example,
-Qoption ccfe -features=bool,iddollar
is interpreted as
-Qoption ccfe -features=bool -Qoption ccfe iddollar
The correct usage is
-Qoption ccfe -features=bool,-features=iddollar
Note that these features do not require -Qoption and
are used only as an example.
-qoption phase option
Use -Qoption.
-qp Same as -p.
-Qproduce sourcetype
Causes the CC driver to produce source code of the type
sourcetype. Source code types are shown in the follow-
ing table.
Value Meaning
.i Preprocessed C++ source from ccfe
.o Object file from the code generator
.s Assembler source from the code generator
-qproduce sourcetype
Use -Qproduce.
-Rpath[:path...]
Builds dynamic library search paths into the executable
file.
This option is passed to ld.
Defaults:
If the -R option is not present, the default library
search path is recorded in the output object and passed
to the runtime linker. The default library search order
can be seen by using the -dryrun option and examining
the -Y option of the ld invocation.
Interactions:
This option accumulates instead of overrides.
If both the LD_RUN_PATH environment variable and the -R
option are specified, then the path from -R is scanned,
and the path from LD_RUN_PATH is ignored.
See also:
-norunpath
-S Compiles and generates only assembly code. This option
causes the CC driver to compile the program and output
an assembly source file, but not assemble the program.
The assembly source file is named with a .s suffix.
-s Strip the symbol table from the executable file. This
option removes all symbol information from output exe-
cutable files. This option is passed to ld.
-staticlib=l[,l...]
Indicates which C++ libraries specified by the -library
option (including its defaults), by the -xlang option,
and by the -xia option are to be linked statically.
Values:
l must be one of the following values.
Value Meaning
[no%]library Link library statically. The valid
values for library are all valid values
for -library (except %all and %none )
all the valid values for -xlang, and
interval (to be used in conjunction with
-xia). Use the prefix no% to disable
linking library.
%all Link statically all the libraries speci-
fied by the -library option, all the
library specified in the -xlang option,
and, if -xia is specified, the interval
libraries.
%none Link no libraries specified in the
-library option and the -xlang option
statically. If -xia is specified in the
command line, link no interval libraries
statically.
Defaults:
If -staticlib is not specified, -staticlib=%none is
assumed.
Interactions:
This option accumulates instead of overrides.
The -staticlib option only works for the C++ libraries
that are selected explicitly with the -xia, the -xlang
option, and the -library option, in addition to the C++
libraries that are selected implicitly by default. Cstd
and Crun are selected by default.
Examples:
The following command links libCrun statically because
Crun is a default value for -library.
(correct)
example% CC -staticlib=Crun test.cc
However, the following command does not link libgc
because libgc is not linked unless explicitly specified
with the -library option.
(incorrect)
example% CC -staticlib=gc test.cc
With the following command, the librwtool library is
linked dynamically. Because librwtool is not a default
library and is not selected using the -library option,
-staticlib has no effect.
(incorrect)
example% CC -lrwtool -library=iostream \
-staticlib=rwtools7
This command links the Tools.h++ library statically.
(correct)
example% CC -library=rwtools7,iostream \
-staticlib=rwtools7
Warnings:
The set of allowable values for libraries is not stable
and might change from release to release.
On Oracle Solaris platforms, system libraries not
available as static libraries.
The options -staticlib=Crun and -staticlib=Cstd do not
work on 64-bit Oracle Solaris x86 platforms. It is
recommended not to link these libraries statically on
any platform. In some cases, static linking can prevent
a program from working.
-sync_stdio=[yes|no]
Use this option when your run-time performance is
degraded due to the synchronization between C++ ios-
treams and C stdio. Synchronization is needed only when
you use iostreams to write to cout and stdio to write
to stdout in the same program. The C++ standard
requires synchronization so the C++ compiler turns it
on by default. However, application performance is
often much better without synchronization. If your pro-
gram does not write to both cout and stdout, you can
use the option -sync_stdio=no to turn off synchroniza-
tion.
Defaults:
If you do not specify -sync_stdio, the compiler sets it
to -sync_stdio=yes.
Examples:
Consider the following example:
#include <stdio.h>
#include <iostream>
int main()
{
std::cout << "\nHello ";
printf("beautiful ");
std::cout << "world!";
printf("\n");
}
With synchronization, the program prints on a line by
itself
Hello beautiful world!
Without synchronization, the output gets scrambled.
Warnings:
This option is only effective for linking of execut-
ables, not for libraries.
-temp=path
Defines the directory for temporary files.
This option sets path as the directory for the tem-
porary files which are generated during the compilation
process. The compiler gives precedence to the value set
by -temp over the value of TMPDIR.
See also:
-keeptmp
-template=a[,a...]
Enables/disables various template options.
a must be one of the following values. The prefix no%
applied to a suboption disables that suboption.
Value Meaning
[no%]extdef search for template definitions in
separate source files.
[no%]geninlinefuncs instantiate inline member func-
tions of the explicitly instan-
tiated class template which were
not generated previously.
[no%]wholeclass Instantiate a whole template
class, rather than only those func-
tions that are used. You must
reference at least one member of
the class; otherwise, the compiler
does not instantiate any members
for the class.
When -template=no%extdef is specified, the compiler
predefines the macro _TEMPLATE_NO_EXTDEF.
Defaults:
-template=no%wholeclass,extdef,no%geninlinefuncs
-time
Use -xtime.
-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
Deletes initial definition of the preprocessor symbol
name. This option removes any initial definition of the
macro symbol name that was created by -D on the same
command line, including those implicitly placed there
by the command-line driver.
This option has no effect on any other predefined mac-
ros nor on macro definitions in source files.
To see the -D options that are placed on the command
line by the command-line driver, add the -dryrun option
to your command line.
You can specify multiple -U options on the command
line.
Examples:
The following command undefines the predefined symbol
__sun. Preprocessor statements in test.cc such as
#ifdef(__sun) will sense that the symbol is undefined.
example% CC -U__sun test.cc
Interactions:
This option accumulates instead of overrides.
All -U options are processed after any -D options that
are present.
-unroll=n
Same as -xunroll=n.
-V Same as -verbose=version.
-v Same as -verbose=diags.
-verbose=a[,a...]
Controls compiler verbosity.
a must be one of the following values. The prefix no%
applied to a suboption disables that suboption when
used with %all.
Value Meaning
[no%]template Turn on the template instantiation
verbose mode, sometimes called the
verify mode. The verbose mode
displays each phase of instantia-
tion as it occurs during
compilation.
[no%]diags Print the command line for each
compilation pass.
[no%]version Direct the CC driver to print the
names and version numbers of the
programs it invokes.
%all Invokes all the above.
%none Invokes none of the above.
Defaults:
If -verbose is not specified, the compiler assumes
-verbose=%none.
Interactions:
This option accumulates instead of overrides.
-Wc,arg
Passes the argument arg to component 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 immediately preceding backslash (\) character; the
backslash is removed from the resulting argument.) All
-W arguments are passed after the regular command-line
arguments.
c can be one of the following:
a Assembler: (fbe), (gas)
c C++ code generator: (cg)(SPARC)
d CC driver
l Link editor (ld)
m mcs
O (Capital letter 'O') Interprocedural optim-
izer
o Postoptimizer
p Preprocessor (cpp)
0 (The number zero) Compiler (ccfe)
2 Optimizer: (iropt)
Note: You cannot use -Wd to pass the CC options listed
in this man page to the C++ compiler.
-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 Identifies code that might have unintended conse-
quences.
(The +w option no longer generates a warning if a func-
tion is too large to inline or if a declared program
element is unused. These warnings do not identify real
problems in the source, and were thus inappropriate to
some development environments. Removing these warnings
from +w enables more aggressive use of +w in those
environments. These warnings are still available with
the +w2 option.)
Generates additional warnings about questionable con-
structs that are:
o Nonportable
o Likely to be mistakes
o Inefficient
Defaults:
If +w is not specified, the compiler warns about con-
structs that are almost certainly problems.
Interactions:
Some C++ standard headers result in warnings when com-
piled with +w.
+w2 Emits the same warnings as +w as well as warnings about
technical violations that are probably harmless, but
that might reduce the maximum portability of your pro-
gram.
The +w2 option no longer warns about the use of
implementation-dependent constructs in the system
header files. Because the system header files are the
implementation, the warning was inappropriate. Removing
these warnings from +w2 enables more aggressive use of
the option.
Warnings:
Some Oracle Solaris software and C++ standard header
files result in warnings when compiled with +w2.
-w Suppresses warning messages.
This option causes the compiler not to print warning
messages. Some warnings, particularly warnings regard-
ing serious anachronisms, cannot be suppressed.
-Xlinker arg
Passes arg to linker ld(1)
Equivalent to -z arg
-Xm Use -features=iddollar.
-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 Oracle 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[= n]
Allows the compiler to perform type-based alias-
analysis.
Defaults:
n must be any, simple, or compatible.
o -xalias_level
If you do not specify -xalias_level, the compiler
sets it to -xalias_level=any. If you specify
-xalias_level without any values, the compiler sets
it to -xalias_level=compatible.
o -xalias_level=any
At this level of analysis, the compiler assumes that
any type may alias any other type. However, despite
this assumption, some optimization is possible.
o -xalias_level=simple
The compiler assumes that fundamental types are not
aliased. Specifically, a storage object with a
dynamic type that is one of the following fundamental
types:
* char, signed char, and unsigned char,
* wchar_t
* short int, unsigned short int,
* int, unsigned int,
* long int, unsigned long int,
* long long int, unsigned long long int,
* float, double, long double,
* enumeration types,
* data pointer types,
* function pointer types,
* data member pointer types, or
* function member pointer types
will only be accessed through lvalues of the follow-
ing types:
* the dynamic type of the object,
* a constant or volatile qualified version
of the dynamic type of the object,
* a type that is the signed or unsigned type
corresponding to the dynamic type of the
object,
* a type that is the signed or unsigned type
corresponding to a constant or volatile
qualified version of the dynamic type of
the object,
* an aggregate or union type that includes
one of the aforementioned types among its
members (including, recursively, a member of
a subaggregate or contained union), or
* a char or unsigned char type.
o -xalias_level=compatible
The compiler assumes that layout-incompatible types
are not aliased. A storage object is only accessed
through lvalues of the following types:
* the dynamic type of the object,
* a constant or volatile qualified version of
the dynamic type of the object,
* a type that is the signed or unsigned type
which corresponds to the dynamic type of
the object,
* a type that is the signed or unsigned type
which corresponds to the constant or volatile
qualified version of the dynamic type of
the object,
* an aggregate or union type that includes one
of the aforementioned types among its members
(including, recursively, a member of a
subaggregate or contained union),
* a type that is (possibly constant or volatile
qualified) base class type of the dynamic
type of the object, or
* a char or unsigned char type.
The compiler assumes that the types of all references
are layout compatible with the dynamic type of the
corresponding storage object. Two types are layout-
compatible under the following conditions:
* If two types are the same type, then they are
layout-compatible types.
* If two types differ only in constant or
volatile qualification, then they are
layout-compatible types.
* For each of the signed integer types, there
exists a corresponding (but different)
unsigned integer type. These corresponding
types are layout compatible.
* Two enumeration types are layout-compatible if
they have the same underlying type.
* Two Plain Old Data (POD) struct types are
layout compatible if they have the same number
of members, and corresponding members
(in order) have layout compatible types.
* Two POD union types are layout compatible
if they have the same number of members, and
corresponding members (in any order) have
layout compatible types.
References may be non-layout-compatible with the
dynamic type of the storage object under limited cir-
cumstances:
* If a POD union contains two or more POD
structs that share a common initial sequence,
and if the POD union object currently contains
one of those POD structs, it is permitted to
inspect the common initial part of any of
them. Two POD structs share a common initial
sequence if corresponding members have layout
compatible types and, as applicable to bit
fields, the same widths, for a sequence of
one or more initial members.
* A pointer to a POD struct object, suitably
converted using a reinterpret_cast, points
to its initial member, or if that member is
a bit field, to the unit in which it resides.
Interactions:
The compiler does not perform type-based alias analysis
at optimization level -xO2 and below.
-xanalyze={code|no}
Compile with this option to produce a static analysis
of the source code that can be viewed using the Code
Analyzer.
When compiling with -xanalyze=code and linking in a
separate step, include -xanalyze=code also on the link
step.
The default is -xanalyze=no.
See the Oracle Solaris Studio Code Analyzer documenta-
tion for further information.
-xannotate[={yes|no}]
(Oracle Solaris) Instructs the compiler to create
binaries that can later be used by the optimization and
observability tools binopt(1), code-analyzer(1), dis-
cover(1), collect(1), and uncover(1).
The default is -xannotate=yes. Specifying -xannotate
without a value is equivalent to -xannotate=yes.
For optimal use of the optimization and observability
tools, -xannotate=yes must be in effect at both com-
pile and link time.
Compile and link with -xannotate=no to produce slightly
smaller binaries and libraries when optimization and
observability tools will not be used.
This option is not available on Linux systems.
-xar Creates archive libraries.
When building a C++ archive that uses templates, it is
necessary in most cases to include in the archive those
template functions that are instantiated in the tem-
plate repository. The template repository is used only
when at least one object file was compiled with the
-instances=extern option. Using with -xar automati-
cally adds those templates to the archive as needed.
However, since the compiler default is not to use a
template cache, the -xar option is often not needed.
You can use the standard system ar(1) command to create
.a archive files of C++ code, unless some code was com-
piled with -instances. In that case use the -xar com-
piler option instead.
Values:
Specify -xar to invokes ar -c-r and create an archive
from scratch.
Examples:
The following command archives the template functions
contained in the repository and the object files.
example% CC -xar -o libmain.a a.o b.o c.o
Warnings:
Do not add .o files from the template repository on the
command line.
Do not use the ar command directly for building
archives. Use CC -xar to ensure that template instan-
tiations are automatically included in the archive.
See Also:
ar(1)
-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: The compiler and linker will mark .o files and
executables that require a particular instruction set
architecture (ISA) so that the executable will not be
loaded at runtime if the running system does not sup-
port that particular ISA.
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 indicates
the memory model, except for compatibility with previ-
ous releases, as indicated below.
Code using _asm statements or inline templates (.il
files) that use architecture-specific instructions
might require compiling with the appropriate -xarch
values to avoid compilation errors.
If you compile and link in separate steps, make sure
you specify the same value for -xarch in both steps.
Values (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. (Oracle 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
(Oracle Solaris only)
This option is equivalent to
-m64 -xarch=native and is provided for compa-
tibility with earlier releases.
Values on 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.
sparc4 Compile for the SPARC4 version of the SPARC-
V9 ISA.
Enables the compiler to use instructions from
the SPARC-V9 instruction set, plus the
UltraSPARC extensions, which includes VIS
1.0, the UltraSPARC-III extensions, which
includes VIS2.0, the fused floating-point
multiply-add instructions, VIS 3.0, and
SPARC4 instructions.
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 for x86 platforms:
Value Meaning
pentium_pro
Limits the instruction set to 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 (Oracle
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 (Oracle
Solaris only)
avx Adds the Advanced Vector Extensions to the
Intel x86 instruction set.
aes Adds the Advanced Encryption Standard
instructions. Note that the compiler does
not generate AES instructions automatically
when -xarch=aes is specified unless the
source code includes .il inline code, _asm
statements, or assembler code that use AES
instructions, or references to AES intrinsic
functions.
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
Defaults:
If -xarch=isa is not specified, the defaults are:
-xarch=generic on SPARC platforms
-xarch=generic on x86 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 emitted.
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.
Use the OMP_NUM_THREADS environment variable to specify
the number of threads to use when running a program
automatically parallelized by the -xautopar compiler
option. If OMP_NUM_THREADS is not set, the default
number of threads used is 2. To use more threads, set
OMP_NUM_THREADS to a higher value. Set OMP_NUM_THREADS
to 1 to run with just one thread. In general, set
OMP_NUM_THREADS to the available number of virtual pro-
cessors on the running system, which can be determined
by using the Oracle Solaris psrinfo(1) command. 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.
-xbinopt={prepare|off}
(SPARC) This option is now obsolete and will be removed
in a future release of the compilers. See -xannotate.
Instructs the compiler to prepare the binary for later
optimizations, transformations and analysis (see
binopt(1)). This option may be used for building exe-
cutables 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.cc b.cc
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[={%all|%default|%none}]
Use the -xbuiltin option to improve the optimization of
code that calls standard library functions. This
option lets the compiler substitute intrinsic functions
or inline system functions where profitable for perfor-
mance. See the er_src(1) man page to learn how to read
compiler commentary output to determine which functions
were substituted by the compiler.
With -xbuiltin=%all, substitutions can cause the set-
ting of errno to become unreliable. If your program
depends on the value of errno, avoid this option.
-xbuiltin=%default only inlines functions that do not
set errno. The value of errno is always correct at any
optimization level, and can be checked reliably. With
-xbuiltin=%default at -xO3 or lower, the compiler will
determine which calls are profitable to inline, and not
inline others.
The -xbuiltin=%none option turns off all substitutions
of library functions.
If you do not specify -xbuiltin, the default is
-xbuiltin=%default when compiling with an optimization
level -xO1 and higher, and -xbuiltin=%none at -xO0. If
you specify -xbuiltin without an argument, the default
is -xbuiltin=%all and the compiler substitutes intrin-
sics or inlines standard library functions much more
aggressively.
Compiling with -fast adds -xbuiltin=%all.
Note: The -xbuiltin option only inlines global func-
tions defined in system header files, never static
functions defined by the user. User code that attempts
to interpose on global functions may result in unde-
fined behavior.
-xcache=c
Define cache properties for use by optimizer.
c must be one of the following:
o generic
o native
o s1/l1/a1[/t1]
o s1/l1/a1[/t1]:s2/l2/a2[/t2]
o s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
The si, li, ai, and ti, 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
ti The number of hardware threads sharing the cache at
level i The ti parameters are optional. A value of 1
is used if not present.
This option specifies the cache properties that the
optimizer can use. It does not guarantee that any par-
ticular cache property is used.
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.
The -xcache values are:
generic
Define the cache properties for good performance
on most platforms. This is the default.
native
Define the cache properties for good performance
on this host platform.
s1/l1/a1[/t1]
Define level 1 cache properties.
s1/l1/a1[/t1]:s2/l2/a2[/t2]
Define levels 1 and 2 cache properties.
s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
Define levels 1, 2, and 3 cache properties.
-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.
Values:
You can substitute 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.
Defaults:
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.
Interactions:
The -xchar option changes the range of values for the
type char only for code compiled with -xchar. This
option does not change the range of values for type
char in any system routine or header file. In particu-
lar, the value of CHAR_MAX and CHAR_MIN, as defined by
limits.h, do not change when this option is specified.
Therefore, CHAR_MAX and CHAR_MIN no longer represent
the range of values encodable in a plain char.
Warnings:
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 Oracle 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 so that it does not depend on
whether type char is signed or unsigned. The sign of
type char varies among compilers and operating systems.
-xcheck[=n]
Enables a runtime check for stack overflow.
Values:
n must be one of the following values.
Value Meaning
%all Perform all checks.
%none Does not perform any checks.
stkovf Perform a runtime check for stack over-
flow 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 over-
flow differently than it handles other
address-space violations, see
sigaltstack(2).
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.
Interactions:
If you specify -xcheck without any arguments, the com-
piler defaults to -xcheck=%none.
-xchip=c
Specifies the target processor for use by the optim-
izer.
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.
This option affects:
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:
Value Meaning
generic Uses timing properties for good performance
on most SPARC processors.
This is the default value that directs the
compiler to use the best timing properties
for good performance on most SPARC proces-
sors, without major performance degradation
on any of them.
native Set the parameters for the best performance
on the host environment.
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.
T3 Optimize for the SPARC T3 processor.
T4 Optimize for the SPARC T4 processor.
sparc64viiplus
Optimize for the SPARC64 VII plus processor.
The -xchip values for x86 platforms are:
Value Meaning
generic Optimize for good performance on most x86
processors.
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 Intel Pentium processor.
pentium_pro
Optimize for the Intel Pentium Pro processor.
pentium3 Optimize for the Intel Pentium 3 processor
pentium4 Optimize for the Intel Pentium 4 processor
sandybridge
Optimize for the Intel Sandy Bridge processor
westmere Optimize for the Intel Westmere processor
amdfam10 Optimize for the AMD FAM10 processor
-xcode=a
(SPARC) Specifies 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 -m64
-xcode=abs64, but these will be inefficient. Shared
objects built with -m64 -xcode=abs32 or -m64
-xcode=abs44 will not work.
The following table shows the -xcode values.
Value Meaning
abs32 Generate 32-bit absolute addresses, which are
fast, but have limited range. Code + data +
bss size is limited to 2**32 bytes. This is
the default on 32-bit architectures.
abs44 SPARC: Generate 44-bit absolute addresses,
which have moderate speed and moderate range.
Code + data + bss size is limited to 2**44
bytes. This is the default on 64-bit archi-
tectures. Do not use this value with dynamic
(shared) libraries.
abs64 SPARC: Generate 64-bit absolute addresses,
which are slow, but have full range. Avail-
able only on 64-bit architectures.
pic13 Generates position-independent code (small
model), which is fast, but has limited range.
Equivalent to -Kpic. Permits references to at
most 2**11 unique external symbols on 32-bit
architectures, 2**10 on 64-bit architectures.
pic32 Generates position-independent code (large
model), which is slow, but has full range.
Equivalent to -KPIC. Permits references to at
most 2**30 unique external symbols on 32-bit
architectures, 2**29 on 64-bit architectures.
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 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 exceed 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.
Defaults:
The default is -xcode=abs32 for 32-bit architectures.
The default is -xcode=abs44 for 64-bit processors.
Warnings:
When you compile and link in separate steps, you must
use the same -xarch option in the compile step and the
link step.
-xdebugformat=[stabs|dwarf]
The C++ compiler default format of debugger informa-
tion is the dwarf format -xdebugformat=dwarf.
Use this option as a way of accessing the new format
for the purpose of porting tools. There is no need to
use this option unless you maintain software which
reads debugger information, or unless a specific tool
tells you that it requires debugger information in one
of these formats.
-xdebugformat=stabs generates debugging information
using the stabs standard format. The stabs format is no
longer supported.
-xdebugformat=dwarf generates debugging information
using the dwarf 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 details of any specific fields or values in either
stabs or dwarf are also evolving.
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 use -xautopar. If you do so,
the -xdepend optimization is done for multiple-
processor systems.
See Also: -xprefetch_auto_type
-xdumpmacros[=value[,value...]]
Use this option when you want to see how macros are
behaving in your program. This option provides informa-
tion such as macro defines, undefines, and instances of
usage. It prints output to the standard error (stderr),
based on the order macros are processed. The -xdumpmac-
ros option is in effect until the end of the file or
until it is overridden by the dumpmacros or
end_dumpmacros pragma.
Values:
The prefix no% applied to a suboption disables that
suboption.
Value Meaning
[no%]defs Print all macro defines
[no%]undefs Print all macro undefines
[no%]use Print information about macros used
[no%]loc Print location (path name and line
number) also for defs, undefs, and use
[no%]conds Print use information for macros used
in conditional directives
[no%]sys Print all macros defines, undefines,
and use information for macros in system
header files
%all Sets the option to
-xdumpmacros=defs,undefs,use,loc,conds,sys.
A good way to use this argument is in
conjunction with the [no%] form of the
other arguments. For example,
-xdumpmacros=%all,no%sys would exclude
system header macros from the output but
still provide information for all other
macros.
%none Do not print any macro information
The option values accumulate so specifying
-xdumpmacros=sys -xdumpmacros=undefs has the same
effect as -xdumpmacros=undefs,sys.
Note: The sub-options loc, conds, and sys are qualif-
iers for defs, undefs and use options. By themselves,
loc, conds, and sys have no effect. For example,
-xdumpmacros=loc,conds,sys has no effect.
Defaults:
If you specify -xdumpmacros without any arguments, it
means -xdumpmacros=defs,undefs,sys. If you do not
specify -xdumpmacros,
it defaults to -xdumpmacros=%none.
-xe Check only for syntax and semantic errors. When you
specify -xe the compiler does not produce any object
code. The output for -xe is directed to stderr.
Use the -xe option if you do not need the object files
produced by compilation. For example, if you are trying
to isolate the cause of an error message by deleting
sections of code, you can speed the edit and compile
cycle by using -xe.
-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.
Values:
The prefix no% applied to a suboption disables that
suboption.
v can be one of the following values:
Value Meaning
[no%]func fragment functions into separate sec-
tions.
[no%]gbldata fragment global data (variables with
external linkage) into separate sec-
tions.
[no%]lcldata fragment local data (variables with
internal linkage) into separate sec-
tions.
%all Fragment functions, global data, and
local data.
%none Fragment nothing.
Defaults:
If you do not specify -xF, the default is -xF=%none. If
you specify -xF without any arguments, the default is
-xF=%none,func.
Interactions:
Using -xF=lcldata inhibits some address calculation
optimizations, so you should only use this flag when it
is experimentally justified.
See Also:
analyzer(1), ld(1)
-xhelp=flags
Displays a brief description of each compiler flag.
-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.
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), which is the default with
current Oracle Solaris Studio compilers.
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.cc 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 example.cc
For more information on hardware counter-based profil-
ing, see the Performance Analyzer manual.
-xia Link the appropriate interval arithmetic libraries and
set a suitable floating-point environment.
The -xia option is a macro that expands to
-fsimple=0 -ftrap=%none -fns=no -library=interval.
Interactions:
To use the interval arithmetic libraries, include
<suninterval.h>.
When you use the interval arithmetic libraries, you
must include one of the following libraries: Cstd, or
iostreams. See -library for information on including
these libraries.
Warnings:
If you use intervals and you specify different values
for -fsimple, -ftrap, or -fns, then your program may
have incorrect behavior.
C++ interval arithmetic is experimental and evolving.
The specifics may change from release to release.
On x86 platforms, -xarch=sse2 must be specified for
32-bit compilations. Also, -xia is not available on
Linux platforms.
See also:
-library
C++ Interval Arithmetic Programming Reference
-xinline[=func_spec[,func_spec...]]
Specifies which user-written routines can be inlined by
the optimizer at -xO3 or higher.
Values:
The prefix no% applied to a suboption disables that
suboption.
func_spec can be one of the following:
Value Meaning
%auto Enable automatic inlining at optim-
ization level -xO4 or higher. This
argument tells the optimizer that
it can inline functions of its
choosing. Note that without the
%auto specification, automatic
inlining is normally turned off
when explicit inlining is specified
on the command line by
-xinline=[no%]func_name...
func_name Strongly request that the optimizer
inline the function. If the func-
tion is not declared as extern "C",
the value of func_name must be man-
gled. You can use the nm command on
the executable file to find mangled
function names. For functions
declared as extern "C", the names
are not mangled by the compiler.
no%func_name When you prefix the name of a rou-
tine on the list with no%, the
inlining of that routine is inhi-
bited. The rule about mangled names
for func_name applies to
no%func_name as well.
Only routines in the file being compiled are considered
for inlining unless you use -xipo[=1|2]. The optimizer
decides which of these routines are appropriate for
inlining.
Defaults:
If the -xinline option is not specified, the compiler
assumes -xinline=%auto. If -xinline= is specified with
no arguments, no functions are inlined regardless of
the optimization level.
Examples:
To enable automatic inlining while disabling inlining
of the function declared int foo(), use
example% CC -xO5 -xinline=%auto,no%__1cDfoo6F_i_ -c
a.cc
To strongly request the inlining of the function
declared as int foo(), and to make all other functions
as the candidates for inlining, use:
example% CC -xO5 -xinline=%auto, __1cDfoo6F_i_ -c a.cc
To strongly request the inlining of the function
declared as int foo(), and to not allow inlining of any
other functions use:
example% CC -xO5 -xinline=__1cDfoo6F_i_ -c a.cc
Interactions:
The -xinline option has no effect for optimization lev-
els below -xO3. At -xO4 and higher, the optimizer
decides which functions should be inlined, and does so
without the -xinline option being specified. At -xO4 or
higher, the compiler also attempts to determine which
functions will improve performance if inlined.
A routine is inlined if any of the following conditions
apply.
o Optimization is set at -xO3 or higher
o Inlining is judged to be profitable and safe
o The function is in the file being compiled, or
the function is in a file that was compiled with
-xipo[=1|2].
Warnings:
If you force the inlining of a function with -xin-
line, you might actually diminish performance.
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 Analyzer 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.
Values
Value Meaning
datarace Prepare the code for analysis by the
Thread Analyzer and define __THA_NOTIFY.
no%datarace This is the default. Do not prepare the
code for analysis by the Thread Analyzer
and do not define __THA_NOTIFY.
Interactions
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 -g0.
Warnings
It is illegal to specify -xinstrument without an argu-
ment.
-xipo[={0|1|2}]
Performs interprocedural optimizations.
The -xipo option performs partial-program optimizations
by invoking an interprocedural analysis pass. It per-
forms optimizations across all object files in the link
step, and the optimizations are not limited to just the
source files on the compile command. However, whole-
program optimizations performed with -xipo do not
include assembly (.s) source files.
The -xipo option is particularly useful when compiling
and linking large multifile applications. Object files
compiled with this flag have analysis information com-
piled within them that enables interprocedural analysis
across source and precompiled program files. However,
analysis and optimization is limited to the object
files compiled with -xipo, and does not extend to
object files or libraries.
Values:
Value Meaning
0 Do not perform interprocedural optimiza-
tions.
1 Perform interprocedural optimizations.
2 Perform interprocedural aliasing
analysis as well as optimization of
memory allocation and layout to improve
cache performance.
Defaults:
If -xipo is not specified, -xipo=0 is assumed.
If only -xipo is specified, -xipo=1 is assumed.
Examples:
The following example compiles and links in the same
step.
example% CC -xipo -xO4 -o prog part1.cc part2.cc
part3.cc
The optimizer performs crossfile inlining across all
three source files. This is done in the final link
step, so the compilation of the source files need not
all take place in a single compilation and could be
over a number of separate compilations, each specifying
the -xipo option.
The following example compiles and links in separate
steps.
example% CC -xipo -xO4 -c part1.cc part2.cc
example% CC -xipo -xO4 -c part3.cc
example% CC -xipo -xO4 -o prog part1.o part2.o part3.o
The object files created in the compile steps have
additional analysis information compiled within them to
permit crossfile optimizations to take place at the
link step.
Interactions:
The -xipo option requires at least optimization level
-xO4.
Warnings:
When compiling and linking are performed in separate
steps, -xipo must be specified in both steps to be
effective. Objects that are compiled without -xipo can
be linked freely with objects that are compiled with
-xipo. Libraries do not participate in crossfile inter-
procedural analysis, even when they are compiled with
-xipo as shown in this example:
example% CC -xipo -xO4 one.cc two.cc three.cc
example% CC -xar -o mylib.a one.o two.o three.o
example% CC -xipo -xO4 -o myprog main.cc four.cc
mylib.a
In this example, interprocedural optimizations will be
performed between one.cc, two.cc, and three.cc, and
between main.cc and four.cc, but not between main.cc or
four.cc and the routines in mylib.a. The first compila-
tion may generate warnings about undefined symbols, but
the interprocedural optimizations will be performed
because it is a compile and link step.
The -xipo option generates significantly larger object
files due to the additional information needed to per-
form optimizations across the files. However, this
additional information does not become part of the
final executable binary file. Any increase in the size
of the executable program will be due to the additional
optimizations performed.
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.
-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.
-xivdep[=p]
Disable or set interpretation of ivdep pragmas
The ivdep pragmas tell a compiler to ignore some or all
loop-carried dependences on array references that it
finds in a loop for purposes of optimization. This
enables a compiler to perform various loop optimiza-
tions such as microvectorization, distribution,
software pipelining, etc., which would not be otherwise
possible. It is used in cases where the user knows
either that the dependences do not matter or that they
never occur in practice.
The interpretation of #pragma ivdep directives depend
upon the value of the -xivdep option.
The following values for p are interpreted as follows:
loop - ignore assumed loop-carried vector dependences
loop_any - ignore all loop-carried vector dependences
back - ignore assumed backward loop-carried vector
dependences
back_any - ignore all backward loop-carried vector
dependences
none - do not ignore any dependences (disables ivdep
pragmas)
These interpretations are provided for compatibility
with other vendor's interpretations of the ivdep
pragma.
-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.cc t2.cc t3.cc
-xkeepframe[=[%all,%none,function_name,no%function_name]]
Prohibit stack related optimizations for the named
functions.
%all - prohibit stack related optimizations for all the
code
%none - allow stack related optimizations for all the
code
If not specified on the command line, the compiler
assumes -xkeepframe=%none
If specified on the command line without a value, the
compiler assumes -xkeepframe=%all This option is accu-
mulative and can appear on the command line multiple
times. For example, -xkeepframe=%all
-xkeepframe=no%func1 indicates that the stack frame
should be kept for all functions except func1. Also,
-xkeepframe overrides -xregs=frameptr. For example,
-xkeepframe=%all -xregs=frameptr indicates that the
stack should be kept for all functions, but the optimi-
zations for -xregs=frameptr would not be done.
-xlang=language[,language]
Includes the appropriate runtime libraries and ensures
the proper runtime environment for the specified
language.
language must be either f77, f90, f95 or c99.
The -f90 and -f95 arguments are equivalent. The c99
argument invokes ISO 9899:1999 C programming language
behavior for objects that were compiled with cc
-xc99=%all and are being linked with CC.
Interactions:
The -xlang=f90 and -xlang=f95 options imply
-library=f90, and the -xlang=f77 option implies
-library=f77. However, the -library=f77 and
-library=f90 options are not sufficient for mixed-
language linking because only the -xlang option insures
the proper runtime environment.
To determine which driver to use for mixed-language
linking, use the following language hierarchy:
1. C++
2. Fortran 95 (or Fortran 90)
3. Fortran 77
4. C or C99
When linking Fortran 95, Fortran 77, and C++ object
files together, use the driver of the highest language.
For example, use the following C++ compiler command to
link C++ and Fortran 95 object files.
example% CC -xlang=f95...
To link Fortran 95 and Fortran 77 object files, use the
Fortran 95 driver as follows:
example% f95 -xlang=f77...
You cannot use the -xlang option and the -xlic_lib
option in the same compiler command. If you are using
-xlang and you need to link in the Sun Performance
Library, use the -library=sunperf instead.
Warnings:
Do not use -xnolib with -xlang.
If you are mixing parallel Fortran objects with C++
objects, the link line must specify the -mt flag.
See also:
-library, -staticlib
-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.
Values
v must be one of the following:
Value Meaning
global Symbol definitions have global linker
scoping which is the least restrictive
linker scoping. All references to the
symbol bind to the definition in the
first dynamic load module that defines
the symbol. This linker scoping is the
current linker scoping for extern sym-
bols.
symbolic Symbol definitions have symbolic linker
scoping which is more restrictive than
global linker scoping. All references to
the symbol from within the dynamic load
module being linked bind to the symbol
defined within the module. Outside of
the module, the symbol appears as though
it is global. This linker scoping
corresponds to the linker option -Bsym-
bolic. Although you cannot use -Bsym-
bolic with C++ libraries, you can use
the -xldscope=symbolic option without
causing problems.
hidden Hidden linker scoping is more restric-
tive than symbolic and global linker
scoping. All references within a dynamic
load module will bind to a definition
within that module. The symbol will not
be visible outside of the module.
Defaults
If you do not specify -xldscope, the compiler assumes
-xldscope=global. If you specify -xldscope without any
values, the compiler issues an error. Multiple
instances of this option on the command line override
each other until the rightmost instance is reached.
Warnings
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 compile at -xO4 or higher in
which case inlining can happen 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 4 "Language
Extensions" of 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
Causes libm to return IEEE 754 values for math routines
in exceptional cases. The default behavior of libm is
XPG-compliant.
This option has an impact on the value of the errno
variable set by certain floating-point math library
routines. See the NOTES section at the end of this man
page for more information.
-xlibmil
Inlines selected library routines for optimization.
There are inline templates for some of the libm library
routines. This option selects those inline templates
that produce the fastest executables for the floating-
point option and platform currently being used.
Note - This option does not affect C++ inline func-
tions. This option has an impact on the value of the
errno variable set by certain floating-point math
library routines. See the NOTES section at the end of
this man page for more information.
-xlibmopt
Uses a library of optimized math routines. You must use
default rounding mode by specifying -fround=nearest
when you use this option.
This option uses a math routine library 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.
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
This option has an impact on the value of the errno
variable set by certain floating-point math library
routines. See the NOTES section at the end of this man
page for more information.
-xlic_lib=sunperf
Deprecated, do not use. Specify -library=sunperf
instead.
-xlicinfo
This option is silently ignored by the compiler.
-xlinkopt[=level]
(SPARC) Perform link-time optimizations on relocatable
object files.
The link 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 link 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
computation simplification, at link time.
Specifying -xlinkopt without a 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 used to compile the
whole program, and with profile feedback.
When compiling in separate steps, -xlinkopt must appear
on both compile and link steps:
example% CC -c -xlinkopt a.cc b.cc
example% CC -o myprog -xlinkopt=2 a.o
Note that the level parameter is only used when the
compiler is linking. In the example above, the link
optimizer level 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 will optimize code coming from static
libraries that appear on the compiler command line, but
it will skip and not optimize code coming from shared
(dynamic) libraries that appear on the command line.
You can also use -xlinkopt when building shared
libraries (compiling with -G ).
The link optimizer is most effective when used with
run-time profile feedback. Profiling reveals the most
and least used parts of the code and directs the optim-
izer to focus its effort accordingly. This is particu-
larly 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.cc
example% progt
example% CC -o prog -xO5 -xprofile=use:profdir -xlinkopt file.cc
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 execut-
able 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).
However, -xM only reports dependencies of the included
headers and not the associated template definition
files. You can use the .KEEP_STATE feature in your
makefile to generate all the dependencies in the
.make.state file that is created by make.
See make(1) for details about makefiles and dependen-
cies.
-xM1 This option is the same as -xM, except that this option
does not report dependencies for the /usr/include
header files and it does not report dependencies for
compiler-supplied header files.
-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
Merges the data segment with the text segment.
The data in the object file is read-only, and is shared
between processes, unless you link with
-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. ld -N.
-xmaxopt[=v]
This command limits the level of pragma opt to the
level specified. v must be one of the following: off,
1, 2, 3, 4, or 5. The default value is -xmaxopt=off
which causes pragma opt to be ignored. If you specify
-xmaxopt without supplying an argument, that is the
equivalent of specifying -xmaxopt=5.
-xmemalign[=ab]
(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.
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 64-bit SPARC programs (-m64) only. Raise
signal SIGBUS for alignments less than or
equal to 4, otherwise interpret access and
continue execution. For 32-bit programs, 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
compiler options that must be specified at both compile
time and at link time, see the C++ User's Guide.
Defaults:
The default for SPARC 64-bit programs (-m64) is
-xmemalign=8s.
The default for SPARC 32-bit programs (-m32) is
-xmemalign=8i.
If you do specify -xmemalign but do not provide a
value, the default is -xmemalign=1i for all platforms.
-xmodel=[a]
(x86) The -xmodel option determines the data address
model for shared objects on the Oracle Solaris x64
platforms and should only be specified for the compila-
tion 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
Disables linking with default system libraries.
Normally (without this option), the C++ compiler links
with several system support libraries to support C++
programs. With this option, the -llib options to link
the default system support libraries are not passed to
ld.
Normally, the compiler links with the system support
libraries in the following order:
For default -compat=5 mode:
-lCstd -lCrun -lm -lc
For -compat=g on Linux, the libraries are:
-lstdc++ -lCrunG3 -lm -lc
For -compat=g on Oracle Solaris x86, the libraries are:
-lstdc++ -lgcc_s -lCrunG3 -lm -lc
The order of the -l options is significant. The -lm
option must appear before -lc.
Note - If the -mt option is specified, the compiler
normally links with -lthread just before it links with
-lm.
To determine which system support libraries will be
linked by default, compile with the -dryrun option. For
example, the output from the following command:
CC foo.cc -m64 -dryrun
includes the following
-lCstd -lCrun -lm -lc
Examples:
For minimal compilation to meet the C application
binary interface, that is, a C++ program with only C
support required, use:
CC -xnolib test.cc -lc
To link libm statically into a single threaded applica-
tion with the generic instruction set, use:
CC -xnolib test.cc -lCstd -lCrun -Bstatic
Interactions:
No static system libraries are available on Oracle
Solaris platforms.
If you specify -xnolib, you must manually link all
required system support libraries in the given order.
You must link the system support libraries last.
If -xnolib is specified, -library is ignored.
Warnings:
Many C++ language features require the use of libCrun
The set of system support libraries is not stable and
might change from release to release.
-xnolibmil
Cancels -xlibmil on the command line.
Use this option with -fast to override linking with the
optimized math library.
-xnolibmopt
Cancels -xlibmopt on the command line.
Interactions:
Use this option after the -fast option on the command
line, as in:
example% CC -fast -xnolibmopt ...
-xOn Specifies optimization level (n). (Note the uppercase
letter O, followed by a digit 1, 2, 3, 4, or 5)
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 makefile that specify
an optimization level.
Generally, the higher the level of optimization with
which a program is compiled, the better the runtime
performance. 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.
Interactions:
If you use -g or -g0 and the optimization level is -xO3
or lower, the compiler provides best-effort symbolic
information with almost full optimization. Tail-call
optimization and back-end inlining are disabled.
If you use -g or -g0 and the optimization level is -xO4
or higher, the compiler provides best-effort symbolic
information with full optimization.
Debugging with -g does not suppress -xOn, but -xOn lim-
its -g in certain ways. For example, the optimization
options reduce the utility of debugging so that you
cannot display variables from dbx, but you can still
use the dbx where command to get a symbolic traceback.
For more information, see Debugging a Program With dbx.
The -xinline option has no effect for optimization lev-
els below -xO3. At -xO4, the optimizer decides which
functions should be inlined, and does so regardless of
whether you specify the -xinline option. At -xO4, the
compiler also attempts to determine which functions
will improve performance if they are inlined. If you
force the inlining of a function with -xinline, you
might actually diminish performance.
Warnings:
If you optimize at -xO3 or -xO4 with very large pro-
cedures, thousands of lines of code in a single pro-
cedure, the optimizer might require an unreasonable
amount of memory. In such cases, machine performance
can be degraded.
To prevent this degradation from taking place, use the
limit command to limit the amount of virtual memory
available to a single process (see the csh(1) man
page). For example, to limit virtual memory to 16 mega-
bytes:
example% limit datasize 16M
This command causes the optimizer to try to recover if
it reaches 16 megabytes of data space.
The limit cannot be greater than the total available
swap space of the machine, and should be small enough
to permit normal use of the machine while a larger com-
pilation is in progress.
The best setting for data size depends on the degree of
optimization requested, the amount of real memory, and
virtual memory available.
To find the actual swap space, type: swap -1
To find the actual real memory, type: dmesg | grep mem
See also:
-xldscope, -fast, -xprofile=p, csh(1) man page
Performance Analyzer discusses the effects of the dif-
ferent levels of optimization on the Performance
Analyzer's data.
-xopenmp[=i]
Enable explicit parallelization with OpenMP directives.
The following table details the -xopenmp values:
Value Meaning
parallel Enables recognition of OpenMP pragmas. The
optimization level under -xopenmp=parallel is
-xO3. The compiler changes the optimization
level to -xO3 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 Oracle 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.
Use the OMP_NUM_THREADS environment variable to specify
the number of threads to use when running an OpenMP
program. If OMP_NUM_THREADS is not set, the default
number of threads used is 2. To use more threads, set
OMP_NUM_THREADS to a higher value. Set OMP_NUM_THREADS
to 1 to run with just one thread. In general, set
OMP_NUM_THREADS to the available number of virtual pro-
cessors on the running system, which can be determined
by using the Oracle Solaris psrinfo(1) comma nd. See
the OpenMP API User's Guide for more information.
To enable nested parallelism, you must set the
OMP_NESTED environmen t variable to TRUE. Nested paral-
lelism is disabled by default. See the Or acle Solaris
Studio OpenMP API User's Guide for details.
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 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.
-xpagesize=n
Set the preferred page size for the stack and the heap.
The n value must be one of the following:
On SPARC:
4K 8K 64K 512K 2M 4M 32M 256M 2G 16G or default.
On x86/x64:
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.
Use the pagesize(1) command on the Oracle Solaris
operating system to determine the number of bytes in a
page. The Oracle Solaris operating system 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 Oracle Solaris
operating system sets the page size.
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.
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 Oracle
Solaris command ppgsz(1) with the equivalent options
before running the program. See the Oracle Solaris man
pages for details.
-xpagesize_heap=n
Set the page size in memory for the heap.
The n value is the same as -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.
For details, see -xpagesize.
-xpagesize_stack=n
Set the page size in memory for the stack.
The n value is the same as -xpagesize.
You must specify a valid page size for the Oracle
Solaris operating system on the target platform. If you
do not specify a valid pagesize, the request is
silently ignored at run-time.
For details, see -xpagesize.
-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
specify 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.cc:
CC -xpch=collect:myheader a.cc
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.cc, the
precompiled-header file is called foo.Cpch.
How the Compiler Handles an Existing Precompiled-Header
File
Here are the rules the compiler uses to determine how
it handles an existing precompiled-header file.
If the compiler finds an existing precompiled-header
file, it only uses the file when the following attri-
butes of the file match the same information derived
from the current compilation:
- The viable prefix matches
- The command line options are exactly the same
- The current working directory is the same
- The source-directory path-name is the same
- The compiler and precompiled header version
numbers match
The following must be true for a viable prefix to qual-
ify as a match:
- The #include filenames are all the same
- All #define and #undef directives reference the
same symbols
and the directives appear in the same order
- The associated values for #define are identical
- Any pragmas that are present appear in their ori-
ginal order
Note that #ident/#pragma idents are passed through "as
is" in the viable prefix and are unchecked for equal-
ity. The string argument is typically different for
each source file and, if checked, would inhibit use of
the existing precompiled-header file.
The compiler version used in the match condition is the
same as that returned by the compiler's -V option.
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.cc bar.cc foobar.cc
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 pre-
fix. 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 precompilable? A header file
is precompilable 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
*/
file c.h
namespace N {
int foo();
[end of file, continued in another file] /* not allowed
*/
file d.h
extern "C" {
int foo();
[end of file, continued in another file] /* not allowed
*/
file e.h
namespace N {
int foo();
} /* OK, a stand-alone namespace declaration */
file f.h
namespace N {
int bar();
} /* OK, namespace re-opened, but still stand-
alone */
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 PCH 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 : %.cc shared.Cpch
$(CC) -xpch=use:shared -xpchstop=foo.h -c $<
default : a.out
foo.o + shared.Cpch : foo.cc
$(CC) -xpch=collect:shared -xpchstop=foo.h foo.cc -c
a.out : foo.o bar.o foobar.o
$(CC) 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
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 after the first include-directive that refer-
ences 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
-xpec[={yes|no}]
(Oracle Solaris) Generates a Portable Executable Code
(PEC) binary.
Generates a Portable Executable Code (PEC) binary. This
option puts the program intermediate representations in
the object file and the binary. This binary may be used
later for tuning and troubleshooting.
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.
-xpg Compiles for profiling with the gprof profiler.
The -xpg option compiles self-profiling code to col-
lect data for profiling with gprof. This option invokes
a runtime recording mechanism that produces a gmon.out
file when the program normally terminates.
Note: There is no advantage for -xprofile if you
specify -xpg. The two do not prepare or use data pro-
vided by the other.
Profiles are generated by using prof or gprof on 64 bit
Oracle Solaris platforms or just gprof on 32 bit
Solaris platforms include approximate user CPU times.
These times are derived from PC sample data (see pcsam-
ple(2)) for routines in the main executable and rou-
tines in shared libraries specified as linker arguments
when the executable is linked. Other shared libraries
(libraries opened after process startup using
dlopen(3DL)) are not profiled.
On 32 bit Oracle Solaris systems, profiles generated
using prof(1) are limited to routines in the execut-
able. 32 bit shared libraries can be profiled by link-
ing 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.
You can also perform this task with the Performance
Analyzer. Refer to the analyzer(1) man page.
Warnings:
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.
Note: Binaries compiled with -xpg for gprof profiling
should not be used with binopt(1), as they are incompa-
tible and can result in internal errors.
Note: On x86 systems, -xpg is incompatible with
-xregs=frameptr because the gprof runtime library
requires a valid frame pointer to determine the return
address of a profiled routine. Note also that compil-
ing with -fast on x86 systems will invoke
-xregs=frameptr. Compile with the following instead:
-fast -xregs=no%frameptr -xpg
-xport64[=v]
Use this option to help you port code to a 64-bit
environment. Specifically, this option warns against
problems such as truncation of types (including
pointers), sign extension, and changes to bit-packing
that are common when you port code from a 32-bit archi-
tecture to a 64-bit architecture.
This option has no effect unless compiling in 64-bit
mode with -m64. (On a 64-bit Linux system, -m64 is the
default.)
Values:
v must be one of the following values.
Value Meaning
no Generate no warnings related to the
porting of code from a 32 bit environ-
ment to a 64 bit environment.
implicit Generate warning only for implicit
conversions. Do not generate warnings
when an explicit cast is present.
full Generate all warnings related to the
porting of code from a 32 bit environ-
ment to a 64 bit environment. This
includes warnings for truncation of 64-
bit values, sign-extension to 64 bits
under ISO value-preserving rules, and
changes to packing of bitfields.
Defaults:
If you do not specify -xport64, the default is
-xport64=no. If you specify -xport64, but do not
specify a flag, the default is -xport64=full.
See Also: -xarch, -m32/-m64
-xprefetch[=a[,a]]
Enable and adjust prefetch instructions on those archi-
tectures that support prefetch. You must compile with
an optimization level 3 or greater with this option.
a must be one of the following values.
Value Meaning
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 prefectch macros.
latx:factor (SPARC) You can only combine this flag
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 floating-point or integer
number.
yes Obsolete - do not use. Use
-xprefetch=auto,explicit instead.
no Obsolete - do not use. Use
-xprefetch=no%auto,no%explicit instead.
With -xprefetch, and -xprefetch=auto the compiler is
free to insert prefetch instructions into the code it
generates. This may result in a performance improvement
on architectures that support prefetch.
If you are running computationally intensive codes on
large multiprocessors, you might find it advantageous
to use -xprefetch=latx:factor. This option instructs
the code generator to adjust the default latency time
between a prefetch and its associated load or store by
the specified factor.
The prefetch latency is the hardware delay between the
execution of a prefetch instruction and the time the
data being prefetched is available in the cache. The
compiler assumes a prefetch latency value when deter-
mining how far apart to place a prefetch instruction
and the load or store instruction that uses the pre-
fetched data.
Note -- the assumed latency between a prefetch and a
load may not be the same as the assumed latency between
a prefetch and a store.
The compiler tunes the prefetch mechanism for optimal
performance across a wide range of machines and appli-
cations. This tuning may not always be optimal. For
memory-intensive applications, especially applications
intended to run on large multiprocessors, you may be
able to obtain better performance by increasing 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 provide the maximum perfor-
mance.
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 1 (one).
To use the -xprefetch=latx:factor option, start with a
factor value near 1.0 and run performance tests against
the application. Then increase or decrease the factor,
as appropriate, and run the performance tests again.
Continue adjusting the factor and running the perfor-
mance tests until you achieve optimum performance. 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.
Defaults:
The default is -xprefetch=auto,explicit.
If automatic prefetching is enabled, such as with
-xprefetch or -xprefetch=auto, but a latency factor is
not specified, then latx:1.0 is assumed.
Interactions:
This option accumulates instead of overrides.
The sun_prefetch.h header file provides the macros for
specifying explicit prefetch instructions. The pre-
fetches will be approximately at the place in the exe-
cutable that corresponds to where the macros appear.
To use the explicit prefetch instructions, you must be
on the correct architecture, include sun_prefetch.h,
and either exclude -xprefetch from the compiler command
or use -xprefetch, -xprefetch=auto,explict,
-xprefetch=explicit.
If you call the macros and include the sun_prefetch.h
header file, but pass -xprefetch=no%explicit, the
explicit prefetches will not appear in your executable.
The -xchip setting effects the determination of the
assumed latencies and therefore the result of a
latx:factor setting.
The latx:factor suboption is valid only when automatic
prefetching is enabled. That is, latx:factor is ignored
unless it is used in conjunction with yes or auto.
Warnings:
Because the compiler tunes the prefetch mechanism for
optimal performance across a wide range of machines and
applications, you should only use the latx:factor
suboption when the performance tests indicate there is
a clear benefit. The assumed prefetch latencies may
change from release to release. Therefore, retesting
the effect of the latency factor on performance when-
ever switching to a different release is highly recom-
mended.
-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.
The prefix no% disables the option.
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 -xalias_level can affect the aggres-
siveness 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
Controls the automatic insertion of prefetch instruc-
tions as determined with -xprefetch=auto. The default
is -xprefetch_level=1 when you specify -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 targets addi-
tional loops, beyond those targeted at level 1 and
-xprefetch=3 targets additional loops beyond those tar-
geted at level 2.
You must compile with optimization level 3 or greater
and generate code for a platform that supports pre-
fetch.
-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 with
-xprofile=collect:prof_dir or
-xprofile=tcov:prof_dir, profile data are stored
at run time in a directory named program.profile
where program is the basename of the profiled
process's main program. In this case, the
environment variables SUN_PROFDATA and
SUN_PROFDATA_DIR can be used to control where the
profile data are stored at run time. If set, the
profile data are written to the directory given by
$SUN_PROFDATA_DIR/$SUN_PROFDATA.
If a profile directory name is specified at compi-
lation time, SUN_PROFDATA_DIR and SUN_PROFDATA
have no effect at run time. 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.
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.cc -o prog
./prog
CC -xprofile=use:myprof.profile -xO5 prog.cc -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.cc -o prog
...run prog from multiple locations...
CC -xprofile=use:/bench/myprof.profile -xO5 prog.cc -o prog
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] or
-xprofile=tcov[: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] or
-xprofile=tcov[:profdir].
To generate data that can be used by both tcov and
-xprofile=use[:profdir], the same profile direc-
tory must be specified at compilation time, using
the option -xprofile=tcov[:profdir]. To minimize
confusion, specify profdir as an absolute path-
name.
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 relative to
the current working directory when the program is
compiled.
If :profdir is specified for any object file, the
same location must be specified for all object
files in the same program. The directory whose
location is specified by :profdir must be accessi-
ble from all machines where the profiled program
is to be executed. 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]
Use -xprofile_ircache[=path] with -xprofile=collect|use
to improve compilation time during 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.cc t2.cc
example% a.out // run collects feedback data
example% CC -xO5 -xprofile=use -xprofile_ircache t1.cc
t2.cc
-xprofile_pathmap=collect_prefix:use_prefix
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 location 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 warn-
ing is issued by the compiler if you also
specify -xpg. Also, -xkeepframe overrides -
xregs=frameptr.
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, %source or a comma-
separated list of one or more function names. This
command-line option can be used on its own, but is best
used with optimization of -xO3 or greater.
Specifying -xrestrict=%source means that all functions
defined in the main source file, but not any header
files or template definition files, are restricted.
If you specify a function list with this option,
pointer parameters in the specified functions are
treated as restricted; if you specify -xrestrict=%all,
all pointer parameters in the entire C++ file are
treated as restricted.
The default is %none. Specifying -xrestrict is
equivalent to specifying -xrestrict=%source.
See Also: -xprefetch_auto_type, '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 platform) Allow the compiler to assume that no
memory protection violations occur.
This option allows the compiler to use the non-faulting
load instruction in the SPARC V9 architecture.
Warnings:
Because non-faulting loads do not cause a trap when a
fault such as address misalignment or segmentation vio-
lation occurs, you should use this option only for pro-
grams in which such faults cannot occur. Because few
programs incur memory-based traps, you can safely use
this option for most programs. Do not use this option
for programs that explicitly depend on memory-based
traps to handle exceptional conditions.
Interactions:
This option takes effect only when used with optimiza-
tion level -xO5 and one of the following -xarch values:
sparc, sparcvis, sparcvis2, or sparcvis3 for both -m32
and -m64.
-xspace
Does not allow optimizations that increase code size.
-xtarget=t
Specifies the target system for instruction set and
optimization.
t must be one of the folowing: native, native64, gen-
eric, generic64 or system-name.
This option is a macro. Each specific value for -xtar-
get expands into a specific set of values for the
-xarch, -xchip, and -xcache options. See the -dryrun
explanation for details on how to see the expansion of
macro options such as -xtarget.
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.
-xtarget=native is equivalent to -m32, -xarch=native,
-xchip=native, -xcache=native, to give best performance
on the 32-bit host system.
-xtarget=native64 is equivalent to -m64,
-xarch=native64, -xchip=native64, -xcache=native to
give best performance on the 64-bit host system.
-xtarget=generic is equivalent to -m32,
-xarch=generic, -xchip=generic, -xcache=generic, to
give the best performance for generic architecture,
chip and cache on most 32-bit systems.
-xtarget=generic64 is equivalent to -m64,
-xarch=generic64, -xchip=generic64, -xcache=generic, to
give the best performance for generic architecture,
chip and cache on most 64-bit systems.
On SPARC platforms:
Compiling for 64-bit Oracle Solaris software on 64-bit
SPARC architctures 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
platform-name
Gets the best performance for the specified
platform. The following are valid SPARC
values for platform name:
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,
T3, T4, sparc64vi, sparc64vii,
sparc64viiplus.
On x86 platforms:
Compiling for 64-bit Oracle Solaris software on 64-bit x86
64-bit platforms is indicated by the -m64 option. If you
specify -xtarget with a flag other than native64 or gen-
eric64, you must also specify the -m64 option as follows:
-xtarget=opteron ... -m64
otherwise the compiler uses a 32-bit memory model.
Value Meaning
processor_name
Generate code for best performance on the
following x86 processors:
nehalem, barcelona, opteron, pentium,
pentium_pro, pentium3, pentium4, penryn,
sandybridge, westmere, woodcrest
For more information about platform and processor
names, see the C++ User's Guide.
The actual expansion of an -xtarget suboption might
change and improve with each compiler release. Compile
with -dryrun to see the actual expansion as follows:
CC -dryrun -xtarget=ultra4 |& grep ###
### command line files and options (expanded):
### -dryrun -xchip=ultra4 -xcache=64/32/4:8192/128/2 -xarch=sparcvis2
-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.
Values
o can be one of the following:
Value Meaning
[no%]dynamic Compile variables for dynamic loading.
Prefix no% disables the option. 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.
Defaults
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.
Interactions
Objects that use __thread must be compiled and linked
with -mt.
Warnings
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.
See Also
-xcode, -KPIC, -Kpic
-xtime
Causes the CC driver to report execution times for the
various compilation passes.
-xtrigraphs[={yes|no}]
Enables or disables recognition of trigraph sequences
as defined by the ISO/ANSI C standard.
-xtrigraphs=yes enables recognition of trigraph
sequences in the source code.
-xtrigraphs=no disables recognition of trigraph
sequences in the source code.
Defaults:
If the -xtrigraphs option is not specified,
-xtrigraphs=yes is assumed.
If only -xtrigraphs is specified -xtrigraphs=yes is
assumed.
-xunroll=n
Enables unrolling of loops where possible.
This option specifies whether or not the compiler
optimizes (unrolls) loops.
When n is 1, it is a suggestion to the compiler not to
unroll loops.
When n is an integer greater than 1, -xunroll=n causes
the compiler to unroll loops n times.
-xustr={ascii_utf16_ushort|no}
This option enables compiler recognition of UTF-16
character strings and literals. Since such strings and
literals are not yet part of any standard, this option
enables recognition of non-standard C++. Specify
-xustr=ascii_utf16_ushort if you need to support an
internationalized application that uses ISO10646 UTF-16
characters. In other words, use this option if your
code contains string characters that you want the com-
piler to convert to UTF-16 characters in the object
file. Without this option, the compiler neither pro-
duces nor recognizes sixteen-bit characters. This
option enables recognition of the U"ASCII_string"
string literals as an array of unsigned short int. This
option also enables recognition of character literals.
For example: unsigned short character = U'Z';
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.cc
const unsigned short *foo = U"foo";
const unsigned short bar[] = U"bar";
const unsigned short *fun() { return foo; }
example% CC -xustr=ascii_utf16_ushort file.cc -c
An 8-bit character literal can be prepended with U to
form a 16-bit UTF-16 character of type unsigned short.
Examples:
const unsigned short x = U'x';
const unsigned short y = U'\x79';
-xvector[=a]
Enables automatic generation of calls to the vector
library and/or the generation of the SIMD (Single
Instruction Multiple Data) instructions on x86 proces-
sors that support SIMD. You must use default rounding
mode by specifying -fround=nearest when you use this
option.
The -xvector option requires optimization level -O3 or
greater. Compilation will not proceed if the optimiza-
tion level is unspecified or lower than -O3, and a mes-
sage is issued.
a can have the following values (prefix no% disables a
suboption):
[no%]lib
(SOLARIS Only) Enables the compiler to transform
math library calls within loops into single calls
to the equivalent vector math routines when such
transformations are possible. This could result in
a performance improvement for loops with large
loop counts. Use no%lib to disable this option.
[no%]simd
(x86 Only) Directs 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. Use no%simd to disable
this option.
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.
%none
Disable this option entirely.
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 Oracle Solaris, -xvector=lib on SPARC Oracle
Solaris, and -xvector=simd on Linux platforms.
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.
-xvis[={yes|no}]
(SPARC) Compile with -xvis=yes when including the
<vis.h> header to generate VIS instructions, or when
using assembler inline code (.il) that uses VIS
instructions. 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.
-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 with 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 create
a 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.cc
Note: Oracle Solaris Studio compilers support OpenMP
3.1 API parallelization. Consequently, the MP pragmas
are deprecated. See the OpenMP API User's Guide for
information on migrating to the OpenMP API.
-xwe Converts all warnings to errors by returning non-zero
exit status.
-Yc,path
Specifies a new path for the location of component c.
If the location of a component is specified, then the
new path name for the component is path/component_name.
This option is passed to ld.
Values
c must be one of the following values.
p Changes the default directory for cpp.
0 Changes the default directory for ccfe.
a Changes the default directory for fbe.
2 Changes the default directory for iropt.
c Changes the default directory for cg (SPARC).
O Changes the default directory for ipo.
k Changes the default directory for CClink.
l Changes the default directory for ld.
f Changes the default directory for c++filt.
m Changes the default directory for mcs.
u Changes the default directory for ube (x86).
h Changes the default directory for ir2hf (x86).
A Specifies a directory to search for all compiler
components. If a component is not found in path,
the search reverts to the directory where the com-
piler is installed.
P Adds path to the default library search path. This
path will be searched before the default library
search paths.
S Changes the default directory for startup object
files
Interactions
You can have multiple -Y options on a command line. If
more than one -Y option is applied to any one com-
ponent, then the last occurrence holds.
See also
Oracle Solaris Linker and Libraries Guide
-z arg
Link editor option.
-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.
For more information see the ld(1) man page and the
Oracle Solaris Linker and Libraries Guide.
PRAGMAS
The following #pragmas are recognized by the compilation
system:
#pragma align
#pragma does_not_read_global_data
#pragma does_not_return
#pragma does_not_write_global_data
#pragma dumpmacros
#pragma end_dumpmacros
#pragma fini
#pragma hdrstop
#pragma ident
#pragma init
#pragma must_have_frame
#pragma pack
#pragma rarely_called
#pragma returns_new_memory
#pragma unknown_control_flow
#pragma weak
#pragma does_not_read_global_data
#pragma does_not_write_global_data
#pragma no_side_effect
SPARC Only:
#pragma no_side_effect
Refer to the C++ User's Guide for more information on these
pragmas.
ENVIRONMENT
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.
SUN_PROFDATA_REPLACE={objfile,program,all}
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]
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
file.a Static library
file.C Input file
file.cc Input file
file.c++ Input file
file.cpp Input file
file.cxx Input file
file.o Object file
file.so Dynamic (shared) library
a.out Linked output
xprof_fini.o Initialization and finalization handlers
for programs compiled with
-xprofile=collect
SEE ALSO
analyzer(1), as(1), c++filt(1), cc(1), csh(1), dbx(1),
gprof(1), ld(1), more(1), nm(1), prof(1), tcov(1)
C++ User's Guide,
C++ Migration Guide,
The C++ Programming Language, Third Edition, Bjarne
Stroustrup, Addison-Wesley 1997
The C Programming Language, B. W. Kernighan and D. M.
Ritchie, Prentice-Hall 1988
Oracle Solaris Linker and Libraries Guide
International Standard (ISO/IEC FDIS 14882), Programming
Languages - C++
NOTES
errno
Certain floating-point math library routines return error
status in the errno variable (defined in errno.h). With
compiler options -fast, -xbuiltin, -xlibmieee, -xlibmil,
-xlibmopt 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 or a
floating-point exception being raised after a floating point
function call could produce inconsistent results.
One way around this problem is to avoid compiling such codes
with these options, such as -fast.
However, if -fast optimization is required and the code
depends on the value of errno being set properly or an
appropriate floating-point exception being raised 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.