CC(1)CC(1)NAMECC - C++ compiler
SYNOPSISCC [-#] [-###] [-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] [-pen‐
tium] [-pg] [-PIC] [-pic] [-pta] [-ptipath] [-pto] [-ptv]
[{-Qoption|-qoption} phase [,option...]] [{-Qproduce|-qpro‐
duce}type] [-qp] [-Rpath[:path...]] [-S] [-s] [-stati‐
clib=l[,l...]] [-sync_stdio=[yes|no]] [-temp=path] [-tem‐
plate=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}]] [-xdump‐
macros[=value[,value...]] [-xe] [-xF[=v]] [-xhelp=flags]
[-xhwcprof[={enable|disable}]] [-xia] [-xin‐
line[=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] [-xpage‐
size_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 Stu‐
dio 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 technologies and other topics.
For the complete description of all new features and functionality 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 defini‐
tion, and should be used only to specify the instruction 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 run‐
ning a 64-bit kernel. Compilation, linking, and execution of 64-bit
objects can only take place in a Oracle Solaris or Linux OS that sup‐
ports 64-bit execution.
SPECIAL x86 NOTES
There are some important issues to be aware of when compiling 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 com‐
piler 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 specialized -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++ CompilerCC converts C++ and assembly source files to object files, and links
object files and libraries into executable programs.
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 assem‐
bly 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 setting 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 automatically 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 direc‐
tories 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 directories 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 compiler 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 produced by options -#, -###,
and -dryrun.
Options specified by the user on the command line will usually override
options read from the defaults file. For example, if the defaults file
specifies compiling with -xO4 and the user specifies -xO2 on the com‐
mand 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 pre‐
processor 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 prob‐
lems.
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 brack‐
ets ( [] ) 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 exam‐
ples, 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 actu‐
ally execute it. Also shows how command options would expand.
-Bbinding
Specifies whether a library binding for linking is symbolic,
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 bindings 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 -Bsymbolic, 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 -Bbind‐
ing 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 infor‐
mation 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 excep‐
tion mechanism relies on comparing what are supposed to be
unique addresses.
-c Compile and produce a .o file for each source file without link‐
ing. You can explicitly name a single object file by using the
-o option. When the compiler produces object code for each .i or
.c input file, it always creates an object file in the current
working directory. If you suppress the linking step, you also
suppress the removal of the object files.
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 compiler. 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. ("Com‐
patibility 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 compatibility
to ANSI/ISO standard mode and is the default. Sets the
__SUNPRO_CC_COMPAT preprocessor 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 func‐
tion 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 function. The C++ com‐
piler inlines calls to an inline function 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 optimization 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 platforms. 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 combination
with dynamic libraries. Most system libraries are only available
as dynamic libraries.
-dalign
(SPARC) Obsolete. You should not use this option. Use -xmema‐
lign=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 output). No compila‐
tion is done; no .o files are generated.
This option causes preprocessor-type line number information 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 -tem‐
plate=no%extdef option with the -E option. If application 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 dis‐
play 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 sup‐
pressed with -erroff and made fatal with -errwarn.
Values and Defaults:
a can be either yes or no. The default is -errtags=no. Specify‐
ing -errtags is equivalent to specifying -errtags=yes.
-errwarn [ = t[,t...]]
Use the -errwarn option to cause the C++ compiler to exit with a
failure status for the given warning messages.
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 warning message. Has no
effect if tag in not issued.
no%tag Prevent CC from exiting with a fatal status if the mes‐
sage specified by tag is issued only as a warning mes‐
sage. 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 followed 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 compile without error in the next release
of the compiler.
Only warning messages from the C++ compiler front-end that dis‐
play 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 start‐
ing point for tuning an executable for maximum run-time perfor‐
mance. The expansion of -fast can change from one release of the
compiler to the next and includes options that are target plat‐
form 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 optimized math rou‐
tines. For more information, see the description of -xlibmopt in
this man page.
This option provides near maximum performance for most applica‐
tions 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 running 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 possible inter‐
actions.
Warnings:
Code compiled with the -fast option is not portable. For exam‐
ple, compiling code using the following command on an Ultra‐
SPARC(TM) III system will generate a binary that will not exe‐
cute 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 especially when compiling
mixed C, Fortran, and C++ source codes.
The expansion of the -fast option includes -D_MATH‐
ERR_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 keywords 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 example, and for
&&). The default is altspell.
[no%]anachronisms
Allow anachronistic constructs. When disabled (that is
-feature=no%anachronisms), no anachronistic 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 imple‐
menting the 1998 C++ standard or the 2003 update. Future
standards will require a larger value for the macro.)
Do not use this option unless you need to redefine __cplus‐
plus to 1 in order to compile code intended for g++.
[no%]except
Allow C++ exceptions. When C++ exceptions are disabled
(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 tempo‐
rary.
Default: -features=no%rvalueref
The C++ compiler has traditionally been lax in enforcing
the rule that a non-const reference cannot 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). -fea‐
tures=no%rtti is not allowed.
[no%]split_init
Put initializers for nonlocal static objects into individ‐
ual 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++ standard
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 func‐
tions or static function templates. The default is the
standard conformant no%tmplrefstatic.
[no%]transitions
Allow ARM language constructs that are problematic in stan‐
dard C++ and that may cause the program to behave differ‐
ently than expected or that may be rejected by future com‐
pilers. 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 standard
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 -fea‐
tures=tmplife. Testing whether the program works both with and
without the -features=tmplife option is one way to test the pro‐
gram'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. Suppres‐
sion 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 optimiza‐
tion level of at least -xO2 for the compiler to generate fused
multiply-add instructions. The compiler marks the binary program
if fused multiply-add instructions are generated in order to
prevent the program from executing on platforms that do not sup‐
port 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
operations 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 sig‐
nificantly 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 com‐
putation takes place, that is, underflows are gradual.
If only -fns is specified -fns=yes is assumed.
Warnings:
When nonstandard mode is enabled, floating-point arithmetic 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 unex‐
pected 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 preci‐
sion 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 rounding preci‐
sion mode to be set to single or double precision, 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 significant bits. In the
default extended precision mode, results are rounded to 64 sig‐
nificant bits. This mode controls only the precision to which
results in registers 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 rounding preci‐
sion 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 breaking 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 expres‐
sions.
o Is established at runtime during the program initialization.
The meanings are the same as those for the ieee_flags function,
which may be used to change the mode at runtime.
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 program.
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 programs are unchanged.
With -fsimple=1, the optimizer is not allowed to opti‐
mize completely without regard to roundoff or excep‐
tions. 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 follow‐
ing:
o IEEE 754 default rounding/trapping modes do not
change after process initialization.
o Computation producing no visible result other than
potential floating-point exceptions 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 reduc‐
tions when -xvector=simd is in effect.
Also permits aggressive floating point optimization
that may cause many programs to produce different
numeric results due to changes in rounding. For exam‐
ple, permits the optimizer to replace all computations
of x/y in a given loop with x*z, where x/y is guaran‐
teed to be evaluated at least once in the loop, z=1y ,
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 -fsimple=0.
If -fsimple is designated but no value is given for n, the com‐
piler uses -fsimple=1.
Warnings:
This option can break IEEE 754 conformance.
See Also:
Techniques for Optimizing Applications: High Performance Comput‐
ing 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 float‐
ing-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 float‐
ing-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 register 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 simultaneously 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 particular 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 compiled with
-xcode=pic13 by default.
When building a shared library from files that involve templates
and were compiled with the -instances=extern option, any tem‐
plate instances referenced by the .o files will be included from
the template cache automatically.
If you are creating a shared object by specifying -G along with
other compiler options that must be specified 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 documented under the descrip‐
tion 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 neces‐
sary -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 ana‐
lyzer(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 optimiza‐
tion 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 debug‐
ging information. For more information, 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 symbolic information
with full optimization.
When you specify this option, the +d option is specified auto‐
matically unless -O or -xO are also specified.
To use the full capabilities of the Performance Analyzer, com‐
pile with the -g option. While some performance analysis fea‐
tures do not require -g, you must compile with -g to view anno‐
tated source, some function level information, and compiler com‐
mentary messages. See the analyzer(1) man page and the Perfor‐
mance 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 debug‐
ging, 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 executable 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 compi‐
lation.
-h[ ]lname
Assigns the name lname to the generated shared dynamic library.
This is a loader option that is passed to ld. In general, 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
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 usrinclude
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 usrinclude
Note — If the spelling matches the name of a standard header
file, also refer to "Standard Header Implementation" 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 behav‐
ior.
-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 reposi‐
tory within comdat sections and gives them global
linkage. (If an instance in the repository is out of
date, it is reinstantiated.)
Note: If you are compiling and linking in separate
steps and you specify -instance=extern for the compi‐
lation step, you must also specify it for the link
step.
explicit Places explicitly instantiated instances into the cur‐
rent object file within comdat sections 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 linkage.
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 compilation time improves.
Values:
Use the file argument to specify the library that contains tem‐
plate instances that could be generated by the current compila‐
tion. The filename argument must contain 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 refer‐
ence to a global datum is generated as a dereference of a
pointer in the global offset table. Each function call is gener‐
ated 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 compilation
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 iostreams
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,stl‐
port4.
[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=stl‐
port4.
[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 iostreams (for example, cout
and std::cout) within a program 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 exam‐
ple, 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
implementations 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 Stu‐
dio releases.
The RW Tools.h++ toolset provided with legacy Sun Studio 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 functionality 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 discon‐
tinued in future Oracle Solaris Studio releases.
Do not redefine or modify any of the configuration macros for
STLport or Oracle Solaris Studio C++ libraries. The libraries
are configured and built in a way that works with the C++ com‐
piler. 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 provide their
own implementation of I/O streams. Specifying 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 plat‐
forms 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 Studio 12 compilers, this is no
longer the case. On most platforms, just adding -m64 to the com‐
mand line is sufficient to create 64-bit objects.
On Oracle Solaris, -m32 is the default. On Linux systems sup‐
porting 64-bit programs, -m64 -xarch=sse2 is the default.
See also -xarch.
-mc Removes duplicate strings from the .comment section of 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 -xmema‐
lign=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 quo‐
tation 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 explic‐
itly list these libraries when building a shared library.
The -xopenmp option (for using the OpenMP shared-memory paral‐
lelization 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 com‐
pile 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 behav‐
ior 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 desti‐
nation 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 exe‐
cutable.
If an executable file uses shared libraries, then the compiler
normally builds in a path that points the runtime 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 different 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 variable LD_LIBRARY_PATH at run time
to specify the location of the shared libraries. This will allow
the runtime 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 programs 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 synchronization
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 speci‐
fies 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 nonstandard pre‐
processor 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 con‐
fusion.
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-sepa‐
rated list. Options that are passed to components 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 recog‐
nizes the -z option for the linker (ld). If you issue a command
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 -zdefaultex‐
tract ... // 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 source‐
type. Source code types are shown in the following 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 invoca‐
tion.
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 executable 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 specified 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 inter‐
val 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++ iostreams and C stdio. Syn‐
chronization 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 program does not write
to both cout and stdout, you can use the option -sync_stdio=no
to turn off synchronization.
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 executables, not
for libraries.
-temp=path
Defines the directory for temporary files.
This option sets path as the directory for the temporary 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 functions of the
explicitly instantiated class template which
were not generated previously.
[no%]wholeclass
Instantiate a whole template class, rather
than only those functions 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 execution.
The -traceback option causes the executable to issue a stack
trace to stderr, dump core, and exit if certain signals are gen‐
erated 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 compiler com‐
mand line when linking. The option is also accepted at compile-
time but is ignored unless an executable 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 signals
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, sig‐
bus, sigsegv, sigsys, sigxcpu, sigxfsz
Any of these can be preceeded with no% to disable catch‐
ing the signal.
For example: -traceback=sigsegv,sigfpe will produce 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 core‐
dumpsize limit to zero using:
% limit coredumpsize 0
The -traceback option has no effect on runtime performance.
-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 macros 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 instan‐
tiation 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 -ver‐
bose=%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 reg‐
ular 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 optimizer
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 consequences.
(The +w option no longer generates a warning if a function 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. Remov‐
ing 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 constructs that
are:
o Nonportable
o Likely to be mistakes
o Inefficient
Defaults:
If +w is not specified, the compiler warns about constructs that
are almost certainly problems.
Interactions:
Some C++ standard headers result in warnings when compiled with
+w.
+w2 Emits the same warnings as +w as well as warnings about techni‐
cal violations that are probably harmless, but that might reduce
the maximum portability of your program.
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 regarding serious anachro‐
nisms, 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 restricts 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 limitation 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 capa‐
bilities 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 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
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 lay‐
out compatible with the dynamic type of the corresponding
storage object. Two types are layout-compatible under the fol‐
lowing 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 circumstances:
* 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 opti‐
mization 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 documentation 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), discover(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 compile 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 template repository. The template
repository is used only when at least one object file was com‐
piled with the -instances=extern option. Using with -xar auto‐
matically 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 compiled with -instances. In that
case use the -xar compiler 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 instantiations 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 support 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 previous 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 earlier
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 running on.
native64 Compile for good performance on this system (Oracle
Solaris only)
This option is equivalent to
-m64 -xarch=native and is provided for compatibility
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 implementa‐
tion-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 exten‐
sions, 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 Instruction Set
(VIS) version 1.0, and with UltraSPARC extensions.
This option enables the compiler to generate code for
good performance 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 exten‐
sions.
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 exten‐
sions, including the Visual Instruction Set (VIS) ver‐
sion 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 exten‐
sions, including the Visual Instruction Set (VIS) ver‐
sion 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 optimization 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 exten‐
sions, including the Visual Instruction Set (VIS) ver‐
sion 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 pro‐
vided 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 platform.
For any particular choice, the generated executable could run
much more slowly on earlier architectures. Also, although
quad-precision floating-point instructions 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 architec‐
ture.
sse Adds the SSE instruction set to the pentium_pro
instruction set.
sse2 Supplements the pentium_pro and SSE instruction 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 instruction 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 instruc‐
tion 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 instruc‐
tions automatically when -xarch=aes is specified
unless the source code includes .il inline code, _asm
statements, or assembler code that use AES instruc‐
tions, 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 serious degradation of performance or in in a
binary program that is not executable on all intended target
platforms.
-xautopar
Turns on automatic parallelization for multiple processors. Does
dependence analysis (analyze loops for inter- iteration data
dependence) and loop restructuring. If optimization is not at
-xO3 or higher, optimization is raised to -xO3 and a warning is
emitted.
Note that -xautopar does not accept OpenMP parallelization
directives.
Avoid -xautopar if you do your own thread management.
To get faster execution, this option requires a multiple proces‐
sor system. On a single-processor system, the resulting binary
usually runs slower.
Use the OMP_NUM_THREADS environment variable to specify the num‐
ber of threads to use when running a program automatically par‐
allelized 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 proces‐
sors 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 optimiza‐
tions, transformations and analysis (see binopt(1)). This option
may be used for building executables or shared objects. This
option must be used with optimization level -xO1 or higher to be
effective. There is a modest increase in size of the binary when
built with this option.
If you compile in separate steps, -xbinopt must appear on both
compile and link steps:
example% CC-c -xO1 -xbinopt=prepare a.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 optimized, transformed or analyzed.
Compiling with -xbinopt=prepare and -g increases the size of the
executable by including debugging information. 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 func‐
tions where profitable for performance. See the er_src(1) man
page to learn how to read compiler commentary output to deter‐
mine which functions were substituted by the compiler.
With -xbuiltin=%all, substitutions can cause the setting 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 intrinsics or inlines standard library
functions much more aggressively.
Compiling with -fast adds -xbuiltin=%all.
Note: The -xbuiltin option only inlines global functions defined
in system header files, never static functions defined by the
user. User code that attempts to interpose on global functions
may result in undefined 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 particular cache prop‐
erty is used.
Although this option can be used alone, it is part of the expan‐
sion 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 particular, the value of CHAR_MAX and CHAR_MIN,
as defined by limits.h, do not change when this option is speci‐
fied. 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 Ora‐
cle 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 overflow of the
main thread in a singly-threaded program as well
as slave-thread stacks in a multithreaded pro‐
gram. If a stack overflow is detected, a SIGSEGV
is generated. If your application needs to handle
a SIGSEGV caused by a stack overflow differently
than it handles other address-space violations,
see sigaltstack(2).
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 compiler
defaults to -xcheck=%none.
-xchip=c
Specifies the target processor for use by the optimizer.
Although this option can be used alone, it is part of the expan‐
sion 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 processors, 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 lim‐
ited 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 architectures. Do not use this value with
dynamic (shared) libraries.
abs64 SPARC: Generate 64-bit absolute addresses, which are
slow, but have full range. Available 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 information 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 -xde‐
bugformat=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 per‐
forms loop restructuring. Loop restructuring includes loop
interchange, loop fusion, scalar replacement, 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 com‐
piler 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 systems. How‐
ever, if you try -xdepend on single-processor systems, you
should not use -xautopar. If you do so, the -xdepend optimiza‐
tion 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 information such as macro
defines, undefines, and instances of usage. It prints output to
the standard error (stderr), based on the order macros are pro‐
cessed. The -xdumpmacros 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 condi‐
tional directives
[no%]sys
Print all macros defines, undefines, and use
information for macros in system header files
%all Sets the option to -xdump‐
macros=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 -xdump‐
macros=undefs,sys.
Note: The sub-options loc, conds, and sys are qualifiers 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 -xdump‐
macros,
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 functions 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 pro‐
gram performance. Generally, this optimization is only effective
when page fault time constitutes a significant fraction of pro‐
gram run time.
Reordering functions and variables for optimal performance
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 improvement.
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 sections.
[no%]gbldata
fragment global data (variables with external
linkage) into separate sections.
[no%]lcldata
fragment local data (variables with internal
linkage) into separate sections.
%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 optimiza‐
tions, so you should only use this flag when it is experimen‐
tally 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 structure 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 instruction pro‐
filing.
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 applica‐
tion'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 profiling, 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 <suninter‐
val.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 -fsim‐
ple, -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 com‐
pilations. 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 optimization
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 nor‐
mally turned off when explicit inlining is
specified on the command line by -xin‐
line=[no%]func_name...
func_name Strongly request that the optimizer inline
the function. If the function is not
declared as extern "C", the value of
func_name must be mangled. 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 routine on the
list with no%, the inlining of that routine
is inhibited. 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 levels 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 -xinline,
you might actually diminish performance.
See Also:
-xldscope
-xinstrument=[no%]datarace]
Specify this option to compile and instrument your program 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 instru‐
mented program with collect -r races to create a data-race-
detection experiment. You can run the instrumented code stand‐
alone but it runs more slowly.
Values
Value Meaning
datarace Prepare the code for analysis by the Thread Ana‐
lyzer 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) rou‐
tines.
This option also sets -g0.
Warnings
It is illegal to specify -xinstrument without an argument.
-xipo[={0|1|2}]
Performs interprocedural optimizations.
The -xipo option performs partial-program optimizations by
invoking an interprocedural analysis pass. It performs opti‐
mizations 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 link‐
ing large multifile applications. Object files compiled with
this flag have analysis information compiled 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 optimizations.
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 com‐
pilation 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 partici‐
pate in crossfile interprocedural 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 compilation may generate warnings about unde‐
fined 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 perform 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 opti‐
mizations as it works with the set of object files in the link
step. The compiler makes the following 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
compile 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 optimize 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 compi‐
lation 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 optimization 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_ar‐
chive=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 per‐
form various loop optimizations such as microvectorization, dis‐
tribution, software pipelining, etc., which would not be other‐
wise 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
optimizer 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 num‐
ber of available processors can degrade performance because of
context switching overheads 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 override 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 accumulative and can
appear on the command line multiple times. For example, -xkeep‐
frame=%all -xkeepframe=no%func1 indicates that the stack frame
should be kept for all functions except func1. Also, -xkeep‐
frame overrides -xregs=frameptr. For example, -xkeep‐
frame=%all -xregs=frameptr indicates that the stack should be
kept for all functions, but the optimizations 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 implementation will be better hid‐
den.
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 defini‐
tion in the first dynamic load module that
defines the symbol. This linker scoping is the
current linker scoping for extern symbols.
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 -Bsymbolic. Although you cannot use
-Bsymbolic with C++ libraries, you can use the
-xldscope=symbolic option without causing prob‐
lems.
hidden Hidden linker scoping is more restrictive than
symbolic and global linker scoping. All refer‐
ences 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 -xld‐
scope=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 automati‐
cally, if you use the inline specifier, or if you are using
cross-file optimization.
For example, suppose library ABC has a default allocator func‐
tion 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 compiler 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 dif‐
ferent versions of the function.
Library functions declared with the __hidden or __symbolic spec‐
ifiers can be generated inline when building the library. They
are not supposed to be overridden by clients. For more informa‐
tion, 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-compli‐
ant.
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 rou‐
tines. This option selects those inline templates that produce
the fastest executables for the floating-point option and plat‐
form currently being used.
Note — This option does not affect C++ inline functions. This
option has an impact on the value of the errno variable set by
certain floating-point math library routines. See the NOTES sec‐
tion 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 perfor‐
mance, 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 performance
optimizations on the binary object code at link-time. The value
level sets the level of optimizations 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 opti‐
mizations, at link time.
2 Perform additional data flow analysis, including dead-
code elimination and address computation simplifica‐
tion, 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 b.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 compile with
-xlinkopt.
You must use -xlinkopt on at least some of the compilation com‐
mands for -xlinkopt to be useful at link time. The optimizer can
still perform some limited optimizations 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 optimizer to focus its effort
accordingly. This is particularly important with large applica‐
tions where optimal placement of code performed at link time can
reduce instruction cache misses. Typically, this would be com‐
piled 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 executable 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 dependencies.
-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 compilation contin‐
ues. -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 preprocessor
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 individual filenames for mul‐
tiple 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 over‐
written if it already exists.
-xMMD Use this option to generate makefile dependencies excluding sys‐
tem header files. This is the same functionality as -xM1, but
compilation continues. -xMMD generates an output file for the
makefile-dependency information derived from the -o output file‐
name, 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 speci‐
fied. 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 specifies the maximum assumed
memory alignment and b specifies the behavior for misaligned
memory accesses.
For memory accesses where the alignment is determinable at com‐
pile 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 possible 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 pro‐
gram 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 suc‐
ceeded 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 sig‐
nal 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 compilation of such objects.
This option is valid only when -m64 is also specified on 64-bit
enabled x64 processors.
a is one of the following:
small
This option generates code for the small model in which the
virtual address of code executed is known at link time and
all symbols are known to be located in the virtual
addresses in the range from 0 to 2^31 - 2^24 - 1.
kernel
Generates code for the kernel model in which all symbols
are defined to be in the range from 2^64 - 2^31 to 2^64 -
2^24.
medium
Generates code for the medium model in which no assumptions
are made about the range of symbolic references to data
sections. Size and address of the text section have the
same limits as the small code model. Applications with
large amounts of static data might require -xmodel=medium
when compiling with -m64.
This option is not cumulative so the compiler sets the model
value according to the rightmost instance of -xmodel on the com‐
mand-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 sev‐
eral 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 out‐
put 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 inter‐
face, that is, a C++ program with only C support required, use:
CC-xnolib test.cc -lc
To link libm statically into a single threaded application with
the generic instruction set, use:
CC-xnolib test.cc -lCstd -lCrun -Bstatic -lm -Bdynamic -lc
Interactions:
No static system libraries are available on Oracle Solaris plat‐
forms.
If you specify -xnolib, you must manually link all required sys‐
tem support libraries in the given order. You must link the sys‐
tem 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 opti‐
mized 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 optimiza‐
tion 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. How‐
ever, higher optimization levels may result in increased compi‐
lation time and larger executable 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 original level.
Values:
-xO1 Do only the basic local optimizations.
-xO2 Do basic local and global optimization. This level usu‐
ally gives minimum code size.
-xO3 Adds global optimizations at the function level. In gen‐
eral, 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 optimization algorithms
that take more compilation time or that do not have as
high a certainty of improving execution time. Optimiza‐
tion at this level is more likely to improve performance
if it is done with profile feedback. See -xprofile=col‐
lect|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 limits -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 sym‐
bolic traceback. For more information, see Debugging a Program
With dbx.
The -xinline option has no effect for optimization levels below
-xO3. At -xO4, the optimizer decides which functions should be
inlined, and does so regardless of whether you specify the -xin‐
line 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 procedures,
thousands of lines of code in a single procedure, 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 megabytes:
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 compilation is in progress.
The best setting for data size depends on the degree of opti‐
mization requested, the amount of real memory, and virtual mem‐
ory 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 different lev‐
els 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 warning. This flag also defines the preproces‐
sor token _OPENMP.
The _OPENMP token is defined to have the decimal value
yyyymm where yyyy and mm are the year and month desig‐
nations of the version of the OpenMP API that the
implementation supports. 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 rec‐
ognized, 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 recogni‐
tion of OpenMP pragmas, makes no change to the opti‐
mization level of your program, and does not predefine
any preprocessor tokens.
If you specify -xopenmp, but do not include an argument, 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, compile 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 appropri‐
ate optimization.
Use the OMP_NUM_THREADS environment variable to specify the num‐
ber 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 vir‐
tual processors 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 envi‐
ronmen t variable to TRUE. Nested parallelism 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 executable must not be any older than the com‐
piler that built the .so with -xopenmp. This is especially
important when you compile libraries that contain OpenMP direc‐
tives.
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 platform. 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 sys‐
tem 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 compile 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 setting 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 platform. 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 oper‐
ating 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_file‐
name. 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 pre‐
compiled-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 determine 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 following 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 con‐
tains 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
header.Cpch based on the source file a.cc:
CC -xpch=collect:myheader a.cc
A valid precompiled-header filename always has the suffix .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 attributes 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 qualify as a
match:
- The #include filenames are all the same
- All #define and #undef directives reference the same sym‐
bols
and the directives appear in the same order
- The associated values for #define are identical
- Any pragmas that are present appear in their original order
Note that #ident/#pragma idents are passed through "as is" in
the viable prefix and are unchecked for equality. 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 precom‐
piled-header file. A precompiled-header file created by one ver‐
sion 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 precompiled header was created.
- The current directory (that is, the directory in which the
compilation is occurring and attempting to use a given precom‐
piled-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 specified with -xpch=col‐
lect 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 multiple
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 directives 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 consistently by the compiler across all the
source files that use the same precompiled-header file.
The viable prefix consists of any of the following pre-processor
directives:
#include
#if/ifdef/ifndef/else/elif/endif
#define/undef
#ident
#pragma
Any of these may reference macros. The #else, #elif, and #endif
directives must match within the viable prefix. Comments are
ignored.
The compiler determines the end point of the viable prefix auto‐
matically 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 generates 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 precom‐
pilable when it is interpreted consistently across different
source files. Specifically, when it contains only complete dec‐
larations. 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 declara‐
tion 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 constraints 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 automati‐
cally, 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-gen‐
erated 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> gener‐
ates an error.
o If you specify -xpch=autofirst or you specify -xpch=auto with‐
out -xpchstop, any declaration, definition, 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 gen‐
eration 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 dependencies. Consider this sample make file:
.KEEP_STATE:
%.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 precom‐
piled-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 references file in each of the source
files that you specify with the cc command.
Use -xpchstop=<include> with -xpch=auto to create a precompiled-
header file that is based on header files up through and includ‐
ing <include>. This flag overrides the default -xpch=auto behav‐
ior 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 collect data
for profiling with gprof. This option invokes a runtime record‐
ing 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 provided 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 pcsample(2)) for routines in the main exe‐
cutable and routines 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 executable. 32 bit shared
libraries can be profiled by linking the executable with -xpg
and using gprof(1).
The Solaris 10 software does not include system libraries com‐
piled with -p. As a result, profiles collected on Solaris 10
platforms do not include call counts for system library rou‐
tines.
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 incompatible 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 compiling 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 trunca‐
tion of types (including pointers), sign extension, and changes
to bit-packing that are common when you port code from a 32-bit
architecture 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 environment to a 64 bit envi‐
ronment.
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 environment to a 64 bit envi‐
ronment. This includes warnings for truncation of
64-bit values, sign-extension to 64 bits under
ISO value-preserving rules, and changes to pack‐
ing 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 architectures
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 instruc‐
tions.
no%auto Disable automatic generation
explicit Enable explicit prefetch macros
Explicit prefetching should only be used under
special circumstances that are supported by mea‐
surements.
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 mul‐
tiprocessors, 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 determining how far apart to place a prefetch
instruction and the load or store instruction that uses the
prefetched data.
Note -- the assumed latency between a prefetch and a load may
not be the same as the assumed latency between a prefetch and a
store.
The compiler tunes the prefetch mechanism for optimal perfor‐
mance across a wide range of machines and applications. This
tuning may not always be optimal. For memory-intensive applica‐
tions, especially applications intended to run on large multi‐
processors, 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 performance.
For applications with datasets that reside entirely within the
external cache, you may be able to obtain better performance by
decreasing the prefetch latency values. To decrease the values,
use a factor that is less than 1 (one).
To use the -xprefetch=latx:factor option, start with a factor
value near 1.0 and run performance tests against the applica‐
tion. Then increase or decrease the factor, as appropriate, and
run the performance tests again. Continue adjusting the factor
and running the performance tests until you achieve optimum per‐
formance. 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 specify‐
ing explicit prefetch instructions. The prefetches will be
approximately at the place in the executable 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 prefetch‐
ing 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 perfor‐
mance tests indicate there is a clear benefit. The assumed
prefetch latencies may change from release to release. There‐
fore, retesting the effect of the latency factor on performance
whenever switching to a different release is highly recommended.
-xprefetch_auto_type=[a]
Where a is [no%]indirect_array_access.
Use this option to determine whether or not the compiler gener‐
ates indirect prefetches for the loops indicated 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%indi‐
rect_array_access.
Options such as -xalias_level can affect the aggressiveness of
computing the indirect prefetch candidates and therefore the
aggressiveness of the automatic indirect prefetch insertion due
to better memory alias disambiguation information.
-xprefetch_level=l
Controls the automatic insertion of prefetch instructions 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 prefetch
instructions. -xprefetch_level=2 targets additional loops,
beyond those targeted at level 1 and -xprefetch=3 targets addi‐
tional loops beyond those targeted at level 2.
You must compile with optimization level 3 or greater and gener‐
ate code for a platform that supports prefetch.
-xprofile=p
Collects data for a profile or use a profile to optimize.
p must be collect[:profdir], use[:profdir], or tcov[:profdir]
This option causes execution frequency data to be collected and
saved during execution, then the data can be used in subsequent
runs to improve performance. Profile collection is safe for mul‐
tithreaded 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
optimization.
If compilation and linking are performed in separate steps, the
same -xprofile option must appear on the compile as well as the
link step. 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 compiler 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, posi‐
tion-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 pro‐
filed object code is executed. If the pathname is not
absolute, it is interpreted relative to the current working
directory when the program is compiled with the option
-xprofile=use:profdir.
If no profile directory name is specified with -xpro‐
file=collect:prof_dir or -xprofile=tcov:prof_dir, profile
data are stored at run time in a directory named pro‐
gram.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 compilation
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 exe‐
cutable or the name specified in the -xprofile=col‐
lect: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 accumu‐
lates in the profdir.profile directory; that is, output
from prior executions is not lost.
Example[1]: to collect and use profile data in the direc‐
tory 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 directory
/bench/myprof.profile and later use the collected 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 asyn‐
chronous profile collections.
use[:profdir]
Uses execution frequency data collected from code compiled
with -xprofile=collect[:profdir] or -xpro‐
file=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 -xpro‐
file=use[:profdir], the same profile directory must be
specified at compilation time, using the option -xpro‐
file=tcov[:profdir]. To minimize confusion, specify
profdir as an absolute pathname.
The profdir is optional. If profdir is not specified, the
name of the executible binary is used. a.out is used if -o
is not specified. The compiler looks for profdir.pro‐
file/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 generated 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 pro‐
file directory name profdir must be used in the optimizing
compilation: -xprofile=use:profdir.
See also -xprofile_ircache for speeding up compilation
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 com‐
piler 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 -xpro‐
file=use:profdir .
If the optional :profdir argument is omitted, a profile
directory will be created when the profiled program is exe‐
cuted. The data stored in the profile directory can only
be used by tcov(1). The location of the profile directory
can be controlled 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 accessible 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 programs 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 profiled 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 runtime profile data.
-xprofile_ircache[=path]
Use -xprofile_ircache[=path] with -xprofile=collect|use to
improve compilation time during the use phase by reusing compi‐
lation 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 loca‐
tion 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 directories.
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 pro‐
file data for an object file that is compiled with -xpro‐
file=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=col‐
lect.
o Your object files share a common basename in the
profile but are distinguished from each other by their loca‐
tion in different directories.
The collect-prefix is the prefix of the UNIX pathname of a
directory tree in which object files were compiled using -xpro‐
file=collect.
The use-prefix is the prefix of the UNIX pathname of a directory
tree in which object files are to be compiled using -xpro‐
file=use.
If you specify multiple instances of -xprofile_pathmap, the com‐
piler processes them in the order of their occurrence. Each
use-prefix specified by an instance of -xprofile_pathmap is com‐
pared with the object file pathname until either a matching use-
prefix is identified or the last specified use-prefix is found
not to match the object file pathname.
-xreduction
Analyzes loops for reduction in automatic parallelization. This
option is valid only if -xautopar is also specified. Otherwise
the compiler issues a warning.
When a reduction recognition is enabled, the compiler paral‐
lelizes 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 following sub‐
options: 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 applica‐
tion 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 registers' 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 float‐
ing-point registers as scratch registers for integer
values. Use of floating-point values may use these reg‐
isters regardless of this option. To generate binary
code free of all references to floating point regis‐
ters, 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 gen‐
eral-purpose register.
The default is -xregs=no%frameptr.
The C++ compiler ignores -xregs=frameptr unless excep‐
tions 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 program performance.
However, some features of the debugger and performance
measurement tools may be limited. Stack tracing, debug‐
gers, 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++ function, 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 platforms, com‐
piling with -xregs=frameptr has a better chance of
improving 32-bit code performance than 64-bit code.
Note: -xregs=frameptr is ignored and a warning 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 applications 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 regis‐
ters in order to safely link with that library.
-xrestrict[=f]
Treats pointer-valued function parameters as restricted point‐
ers. 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 parame‐
ters 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 program, 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 violation occurs, you
should use this option only for programs 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 optimization 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 optimiza‐
tion.
t must be one of the folowing: native, native64, generic,
generic64 or system-name.
This option is a macro. Each specific value for -xtarget 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 plat‐
forms is indicated by the -m64 option. If you specify -xtarget with a
flag other than native64 or generic64, you must also specify the -m64
option as follows:
-xtarget=opteron ... -m64
otherwise the compiler uses a 32-bit memory model.
Value Meaning
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 speci‐
fier, 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 -xthread‐
var=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 com‐
piler 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 arguments, 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 sig‐
nificantly faster, and hence should be the default for executa‐
bles.
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 com‐
piler 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 compiler to convert
to UTF-16 characters in the object file. Without this option,
the compiler neither produces nor recognizes sixteen-bit charac‐
ters. 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 argu‐
ment, the compiler won't accept it and instead issues a warning.
The default can change if the C or C++ standards define a mean‐
ing 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 processors 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 optimization level is
unspecified or lower than -O3, and a message is issued.
a can have the following values (prefix no% disables a subop‐
tion):
[no%]lib
(SOLARIS Only) Enables the compiler to transform math
library calls within loops into single calls to the equiva‐
lent 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 opti‐
mization 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=wood‐
crest, -xarch=generic64, -xarch=sse2, -xarch=sse3, or -fast
on a modern platform to use it. If the target 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, -xvec‐
tor=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 command.
-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 instruc‐
tion set. Even though the UltraSPARC processors are 64-bit,
there are many cases, especially in multimedia applications,
when the data are limited to eight or 16 bits in size. The VIS
instructions can process four 16-bit data with one instruction
so they greatly improve the performance of applications that
handle new media such as imaging, linear algebra, signal pro‐
cessing, 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 directives.
The compiler issues warnings when it detects the following situ‐
ations:
o Loops are parallelized using MP directives with data dependen‐
cies between different loop iterations
o OpenMP data-sharing attributes-clauses are problematic. 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 pro‐
cessed 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 sta‐
tus.
-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 compiler 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 component, 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 .nf #pragma does_not_read_global_data #pragma
does_not_write_global_data #pragma no_side_effect
SPARC Only:
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 program compiled
with -xprofile=collect in a directory named profdir in the
current working directory at the time that the program is
executed. If the optional argument :profdir was specified in
-xprofile=collect[:profdir] at compilation time, SUN_PROF‐
DATA 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 dirname is dirname. If dirname is not absolute,
it is interpreted relative to the current working directory
at the time that the program is executed. If the optional
argument :profdir was specified in -xprofile=col‐
lect[:profdir] at compilation time, SUN_PROFDATA_DIR has no
effect.
SUN_PROFDATA_REPLACE={objfile,program,all}
SUN_PROFDATA_REPLACE indicates the scope of profile 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 meanings are as
follows:
objfile
reset profile data of changed object file
program
reset profile data of all object files in program con‐
taining 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_PROF‐
DATA_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 asynchronous profile
collection. In asynchronous profile collection, profile data
are collected from a running 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 envi‐
ronment variables:
$ 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 pro‐
grams compiled with -xprofile=collect
SEE ALSOanalyzer(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, Addi‐
son-Wesley 1997
The C Programming Language, B. W. Kernighan and D. M. Ritchie, Pren‐
tice-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 opti‐
mizing out such library calls and to to ensure that calls to math func‐
tions set errno as documented.
4th Berkeley Distribution December 2011 CC(1)