NAME
CC - C++ compiler
SYNOPSIS
CC [-B{dynamic|static|symbolic}] [-c] [-cg{89|92}]
[-compat[={4|5|g}]] [+d] [-Dname[=def]] [-d{y|n}]
[-dalign] [-dryrun] [-E] [+e{0|1}] [-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] [-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]
[-migration] [-misalign] [-mr[,string]] [-mt] [-native]
[-noex] [-nofstore] [-nolib] [-nolibmil] [-noqueue]
[-norunpath] [-O[n]] [-O[level]] [-o file] [+p] [-P]
[-p] [-pentium] [-pg] [-PIC] [-pic] [-pta] [-ptipath]
[-pto] [-ptrpath] [-ptv]
[{-Qoption|-qoption}phase[,option...]]
[{-Qproduce|-qproduce}type] [-qp] [-Rpath[:path...]]
[-readme] [-S] [-s] [-sb] [-sbfast]
[-staticlib=l[,l...]] [-sync_stdio=[yes|no]]
[-temp=path] [-template=a[,a...]] [-time]
[-traceback[=list]] [-Uname] [-unroll=n] [-V] [-v]
[-vdelx] [-verbose=a[,a...]] [+w] [+w2] [-w] [-Xm]
[-xaddr32[={yes|no}]] [-xalias_level[=n]] [-xannotate]
[-xar] [-xarch=isa] [-xautopar] [-xbinopt={a}]
[-xbuiltin[={%all|%none}]] [-xcache=c] [-xcg{89|92}]
[-xchar[=o]] [-xcheck[=n]] [-xchip=c] [-xcode=v]
[-xcrossfile[=n]] [-xdebugformat=[stabs|dwarf]]
[-xdepend[={yes|no}]] [-xdumpmacros[=value[,value...]]
[-xe] [-xF[=v]] [-xhelp={flags|readme}]
[-xhwcprof[={enable|disable}]] [-xia]
[-xinline[=func_spec[,func_spec...]]
[-xinstrument=[no%]datarace] [-xipo[={0|1|2}]
[-xipo_archive[=a]] [-xjobs=n] [-xkeepframe[=p]]
[-xlang=language[,language]] [-xldscope=[v]] [-xlib-
mieee] [-xlibmil] [-xlibmopt] [-xlic_lib=sunperf]
[-xlicinfo] [-xlinkopt[=level]] [-xloopinfo] [-xM]
[-xM1] [-xMD] [-xMF] [-xMMD] [-xMerge] [-xmaxopt[=v]]
[-xmemalign=ab] [-xmodel=[a]] [-xnolib] [-xnolibmil]
[-xnolibmopt] [-xOn] [-xopenmp] [-xpagesize=n]
[-xpagesize_heap=n] [-xpagesize_stack=n] [-xpch=v]
[-xpchstop] [-xpec] [-xpg] [-xport64[=v]]
[-xprefetch[=a[,a]] [-xprefetch_auto_type=[a]
[-xprefetch_level[=l]] [-xprofile=p]
[-xprofile_ircache[=path]]
[-xprofile_pathmap=collect_prefix:use_prefix] [-xreduc-
tion] [-xregs=r[,r...]] [-xrestrict[=f]] [-xs]
[-xsafe=mem] [-xsb] [-xsbfast] [-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] ...
Oracle Solaris Studio 12.2 C++ Compiler
This man page details the options or flags for the Solaris
Studio 12.2 C++ compiler. For the complete description of
all new features and functionality in the Solaris Studio
suite, see the readmes at
http://developers.sun.com/sunstudio/documentation/ The
information in the readmes supercedes the information in
this manpage.
A man page, by definition, is a quick reference. For more
detailed information on the C++ compiler and its options,
see the C++ User's Guide.
See the online readme file, viewable by calling
CC -xhelp=readme
for the latest important information on platforms, environ-
ments, new features, and software corrections.
COMPILING FOR 64-BIT PLATFORMS:
The way to specify compilation of a 32-bit or 64-bit binary
has changed in this release. The -xarch option no longer
carries an implicit memory model, 32-bit ILP32 or 64-bit
LP64, with each definition, and is now used only to specify
the instruction set of the target processor.
Use the new -m32 and -m64 options to specify the memory
model of the target compilation.
The ILP32 model specifies that C-language int, long, and
pointer data types are all 32-bits wide. The LP64 model
specifies that long and pointer data types are all 64-bits
wide. The Solaris and Linux OS also support large files and
large arrays under the LP64 memory model.
When compiling with -m64, the resulting executable will work
only on 64-bit UltraSPARC(R) or x86 processors under Solaris
OS or Linux OS running a 64-bit kernel. Compilation, link-
ing, and execution of 64-bit objects can only take place in
a Solaris or Linux OS that supports 64-bit execution.
SPECIAL x86 NOTES
There are some important issues to be aware of when compil-
ing for x86 Solaris platforms.
The legacy Sun-style parallelization pragmas are no longer
supported on any platform. Use OpenMP instead. See the
OpenMP API User's Guide for information on converting legacy
parallelization directives to OpenMP.
Programs compiled with -xarch set to sse, sse2, sse2a, or
sse3 must be run only on platforms that provide these exten-
sions and features.
If you compile and link in separate steps, always link using
the compiler and with same -xarch setting to ensure that the
correct startup routine is linked.
Numerical results on x86 might differ from results on SPARC
due to the x86 80-bit floating-point registers. To minimize
these differences, use the -fstore option or compile with
-xarch=sse2 if the hardware supports SSE2.
Numerical results can also differ between Solaris and Linux
because the intrinsic math libraries (for example, sin(x))
are not the same.
Binary Compatibility Verification
Starting with Sun Studio 11 and the Solaris 10 OS, program
binaries compiled and built using these specialized -xarch
hardware flags are verified that they are being run on the
appropriate platform.
On systems prior to Solaris 10, no verification is done and
it is the user's responsibility to ensure objects built
using these flags are deployed on suitable hardware.
Running programs compiled with these -xarch options on plat-
forms that are not enabled with the appropriate features or
instruction set extensions could result in segmentation
faults or incorrect results occurring without any explicit
warning messages.
This warning extends also to programs that employ .il inline
assembly language functions or __asm() assembler code that
utilize SSE, SSE2, SSE2a, and SSE3 instructions and exten-
sions.
Overview of the C++ Compiler
CC converts C++ and assembly source files to object files,
and links object files and libraries into executable pro-
grams.
Programs that contain C++ objects must be linked with CC.
CC takes arguments ending in .c, .C, .cc, .cxx, .c++, .cpp,
or .i to be C++ source programs. Arguments ending in .s are
presumed to be assembly source files. Arguments ending in
.o are presumed to be object files.
Files whose names do not end with the above suffixes are
treated as object programs or libraries and are handed over
to the link editor. Unless -c, -S, -E, or -P is specified,
these programs and libraries, together with the results of
any specified compilations or assemblies, are linked in the
order given to produce an output file named a.out. You can
specify a different name for the executable by using the -o
option.
If a single file is compiled and linked all at once, the
intermediate files are deleted.
Before you use the CC command, insert into your search path
the name of the directory in which you have chosen to
install the C++ compilation system. For instructions on set-
ting your search path, see the csh(1) or the sh(1) man page.
OPTIONS
In general, compiler options are processed from left to
right (with the exception that the -U options are processed
after all -D options), allowing selective overriding of
macro options (options that include other options). This
rule does not apply to linker options.
For a complete description of the C++ compiler options,
including examples, see the C++ User's Guide.
CC accepts the following options.
-Bbinding
Specifies whether a library binding for linking is sym-
bolic, dynamic (shared), or static (nonshared).
-Bdynamic is the default. You can use the -B option
several times on a command line.
For more information on the -Bbinding option, see the
ld(1) man page and the Solaris documentation.
-Bdynamic directs the link editor to look for liblib.so
files. Use this option if you want shared library bind-
ings for linking. If the liblib.so files are not
found, it looks for liblib.a files.
-Bstatic directs the link editor to look only for
liblib.a files. The .a suffix indicates that the file
is static, that is, nonshared. Use this option if you
want nonshared library bindings for linking.
-Bsymbolic forces symbols to be resolved within a
shared library if possible, even when a symbol is
already defined elsewhere. For an explanation of -Bsym-
bolic, see the ld(1) man page.
This option and its arguments are passed to the linker,
ld. If you compile and link in separate steps and are
using the -Bbinding option, you must include the option
in the link step.
Warning:
Never use -Bsymbolic with programs containing C++ code,
use linker scoping instead. See the C++ User's Guide
for more information on linker scoping. See also the
-xldscope option.
With -Bsymbolic, references in different modules can
bind to different copies of what is supposed to be one
global object.
The exception mechanism relies on comparing addresses.
If you have two copies of something, their addresses
won't compare equal, and the exception mechanism can
fail because the exception mechanism relies on compar-
ing what are supposed to be unique addresses.
-c Directs the CC driver to suppress linking with ld and,
instead, produce a .o file for each source file. If
you specify only one source file on the command line,
then you can explicitly name the object file with the
-o option. For example:
o If you enter CC -c x.cc, the object file, x.o, is
generated.
o If you enter CC -c x.cc -o y.o, the object file,
y.o, is generated.
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.
-cg{89|92}
(SPARC) Obsolete. You should not use this option.
Current Solaris operating systems no longer support
SPARC V7 architecture. Compiling with this option gen-
erates code that runs slower on current SPARC plat-
forms.
-compat[={4|5|g}]
Sets the major release compatibility mode of the com-
piler. This option controls the __cplusplus and
__SUNPRO_CC_COMPAT preprocessor symbols.
The C++ compiler has three principal modes. The compa-
tibility mode accepts the Annotated C++ Reference
Manual (ARM) semantics and language defined by the 4.2
compiler (-compat[=4]). The standard mode accepts con-
structs according to the ANSI/ISO 1998 C++ standard as
corrected in 2003 (standard mode, -compat=5). These
modes are incompatible with each other because the
ANSI/ISO standard forces significant, incompatible
changes in name mangling, vtable layout, and other ABI
details. These modes are differentiated by the -compat
option as shown in the following table.
-compat=g adds compatibility with the gcc/g++ compiler
on Linux platforms.
Value Meaning
-compat[=4]
(Compatibility mode) Set language and binary
compatibility to that of the 4.0.1, 4.1, and 4.2
compilers. Sets the __cplusplus preprocessor
macro to 1 and the __SUNPRO_CC_COMPAT preproces-
sor macro to 4).
-compat=5
(Standard mode) Set the language and binary com-
patibility to ANSI/ISO standard mode. Sets the
__cplusplus preprocessor macro to 199711L and
the __SUNPRO_CC_COMPAT preprocessor macro to 5).
-compat=g
(Linux Only) enables recognition of g++ language
extensions and causes the compiler to generate
code that is binary-compatible with g++ on the
Linux platform.
The binary compatibility extends only to shared
(dynamic or .so) libraries, not to individual .o
files or archive (.a) libraries.
Sets the __cplusplus preprocessor macro to
199711L and the __SUNPRO_CC_COMPAT preprocessor
macro to 'G'.
Example 1, linking g++ shared library to 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 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. If only -compat is specified, -compat=4 is
assumed.
Interactions:
You cannot use the standard libraries in compatibility
mode (-compat[=4]).
Use of -compat[=4] with any of the following options is
not supported.
o -Bsymbolic
o -features=[no%]strictdestorder
o -features=[no%]tmplife
o -library=[no%]iostream
o -library=[no%]Cstd
o -library=[no%]Crun
o -library=[no%]rwtools7_std
o -library=stdcxx4
o -xarch=v9
o -xarch=v9a
o -xarch=v9b
Use of -compat=5 with any of the following options is
not supported.
o -Bsymbolic
o +e
o -features=[no%]arraynew
o -features=[no%]explicit
o -features=[no%]namespace
o -features=[no%]rtti
o -library=[no%]complex
o -library=[no%]libC
o -vdelx
+d Prevents the compiler from expanding C++ inline func-
tions.
Under the C++ language rules, a C++ inline function is
a function for which one of the following statements is
true.
o The function is defined using the inline keyword.
o The function is defined (not just declared) inside a
class definition
o The function is a compiler-generated class member
function
Under the C++ language rules, the compiler can choose
whether actually to inline a call to an inline func-
tion. The C++ compiler inlines calls to an inline func-
tion unless:
o The function is too complex
o The +d option is selected
o The -g option is selected with no optimization option
Interactions:
This option is automatically turned on when you specify
-g, the debugging option.
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 -x04 or -x05.
-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 if the "array" forms of operators new and
delete are enabled
(see "-features=[no%]arraynew")
__BUILTIN_VA_ARG_INCR
__DATE__
__FILE__
__LINE__
__STDC__ = 0
__SUNPRO_CC = 0x5110
__SUNPRO_CC_COMPAT = 4 or 5
__TIME__
__cplusplus
__sun
__unix
_BOOL if type bool is enabled
(see "-features=[no%]bool")
_WCHAR_T
sun
unix
__SVR4 (Solaris)
__SunOS_OSversion _OSversion (Solaris)
SPARC only:
sparc
__SUN_PREFETCH = 1
__sparc
SPARC V9 only:
__sparcv9 (with -m64)
x86 only:
linux
__amd64 (with -m64)
__gnu__linux__
__linux
__linux__
__x86_64 (with -m64)
Defaults:
If you do not use [=def], name is defined as 1.
Interactions:
If +p is used, sun, unix, sparc and i386 are not
defined.
-d{y|n}
Allows or disallows dynamic libraries for the entire
executable.
-dy specifies dynamic linking, which is the default, in
the link editor.
-dn specifies static linking in the link editor.
This option and its arguments are passed to ld.
Interactions:
This option causes fatal errors if you use it in combi-
nation with dynamic libraries. Most system libraries
are only available as dynamic libraries.
-dalign
(SPARC) Obsolete. You should not use this option. Use
-xmemalign=8s instead. For a complete list of obsolete
options, see the C++ User's Guide.
This option is silently ignored on x86/x64 platforms.
-dryrun
Directs the CC driver to show, but not execute, the
commands constructed by the compilation driver.
-E Directs the CC driver to only preprocess the C++ source
files, and to send the result to stdout (standard out-
put). No compilation is done; no .o files are gen-
erated.
This option causes preprocessor-type line number infor-
mation to be included in the output.
To compile the output of the -E option when the source
code involves templates, you might need to use the -
template=no%extdef option with the -E option. If appli-
cation code uses the "definitions separate" template
source code model, the output of the -E option might
still not compile. Refer to the C++ Users Guide
chapters on templates for more information.
+e{0|1}
Controls virtual table generation in compatibility mode
(-compat[=4]). This option is invalid and ignored in
standard mode (the default mode).
Values:
o +e0 suppresses the generation of virtual tables, and
creates external references to those that are needed.
o +e1 creates virtual tables for all defined classes
with virtual functions.
Interactions:
When you compile with this option, also use the
-features=no%except option. Otherwise the compiler
generates virtual tables for internal types used in
exception handling.
If template classes have virtual functions, ensuring
that the compiler generates all needed virtual
tables, but does not duplicate these tables, might
not be possible.
-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 mes-
sage by using the -errtags=yes option.
no%tag Enables the warning message specified by this
tag.
%all Suppresses all warning messages.
%none Enables all warning messages. This is the
default.
Order is important; for example, %all,no%tag suppresses
all warning messages except tag.
Defaults:
The default is -erroff=%none. Specifying -erroff is
equivalent to specifying -erroff=%all.
Warnings:
Only warning messages from the C++ compiler front-end
that display a tag when the -errtags option is used can
be suppressed with the -erroff option.
-errtags [ = a]
Displays the message tag for each warning message of
the C++ compiler front-end that can be suppressed with
the -erroff option or made a fatal error with the
-errwarn option. Messages from the C++ compiler driver
and other components of the C++ compilation system do
not have error tags and cannot be suppressed with -err-
off and made fatal with -errwarn.
Values and Defaults:
a can be either yes or no. The default is -errtags=no.
Specifying -errtags is equivalent to specifying
-errtags=yes.
-errwarn [ = t[,t...]]
Use the -errwarn option to cause the C++ compiler to
exit with a failure status for the given warning mes-
sages.
Values:
t is a comma-separated list that consists of one or
more of the following: tag, no%tag, %all, %none. Order
is important; for example %all,no%tag causes the C++
compiler to exit with a fatal status if any warning
except tag is issued.
The following table details the -errwarn values:
tag Cause CC to exit with a fatal status if the
message specified by tag is issued as a warn-
ing message. Has no effect if tag in not
issued.
no%tag Prevent CC from exiting with a fatal status if
the message specified by tag is issued only as
a warning message. Has no effect if tag is not
issued. Use this option to revert a warning
message that was previously specified by this
option with tag or %all from causing CC to
exit with a fatal status when issued as a
warning message.
%all Cause CC to exit with a fatal status if any
warning messages are issued. %all can be fol-
lowed by no%tag to exempt specific warning
messages from this behavior.
%none Prevents any warning messages from causing CC
to exit with a fatal status should any warning
tag be issued. This is the default.
Defaults:
The default is -errwarn=%none. If you specify -errwarn
alone, it is equivalent to -errwarn=%all.
Warnings:
The warning messages generated by the C++ compiler
change from release to release as the compiler error
checking improves and features are added. Code that
compiles using -errwarn=%all without error may not com-
pile without error in the next release of the compiler.
Only warning messages from the C++ compiler front-end
that display a tag when the -errtags option is used can
be specified with the -errwarn option to cause the C++
compiler to exit with a failure status.
See Also:
-erroff, -errtags
-fast
This option is a macro that you can effectively use as
a starting point for tuning an executable for maximum
run-time performance. The expansion of -fast can change
from one release of the compiler to the next and
includes options that are target platform specific. Use
the -dryrun option to examine the expansion of -fast,
and incorporate the appropriate options of -fast into
the ongoing process of tuning the executable.
Modules that are compiled with -fast must also be
linked with -fast. For a complete list of compiler
options that must be specified at both compile time and
at link time, see the C++ User's Guide.
The expansion of -fast now includes the new -xlibmopt
option. This option enables the compiler to use a
library of optimized math routines. For more informa-
tion, see the description of -xlibmopt in this man
page.
This option provides near maximum performance for most
applications by expanding the following compilation
options:
-fns (SPARC, x86)
-fsimple=2 (SPARC, x86)
-nofstore (x86)
-xarch (SPARC, x86)
-xbuiltin=%all (SPARC, x86)
-xcache (SPARC, x86)
-xchip (SPARC, x86)
-xdepend (SPARC, x86)
-xlibmil (SPARC, x86)
-xlibmopt (SPARC)
-xmemalign (SPARC)
-xO5 (SPARC, x86)
-xregs=frameptr (x86)
-xtarget=native (SPARC, x86)
-xprefetch=auto,explicit (SPARC, x86)
Note that this selection of component option flags is
subject to change with each release of the compiler.
You can view an expansion of the -fast options by run-
ning the command
CC -fast -xdryrun |& grep ###
For details on the options set by -fast, see the C++
User's Guide.
Interactions:
You can override the values set by -fast by specifying
different values to the right of -fast on the command
line. For example, although the optimization level set
by -fast is -xO5, if you specify -fast, -xO3, the
optimization level becomes -xO3.
The -fast macro expands into compilation options that
may affect other specified options. For example, in the
following command, the expansion of the -fast macro
includes -xtarget=native which reverts -xarch to one of
the 32-bit architecture options.
Incorrect:
example% CC -xarch=v9 -fast test.cc
Correct:
example% CC -fast -xarch=v9 test.cc
See the description for each option to determine possi-
ble interactions.
Warnings:
Code compiled with the -fast option is not portable.
For example, compiling code using the following command
on an UltraSPARC(TM) III system will generate a binary
that will not execute on an UltraSPARC II system.
example% CC -fast test.cc
Do not use this option for programs that depend on IEEE
standard floating-point exception handling; different
numerical results, premature program termination, or
unexpected SIGFPE signals might occur.
The -fast option includes -fns -ftrap=%none; that is,
this option turns off all trapping.
The -fast option on x86 includes -xregs=frameptr. Be
sure to read the discussion of -xregs=frameptr espe-
cially when compiling mixed C, Fortran, and C++ source
codes.
In previous SPARC releases, the -fast macro included
-fnonstd, now it does not.
In previous SPARC releases, the -fast macro expanded to
-fsimple=1. Now it expands to -fsimple=2.
In previous releases, the -fast macro expanded to -xO4.
Now it expands to -xO5.
The expansion of the -fast option includes
-D_MATHERR_ERRNO_DONTCARE.
See also:
Numerical Computation Guide, ieee_sun(3m).
-features=a
Enables/disables various C++ language features.
The following flags are valid for both standard mode
(default) and compatibility mode (-compat[=4]) unless
otherwise specified.
Value Meaning
%all All the -feature options that are valid
for the specified mode (compatibility
mode or standard mode).
%none Turn off all the features that can be
turned off for the specified mode (com-
patibility mode or standard mode).
[no%]altspell [Do not] Recognize alternative token
spellings (for example, and for &&).
The default is no%altspell in compati-
bility mode and altspell in standard
mode.
[no%]anachronisms
[Do not] Allow anachronistic constructs.
When disabled (that is
-feature=no%anachronisms), no
anachronistic constructs are allowed.
The default is anachronisms.
[no%]arraynew (Compatibility mode only) [Do not]
Recognize array forms of operator new
and operator delete (for example, opera-
tor new[] (void*) ). When enabled, the
macro __ARRAYNEW = 1. When not enabled,
the macro is not defined. The default is
no%arraynew. For details on the use of
this flag, see the C++ Migration Guide.
[no%]bool [Do not] Allow the bool type and
literals. When enabled, the macro _BOOL
= 1. When disabled, the macro is not
defined. The default is no%bool in com-
patibility mode and bool in standard
mode.
[no%]conststrings
[Do not] Put literal strings in read-
only memory. The default is
no%conststrings in compatibility mode
and conststrings in standard mode.
[no%]except [Do not] 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 gen-
erate exception code. Note that the key-
words try, throw, and catch are always
reserved. The default is except.
[no%]explicit (Compatibility mode only) [Do not]
Recognize the keyword explicit. The
default is no%explicit.
[no%]export [Do not] Recognize the keyword export.
The default is no%export in compatibil-
ity mode and export in standard mode.
[no%]extensions
[Do not] Allow non-standard code that is
commonly accepted by other C++ com-
pilers. 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 [Do not] Allow $ as a non-initial iden-
tifier character. The default is
no%iddollar.
[no%]localfor [Do not] Use new standard-conforming
local-scope rules for the for statement.
The default is no%localfor in compati-
bility mode and localfor in standard
mode.
[no%]mutable [Do not] Recognize the keyword mutable.
The default is no%mutable in compatibil-
ity mode and mutable in standard mode.
[no%]namespace (Compatibility mode only) [Do not]
Recognize keywords namespace and using.
The default is no%namespace.
The purpose of -features=namespace is to
aid in converting code to standard mode.
By enabling this option, you get error
messages if you use these keywords as
identifiers. The keyword recognition
options allow you to find uses of the
added keywords without having to compile
in standard mode.
[no%]nestedaccess
(Standard mode only) [Do not] Allow
nested classes to access private members
of the enclosing class.
Default: -features=nestedacces
[no%]rvalueref [Do not] Allow binding a non-const
reference to an rvalue or temporary.
Default: -features=no%rvalueref
The C++ compiler has traditionally been
lax in enforcing the rule that a non-
const reference cannot be bound to a
temporary or rvalue. Beginning with
Studio Express 6/10 the C++ compiler
will not allow the invalid code by
default. To restore the old compiler
behavior, use the option
-features=rvalueref.
[no%]rtti [Do not] Allow runtime type identifica-
tion (RTTI). RTTI must be enabled to
use the dynamic_cast<> and typeid opera-
tors. For -compat=4 mode, the default is
no%rtti. Otherwise, the default is
-features=rtti, and the option
-features=no%rtti is not allowed.
[no%]split_init
[Do not] Put initializers for nonlocal
static objects into individual func-
tions. When you use
-features=no%split_init, the compiler
puts all the initializers in one func-
tion. Using -features=no%split_init
minimizes code size at the possible
expense of compile time. The default is
split_init.
[no%]strictdestorder
(Standard mode only) [Do not] Follow the
requirements specified by the C++ stan-
dard regarding the order of the destruc-
tion of objects with static storage
duration. The default is strictdes-
trorder.
[no%]tmplife (Standard mode only) [Do not] 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
[Do not] allow function templates to
refer to dependent static functions or
static function templates. The default
is the standard conformant
no%tmplrefstatic.
[no%]transitions
[Do not] allow ARM language constructs
that are problematic in standard C++ and
that may cause the program to behave
differently than expected or that may be
rejected by future compilers. When you
use -features=no%transitions, the com-
piler issues warnings about these con-
structs instead of error messages. When
you use -features=transitions in compa-
tibility mode (-compate[=4]), the com-
piler displays the warnings about these
constructs only if +w or +w2 is speci-
fied. The following constructs are con-
sidered to be transition errors: rede-
fining a template after it was used,
omitting the typename directive when it
is needed in a template definition, and
implicitly declaring type int. The set
of transition errors may change in a
future release. The default is transi-
tions.
Defaults:
If -features is not specified, the following is assumed
for compatibility mode (-compat[=4]):
-features=%none,anachronisms,except,split_init,transitions
If -features is not specified, the following is assumed
for standard mode (the default mode):
-features=%all,no%iddollar,no%extensions,no%tmplife
Interactions:
This option accumulates instead of overrides.
Use of the following in standard mode (the default) is
not compatible with the standard libraries and headers:
o no%bool
o no%except
o no%mutable
o no%explicit
Warnings:
Be careful when you specify -features=%all or
-features=%none. The set of features can change with
each compiler release and with each patch. Conse-
quently, you can get unintended behavior.
The behavior of a program might change when you use
-features=tmplife. Testing whether the program works
both with and without the -features=tmplife option is
one way to test the program's portability.
The compiler assumes -features=split_init by default in
compat mode (-compt=4). If you use the -features=%none
option to turn off other features, you may find it
desirable to turn the splitting of initializers into
separate functions back on by using
-features=%none,split_init instead.
-filt[=filter[,filter...]]
Suppress the filtering that CC normally applies to
linker error messages.
filter must be one of the following values
[no%]errors [Do not] Show the C++ explanations of
the linker error messages. The suppres-
sion of the explanations is useful when
the linker diagnostics are provided
directly to another tool.
[no%]names [Do not] Demangle the C++ mangled linker
names.
[no%]returns [Do not] Demangle the return types of
functions. Suppression of this deman-
gling helps you to identify function
names more quickly, but note that in the
case of co-variant returns, some func-
tions differ only in the return type.
[ no% ] stdlib [Do not] Simplify names from the stan-
dard library in both the linker and com-
piler error messages. This makes it
easier for you to recognize the name of
standard-library functions.
%all Equivalent to
-filt=errors,names,returns,stdlib. This
is the default behavior.
%none Equivalent to
-filt=no%errors,no%names,no%returns,no%stdlib.
Defaults:
If you do not specify the -filt option, or if you
specify -filt without any values, then the compiler
assumes -filt=errors,names,returns,stdlib.
Interactions:
[no%]returns has no effect when used with no%names.
That is, the following options are equivalent:
-filt=no%names
-filt=no%names,no%returns
-filt=no%names,returns
See also c++filt(1).
-flags
Same as -xhelp=flags.
-fma [= { none|fused}]
(SPARC) Enables automatic generation of floating-point,
fused, multiply-add instructions. -fma=none disables
generation of these instructions. -fma=fused allows the
compiler to attempt to find opportunities to improve
the performance of the code by using floating-point,
fused, multiply-add instructions.
The default is -fma=none.
The minimum requirements are -xarch=sparcfmaf and an
optimization level of at least -xO2 for the compiler to
generate fused multiply-add instructions. The compiler
marks the binary program if fused multiply-add instruc-
tions are generated in order to prevent the program
from executing on platforms that do not support them.
Fused multiply-adds eliminate the intermediate rounding
step between the multiply and the add. Consequently,
programs may produce different results when compiled
with -fma=fused, although precision will tend to be
increased rather than decreased.
-fnonstd
This option causes hardware traps to be enabled for
floating-point overflow, division by zero, and invalid
operations exceptions.
These results are converted into SIGFPE signals. If
the program has no SIGFPE handler, it terminates with a
memory dump (unless you limit the core dump size to 0).
SPARC: In addition, -fnonstd selects SPARC nonstandard
floating point.
Defaults:
If -fnonstd is not specified, IEEE 754 floating-point
arithmetic exceptions do not abort the program, and
underflows are gradual.
Expansions:
x86: -fnonstd expands to -ftrap=common.
SPARC: -fnonstd expands to -fns -ftrap=common.
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 sub-
normal 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 significantly improve the performance
of some programs.
Optional use of =yes or =no provides a way of toggling
the -fns flag following some other macro flag that
includes -fns, such as -fast.
-fns is the same as -fns=yes.
-fns=yes selects non-standard floating point.
-fns=no selects standard floating point.
Defaults:
If -fns is not specified, the nonstandard floating-
point mode is not enabled automatically. Standard IEEE
754 floating-point computation takes place, that is,
underflows are gradual.
If only -fns is specified -fns=yes is assumed.
Warnings:
When nonstandard mode is enabled, floating-point arith-
metic may produce results that do not conform to the
requirements of the IEEE 754 standard.
On SPARC systems, this option is effective only if used
when compiling the main program.
If you compile one routine with -fns, then compile all
routines of the program with the -fns option; otherwise
you can get unexpected results.
-fprecision=a
(x86 platform) Sets floating-point rounding precision
mode. a must be one of: single, double, extended.
The -fprecision flag sets the rounding precision mode
bits in the Floating Point Control Word. These bits
control the precision to which the results of basic
arithmetic operations (add, subtract, multiply, divide,
and square root) are rounded.
The following table shows the meanings of the values of
a.
Value Meaning
single Rounds to an IEEE single-precision value
double Rounds to an IEEE double-precision value
extended Rounds to the maximum precision available
When a is single or double, this flag causes the round-
ing precision mode to be set to single or double preci-
sion, respectively, when a program begins execution.
When p is extended or the -fprecision flag is not used,
the rounding precision mode remains as the extended
precision.
The single precision rounding mode causes results to be
rounded to 24 significant bits, and double precision
rounding mode causes results to be rounded to 53 signi-
ficant bits. In the default extended precision mode,
results are rounded to 64 significant bits. This mode
controls only the precision to which results in regis-
ters are rounded, and it does not affect the range. All
results in register are rounded using the full range of
the extended double format. Results that are stored in
memory are rounded to both the range and precision of
the destination format.
The nominal precision of the float type is single. The
nominal precision of the long double type is extended.
Defaults:
When the -fprecision flag is not specified, the round-
ing precision mode defaults to extended.
Warnings:
This option is effective only on x86 systems and only
if used when compiling the main program, but is ignored
if compiling for 64-bit platforms (-m64), or SSE2-
enabled processors (-xarch=sse2). -fprecision is
ignored on SPARC platforms.
-fround=a
Sets the IEEE rounding mode in effect at startup.
a must be one of: nearest, tozero, negative, positive.
Value Meaning
nearest Rounds towards the nearest number and break-
ing ties to even numbers.
tozero Round-to-zero.
negative Round-to-negative-infinity.
positive Round-to-positive-infinity.
This option sets the IEEE 754 rounding mode that:
o Can be used by the compiler in evaluating constant
expressions.
o Is established at runtime during the program initial-
ization.
The meanings are the same as those for the ieee_flags
function, which may be used to change the mode at run-
time.
Defaults:
When the -fround option is not specified, the rounding
mode defaults to -fround=nearest.
Warnings:
If you compile one routine with -fround=a, compile all
routines of the program with the same -fround=a option;
otherwise, you can get unexpected results. This option
is effective only if used when compiling the main pro-
gram.
-fsimple[=n]
Selects floating-point optimization preferences.
If n is present, it must be 0, 1 or 2.
The following table shows the -fsimple values.
Value Meaning
0 Permits no simplifying assumptions. Preserves
strict IEEE 754 conformance.
1 Allows conservative simplification. The
resulting code does not strictly conform to
IEEE 754, but numeric results of most pro-
grams are unchanged.
With -fsimple=1, the optimizer is not allowed
to optimize completely without regard to
roundoff or exceptions. In particular, a
floating point computation cannot be replaced
by one that produces different results with
rounding modes held constant at runtime.
With -fsimple=1, the optimizer can assume the
following:
o IEEE 754 default rounding/trapping modes do
not change after process initialization.
o Computation producing no visible result
other than potential floating-point excep-
tions may be deleted.
o Computation with Infinity or NaNs as
operands need not propagate NaNs to their
results. For example, x*0 may be replaced
by 0.
o Computations do not depend on sign of zero.
2 Includes all the functionality of -fsimple=1,
and also enables the use of SIMD instructions
to compute reductions when -xvector=simd is
in effect.
Also permits aggressive floating point optim-
ization that may cause many programs to pro-
duce different numeric results due to changes
in rounding. For example, permits the optim-
izer to replace all computations of x/y in a
given loop with x*z, where x/y is guaranteed
to be evaluated at least once in the loop,
z=1/y , and the values of y and z are known
to have constant values during execution of
the loop.
Defaults:
If -fsimple is not designated, the compiler uses -fsim-
ple=0.
If -fsimple is designated but no value is given for n,
the compiler uses -fsimple=1.
Warnings:
This option can break IEEE 754 conformance.
See Also:
Techniques for Optimizing Applications: High Perfor-
mance Computing written by Rajat Garg and Ilya Sharapov
for a more detailed explanation of how optimization can
impact precision.
-fstore
(x86 platform) Forces precision of floating-point
expressions.
This option causes the compiler to convert the value of
a floating-point expression or function to the type on
the left side of an assignment - when that expression
or function is assigned to a variable, or when that
expression is cast to a shorter floating-point type
rather than leaving the value in a register.
To turn off this option, use the -nofstore option.
Warnings:
Due to roundoffs and truncation, the results may be
different from those that are generated from the regis-
ter values.
-ftrap=a[,a...]
Sets the IEEE trapping mode in effect at startup but
does not install a SIGFPE handler. You can use
ieee_handler(3M) or fex_set_handling(3M) to simultane-
ously enable traps and install a SIGFPE handler. If you
specify more than one value, the list is processed
sequentially from left to right.
a must be one of the following values.
Value Meaning
[no%]division [Do not] Trap on division by zero.
[no%]inexact [Do not] Trap on inexact result.
[no%]invalid [Do not] Trap on invalid operation.
[no%]overflow [Do not] Trap on overflow.
[no%]underflow [Do not] Trap on underflow.
%all Trap on all the above.
%none Trap on none of the above.
common Trap on invalid, division by zero, and
overflow.
Note that the [no%] form of the option is used only to
modify the meanings of the %all or common value and
must be used with one of these values, as shown in the
example. The [no%] form of the option by itself does
not explicitly cause a particular trap to be disabled.
Defaults:
If you do not specify -ftrap, the compiler assumes
-ftrap=%none.
Example: -ftrap=%all,no%inexact means to set all traps
except inexact.
Warnings:
If you compile one routine with -ftrap, compile all
routines of the program with the same -ftrap option;
otherwise, you can get unexpected results.
Use the -ftrap=inexact trap with caution, as it will
result in the trap being issued whenever a floating-
point value cannot be represented exactly. For example,
the following statement may generate this condition:
x = 1.0 / 3.0;
-G Build a dynamic shared library instead of an executable
file; see the ld(1) man page and the C++ User's Guide.
All source files specified in the command line are com-
piled with -xcode=pic13 by default.
When building a shared library from files that involve
templates and were compiled with the -instances=extern
option, any template instances referenced by the .o
files will be included from the template cache automat-
ically.
If you are creating a shared object by specifying -G
along with other compiler options that must be speci-
fied at both compile time and link time, make sure that
those same options are also specified at both compile
time and link time when you link with the resulting
shared object.
When you create a shared object, all the object files
that are compiled with -xarch=v9 must also be compiled
with an explicit -xcode value as documented under the
description of -xcode.
The following options are passed to ld if -c is not
specified:
o -dy
o -G
o -R
Do not use ld -G to build shared libraries; use CC -G.
The CC driver automatically passes several options to
ld that are needed for C++.
When you use the -G option, the compiler does not pass
any default -l options to ld. If you want the shared
library to have a dependency on another shared library,
you must pass the necessary -l option on the command
line. For example, if you want the shared library to be
dependent upon libCrun, you must pass -lCrun on the
command line.
-g Instructs both the compiler and the linker to prepare
the file or program for debugging. The tasks include:
o Producing more detailed information, known as stabs,
in the symbol table of the object files and the exe-
cutable
o Producing some "helper functions," which the Debugger
can call to implement some of its features
o Disabling the inline generation of functions, if no
optimization level is specified; that is, using this
option implies the +d option if no optimization level
is also specified. -g with any -O or -xO level does
not disable inlining.
o Disabling certain levels of optimization
Interactions:
If you use this option with -xO[level] (or its
equivalent options, such as -O), you will get inlining
and limited debugging information. For more informa-
tion, see the entry for -xO.
If you specify -gO and the optimization level is -xO3
or lower, the compiler provides best-effort symbolic
information with almost full optimization. Tail-call
optimization is disabled.
If you use this option and the optimization level is
-xO4 or higher, the compiler provides best effort sym-
bolic information with full optimization.
When you specify this option, the +d option is speci-
fied automatically unless -O or -xO are also specified.
To use the full capabilities of the Performance
Analyzer, compile with the -g option. While some per-
formance analysis features do not require -g, you must
compile with -g to view annotated source, some function
level information, and compiler commentary messages.
See the analyzer(1) man page and the Performance
Analyzer manual for more information.
The commentary messages that are generated with -g
describe the optimizations and transformations that the
compiler made while compiling your program. Use the
er_src(1) command to display the messages which are
interleaved with the source code.
Warnings
If you compile and link your program in separate steps,
then including the -g option in one step and excluding
it from the other step will not affect the correctness
of the program, but it will affect the ability to debug
the program. Any module that is not compiled with -g
(or -g0), but is linked with -g (or -g0) will not be
prepared properly for debugging. Note that compiling
the module that contains the function main with the -g
option (or the -g0 option) is usually necessary for
debugging.
See also:
For more information, see the explanations for -g0,
-xs, and +d, as well as the ld(1) man page.
-g0 Instructs the compiler to prepare the file or program
for debugging, but not to disable inlining. This option
is the same as -g, except that +d is disabled and dbx
cannot step into inlined functions.
See also:
+d
-H On the standard error output (stderr), prints, one per
line, the path name of each #include file contained in
the current compilation.
-h[ ]lname
Assigns the name lname to the generated shared dynamic
library.
This is a loader option that is passed to ld. In gen-
eral, the name after -h should be exactly the same as
the one after -o. A space between the -h and lname is
optional.
The compile-time loader assigns the specified name to
the shared dynamic library you are creating. It
records the name in the library file as the intrinsic
name of the library. If there is no
-hlname option, then no intrinsic name is recorded in
the library file.
Every executable file has a list of needed shared
library files. When the runtime linker links the
library into an executable file, the linker copies the
intrinsic name from the library into that list of
needed shared library files. If there is no intrinsic
name of a shared library, then the linker copies the
path of the shared library file instead. This command
line is an example:
% CC -G -o libx.so.1 -h libx.so.1 a.o b.o c.o
Interactions:
This option accumulates instead of overrides.
-help
Same as -xhelp=flags.
-Ipathname
Adds pathname to the list of directories that are
searched for #include files with relative file names -
those that do not begin with a slash.
The compiler searches for quote-included files (of the
form #include "foo.h") in this order:
1. In the directory containing the source
2. In the directories named with -I options, if any
3. In the include directories for compiler-provided
C++ header files, ANSI C header files, and
special-purpose files
4. In /usr/include
The compiler searches for bracket-included files (of
the form #include <foo.h>) in this order:
1. In the directories named with -I options, if any
2. In the include directories for compiler-provided
C++ header files, ANSI C header files, and
special-purpose files
3. In /usr/include
Note - If the spelling matches the name of a standard
header file, also refer to "Standard Header Implementa-
tion" in the C++ User's Guide.
Interactions:
This option accumulates instead of overrides.
The -I- option allows you to override the default
search rules.
If -library=no%Cstd is specified, then the compiler-
provided Cstd header files are not searched.
Note - If -ptipath is not used, the compiler looks for
template files in -Ipathname. It is recommended that
you use -Ipathname instead of -ptipath.
Warnings
Never specify the compiler installation area,
/usr/include, /lib, /usr/lib, as search directories.
-I- Change the include-file search rules to the following:
o For include files of the form #include "foo.h",
search the directories in the following order:
1. The directories named with -I options (both
before and after -I-)
2. The directories for compiler-provided C++
header files, ANSI C header files, and
special-purpose files.
3. The /usr/include directory.
o For include files of the form #include <foo.h>,
search the directories in the following order:
1. The directories named with the -I options
that appear after -I-.
2. The directories for compiler-provided C++
header files, ANSI C header files, and
special-purpose files.
3. The /usr/include directory.
Warnings
Never specify the compiler installation area,
/usr/include, /lib, /usr/lib, as search directories.
Only the first -I- in a command line causes the
described behavior.
-i Tells the linker, ld(1), to ignore any LD_LIBRARY_PATH
setting.
-include filename
This option causes the compiler to treat filename as if
it appears in the first line of a primary source file
as a #include preprocessor directive.
The first directory the compiler searches for filename
is the current working directory and not the directory
containing the main source file, as is the case when a
file is explicitly included. If the compiler cannot
find filename in the current working directory, it
searches the normal directory paths. If you specify
multiple -include options, the files are included in
the order they appear on the command line.
-inline
Same as -xinline.
-instances=a
Controls the placement and linkage of template
instances. The following table shows the meanings of
the values of a.
Value Meaning
extern Places all needed instances into the template
repository within comdat sections and gives
them global linkage. (If an instance in the
repository is out of date, it is reinstan-
tiated.)
Note: If you are compiling and linking in
separate steps and you specify
-instance=extern for the compilation step,
you must also specify it for the link step.
explicit Places explicitly instantiated instances into
the current object file within comdat sec-
tions and gives them global linkage. Does not
generate any other needed instances.
global Places all needed instances into the current
object file within comdat sections and gives
them global linkage.
semiexplicit
Places explicitly instantiated instances and
all instances needed by the explicit
instances into the current object file within
comdat sections and gives them global link-
age.
static Note: -instances=static is deprecated. There
is no longer any reason to use
-instances=static, because -instances=global
now gives you all the advantages of static
without the disadvantages. This option was
provided in earlier compilers to overcome
problems that do not exist in this version of
the compiler.
Places all needed instances into the current
object file and gives them static linkage.
Defaults:
If instances is not specified, -instances=global is
assumed.
Warnings:
static and semiexplicit values may produce invalid
results. See C++ User's Guide for more information.
-instlib=file
Use this option to inhibit the generation of a template
instances that are duplicated in a library, either
static or shared, and the current object. In general,
if your program shares large numbers of instances with
libraries, try -instlib=file and see whether compila-
tion time improves.
Values:
Use the file argument to specify the library that you
know contains the existing template instances. 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. You should not use this option. Use
-xcode=pic32 instead.
(x86) Same as -Kpic on x86 architectures.
-Kpic
(SPARC) Obsolete. You should not use this option. Use
-xcode=pic13 instead.
(x86) Produces position-independent code. Use this
option to compile source files when building a shared
library. Each reference to a global datum is generated
as a dereference of a pointer in the global offset
table. Each function call is generated in pc-relative
addressing mode through a procedure linkage table.
-keeptmp
Retains the temporary files that are created during
compilation. Along with -verbose=diags, this option is
useful for debugging.
-Lpath
Adds path to the library search paths.
This option is passed to ld. The linker searches the
directory specified by path before it searches the
compiler-provided directories.
Interactions:
This option accumulates instead of overrides.
Warnings
Never specify the /usr/include, lib, /usr/lib, or the
compiler installation area as search directories.
-llib
Add library liblib.a or liblib.so to linker's list of
search libraries.
This option is passed to ld. Normal libraries have
names such as liblib.a or liblib.so where the lib and
.a or .so parts are required. You can specify the lib
part with this option. Put as many libraries as you
want on a single command line; they are searched in the
order specified with -Lpath.
Use this option after your object file names.
Interactions:
This option accumulates instead of overrides.
Warnings:
If you are building a multithreaded application or
linking your application to a multithreaded library,
you must compile and link your program with the -mt
option instead of linking your application directly
with -lthread.
See also:
-mt
-libmieee
Use -xlibmieee.
-libmil
Use -xlibmil.
-library=lib[,lib...]
Incorporates specified CC-provided libraries into com-
pilation and linking.
When the -library option is used to specify a CC-
provided library, the proper -I paths are set during
compilation and the proper -L, -Y, -P, and -R paths and
-l options are set during linking.
Values:
The following table shows the meanings of the values
for lib.
For compatibility mode (-compat[=4]):
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 [Do not] Use classic-iostreams
Tools.h++ version 7.
[no%]rwtools7_dbg [Do not] Use debug-enabled
Tools.h++ version 7.
[no%]complex [Do not] Use libcomplex, for com-
plex arithmetic.
[no%]interval Deprecated. Do not use. Use -xia.
[no%]libC [Do not] Use libC, the C++ support
library.
[no%]gc [Do not] Use libgc, garbage collec-
tion.
[no%]sunperf [Do not] Use the Sun Performance
Library(TM).
%none Use no C++ libraries except for
libC.
For standard mode (the default mode):
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 [Do not] Use classic-iostreams
Tools.h++ version 7.
[no%]rwtools7_dbg [Do not] Use debug-enabled
Tools.h++ version 7.
[no%]rwtools7_std [Do not] Use standard-iostreams
Tools.h++ version 7.
[no%]rwtools7_std_dbg
[Do not] Use debug_enabled
standard-iostreams Tools.h++ ver-
sion 7.
[no%]interval Deprecated. Do not use. Use -xia.
[no%]iostream [Do not] Use libiostream, the clas-
sic iostreams library.
[no%]Cstd [Do not] Use libCstd, the C++ stan-
dard library. [Do not] include the
compiler-provided C++ standard
library header files.
[no%]stlport4 [Do not] Use STLport's implementa-
tion of the standard library. If
you specify -library=stlport4, the
command expands to
-library=no%Cstd,stlport4.
[no%]stlport4_dbg [Do not] Use STLport's debug-
enabled library.
[no%]stdcxx4 [Do not] Use the Apache stdcxx ver-
sion 4 library installed as part of
Solaris, instead of the default
libCstd. This option also sets the
-mt option implicitly. The stdcxx
library requires multi-threading
mode. This option must be used
consistently on every compilation
and link command in the entire
application. Code compiled with
-library=stdcxx4 cannot be used in
the same program as code compiled
with the default -library=Cstd or
the optional -library=stlport4.
[no%]Crun [Do not] Use libCrun, the C++ run-
time library
[no%]gc [Do not] Use libgc, garbage collec-
tion.
[ no% ]sunperf [Do not] Use the Sun Performance
Library.
%none Use no C++ libraries except for
libCrun.
Defaults:
For compatibility mode (-compat[=4]), if -library is
not specified, -library=libC is assumed.
The libC library is always included unless it is
specifically excluded using -library=no%libC.
For standard mode (the default mode), the libCstd
library is always included unless it is specifically
excluded by using -library=%none, -library=no%Cstd, or
-library=stlport4.
Also, regardless of standard or compat mode, the libm
and libc libraries are always included, even if you
specify -library=%none. In standard mode, libCrun is
always included.
Examples:
To link in standard mode (the default mode) without any
C++ libraries (except libCrun), use:
example% CC -library=%none
To include the classic-iostreams Rogue Wave tools.h++
library in standard mode, use:
example% CC -library=rwtools7,iostream
To include the standard-iostreams Rogue Wave tools.h++
library in standard mode, use:
example% CC -library=rwtools7_std
To include the classic-iostreams Rogue Wave tools.h++
library in compatibility mode, use:
example% CC -compat -library=rwtools7
When you include the classic-iostreams Rogue Wave tools
library in standard mode (the default mode), you must
also include libiostream (see the C++ Migration Guide
for additional information). You can use the standard-
iostreams Rogue Wave tools library in standard mode
only. The following command examples show both valid
and invalid use of the Rogue Wave tools.h++ library
options.
Valid:
example% CC -compat -library=rwtools7 foo.cc
Invalid:
example% CC -compat -library=rwtools7_std foo.cc
Valid, classic iostreams
example% CC -library=rwtools7,iostream foo.cc
Invalid
example% CC -library=rwtools7 foo.cc
Valid, standard iostreams
example% CC -library=rwtools7_std foo.cc
Invalid
example% CC -library=rwtools7_std,iostream foo.cc
If you include both libCstd and libiostream, you must
be careful to not use the old and new forms of ios-
treams (for example, cout and std::cout) within a pro-
gram to access the same file. Mixing standard iostreams
and classic iostreams in the same program is likely to
cause problems if the same file is accessed from both
classic and standard iostream code.
Programs linking neither libC nor libCrun might not use
all features of the C++ language.
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.
You cannot use -library=stlport4 and -library=Cstd on
the same command line.
You cannot use -library=sunperf and -xlic_lib=sunperf
on the same command line.
Use of the -library option ensures that the -l options
for the specified libraries are emitted in the right
order. For example, the -l options are passed to ld in
the order -lrwtool -liostream for both
-library=rwtools7,iostream and
-library=iostream,rwtools7.
When you use the interval arithmetic libraries, you
must include one of the following libraries: libC,
libCstd, or libiostreams.
The specified libraries are linked before the system
support libraries are linked.
Warnings:
Do not redefine or modify any of the configuration mac-
ros for STLport or Solaris Studio C++ libraries. The
libraries are configured and built in a way that works
with the C++ compiler. libCstd and Tool.h++ are config-
ured 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, 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++ Migration Guide,
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 Solaris platforms and on
Linux platforms that are not 64-bit enabled. The LP64
memory model (64-bit long, pointer data types) is the
default on Linux platforms that are 64-bit enabled.
-m64 is permitted only on platforms that are enabled
for the LP64 model.
Object files or libraries compiled with -m32 cannot be
linked with object files or libraries compiled with
-m64.
When compiling applications with large amounts of
static data using -m64, -xmodel=medium may also be
required. Be aware that some Linux platforms do not
support the medium model.
Modules that are compiled with -m32|-m64 must also be
linked with -m32|-m64. For a complete list of compiler
options that must be specified at both compile time and
at link time, see the C++ User's Guide.
Note that in previous compiler releases, the memory
model, ILP32 or LP64, was implied by the choice of the
instruction set with -xarch. Starting with the Sun Stu-
dio 12 compilers, this is no longer the case. On most
platforms, just adding -m64 to the command line is suf-
ficient to create 64-bit objects.
On Solaris, -m32 is the default. On Linux systems sup-
porting 64-bit programs, -m64 -xarch=sse2 is the
default.
See also -xarch.
-mc Removes duplicate strings from the .comment section of
the object file. When you use the -mc option, the mcs
-c command is invoked.
-migration
Explains where to get information about migrating
source code that was built for earlier versions of the
compiler.
Note - This option might cease to exist in the next
release.
-misalign
(SPARC) Obsolete. You should not usethis option. Use
the -xmemalign=2i option instead. For a complete list
of obsolete options, see the C++ User's Guide.
-mr[,string]
Removes all strings from the .comment section of the
object file and, if string is supplied, places string
in that section. If the string contains blanks, the
string must be enclosed in quotation marks. When you
use this option, the command mcs -d [-a string] is
invoked.
Interactions:
This option is not valid when either -S, -xsbfast, or
-sbfast is specified.
-mt[={yes|no}]
Use this option to compile and link multithreaded code
using the Solaris threads or POSIX threads API. The
-mt=yes option assures that libraries are linked in the
appropriate order.
This option passes -D_REENTRANT to the preprocessor.
To use Solaris threads, include the thread.h header
file and compile with the -mt=yes option. To use POSIX
threads on Solaris platforms, include the pthread.h
header file and compile with the -mt=yes option.
On Linux platforms, only the POSIX threads API is
available. (There is no libthread on Linux platforms.)
Consequently, -mt=yes on Linux platforms adds -lpthread
instead of -lthread. To use POSIX threads on Linux
platforms, compile with -mt.
Note that when compiling with -G,neither -ltread nor
-lpthread are automatically included by -mt=yes. You
will need to explicitly list these libraries when
building a shared library.
The -xopenmp option (for using the OpenMP shared-memory
parallelization API) includes -mt=yes automatically.
If you compile with -mt=yes and link in a separate
step, you must use the -mt=yes option in the link step
as well as the compile step. If you compile and link
one translation unit with -mt=yes, you must compile and
link all units of the program with -mt=yes
-mt=yes is the default behavior of the compiler. If
this behavior is not desired use the option -mt=no.
The option -mt is equivalent to -mt=yes.
See also: -xnolib
-native
Use -xtarget=native.
-noex
Use -features=no%except.
-nofstore
(x86 platform) Disables forced precision of expression.
This option does not force the value of a floating-
point expression or function to the type on the left
side of an assignment but leaves the value in a regis-
ter when that expression or function is assigned to a
variable or when it is cast to a shorter floating-point
type.
See also:
-fstore
-nolib
Use -xnolib.
-nolibmil
Use -xnolibmil.
-noqueue
Disables license queueing. If no license is available,
this option returns without queueing your request and
without compiling. A nonzero status is returned for
testing makefiles.
-norunpath
Does not build the path for shared libraries into the
executable.
If an executable file uses shared libraries, then the
compiler normally builds in a path that points the run-
time linker to those shared libraries. To do so, the
compiler passes the -R option to ld. The path depends
on the directory where you have installed the compiler.
This option is recommended for building executables
that will be shipped to customers who may have a dif-
ferent path for the shared libraries that are used by
the program.
Interactions:
If you use any shared libraries under the compiler
installed area (default location <installpath>/lib )
and you also use -norunpath, then you should either use
the -R option at link time or set the environment vari-
able LD_LIBRARY_PATH at run time to specify the loca-
tion of the shared libraries. This will allow the
runtime linker to find the shared libraries.
-O The -O macro now expands to -xO3 instead of -xO2. The
change in default yields higher run-time performance.
However, -xO3 may be inappropriate for programs that
rely on all variables being automatically considered
volatile. Typical programs that might have this assump-
tion are device drivers and older multi-threaded appli-
cations that implement their own synchronization primi-
tives. The work around is to compile with -xO2 instead
of -O.
-O[level]
Use -xOlevel.
-o filename
Sets the name of the output file (with the suffix, .o)
or the executable file to filename.
Note - If the compiler must store template instances,
it stores them in the template repository in the output
file's directory.
Warning:
filename must have the appropriate suffix for the type
of file to be produced by the compilation (see FILES).
It cannot be the same file as the source file, since
the CC driver does not overwrite the source file.
+p Ignore non-standard preprocessor asserts.
Defaults:
If +p is not present, the compiler 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 Use -xpg.
-PIC SPARC: Same as -xcode=pic32.
x86: Same as -KPIC.
-pic SPARC: Same as -xcode=pic13.
x86: Same as -Kpic.
-pta Use -template=wholeclass.
-ptipath
Specifies an additional search directory for template
source.
This option is an alternative to the normal search path
set by -Ipathname. If the -ptipath flag is used, the
compiler looks for template definition files on this
path and ignores the -Ipathname flag.
Using the -Ipathname flag instead of -ptipath produces
less confusion.
Interactions:
This option accumulates instead of overrides.
-pto Use -instances=static.
-ptrpath
This option is obsolete and is ignored by the compiler.
Warnings:
Even though the -ptr option is ignored, you should
remove it from all compilation commands because, in a
later release, it may be reused with a different
behavior.
-ptv Use -verbose=template.
-Qoption phase[,option...]
Passes option to the compilation phase.
To pass multiple options, specify them in order as a
comma-separated list. Options that are passed to com-
ponents with -Q can be reordered. Options that the
driver recognizes are kept in the correct order. Do not
use -Q for options that the driver already recognizes.
For example, the C++ compiler recognizes 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
-zdefaultextract ... // error
the -z options can be reordered, giving incorrect
results.
The following table shows the possible values for
phase.
SPARC x86
ccfe ccfe
iropt iropt
cg ube
CClink CClink
ld ld
Examples:
When the CC driver invokes ld in the following command,
-Qoption passes the -i option to ld:
example% CC -Qoption ld -i test.cc
Warnings:
Be careful to avoid unintended effects. For example
-Qoption ccfe -features=bool,iddollar
is interpreted as
-Qoption ccfe -features=bool -Qoption ccfe iddollar
The correct usage is
-Qoption ccfe -features=bool,-features=iddollar
-qoption phase option
Use -Qoption.
-qp Same as -p.
-Qproduce sourcetype
Causes the CC driver to produce source code of the type
sourcetype. Source code types are shown in the follow-
ing table.
Value Meaning
.i Preprocessed C++ source from ccfe
.o Object file from the code generator
.s Assembler source from the code generator
-qproduce sourcetype
Use -Qproduce.
-Rpath[:path...]
Builds dynamic library search paths into the executable
file.
This option is passed to ld.
Defaults:
If the -R option is not present, the default library
search path is recorded in the output object and passed
to the runtime linker. The default library search order
can be seen by using the -dryrun option and examining
the -Y option of the ld invocation.
Interactions:
This option accumulates instead of overrides.
If both the LD_RUN_PATH environment variable and the -R
option are specified, then the path from -R is scanned,
and the path from LD_RUN_PATH is ignored.
See also:
-norunpath
-readme
Same as -xhelp=readme.
-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.
-sb Deprecated - do not use. The source browser functional-
ity is obsolete.
-sbfast
Deprecated - do not use. The source browser functional-
ity is obsolete.
-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 [Do not] 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).
%all Link statically all the libraries speci-
fied by the -library option, all the
library specified in the -xlang option,
and, if -xia is specified, the interval
libraries.
%none Link no libraries specified in the
-library option and the -xlang option
statically. If -xia is specified in the
command line, link no interval libraries
statically.
Defaults:
If -staticlib is not specified, -staticlib=%none is
assumed.
Interactions:
This option accumulates instead of overrides.
The -staticlib option only works for the C++ libraries
that are selected explicitly with the -xia, the -xlang
option, and the -library option, in addition to the C++
libraries that are selected implicitly by default. In
compatibility mode (-compat=[4]), libC is selected by
default. In standard mode (the default mode), 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.
When using -xarch=v9, -xarch=v9a, or -xarch=v9b, (or
equivalent 64-bit architecture options), some libraries
are not available as static libraries.
The options -staticlib=Crun and -staticlib=Cstd do not
work on 64-bit 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. Synchronization is needed only
when you use iostreams to write to cout and stdio to
write to stdout in the same program. The C++ standard
requires synchronization so the C++ compiler turns it
on by default. However, application performance is
often much better without synchronization. If your pro-
gram does not write to both cout and stdout, you can
use the option -sync_stdio=no to turn off synchroniza-
tion.
Defaults:
If you do not specify -sync_stdio, the compiler sets it
to -sync_stdio=yes.
Examples:
Consider the following example:
#include <stdio.h>
#include <iostream>
int main()
{
std::cout << "\nHello ";
printf("beautiful ");
std::cout << "world!";
printf("\n");
}
With synchronization, the program prints on a line by
itself
Hello beautiful world!
Without synchronization, the output gets scrambled.
Warnings:
This option is only effective for linking of execut-
ables, not for libraries.
-temp=path
Defines the directory for temporary files.
This option sets path as the directory for the tem-
porary files which are generated during the compilation
process. The compiler gives precedence to the value set
by -temp over the value of TMPDIR.
See also:
-keeptmp
-template=a[,a...]
Enables/disables various template options.
a must be one of the following values.
Value Meaning
[no%]extdef [Do not] search for template defin-
itions in separate source files.
[no%]geninlinefuncs [Do not] instantiate inline member
functions of the explicitly instan-
tiated class template which were
not generated previously.
[no%]wholeclass [Do not] Instantiate a whole tem-
plate 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 execu-
tion.
The -traceback option causes the executable to issue a
stack trace to stderr, dump core, and exit if certain
signals are generated by the program. If multiple
threads generate a signal, a stack trace will only be
produced for the first one.
To use traceback, add the -traceback option to the com-
piler command line when linking. The option is also
accepted at compile-time but is ignored unless an exe-
cutable binary is generated. Using -traceback with -G
to create a shared library is an error.
%none or none
disables traceback
common
specifies that a stack trace should be issued if
any of a set of common signals is generated --
sigill, sigfpe, sigbus, sigsegv, and sigabrt.
signals_list
specifies a comma-separated list of names of sig-
nals which should generate a stack trace, in lower
case. The following signals (those that cause the
generation of a core file) can be caught:
sigquit, sigill, sigtrap, sigabrt, sigemt, sigfpe,
sigbus, sigsegv, sigsys, sigxcpu, sigxfsz
Any of these can be preceeded with no% to disable
catching the signal.
For example: -traceback=sigsegv,sigfpe will pro-
duce a stack trace and core dump if either sigsegv
or sigfpe is generated.
If the option is not specified, the default is
-traceback=%none
-traceback without any = sign implies -traceback=common
Note: If the core dump is not wanted, users may set the
coredumpsize limit to zero using:
% limit coredumpsize 0
The -traceback option has no effect on runtime perfor-
mance.
-Uname
Deletes initial definition of the preprocessor symbol
name. This option removes any initial definition of the
macro symbol name that was created by -D on the same
command line, including those implicitly placed there
by the command-line driver.
This option has no effect on any other predefined mac-
ros nor on macro definitions in source files.
To see the -D options that are placed on the command
line by the command-line driver, add the -dryrun option
to your command line.
You can specify multiple -U options on the command
line.
Examples:
The following command undefines the predefined symbol
__sun. Preprocessor statements in test.cc such as
#ifdef(__sun) will sense that the symbol is undefined.
example% CC -U__sun test.cc
Interactions:
This option accumulates instead of overrides.
All -U options are processed after any -D options that
are present.
-unroll=n
Same as -xunroll=n.
-V Same as -verbose=version.
-v Same as -verbose=diags.
-vdelx
Deprecated, do not use. This flag is available only for
compatibility mode (-compat[=4]).
For expressions using delete[], this option generates a
call to the runtime library function _vector_deletex_
instead of generating a call to _vector_delete_.
The function _vector_delete_ takes two arguments: the
pointer to be deleted and the size of each array ele-
ment.
The function _vector_deletex_ behaves the same as
_vector_delete_ except that it takes an additional
third argument: the address of the destructor for the
class. This third argument is not used by the function
but is provided to be used by third-party vendors.
Defaults:
When -vdelx is not specified, the compiler generates a
call to _vector_delete_ for expressions using delete[].
Warnings:
This is an obsolete option that will be removed in
future releases. Do not use this option unless you have
bought some software from a third-party vendor and the
vendor recommends using this option.
-verbose=a[,a...]
Controls compiler verbosity.
a must be one of the following values.
Value Meaning
[no%]template [Do not] Turn on the template
instantiation verbose mode, some-
times called the verify mode. The
verbose mode displays each phase of
instantiation as it occurs during
compilation.
[no%]diags [Do not] Print the command line for
each compilation pass.
[no%]version [Do not) Direct the CC driver to
print the names and version numbers
of the programs it invokes.
%all Invokes all the above.
%none Invokes none of the above.
Defaults:
If -verbose is not specified, the compiler assumes
-verbose=%none.
Interactions:
This option accumulates instead of overrides.
+w Identifies code that might have unintended conse-
quences. The +w option no longer generates a warning if
a function is too large to inline or if a declared pro-
gram element is unused. These warnings do not identify
real problems in the source, and were thus inappropri-
ate to some development environments. Removing these
warnings from +w enables more aggressive use of +w in
those environments. These warnings are still available
with the +w2 option.
Generates additional warnings about questionable con-
structs that are:
o Nonportable
o Likely to be mistakes
o Inefficient
Defaults:
If +w is not specified, the compiler warns about con-
structs that are almost certainly problems.
Interactions:
Some C++ standard headers result in warnings when com-
piled with +w.
+w2 Emits the same warnings as +w as well as warnings about
technical violations that are probably harmless, but
that might reduce the maximum portability of your pro-
gram.
The +w2 option no longer warns about the use of
implementation-dependent constructs in the system
header files. Because the system header files are the
implementation, the warning was inappropriate. Removing
these warnings from +w2 enables more aggressive use of
the option.
Warnings:
Some Solaris software and C++ standard header files
result in warnings when compiled with +w2.
-w Suppresses warning messages.
This option causes the compiler not to print warning
messages. Some warnings, particularly warnings regard-
ing serious anachronisms, cannot be suppressed.
-Xm Use -features=iddollar.
-xaddr32[={yes|no}]
(x86/x64 only) The -xaddr32=yes compilation flag res-
tricts the resulting executable or shared object to a
32-bit address space.
An executable that is compiled in this manner results
in the creation of a process that is restricted to a
32-bit address space.
When -xaddr32=no is specified a usual 64 bit binary is
produced.
If the -xaddr32 option is not specified, -xaddr32=no is
assumed.
If only -xaddr32 is specified -xaddr32=yes is assumed.
This option is only applicable to -m64 compilations and
only on Solaris platforms supporting SF1_SUNW_ADDR32
software capability.
Since Linux kernel does not support addres space limi-
tation this option is not available on Linux. The
-xaddr32 option is ignored on Linux.
When linking, if a single object file was compiled with
-xaddr32=yes the whole output file is assumed to be
compiled with -xaddr32=yes.
A shared object that is restricted to a 32-bit address
space must be loaded by a process that executes within
a restricted 32-bit mode address space.
For more information refer to the SF1_SUNW_ADDR32
software capabilities definition, described in the
Linker and Libraries Guide.
-xalias_level[= n]
Allows the compiler to perform type-based alias-
analysis.
Defaults:
n must be any, simple, or compatible.
o -xalias_level
If you do not specify -xalias_level, the compiler
sets it to -xalias_level=any. If you specify
-xalias_level without any values, the compiler sets
it to -xalias_level=compatible.
o -xalias_level=any
At this level of analysis, the compiler assumes that
any type may alias any other type. However, despite
this assumption, some optimization is possible.
o -xalias_level=simple
The compiler assumes that fundamental types are not
aliased. Specifically, a storage object with a
dynamic type that is one of the following fundamental
types:
* char, signed char, and unsigned char,
* wchar_t
* short int, unsigned short int,
* int, unsigned int,
* long int, unsigned long int,
* long long int, unsigned long long int,
* float, double, long double,
* enumeration types,
* data pointer types,
* function pointer types,
* data member pointer types, or
* function member pointer types
will only be accessed through lvalues of the follow-
ing types:
* the dynamic type of the object,
* a constant or volatile qualified version
of the dynamic type of the object,
* a type that is the signed or unsigned type
corresponding to the dynamic type of the
object,
* a type that is the signed or unsigned type
corresponding to a constant or volatile
qualified version of the dynamic type of
the object,
* an aggregate or union type that includes
one of the aforementioned types among its
members (including, recursively, a member of
a subaggregate or contained union), or
* a char or unsigned char type.
o -xalias_level=compatible
The compiler assumes that layout-incompatible types
are not aliased. A storage object is only accessed
through lvalues of the following types:
* the dynamic type of the object,
* a constant or volatile qualified version of
the dynamic type of the object,
* a type that is the signed or unsigned type
which corresponds to the dynamic type of
the object,
* a type that is the signed or unsigned type
which corresponds to the constant or volatile
qualified version of the dynamic type of
the object,
* an aggregate or union type that includes one
of the aforementioned types among its members
(including, recursively, a member of a
subaggregate or contained union),
* a type that is (possibly constant or volatile
qualified) base class type of the dynamic
type of the object, or
* a char or unsigned char type.
The compiler assumes that the types of all references
are layout compatible with the dynamic type of the
corresponding storage object. Two types are layout-
compatible under the following conditions:
* If two types are the same type, then they are
layout-compatible types.
* If two types differ only in constant or
volatile qualification, then they are
layout-compatible types.
* For each of the signed integer types, there
exists a corresponding (but different)
unsigned integer type. These corresponding
types are layout compatible.
* Two enumeration types are layout-compatible if
they have the same underlying type.
* Two Plain Old Data (POD) struct types are
layout compatible if they have the same number
of members, and corresponding members
(in order) have layout compatible types.
* Two POD union types are layout compatible
if they have the same number of members, and
corresponding members (in any order) have
layout compatible types.
References may be non-layout-compatible with the
dynamic type of the storage object under limited cir-
cumstances:
* If a POD union contains two or more POD
structs that share a common initial sequence,
and if the POD union object currently contains
one of those POD structs, it is permitted to
inspect the common initial part of any of
them. Two POD structs share a common initial
sequence if corresponding members have layout
compatible types and, as applicable to bit
fields, the same widths, for a sequence of
one or more initial members.
* A pointer to a POD struct object, suitably
converted using a reinterpret_cast, points
to its initial member, or if that member is
a bit field, to the unit in which it resides.
Interactions:
The compiler does not perform type-based alias analysis
at optimization level -xO2 and below.
-xannotate[={yes|no}]
(Solaris) Instructs the compiler to create binaries
that can later be transformed by binary modification
tools like binopt(1). Future binary analysis, code cov-
erage and memory error detection tools will also work
with binaries built with this option.
Use the -xannotate=no option to prevent the modifica-
tion of the binary file by these tools.
The -xannotate=yes option must be used with optimiza-
tion level -xO1 or higher to be effective, and it is
only effective on systems with the new linker support
library interface - ld_open(). If the compiler is used
on a system without this linker interface (for example
Solaris 9), it silently will revert to -xannotate=no.
The new linker interface is available in Solaris 10
patch 127111-07, Solaris 10 Update 5 and OpenSolaris.
The default is -xannotate=yes, but if either of the
above conditions is not met, the default reverts to
-xannotate=no.
This option is not available on Linux systems.
-xar Creates archive libraries.
When building a C++ archive that uses templates, it is
necessary in most cases to include in the archive those
template functions that are instantiated in the tem-
plate repository. Using this option automatically adds
those templates to the archive as needed.
Values:
Specify -xar to invokes ar -c-r and create an archive
from scratch.
Examples:
The following command archives the template functions
contained in the repository and the object files.
example% CC -xar -o libmain.a a.o b.o c.o
Warnings:
Do not add .o files from the template repository on the
command line.
Do not use the ar command directly for building
archives. Use CC -xar to ensure that template instan-
tiations are automatically included in the archive.
See Also:
ar(1)
-xarch= isa
Specifies the target architecture instruction set
(ISA).
This option limits the code generated by the compiler
to the instructions of the specified instruction set
architecture by allowing only the specified set of
instructions. This option does not guarantee use of any
target-specific instructions. However, use of this
option can affect the portability of a binary program.
See the Notes and Warnings sections at the end of this
entry.
Note: Use the -m64 or -m32 option to specify the
intended memory model, LP64 (64-bits) or ILP32 (32-
bits) respectively. The -xarch flag no longer indicates
the memory model, except for compatibility with previ-
ous releases, as indicated below.
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. (Solaris only)
This option is equivalent to
-m64 -xarch=generic
and is provided for compatibility with ear-
lier releases. Use -m64 to specify 64-bit
compilation instead of -xarch=generic64
native Compile for good performance on this system
The compiler chooses the appropriate setting
for the current system processor it is run-
ning on.
native64 Compile for good performance on this system
(Solaris only)
This option is equivalent to
-m64 -xarch=native and is provided for compa-
tibility with earlier releases.
Values on SPARC platforms:
sparc Compile for the SPARC-V9 ISA.
Compile for the V9 ISA, but without the
Visual Instruction Set (VIS), and without
other implementation-specific ISA extensions.
This option enables the compiler to generate
code for good performance on the V9 ISA.
sparcvis Compile for the SPARC-V9 ISA plus VIS.
Compile for SPARC-V9 plus the Visual Instruc-
tion Set (VIS) version 1.0, and with
UltraSPARC extensions. This option enables
the compiler to generate code for good per-
formance on the UltraSPARC architecture.
sparcvis2 Compile for the SPARC-V9 ISA with UltraSPARC
III extensions.
Enables the compiler to generate object code
for the UltraSPARC architecture, plus the
Visual Instruction Set (VIS) version 2.0, and
with UltraSPARC III extensions.
sparcvis3 Compile for the SPARC-V9 ISA with UltraSPARC
III and VIS 3 extensions.
Enables the compiler to use instructions from
the SPARC-V9 instruction set, plus the
UltraSPARC extensions, including the Visual
Instruction Set (VIS) version 1.0, the
UltraSPARC-III extensions, including the
Visual Instruction Set (VIS) version 2.0, the
fused multiply-add instructions, and the
Visual Instruction Set (VIS) version 3.0
sparcfmaf Compile for the sparcfmaf version of the
SPARC-V9 ISA.
Enables the compiler to use instructions from
the SPARC-V9 instruction set, plus the
UltraSPARC extensions, including the Visual
Instruction Set (VIS) version 1.0, the
UltraSPARC-III extensions, including the
Visual Instruction Set (VIS) version 2.0, and
the SPARC64 VI extensions for floating-point
multiply-add.
Note that you must use -xarch=sparcfmaf in
conjunction with -fma=fused and some optimi-
zation level to get the compiler to attempt
to find opportunities to use the multiply-add
instructions automatically.
sparcima Compile for the sparcima version of the
SPARC-V9 ISA.
Enables the compiler to use instructions from
the SPARC-V9 instruction set, plus the
UltraSPARC extensions, including the Visual
Instruction Set (VIS) version 1.0, the
UltraSPARC-III extensions, including the
Visual Instruction Set (VIS) version 2.0, the
SPARC64 VI extensions for floating-point
multiply-add, and the SPARC64 VII extensions
for integer multiply-add.
v9 Is equivalent to -m64 -xarch=sparc
Legacy makefiles and scripts that use
-xarch=v9 to obtain the 64-bit memory model
need only use -m64.
v9a Is equivalent to -m64 -xarch=sparcvis and is
provided for compatibility with earlier
releases.
v9b Is equivalent to -m64 -xarch=sparcvis2 and
is provided for compatibility with earlier
releases.
Notes:
o Legacy 32-bit SPARC instruction set architectures V7
and V8 imply -m32 and cannot be combined with -m64.
o Object binary files (.o) compiled with sparc and
sparcvis can be linked and can execute together, but
only on a sparcvis compatible platform.
o Object binary files (.o) compiled with sparc,
sparcvis, and sparcvis2 can be linked and can execute
together, but only on a sparcvis2 compatible plat-
form.
For any particular choice, the generated executable
could run much more slowly on earlier architectures.
Also, although quad-precision floating-point instruc-
tions are available in many of these instruction set
architectures, the compiler does not use these
instructions in the code it generates.
Values specific for x86 platforms:
Value Meaning
pentium_pro
Limits the instruction set to pentium_pro
architecture.
sse Adds the SSE instruction set to the
pentium_pro instruction set.
sse2 Supplements the pentium_pro and SSE instruc-
tion sets with the SSE2 instruction set.
sse3 Supplements the pentium_pro, SSE, and SSE2
instruction sets with the SSE3 instruction
set.
ssse3 Supplements the pentium_pro, SSE, SSE2, and
SSE3 instruction sets with the SSSE3
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 instruction set.
amdsse4a Uses the AMD SSE4a Instruction set.
amd64 Is equivalent to -m64 -xarch=sse2 (Solaris
only)
Legacy makefiles and scripts that use
-xarch=amd64 to obtain the 64-bit memory
model need only use -m64.
pentium_proa
Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the
pentium_pro architecture.
ssea Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the 32-bit
SSE architecture.
sse2a Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the SSE2
architecture.
amd64a Is equivalent to -m64 -xarch=sse2a (Solaris
only)
Note: If any part of a program is compiled or
linked on an x86 platform with -m64, then all
parts of the program must be compiled with
one of these options as well.
For details on the various Intel instruction
set architectures (SSE, SSE2, SSE3, SSSE3,
and so on) refer to the Intel-64 and IA-32
Intel Architecture Software Developer's
Manual
(http://developer.intel.com/products/processor/manuals/)
Defaults:
If -xarch=isa is not specified, the defaults are:
-xarch=generic on SPARC platforms
-xarch=generic on x86 platforms
Interactions:
Although this option can be used alone, it is part of
the expansion of the -xtarget option and can be used
to override the -xarch value that is set by a
specific -xtarget option.
For example, -xtarget=ultra4 expands to
-xarch=sparcvis2 -xcache=64/32/4:8192/128/2
-xchip=ultra4
Warnings:
If this option is used with optimization, the
appropriate choice can provide good performance of
the executable on the specified architecture. An
inappropriate choice, however, might result in seri-
ous degradation of performance or in in a binary pro-
gram that is not executable on all intended target
platforms.
-xautopar
Turns on automatic parallelization for multiple proces-
sors. Does dependence analysis (analyze loops for
inter- iteration data dependence) and loop restructur-
ing. If optimization is not at -xO3 or higher, optimi-
zation is raised to -xO3 and a warning is emitted.
Note that -xautopar does not accept OpenMP paralleliza-
tion directives.
Avoid -xautopar if you do your own thread management.
To get faster execution, this option requires a multi-
ple processor system. On a single-processor system, the
resulting binary usually runs slower.
To run a parallelized program in a multithreaded
environment, you must set the OMP_NUM_THREADS environ-
ment variable prior to execution. See the OpenMP API
User's Guide for more information.
If you use -xautopar and compile and link in one step,
then linking automatically includes the microtasking
library and the threads-safe C runtime library. If you
use -xautopar and compile and link in separate steps,
then you must link with CC -xautopar as well.
-xbinopt={prepare|off}
(SPARC) Instructs the compiler to prepare the binary
for later optimizations, transformations and analysis
(see binopt(1)). This option may be used for building
executables or shared objects. This option must be used
with optimization level -xO1 or higher to be effective.
There is a modest increase in size of the binary when
built with this option.
If you compile in separate steps, -xbinopt must appear
on both compile and link steps:
example% CC -c -xO1 -xbinopt=prepare a.cc b.cc
example% CC -o myprog -xbinopt=prepare a.o
If some source code is not available for compilation,
this option may still be used to compile the remainder
of the code. It should then be used in the link step
that creates the final binary. In such a situation,
only the code compiled with this option can be optim-
ized, transformed or analyzed.
Compiling with -xbinopt=prepare and -g increases the
size of the executable by including debugging informa-
tion. The default is -xbinopt=off.
-xbuiltin[={%all|%none}]
Enables or disables better optimization of standard
library calls.
By default, the functions declared in standard library
headers are treated as ordinary functions by the com-
piler. However, some of those functions can be recog-
nized as "intrinsic" or "built-in" by the compiler.
When treated as a built-in, the compiler can generate
more efficient code. For example, the compiler can
recognize that some functions have no side effects, and
always return the same output given the same input.
Some functions can be generated inline directly by the
compiler. See the er_src(1) man page for an explana-
tion of how to read compiler commentary in object files
to determine for which functions the compiler actually
makes a substitution.
-xbuiltin=%all asks the compiler to recognize as many
of the built-in standard functions as possible. The
exact list of recognized functions varies with the ver-
sion of the compiler code generator.
-xbuiltin=%none is the default behavior.
Defaults:
If the -xbuiltin option is not specified, the compiler
assumes -xbuiltin=%none. If only -xbuiltin is speci-
fied, the compiler assumes -xbuiltin=%all.
Note: 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.
-xcache=c
Defines the cache properties for use by the optimizer.
This option specifies the cache properties that the
optimizer can use. It does not guarantee that any par-
ticular cache property is used.
Although this option can be used alone, it is part of
the expansion of the -xtarget option; its primary use
is to override a value supplied by the -xtarget option.
c must be one of the following:
o generic
o native
o s1/l1/a1
o s1/l1/a1:s2/l2/a2
o s1/l1/a1:s2/l2/a2:s3/l3/a3
That is, -xcache={generic |
s1/l1/a1[:s2/l2/a2[:s3/l3/a3]]}, where the si/li/ai are
defined as follows:
si The size of the data cache at level i, in kilo-
bytes
li The line size of the data cache at level i, in
bytes
ai The associativity of the data cache at level i
For example, i=1 designates level 1 cache properties,
s1/l1/a1.
The following table shows the -xcache values.
Value Meaning
generic Defines the cache properties for good
performance on most SPARC processors.
This is the default value which directs
the compiler to use cache properties for
good performance on most SPARC proces-
sors, without major performance degrada-
tion on any of them.
native Set the parameters for the best perfor-
mance on the host environment.
s1/l1/a1 Defines level 1 cache properties.
s1/l1/a1:s2/l2/a2
Defines levels 1 and 2 cache proper-
ties.
s1/l1/a1:s2/l2/a2:s3/l3/a3
Defines levels 1, 2, and 3 cache pro-
perties.
Example:
-xcache=16/32/4:1024/32/1 specifies the following:
Level 1 cache has: Level 2 cache has:
16K bytes 1024K bytes
32-byte line size 32-byte line size
4-way associativity Direct mapping
-xcg{89|92}
(SPARC) Obsolete. You should not use this option.
Current Solaris operating systems no longer support
SPARC V7 architecture. Compiling with this option gen-
erates code that runs slower on current SPARC plat-
forms.
-xchar=o
The option is provided solely for the purpose of easing
the migration of code from systems where the char type
is defined as unsigned. Unless you are migrating from
such a system, do not use this option. Only code that
relies on the sign of a char type needs to be rewritten
to explicitly specify signed or unsigned.
Values:
You can substitute one of the following values for o:
o signed: Treat character constants and variables
declared as char as signed. This impacts the behavior
of compiled code, it does not affect the behavior of
library routines.
o s: equivalent to signed.
o unsigned: Treat character constants and variables
declared as char as unsigned. This impacts the
behavior of compiled code, it does not affect the
behavior of library routines.
o u: equivalent to unsigned.
Defaults:
If you do not specify -xchar, the compiler assumes
-xchar=s. If you specify -xchar, but do not specify a
value, the compiler assumes -xchar=s.
Interactions:
The -xchar option changes the range of values for the
type char only for code compiled with -xchar. This
option does not change the range of values for type
char in any system routine or header file. In particu-
lar, the value of CHAR_MAX and CHAR_MIN, as defined by
limits.h, do not change when this option is specified.
Therefore, CHAR_MAX and CHAR_MIN no longer represent
the range of values encodable in a plain char.
Warnings:
If you use -xchar, be particularly careful when you
compare a char against a predefined system macro
because the value in the macro may be signed. This is
most common for any routine that returns an error code
which is accessed through a macro. Error codes are
typically negative values so when you compare a char
against the value from such a macro, the result is
always false. A negative number can never be equal to
any value of an unsigned type.
It is strongly recommended that you never use -xchar to
compile routines for any interface exported through a
library. The Solaris ABI specifies type char as signed,
and system libraries behave accordingly. The effect of
making char unsigned has not been extensively tested
with system libraries. Instead of using this option,
modify your code so that it does not depend on whether
type char is signed or unsigned. The sign of type char
varies among compilers and operating systems.
-xcheck[=n]
Enables a runtime check for stack overflow.
Values:
n must be one of the following values.
Value Meaning
%all Perform all checks.
%none Does not perform any checks.
stkovf Perform a runtime check for stack over-
flow of the main thread in a singly-
threaded program as well as slave-thread
stacks in a multithreaded program. If a
stack overflow is detected, a SIGSEGV is
generated. If your application needs to
handle a SIGSEGV caused by a stack over-
flow differently than it handles other
address-space violations, see
sigaltstack(2).
no%stkovf Turns off stack-overflow checking.
init_local Initialize local variables. See the C
User's Guide description of this option
for a list of the predefined values used
by the compiler to initialize variables.
no%init_local Do not initialize local variables.
Interactions:
If you specify -xcheck without any arguments, the com-
piler defaults to -xcheck=%none.
-xchip=c
Specifies the target processor for use by the optim-
izer.
Although this option can be used alone, it is part of
the expansion of the -xtarget option; its primary use
is to override a value supplied by the -xtarget option.
This option specifies timing properties by specifying
the target processor.
This option affects:
o The ordering of instructions, that is, scheduling
o The way the compiler uses branches
o The instructions to use in cases where semantically
equivalent alternatives are available
The -xchip values for SPARC platforms are:
Value Meaning
generic Uses timing properties for good performance
on most SPARC processors.
This is the default value that directs the
compiler to use the best timing properties
for good performance on most SPARC proces-
sors, without major performance degradation
on any of them.
native Set the parameters for the best performance
on the host environment.
sparc64vi Optimize for the SPARC64 VI processor.
sparc64vii
Optimize for the SPARC64 VII processor.
super Optimize for the SuperSPARC processor.
super2 Optimize for the SuperSPARC II processor.
micro Optimize for the MicroSPARC(TM) processor.
micro2 Optimize for the MicroSPARC II processor.
hyper Optimize for the HyperSPARC(TM) processor.
hyper2 Optimize for the HyperSPARC II processor.
ultra Optimize for the UltraSPARC(TM) processor.
ultra2 Optimize for the UltraSPARC II processor.
ultra2e Optimize for the UltraSPARC IIe processor.
ultra2i Optimize for the UltraSPARC IIi processor.
ultra3 Optimize for the UltraSPARC III processor.
ultra3cu Optimize for the UltraSPARC IIIcu processor.
ultra3i Optimize for the UltraSPARC IIIi processor.
ultra4 Optimize for the UltraSPARC IV processor.
ultra4plus
Optimize for the UltraSPARC IVplus processor.
ultraT1 Optimize for the UltraSPARC T1 processor.
ultraT2 Optimize for the UltraSPARC T2 processor.
ultraT2plus
Optimize for the UltraSPARC T2+ processor.
ultraT3 Optimize for the UltraSPARC T3 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 Pentium 3 style processor
pentium4 Optimize for Pentium 4 style 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
-xarch=v9 -xcode=abs64, but these will be inefficient.
Shared objects built with -xarch=v9 -xcode=abs32 or
-xarch=v9 -xcode=abs44 will not work.
The following table shows the -xcode values.
Value Meaning
abs32 Generate 32-bit absolute addresses, which are
fast, but have limited range. Code + data +
bss size is limited to 2**32 bytes. This is
the default on 32-bit architectures.
abs44 SPARC: Generate 44-bit absolute addresses,
which have moderate speed and moderate range.
Code + data + bss size is limited to 2**44
bytes. This is the default on 64-bit archi-
tectures. Do not use this value with dynamic
(shared) libraries.
abs64 SPARC: Generate 64-bit absolute addresses,
which are slow, but have full range. Avail-
able only on 64-bit architectures.
pic13 Generates position-independent code (small
model), which is fast, but has limited range.
Equivalent to -Kpic. Permits references to at
most 2**11 unique external symbols on 32-bit
architectures, 2**10 on 64-bit architectures.
pic32 Generates position-independent code (large
model), which is slow, but has full range.
Equivalent to -KPIC. Permits references to at
most 2**30 unique external symbols on 32-bit
architectures, 2**29 on 64-bit architectures.
To determine whether to use -xcode=pic13 or
-xcode=pic32, check the size of the Global Offset Table
(GOT) by using elfdump -c (see the elfdump(1) man page
for more information) and for the section header,
sh_name: .got. The sh_size value is the size of the
GOT. If the GOT is less than 8,192 bytes, specify
-xcode=pic13, otherwise specify -xcode=pic32.
In general, use the following guidelines to determine
how you should use -xcode:
o If you are building an executable you should not use
-xcode=pic13 or -xcode=pic32.
o If you are building an archive library only for
linking into executables you should not use
-xcode=pic13 or -xcode=pic32.
o If you are building a shared library, start with
-xcode=pic13 and once the GOT size exceed 8,192 bytes,
use -xcode=pic32.
o If you are building an archive library for linking
into shared libraries you should just use -xcode=pic32.
Defaults:
The default is -xcode=abs32 for 32-bit architectures.
The default is -xcode=abs44 for 64-bit processors.
Warnings:
When you compile and link in separate steps, you must
use the same -xarch option in the compile step and the
link step.
-xcrossfile[=n]
Oboslete - do not use. Use -xipo instead.
-xdebugformat=[stabs|dwarf]
The C++ compiler default format of debugger informa-
tion is the dwarf format -xdebugformat=dwarf.
Use this option as a way of accessing the new format
for the purpose of porting tools. There is no need to
use this option unless you maintain software which
reads debugger information, or unless a specific tool
tells you that it requires debugger information in one
of these formats.
-xdebugformat=stabs generates debugging information
using the stabs standard format. The stabs format is no
longer supported.
-xdebugformat=dwarf generates debugging information
using the dwarf standard format.
If you do not specify -xdebugformat, the compiler
assumes -xdebugformat=dwarf. This option requires an
argument.
This option affects the format of the data that is
recorded with the -g option. Some small amount of
debugging information is recorded even without -g, and
the format of that information is also controlled with
this option. So -xdebugformat has a an effect even
when -g is not used.
The details of any specific fields or values in either
stabs or dwarf are also evolving.
See also the dumpstabs(1) and dwarfdump(1) man pages
for more information.
-xdepend[=[yes|no] ]
Analyzes loops for inter-iteration data dependencies
and performs loop restructuring. Loop restructuring
includes loop interchange, loop fusion, scalar replace-
ment, and elimination of "dead" array assignments.
On SPARC, -xdepend is turned on for all optimization
levels -xO3 and above, and is off for lower opt levels.
Also, an explicit setting of -xdepend overrides any
implicit setting.
On x86, if optimization is not at -xO3 or higher, the
compiler raises the optimization to -xO3 and issues a
warning.
If you do not specify -xdepend, the default is
-xdepend=no which means the compiler does not analyze
loops for data dependencies. If you specify -xdepend
but do not specify an argument, the compiler sets the
option to -xdepend=yes which means the compiler
analyzes loops for data dependencies.
Dependency analysis is included in -xautopar. The
dependency analysis is done at compile time.
Dependency analysis may help on single-processor sys-
tems. However, if you try -xdepend on single-processor
systems, you should not use -xautopar. If you do so,
the -xdepend optimization is done for multiple-
processor systems.
See Also: -xprefetch_auto_type
-xdumpmacros[=value[,value...]]
Use this option when you want to see how macros are
behaving in your program. This option provides informa-
tion such as macro defines, undefines, and instances of
usage. It prints output to the standard error (stderr),
based on the order macros are processed. The -xdumpmac-
ros option is in effect until the end of the file or
until it is overridden by the dumpmacros or
end_dumpmacros pragma.
Values:
Value Meaning
[no%]defs [Do not] Print all macro defines
[no%]undefs [Do not] Print all macro undefines
[no%]use [Do not] Print information about macros
used
[no%]loc [Do not] Print location (path name and
line number) also for defs, undefs, and
use
[no%]conds [Do not] Print use information for mac-
ros used in conditional directives
[no%]sys [Do not] Print all macros defines, unde-
fines, and use information for macros in
system header files
%all Sets the option to
-xdumpmacros=defs,undefs,use,loc,conds,sys.
A good way to use this argument is in
conjunction with the [no%] form of the
other arguments. For example,
-xdumpmacros=%all,no%sys would exclude
system header macros from the output but
still provide information for all other
macros.
%none Do not print any macro information
The option values accumulate so specifying
-xdumpmacros=sys -xdumpmacros=undefs has the same
effect as -xdumpmacros=undefs,sys.
Note: The sub-options loc, conds, and sys are qualif-
iers for defs, undefs and use options. By themselves,
loc, conds, and sys have no effect. For example,
-xdumpmacros=loc,conds,sys has no effect.
Defaults:
If you specify -xdumpmacros without any arguments, it
means -xdumpmacros=defs,undefs,sys. If you do not
specify -xdumpmacros,
it defaults to -xdumpmacros=%none.
-xe Check only for syntax and semantic errors. When you
specify -xe the compiler does not produce any object
code. The output for -xe is directed to stderr.
Use the -xe option if you do not need the object files
produced by compilation. For example, if you are trying
to isolate the cause of an error message by deleting
sections of code, you can speed the edit and compile
cycle by using -xe.
-xF[=v]
The -xF option enables the optimal reordering of func-
tions and variables by the linker.
This option instructs the compiler to place functions
and/or data variables into separate section fragments,
which enables the linker, using directions in a mapfile
specified by the linker's -M option, to reorder these
sections to optimize program performance. Generally,
this optimization is only effective when page fault
time constitutes a significant fraction of program run
time.
Reordering functions and variables for optimal perfor-
mance requires the following operations:
1. Compiling and linking with -xF.
2. Following the instructions in the Performance
Analyzer manual regarding how to generate a mapfile for
functions or following the instructions in the Linker
and Libraries Guide regarding how to generate a mapfile
for data.
3. Relinking with the new mapfile by using the linker's
-M option.
4. Re-executing under the Analyzer to verify improve-
ment.
Values:
v can be one of the following values:
Value Meaning
[no%]func [Do not] fragment functions into
separate sections.
[no%]gbldata [Do not] fragment global data (variables
with external linkage) into separate
sections.
[no%]lcldata [Do not] 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
optimizations, so you should only use this flag when it
is experimentally justified.
See Also:
analyzer(1), ld(1)
-xhelp=flags
Displays a brief description of each compiler flag.
-xhelp=readme
Displays the contents of the online README file. The
README file is paged by the command specified by the
environment variable, PAGER. If PAGER is not set, the
default paging command is more.
-xhwcprof[={enable|disable}]
(SPARC) Use the -xhwcprof option to enable compiler
support for dataspace profiling.
When -xhwcprof is enabled, the compiler generates
information that helps tools associate profiled load
and store instructions with the data-types and struc-
ture members (in conjunction with symbolic information
produced with -g) to which they refer. It associates
profile data with the data space of the target, rather
than the instruction space, and provides insight into
behavior that is not easily obtained from only instruc-
tion profiling.
You can compile a specified set of object files with
-xhwcprof however, -xhwcprof is most useful when
applied to all object files in the application. This
will provide coverage to identify and correlate all
memory references distributed in the application's
object files.
If you are compiling and linking in separate steps, use
-xhwcprof at link time as well. Future extensions to
-xhwcprof may require its use at link time. For a com-
plete list of compiler options that must be specified
at both compile time and at link time, see the C User's
Guide.
An instance of -xhwcprof=enable or -xhwcprof=disable
overrides all previous instances of -xhwcprof in the
same command line.
-xhwcprof is disabled by default. Specifying -xhwcprof
without any arguments is the equivalent to
-xhwcprof=enable.
-xhwcprof requires that optimization be turned on and
that the debug data format be set to dwarf
(-xdebugformat=dwarf), which is the default with
current Solaris Studio compilers.
The combination of -xhwcprof and -g increases compiler
temporary file storage requirements by more than the
sum of the increases due to -xhwcprof and -g specified
alone.
The following command compiles example.cc and specifies
support for hardware counter profiling and symbolic
analysis of data types and structure members using
DWARF symbols:
example% CC -c -O -xhwcprof -g example.cc
For more information on hardware counter-based profil-
ing, see the Performance Analyzer manual.
-xia Link the appropriate interval arithmetic libraries and
set a suitable floating-point environment.
The -xia option is a macro that expands to
-fsimple=0 -ftrap=%none -fns=no -library=interval.
Interactions:
To use the interval arithmetic libraries, include
<suninterval.h>.
When you use the interval arithmetic libraries, you
must include one of the following libraries: libC,
Cstd, or iostreams. See -library for information on
including these libraries.
Warnings:
If you use intervals and you specify different values
for -fsimple, -ftrap, or -fns, then your program may
have incorrect behavior.
C++ interval arithmetic is experimental and evolving.
The specifics may change from release to release.
On x86 platforms, -xarch=sse2 must be specified for
32-bit compilations. Also, -xia is not available on
Linux platforms.
See also:
-library
C++ Interval Arithmetic Programming Reference,
Interval Arithmetic Solves Nonlinear Problems While
Providing Guaranteed Results
(http://www.sun.com/software/sundev/news/features/intervals.html)
-xinline[=func_spec[,func_spec...]]
Specifies which user-written routines can be inlined by
the optimizer at -xO3 or higher.
Values:
func_spec can be one of the following:
Value Meaning
%auto Enable automatic inlining at optim-
ization level -xO4 or higher. This
argument tells the optimizer that
it can inline functions of its
choosing. Note that without the
%auto specification, automatic
inlining is normally turned off
when explicit inlining is specified
on the command line by
-xinline=[no%]func_name...
func_name Strongly request that the optimizer
inline the function. If the func-
tion is not declared as extern "C",
the value of func_name must be man-
gled. You can use the nm command on
the executable file to find mangled
function names. For functions
declared as extern "C", the names
are not mangled by the compiler.
no%func_name When you prefix the name of a rou-
tine on the list with no%, the
inlining of that routine is
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 lev-
els below -xO3. At -xO4 and higher, the optimizer
decides which functions should be inlined, and does so
without the -xinline option being specified. At -xO4 or
higher, the compiler also attempts to determine which
functions will improve performance if inlined.
A routine is inlined if any of the following conditions
apply.
o Optimization is set at -xO3 or higher
o Inlining is judged to be profitable and safe
o The function is in the file being compiled, or
the function is in a file that was compiled with
-xipo[=1|2].
Warnings:
If you force the inlining of a function with -xin-
line, you might actually diminish performance.
See Also:
-xldscope
-xinstrument=[no%]datarace]
Specify this option to compile and instrument your pro-
gram for analysis by the Thread Analyzer. For more
information on the Thread Analyzer, see tha(1) for
details.
You can then use the Performance Analyzer to run the
instrumented program with collect -r races to create a
data-race-detection experiment. You can run the instru-
mented code standalone but it runs more slowly.
Values
Value Meaning
instrument Prepare the code for analysis by the
Thread Analyzer and define __THA_NOTIFY.
no%instrument This is the default. Do not prepare the
code for analysis by the Thread Analyzer
and do not define __THA_NOTIFY.
Interactions
If you compile and link in seperate steps, you must
specify -xinstrument=datarace in both the compilation
and linking steps.
This option defines the preprocessor token
__THA_NOTIFY. You can specify #ifdef __THA_NOTIFY to
guard calls to libtha(3) routines.
This option also sets -g0.
Warnings
It is illegal to specify -xinstrument without an argu-
ment.
-xipo[={0|1|2}]
Performs interprocedural optimizations.
The -xipo option performs partial-program optimizations
by invoking an interprocedural analysis pass. It per-
forms optimizations across all object files in the link
step, and the optimizations are not limited to just the
source files on the compile command. However, whole-
program optimizations performed with -xipo do not
include assembly (.s) source files.
The -xipo option is particularly useful when compiling
and linking large multifile applications. Object files
compiled with this flag have analysis information com-
piled within them that enables interprocedural analysis
across source and precompiled program files. However,
analysis and optimization is limited to the object
files compiled with -xipo, and does not extend to
object files or libraries.
Values:
Value Meaning
0 Do not perform interprocedural optimiza-
tions.
1 Perform interprocedural optimizations.
2 Perform interprocedural aliasing
analysis as well as optimization of
memory allocation and layout to improve
cache performance.
Defaults:
If -xipo is not specified, -xipo=0 is assumed.
If only -xipo is specified, -xipo=1 is assumed.
Examples:
The following example compiles and links in the same
step.
example% CC -xipo -xO4 -o prog part1.cc part2.cc
part3.cc
The optimizer performs crossfile inlining across all
three source files. This is done in the final link
step, so the compilation of the source files need not
all take place in a single compilation and could be
over a number of separate compilations, each specifying
the -xipo option.
The following example compiles and links in separate
steps.
example% CC -xipo -xO4 -c part1.cc part2.cc
example% CC -xipo -xO4 -c part3.cc
example% CC -xipo -xO4 -o prog part1.o part2.o part3.o
The object files created in the compile steps have
additional analysis information compiled within them to
permit crossfile optimizations to take place at the
link step.
Interactions:
The -xipo option requires at least optimization level
-xO4. You cannot use both the -xipo option and the
-xcrossfile option in the same compile command.
Warnings:
When compiling and linking are performed in separate
steps, -xipo must be specified in both steps to be
effective. Objects that are compiled without -xipo can
be linked freely with objects that are compiled with
-xipo. Libraries do not participate in crossfile inter-
procedural analysis, even when they are compiled with
-xipo as shown in this example:
example% CC -xipo -xO4 one.cc two.cc three.cc
example% CC -xar -o mylib.a one.o two.o three.o
example% CC -xipo -xO4 -o myprog main.cc four.cc
mylib.a
In this example, interprocedural optimizations will be
performed between one.cc, two.cc, and three.cc, and
between main.cc and four.cc, but not between main.cc or
four.cc and the routines in mylib.a. The first compila-
tion may generate warnings about undefined symbols, but
the interprocedural optimizations will be performed
because it is a compile and link step.
The -xipo option generates significantly larger object
files due to the additional information needed to per-
form optimizations across the files. However, this
additional information does not become part of the
final executable binary file. Any increase in the size
of the executable program will be due to the additional
optimizations performed.
When Not To Use -xipo=2 Interprocedural Analysis
The compiler tries to perform whole-program analysis
and optimizations as it works with the set of object
files in the link step. The compiler makes the follow-
ing two assumptions for any function (or subroutine)
foo() defined in this set of object files:
(1) foo() is not called explicitly by another routine
that is defined outside this set of object files at
runtime.
(2) The calls to foo() from any routine in the set of
object files are not interposed upon by a different
version of foo() defined outside this set of object
files.
Do not compile with -xipo=2 if assumption (1) is not
true for the given application.
Do not compile with either -xipo=1 or -xipo=2 if
assumption (2) is not true.
As an example, consider interposing on the function
malloc() with your own version and compiling with
-xipo=2. Consequently, all the functions in any library
that reference malloc() that are linked with your code
have to be compiled with -xipo=2 also and their object
files need to participate in the link step. Since this
might not be possible for system libraries, do not com-
pile your version of malloc() with -xipo=2.
As another example, suppose that you build a shared
library with two external calls, foo() and bar() inside
two different source files. Furthermore, suppose that
bar() calls foo(). If there is a possibility that foo()
could be interposed at runtime, then do not compile the
source file for foo() or for bar() with -xipo=1 or
-xipo=2. Otherwise, foo() could be inlined into bar(),
which could cause incorrect results.
-xipo_archive[=a]
The -xipo_archive option enables the compiler to optim-
ize object files that are passed to the linker with
object files that were compiled with -xipo and that
reside in the archive library (.a) before producing an
executable. Any object files contained in the library
that were optimized during the compilation are replaced
with their optimized version.
a is one of the following:
writeback
The compiler optimizes object files passed to the
linker with object files compiled with -xipo that
reside in the archive library (.a) before producing an
executable. Any object files contained in the library
that were optimized during the compilation are
replaced with an optimized version.
For parallel links that use a common set of archive
libraries,each link should create its own copy of
archive libraries to be optimized before linking.
readonly
The compiler optimizes object files passed to the
linker with object files compiled with -xipo that
reside in the archive library (.a) before producing an
executable.
The option -xipo_archive=readonly enables cross-module
inlining and interprocedural data flow analysis of
object files in an archive library specified at link
time. However, it does not enable cross-module optim-
ization of the archive library's code except for code
that has been inserted into other modules by cross
module inlining.
To apply cross-module optimization to code within an
archive library, -xipo_archive=writeback is required.
Note that doing so modifies the contents of the
archive library from which the code was extracted.
none
Default. There is no processing of archive files. The
compiler does not apply cross-module inlining or other
cross-module optimizations to object files compiled
using -xipo and extracted from an archive library at
link time. To do that, both -xipo and either
-xipo_archive=readonly or -xipo_archive=writeback must
be specified at link time.
It is illegal to specify -xipo_archive without a flag.
-xjobs=n
Compile with multiple processors.
Specify the -xjobs option to set how many processes the
compiler creates to complete its work. This option can
reduce the build time on a multi-cpu machine.
Currently, -xjobs works only with the -xipo option.
When you specify -xjobs=n, the interprocedural optim-
izer uses n as the maximum number of code generator
instances it can invoke to compile different files.
Generally, a safe value for n is 1.5 multiplied by the
number of available processors. Using a value that is
many times the number of available processors can
degrade performance because of context switching over-
heads among spawned jobs. Also, using a very high
number can exhaust the limits of system resources such
as swap space.
You must always specify -xjobs with a value. Otherwise
an error diagnostic is issued and compilation aborts.
Multiple instances of -xjobs on the command line over-
ride each other until the rightmost instance is
reached.
The following example compiles more quickly on a system
with two processors than the same command without the
-xjobs option.
example% CC -xipo -xO4 -xjobs=3 t1.cc t2.cc t3.cc
-xkeepframe[=[%all,%none,function_name,no%function_name]]
Prohibit stack related optimizations for the named
functions.
%all - prohibit stack related optimizations for all the
code
%none - allow stack related optimizations for all the
code
If not specified on the command line, the compiler
assumes -xkeepframe=%none
If specified on the command line without a value, the
compiler assumes -xkeepframe=%all
-xlang=language[,language]
Includes the appropriate runtime libraries and ensures
the proper runtime environment for the specified
language.
language must be either f77, f90, f95 or c99.
The -f90 and -f95 arguments are equivalent. The c99
argument invokes ISO 9899:1999 C programming language
behavior for objects that were compiled with cc
-xc99=%all and are being linked with CC.
Interactions:
The -xlang=f90 and -xlang=f95 options imply
-library=f90, and the -xlang=f77 option implies
-library=f77. However, the -library=f77 and
-library=f90 options are not sufficient for mixed-
language linking because only the -xlang option insures
the proper runtime environment.
To determine which driver to use for mixed-language
linking, use the following language hierarchy:
1. C++
2. Fortran 95 (or Fortran 90)
3. Fortran 77
4. C or C99
When linking Fortran 95, Fortran 77, and C++ object
files together, use the driver of the highest language.
For example, use the following C++ compiler command to
link C++ and Fortran 95 object files.
example% CC -xlang=f95...
To link Fortran 95 and Fortran 77 object files, use the
Fortran 95 driver as follows:
example% f95 -xlang=f77...
You cannot use the -xlang option and the -xlic_lib
option in the same compiler command. If you are using
-xlang and you need to link in the Sun Performance
Library, use the -library=sunperf instead.
Warnings:
Do not use -xnolib with -xlang.
If you are mixing parallel Fortran objects with C++
objects, the link line must specify the -mt flag.
See also:
-library, -staticlib
-xldscope={v}
Changes the default linker scoping for the definition
of extern symbols. Changing the default can result in
faster and safer shared libraries because the implemen-
tation will be better hidden.
Values
v must be one of the following:
Value Meaning
global Symbol definitions have global linker
scoping which is the least restrictive
linker scoping. All references to the
symbol bind to the definition in the
first dynamic load module that defines
the symbol. This linker scoping is the
current linker scoping for extern sym-
bols.
symbolic Symbol definitions have symbolic linker
scoping which is more restrictive than
global linker scoping. All references to
the symbol from within the dynamic load
module being linked bind to the symbol
defined within the module. Outside of
the module, the symbol appears as though
it is global. This linker scoping
corresponds to the linker option -Bsym-
bolic. Although you cannot use -Bsym-
bolic with C++ libraries, you can use
the -xldscope=symbolic option without
causing problems.
hidden Hidden linker scoping is more restric-
tive than symbolic and global linker
scoping. All references within a dynamic
load module will bind to a definition
within that module. The symbol will not
be visible outside of the module.
Defaults
If you do not specify -xldscope, the compiler assumes
-xldscope=global. If you specify -xldscope without any
values, the compiler issues an error. Multiple
instances of this option on the command line override
each other until the rightmost instance is reached.
Warnings
If you intend to allow a client to override a function
in a library, you must be sure that the function is not
generated inline during the library build. The compiler
inlines a function if you specify the function name
with -xinline, if you compile at -xO4 or higher in
which case inlining can happen automatically, if you
use the inline specifier, or if you are using cross-
file optimization.
For example, suppose library ABC has a default alloca-
tor function that can be used by library clients, and
is also used internally in the library:
void* ABC_allocator(size_t size) { return malloc(size);
}
If you build the library at -xO4 or higher, the com-
piler inlines calls to ABC_allocator that occur in
library components. If a library client wants to
replace ABC_allocator with a customized version, the
replacement will not occur in library components that
called ABC_allocator. The final program will include
different versions of the function.
Library functions declared with the __hidden or __sym-
bolic specifiers can be generated inline when building
the library. They are not supposed to be overridden by
clients. For more information, see chapter 4 "Language
Extensions" of the C++ User's Guide.
Library functions declared with the __global specifier,
should not be declared inline, and should be protected
from inlining by use of the -xinline compiler option.
See Also
-xinline, -xO, -xcrossfile, ld(1).
-xlibmieee
Causes libm to return IEEE 754 values for math routines
in exceptional cases. The default behavior of libm is
XPG-compliant.
This option has an impact on the value of the errno
variable set by certain floating-point math library
routines. See the NOTES section at the end of this man
page for more information.
-xlibmil
Inlines selected library routines for optimization.
There are inline templates for some of the libm library
routines. This option selects those inline templates
that produce the fastest executables for the floating-
point option and platform currently being used.
Note - This option does not affect C++ inline func-
tions. This option has an impact on the value of the
errno variable set by certain floating-point math
library routines. See the NOTES section at the end of
this man page for more information.
-xlibmopt
Uses a library of optimized math routines. You must use
default rounding mode by specifying -fround=nearest
when you use this option.
This option uses a math routine library optimized for
performance, and usually generates faster code. The
results may be slightly different from those produced
by the normal math library. If so, they usually differ
in the last bit.
The order on the command line for this library option
is not significant.
Interactions:
This option is implied by the -fast option.
See also:
-fast
-xnolibmopt
This option has an impact on the value of the errno
variable set by certain floating-point math library
routines. See the NOTES section at the end of this man
page for more information.
-xlic_lib=sunperf
Deprecated, do not use. Specify -library=sunperf
instead.
-xlicinfo
This option is silently ignored by the compiler.
-xlinkopt[=level]
(SPARC) Perform link-time optimizations on relocatable
object files.
The link optimizer performs a number of advanced per-
formance optimizations on the binary object code at
link-time. The value level sets the level of
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 optimizations, at link time.
2 Perform additional data flow analysis, includ-
ing dead-code elimination and address computa-
tion simplification, at link time.
Specifying -xlinkopt without a level parameter implies
-xlinkopt=1.
These optimizations are performed at link time by
analyzing the object binary code. The object files are
not rewritten but the resulting executable code may
differ from the original object codes.
This option is most effective when used to compile the
whole program, and with profile feedback.
When compiling in separate steps, -xlinkopt must appear
on both compile and link steps:
example% CC -c -xlinkopt a.cc b.cc
example% CC -o myprog -xlinkopt=2 a.o
Note that the level parameter is only used when the
compiler is linking. In the example above, the link
optimizer level is 2 even though the object binaries
were compiled with an implied level of 1.
Do not use the -zcombreloc linker option when you com-
pile with -xlinkopt.
You must use -xlinkopt on at least some of the compila-
tion commands for -xlinkopt to be useful at link time.
The optimizer can still perform some limited optimiza-
tions on object binaries not compiled with -xlinkopt.
-xlinkopt will optimize code coming from static
libraries that appear on the compiler command line, but
it will skip and not optimize code coming from shared
(dynamic) libraries that appear on the command line.
You can also use -xlinkopt when building shared
libraries (compiling with -G ).
The link optimizer is most effective when used with
run-time profile feedback. Profiling reveals the most
and least used parts of the code and directs the optim-
izer to focus its effort accordingly. This is particu-
larly important with large applications where optimal
placement of code performed at link time can reduce
instruction cache misses. Typically, this would be
compiled as follows:
example% CC -o progt -xO5 -xprofile=collect:profdir file.cc
example% progt
example% CC -o prog -xO5 -xprofile=use:profdir -xlinkopt file.cc
For details on using profile feedback, see -xprofile
Note that compiling with this option increases link
time slightly. Object file sizes also increase, but
the size of the executable remains the same. Compiling
with -xlinkopt and -g increases the size of the execut-
able by including debugging information.
-xloopinfo
Shows which loops are parallelized and which are not.
This option is normally for use with the -xautopar
option.
-xM Runs only the preprocessor on the named C++ programs,
requesting that it generate makefile dependencies and
send the result to the standard output (see make (1)
for details about makefiles and dependencies).
However, -xM only reports dependencies of the included
headers and not the associated template definition
files. You can use the .KEEP_STATE feature in your
makefile to generate all the dependencies in the
.make.state file that is created by make.
See make(1) for details about makefiles and dependen-
cies.
-xM1 This option is the same as -xM, except that this option
does not report dependencies for the /usr/include
header files and it does not report dependencies for
compiler-supplied header files.
-xMD Generates makefile dependencies like -xM but compila-
tion continues. -xMD generates an output file for the
makefile-dependency information derived from the -o
output filename, if specified, or the input source
filename, replacing (or adding) the filename suffix
with .d . If you specify -xMD and -xMF, the
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 indivi-
dual filenames for multiple input files with -xMF on
one command line. Compiling with -xMD -xMF or -xMMD
-xMF with more than one source file is not allowed and
generates an error. The dependency file is overwritten
if it already exists.
-xMMD
Use this option to generate makefile dependencies
excluding system header files. This is the same func-
tionality as -xM1, but compilation continues. -xMMD
generates an output file for the makefile-dependency
information derived from the -o output filename, if
specified, or the input source filename, replacing (or
adding) the filename suffix with .d . If you specify
-xMF, the compiler uses the filename you provide
instead. Compiling with -xMMD -xMF or -xMMD -o
filename with more than one source file is not allowed
and generates an error. The dependency file is
overwritten if it already exists.
-xMerge
(SPARC platform) Merges the data segment with the text
segment.
The data in the object file is read-only, and is shared
between processes, unless you link with
-xMerge -ztext -xprofile=collect should not be used
together. While -xMerge forces statically initialized
data into read-only storage, -ztext prohibits
position-dependent symbol relocations in read-only
storage, and -xprofile=collect generates statically
initialized, position-dependent symbol relocations in
writable storage. ld -N.
-xmaxopt[=v]
This command limits the level of pragma opt to the
level specified. v must be one of the following: off,
1, 2, 3, 4, or 5. The default value is -xmaxopt=off
which causes pragma opt to be ignored. If you specify
-xmaxopt without supplying an argument, that is the
equivalent of specifying -xmaxopt=5.
-xmemalign[=ab]
(SPARC) Use the -xmemalign option to control the
assumptions the compiler makes about the alignment of
data. By controlling the code generated for potentially
misaligned memory accesses and by controlling program
behavior in the event of a misaligned access, you can
more easily port your code to SPARC.
Specify the maximum assumed memory alignment and
behavior of misaligned data accesses. There must be a
value for both a (alignment) and b (behavior). a speci-
fies the maximum assumed memory alignment and b speci-
fies the behavior for misaligned memory accesses.
For memory accesses where the alignment is determinable
at compile time, the compiler generates the appropriate
load/store instruction sequence for that alignment of
data.
For memory accesses where the alignment cannot be
determined at compile time, the compiler must assume an
alignment to generate the needed load/store sequence.
If actual data alignment at runtime is less than the
specified alignment, the misaligned access attempt (a
memory read or write) generates a trap. The two possi-
ble responses to the trap are as follows:
o The OS converts the trap to a SIGBUS signal. If the
program does not catch the signal, the program aborts.
Even if the program catches the signal, the misaligned
access attempt will not have succeeded.
o The OS handles the trap by interpreting the
misaligned access and returning control to the program
as if the access had succeeded normally.
Values:
Accepted values for a are:
1 Assume at most 1 byte alignment.
2 Assume at most 2 byte alignment.
4 Assume at most 4 byte alignment.
8 Assume at most 8 byte alignment.
16 Assume at most 16 byte alignment.
Accepted values for b are:
i Interpret access and continue execution.
s Raise signal SIGBUS.
f For variants of -xarch=v9 only. Raise signal
SIGBUS for alignments less than or equal to
4, otherwise interpret access and continue
execution. For all other -xarch values, the f
flag is equivalent to i.
You must also specify -xmemalign whenever you want to
link to an object file that was compiled with the value
of b set to either i or f. For a complete list of com-
piler options that must be specified at both compile
time and at link time, see the C++ User's Guide.
Defaults:
If you do not specify -xmemalign, the default is
-xmemalign=8s for all v9 architectures.
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 Solaris x64 platforms
and should only be specified for the compilation of
such objects.
This option is valid only when -m64 is also specified
on 64-bit enabled x64 processors.
a is one of the following:
small
This option generates code for the small model in
which the virtual address of code executed is
known at link time and all symbols are known to be
located in the virtual addresses in the range from
0 to 2^31 - 2^24 - 1.
kernel
Generates code for the kernel model in which all
symbols are defined to be in the range from 2^64 -
2^31 to 2^64 - 2^24.
medium
Generates code for the medium model in which no
assumptions are made about the range of symbolic
references to data sections. Size and address of
the text section have the same limits as the small
code model. Applications with large amounts of
static data might require -xmodel=medium when com-
piling with -m64.
This option is not cumulative so the compiler sets the
model value according to the rightmost instance of
-xmodel on the command-line.
If you do not specify -xmodel, the compiler assumes
-xmodel=small. Specifying -xmodel without an argument
is an error.
It is not necessary to compile all translation units
with this option. You can compile select files as long
as you ensure the object you are accessing is within
reach.
Be aware that not all Linux system support the medium
model.
-xnolib
Disables linking with default system libraries.
Normally (without this option), the C++ compiler links
with several system support libraries to support C++
programs. With this option, the -llib options to link
the default system support libraries are not passed to
ld.
Normally, the compiler links with the system support
libraries in the following order:
o Standard mode (default mode):
-lCstd -lCrun -lm -lc
o Compatibility mode (-compat[=4]):
-lC -lm -lc
The order of the -l options is significant. The -lm
option must appear before -lc.
Note - If the -mt option is specified, the compiler
normally links with -lthread just before it links with
-lm.
To determine which system support libraries will be
linked by default, compile with the -dryrun option. For
example, the output from the following command:
example% CC foo.cc -xarch=v9 -dryrun
includes the following
-lCstd -lCrun -lm -lc
Examples:
For minimal compilation to meet the C application
binary interface, that is, a C++ program with only C
support required, use:
example% CC -xnolib test.cc -lc
To link libm statically into a single threaded applica-
tion with the generic instruction set, use:
o Standard mode:
example% CC -xnolib test.cc -lCstd -lCrun -Bstatic
-lm -Bdynamic -lc"
o Compatibility mode:
example% CC -compat -xnolib test.cc -lc -Bstatic -lm
-Bdynamic -lc"
Interactions:
Some static system libraries, such as libm.a and libc.a
are not available when linking with -xarch=v9,
-xarch=v9a, or -xarch=v9b.
If you specify -xnolib, you must manually link all
required system support libraries in the given order.
You must link the system support libraries last.
If -xnolib is specified, -library is ignored.
Warnings:
Many C++ language features require the use of libC
(compatibility mode) or libCrun (standard mode).
The set of system support libraries is not stable and
might change from release to release.
-xnolibmil
Cancels -xlibmil on the command line.
Use this option with -fast to override linking with the
optimized math library.
-xnolibmopt
Does not use the math routine library by turning off
any previously specified -xlibmopt options.
Interactions:
Use this option after the -fast option on the command
line, as in:
example% CC -fast -xnolibmopt ...
-xOn Specifies optimization level (n). (Note the uppercase
letter O, followed by a digit 1, 2, 3, 4, or 5)
The default is no optimization. However, this is only
possible if you do not specify an optimization level.
If you specify an optimization level, there is no
option for turning optimization off.
If you are trying to avoid setting an optimization
level, be sure not to specify any option that implies
an optimization level. For example, -fast is a macro
option that sets optimization at -xO5. All other
options that imply an optimization level give a warning
message that optimization has been set. The only way to
compile without any optimization is to delete all
options from the command line or makefile that specify
an optimization level.
Generally, the higher the level of optimization with
which a program is compiled, the better the runtime
performance. However, higher optimization levels may
result in increased compilation time and larger execut-
able files.
There are five levels that you can use with -xOn. The
actual optimizations performed by the compiler at each
level may change with each compiler release. They are
only summarized here.
If the optimizer runs out of memory, it attempts to
proceed over again at a lower level of optimization,
resuming compilation of subsequent routines at the ori-
ginal level.
Values:
-xO1 Do only the basic local optimizations.
-xO2 Do basic local and global optimization. This level
usually gives minimum code size.
-xO3 Adds global optimizations at the function level.
In general, this level, and -xO4, usually result
in the minimum code size when used with the
-xspace option.
-xO4 Adds automatic inlining of functions in the same
file. In general, -xO4 results in larger code
unless combined with -xspace.
See -inline to control which routines are inlined.
-xO5 Does the highest level of optimization, suitable
only for the small fraction of a program that uses
the largest fraction of computer time. Uses optim-
ization algorithms that take more compilation time
or that do not have as high a certainty of improv-
ing execution time. Optimization at this level is
more likely to improve performance if it is done
with profile feedback. See -xprofile=collect|use.
Interactions:
If you use -g or -g0 and the optimization level is -xO3
or lower, the compiler provides best-effort symbolic
information with almost full optimization. Tail-call
optimization and back-end inlining are disabled.
If you use -g or -g0 and the optimization level is -xO4
or higher, the compiler provides best-effort symbolic
information with full optimization.
Debugging with -g does not suppress -xOn, but -xOn lim-
its -g in certain ways. For example, the optimization
options reduce the utility of debugging so that you
cannot display variables from dbx, but you can still
use the dbx where command to get a symbolic traceback.
For more information, see Debugging a Program With dbx.
The -xinline option has no effect for optimization lev-
els below -xO3. At -xO4, the optimizer decides which
functions should be inlined, and does so regardless of
whether you specify the -xinline option. At -xO4, the
compiler also attempts to determine which functions
will improve performance if they are inlined. If you
force the inlining of a function with -xinline, you
might actually diminish performance.
Warnings:
If you optimize at -xO3 or -xO4 with very large pro-
cedures, thousands of lines of code in a single pro-
cedure, the optimizer might require an unreasonable
amount of memory. In such cases, machine performance
can be degraded.
To prevent this degradation from taking place, use the
limit command to limit the amount of virtual memory
available to a single process (see the csh(1) man
page). For example, to limit virtual memory to 16 mega-
bytes:
example% limit datasize 16M
This command causes the optimizer to try to recover if
it reaches 16 megabytes of data space.
The limit cannot be greater than the total available
swap space of the machine, and should be small enough
to permit normal use of the machine while a larger com-
pilation is in progress.
The best setting for data size depends on the degree of
optimization requested, the amount of real memory, and
virtual memory available.
To find the actual swap space, type: swap -1
To find the actual real memory, type: dmesg | grep mem
See also:
-xldscope, -fast, -xprofile=p, csh(1) man page
Performance Analyzer discusses the effects of the dif-
ferent levels of optimization on the Performance
Analyzer's data.
-xopenmp [=i]
Use the -xopenmp option to enable explicit paralleliza-
tion with OpenMP directives. To run a parallelized
program in a multithreaded environment, you must set
the OMP_NUM_THREADS environment variable prior to exe-
cution. To enable nested parallelism, you must set the
OMP_NESTED environment variable to TRUE. Nested paral-
lelism is disabled by default. See the OpenMP API
User's Guide for details.
Values
i must be one of the following:
Value Meaning
o -xopenmp=parallel
Enables recognition of OpenMP pragmas. The optimiza-
tion level under -xopenmp=parallel is -x03. The com-
piler issues a warning if the optimization level of
your program is changed from a lower level to -x03.
This flag also defines the preprocessor token
_OPENMP.
The _OPENMP macro name is defined to have the decimal
value yyyymm where yyyy and mm are the year and month
designations of the version of the OpenMP API that
the implementation supports. Refer to the Solaris
Studio OpenMP API User's Guide for the value of the
_OPENMP macro for a particular release.
0 -xopenmp=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 com-
piler issues an error. If you do not specify an
optimization level with -xopenmp=noopt, the OpenMP
pragmas are recognized, the program is parallelized
accordingly, but no optimization is done. This flag
also defines the preprocessor token _OPENMP.
o -xopenmp=none
The -xopenmp=none command does not enable recognition
of OpenMP pragmas, makes no change to the optimiza-
tion level of your program, and does not predefine
any preprocessor tokens.
Defaults
If you do not specify -xopenmp, the compiler sets the
option to -xopenmp=none. If you specify only -xopenmp,
the compiler sets the option to -xopenmp=parallel.
If you specify -xopenmp, but without an argument, the
compiler sets the option to -xopenmp=parallel.
Interactions
If you are debugging an OpenMP program with dbx, com-
pile with -g -xopenmp=noopt so you can breakpoint
within parallel regions and display the contents of
variables.
Warnings
If you compile and link in seperate steps, specify
-xopenmp in both the compilation step and the link
step. This is important if you are building a shared
object. The compiler which was used to compile the exe-
cutable must not be any older than the compiler that
built the .so with -xopenmp. This is especially impor-
tant when you compile libraries that contain OpenMP
directives.
Make sure that the latest patch of the OpenMP runtime
library, libmtsk.so, is installed on the system for
best performance.
See Also
For a complete summary of the OpenMP Fortran 95, C, and
C++ application program interface (API) for building
multiprocessing applications, see the OpenMP API User's
Guide.
-xpagesize=n
Set the preferred page size for the stack and the heap.
The n value must be one of the following:
On SPARC:
4K 8K 64K 512K 2M 4M 32M 256M 2G 16G or default.
On x86/x64:
4K 2M 4M 1G or default.
You must specify a valid page size for the target plat-
form. If you do not specify a valid pagesize, the
request is silently ignored at run-time.
Note: 1G support on x86/x64 platforms was added with
Solaris 10 5/08. Compiler support on x86/x64 was intro-
duced in Sun Studio 12 patch 126498-02.
Use the getpagesize(3C) command on the Solaris operat-
ing environment to determine the number of bytes in a
page. The Solaris operating environment offers no
guarantee that the page size request will be honored.
You can use pmap(1) or meminfo(2) to determine page
size of the target platform.
The -xpagesize option has no effect unless you use it
at compile time and at link time. For a complete list
of compiler options that must be specified at both com-
pile time and at link time, see the C++ User's Guide.
If you specify -xpagesize=default, the Solaris operat-
ing environment sets the page size.
This option is a macro for -xpagesize_heap and
-xpagesize_stack. These two options accept the same
arguments as -xpagesize. You can set them both with the
same value by specifying -xpagesize=n or you can
specify them individually with different values.
Compiling with this option has the same effect as set-
ting the LD_PRELOAD environment variable to mpss.so.1
with the equivalent options, or running the Solaris
command ppgsz(1) with the equivalent options before
running the program. See the Solaris man pages for
details.
-xpagesize_heap=n
Set the page size in memory for the heap.
The n value is the same as -xpagesize.
You must specify a valid page size for the target plat-
form. If you do not specify a valid pagesize, the
request is silently ignored at run-time.
For details, see -xpagesize.
-xpagesize_stack=n
Set the page size in memory for the stack.
The n value is the same as -xpagesize.
You must specify a valid page size for the Solaris
operating environment on the target platform. If you do
not specify a valid pagesize, the request is silently
ignored at run-time.
For details, see -xpagesize.
-xpch=v
This compiler option activates the precompiled-header
feature. v can be auto, autofirst,
collect:pch_filename, or use:pch_filename. You can take
advantage of this feature through the -xpch and
-xpchstop options in combination with the #pragma
hdrstop directive.
Use the -xpch option to create a precompiled-header
file and improve your compilation time. The
precompiled-header file is designed to reduce compile
time for applications whose source files share a common
set of include files containing a large amount of
source code. A precompiled header works by collecting
information about a sequence of header files from one
source file, and then using that information when
recompiling that source file, and when compiling other
source files that have the same sequence of headers.
Creating a Precompiled-Header File Automatically
You can let the compiler generate the precompiled-
header file for you automatically. Choose between one
of the following two ways to do this. One way is for
the compiler to create the precompiled-header file from
the first include file it finds in the source file. The
other way is for the compiler to select from the set of
include files found in the source file starting with
the first include file and extending through a well-
defined point that determines which include file is the
last one. Use one of the following two flags to deter-
mine which method the compiler uses to automatically
generate a precompiled header:
-xpch=auto
The contents of the precompiled-header file is
based on the longest viable prefix (see the fol-
lowing section for an explanation of how a viable
prefix is identified) that the compiler finds in
the source file. This flag produces a precompiled
header file that consists of the largest possible
number of header files.
-xpch=autofirst
This flag produces a precompiled-header file that
contains only the first header found in the source
file.
Creating the Precompiled-Header File Manually
If you decide to create your precompiled-header file
manually, you must start by first using -xpch and
specify the collect mode. The compilation command that
specifies -xpch=collect must only specify one source
file. In the following example, the -xpch option
creates a precompiled-header file called myheader.Cpch
based on the source file a.cc:
CC -xpch=collect:myheader a.cc
A valid precompiled-header filename always has the suf-
fix .Cpch. When you specify pch_filename, you can add
the suffix or let the compiler add it for you. For
example, if you specify CC -xpch=collect:foo a.cc, the
precompiled-header file is called foo.Cpch.
How the Compiler Handles an Existing Precompiled-Header
File
Here are the rules the compiler uses to determine how
it handles an existing precompiled-header file.
If the compiler finds an existing precompiled-header
file, it only uses the file when the following attri-
butes of the file match the same information derived
from the current compilation:
- The viable prefix matches
- The command line options are exactly the same
- The current working directory is the same
- The source-directory path-name is the same
- The compiler and precompiled header version
numbers match
The following must be true for a viable prefix to qual-
ify as a match:
- The #include filenames are all the same
- All #define and #undef directives reference the
same symbols
and the directives appear in the same order
- The associated values for #define are identical
- Any pragmas that are present appear in their ori-
ginal order
Note that #ident/#pragma idents are passed through "as
is" in the viable prefix and are unchecked for equal-
ity. The string argument is typically different for
each source file and, if checked, would inhibit use of
the existing precompiled-header file.
The compiler version used in the match condition is the
same as that returned by the compiler's -V option.
Directing the Compiler to Use a Specific Precompiled-
Header File
You can also direct the compiler to use a specific
precompiled header. Specify -xpch=use:pch_filename to
do this. You can specify any number of source files
with the same sequence of include files as the source
file used to create the precompiled-header file. For
example, your command in use mode could look like this:
CC -xpch=use:foo.Cpch foo.cc bar.cc foobar.cc
You should only use an existing precompiled-header file
if the following is true. If any of the following is
not true, you should recreate the precompiled-header
file:
- The compiler that you are using to access the
precompiled-header file is the same as the compiler
that created the precompiled-header file. A
precompiled-header file created by one version of the
compiler may not be usable by another version of the
compiler.
- Except for the -xpch option, the compiler options you
specify with -xpch=use must match the options that were
specified when the precompiled-header file was created.
- The set of included headers you specify with
-xpch=use is identical to the set of headers that were
specified when the precompiled header was created.
- The contents of the included headers that you specify
with -xpch=use is identical to the contents of the
included headers that were specified when the precom-
piled header was created.
- The current directory (that is, the directory in
which the compilation is occurring and attempting to
use a given precompiled-header file) is the same as the
directory in which the precompiled-header file was
created.
- The initial sequence of pre-processing directives,
including #include directives, in the file you speci-
fied with -xpch=collect are the same as the sequence of
pre-processing directives in the files you specify with
-xpch=use.
The Viable Prefix
In order to share a precompiled-header file across mul-
tiple source files, those source files must share a
common set of include files as their initial sequence
of tokens. A token is a keyword, name or punctuation
mark. Comments and code that is excluded by #if direc-
tives are not recognized by the compiler as tokens.
This initial sequence of tokens is known as the viable
prefix. In other words, the viable prefix is the top
portion of the source file that is common to all source
files. The compiler uses this viable prefix as the
basis for creating a precompiled-header file and
thereby determining which header files from the source
are pre-compiled.
The viable prefix that the compiler finds during the
current compilation must match the viable prefix that
it used to create the precompiled-header file. In other
words, the viable prefix must be interpreted con-
sistently by the compiler across all the source files
that use the same precompiled-header file.
The viable prefix consists of any of the following
pre-processor directives:
#include
#if/ifdef/ifndef/else/elif/endif
#define/undef
#ident
#pragma
Any of these may reference macros. The #else, #elif,
and #endif directives must match within the viable pre-
fix. Comments are ignored.
The compiler determines the end point of the viable
prefix automatically when you specify -xpch=auto or
-xpch=autofirst and is defined as follows. For
-xpch=collect or -xpch=use, the viable prefix ends with
a #pragma hdrstop.
- The first declaration/definition statement
- The first #line directive
- A #pragma hdrstop directive
- After the named include file if you specify
-xpch=auto and -xpchstop
- The first include file if you specify -xpch=autofirst
Note: An end point within a conditional statement gen-
erates a warning and disables the automatic creation of
a precompiled-header file. Also, if you specify both
the #pragma hdrstop and the -xpchstop option, then the
compiler uses the earlier of the two stop points to
terminate the viable prefix.
Within the viable prefix of each file that shares a
precompiled-header file, each corresponding #define and
#undef directive must reference the same symbol (in the
case of #define, each one must reference the same
value). Their order of appearance within each viable
prefix must be the same as well. Each corresponding
pragma must also be the same and appear in the same
order across all the files sharing a precompiled
header.
Screening Header Files for Problems
What makes a header file precompilable? A header file
is precompilable when it is interpreted consistently
across different source files. Specifically, when it
contains only complete declarations. That is, a
declaration in any one file must stand alone as a valid
declaration. Incomplete type declarations, such as
struct S;, are valid declarations. The complete type
declaration can appear in some other file. Consider
these example header files:
file a.h
struct S {
#include "x.h" /* not allowed */
};
file b.h
struct T; // ok, complete declaration
struct S {
int i;
[end of file, continued in another file] /* not allowed
*/
file c.h
namespace N {
int foo();
[end of file, continued in another file] /* not allowed
*/
file d.h
extern "C" {
int foo();
[end of file, continued in another file] /* not allowed
*/
file e.h
namespace N {
int foo();
} /* OK, a stand-alone namespace declaration */
file f.h
namespace N {
int bar();
} /* OK, namespace re-opened, but still stand-
alone */
A header file that is incorporated into a precompiled-
header file must not violate the following. The results
of compiling a program that violate any of these con-
straints is undefined.
- The header file must not use __DATE__ and __TIME__.
- The header file must not contain #pragma hdrstop.
The Precompiled-Header File Cache
When the compiler creates a precompiled-header file
automatically, the compiler writes it to the
SunWS_cache directory. This directory always resides in
the location where the object file is created. Updates
to the file are preformed under a lock so that it works
properly under dmake.
If you need to force the compiler to rebuild
automatically-generated precompiled-header files, you
can clear the PCH cache directory with the CCadmin
tool. See the CCadmin(1) man page for more information.
Warnings
o Do not specify conflicting -xpch flags on the command
line. For example, specifying both -xpch=collect and
-xpch=auto, or specifying both -xpch=autofirst with
-xpchstop=<include> generates an error.
o If you specify -xpch=autofirst or you specify
-xpch=auto without -xpchstop, any declaration, defini-
tion, or #line directive that appears prior to the
first include file, or appears prior to the include
file that is specified with -xpchstop for -xpch=auto,
generates a warning and disables the automatic genera-
tion of the precompiled-header file.
o A #pragma hdrstop before the first include file under
-xpch=autofirst or -xpch=auto disables the automatic
generation of the precompiled-header file.
Precompiled-Header File Dependencies and make Files
The compiler generates dependency information for
precompiled-header files when you specify
-xpch=collect. You need to create the appropriate rules
in your make files to take advantage of these dependen-
cies. Consider this sample make file:
%.o : %.cc shared.Cpch
$(CC) -xpch=use:shared -xpchstop=foo.h -c $<
default : a.out
foo.o + shared.Cpch : foo.cc
$(CC) -xpch=collect:shared -xpchstop=foo.h foo.cc -c
a.out : foo.o bar.o foobar.o
$(CC) foo.o bar.o foobar.o
clean :
rm -f *.o shared.Cpch .make.state a.out
These make rules, along with the dependencies generated
by the compiler, force a manually created precompiled-
header file to be recreated if any source file you used
with -xpch=collect, or any of the headers that are part
of the precompiled-header file, have changed. This
prevents the use of an out of date precompiled-header
file.
For -xpch=auto or -xpch=autofirst, you do not have to
create any additional make rules in your makefiles.
See Also: -xpchstop
-xpchstop=file
where file is the last include file to be considered in
creating a precompiled-header file. Using -xpchstop on
the command line is equivalent to placing a hdrstop
pragma (See -xhelp=readme) after the first include-
directive that references file in each of the source
files that you specify with the cc command.
Use -xpchstop=<include> with -xpch=auto to create a
precompiled-header file that is based on header files
up through and including <include>. This flag overrides
the default -xpch=auto behavior of using all header
files contained in the entire viable prefix.
See Also: -xpch, -xhelp=readme
-xpec[={yes|no}]
(Solaris) Generates a Portable Executable Code (PEC)
binary.
PEC binaries can be used with the Automatic Tuning Sys-
tem (ATS) which works by rebuilding the compiled PEC
binary for tuning and troubleshooting - the original
source code is not required. More information about the
ATS is available at
http://cooltools.sunsource.net/ats/index.html.
A binary that is built with -xpec is usually five to
ten times larger than if it is built without -xpec.
If you do not specify -xpec, the compiler sets it to
-xpec=no. If you specify -xpec, but do not supply a
flag, the compiler sets it to -xpec=yes.
-xpg Compiles for profiling with the gprof profiler.
The -xpg option compiles self-profiling code to col-
lect data for profiling with gprof. This option invokes
a runtime recording mechanism that produces a gmon.out
file when the program normally terminates.
Note: There is no advantage for -xprofile if you
specify -xpg. The two do not prepare or use data pro-
vided by the other.
Profiles are generated by using prof or gprof on 64 bit
Solaris platforms or just gprof on 32 bit Solaris plat-
forms include approximate user CPU times. These times
are derived from PC sample data (see pcsample(2)) for
routines in the main executable and routines in shared
libraries specified as linker arguments when the exe-
cutable is linked. Other shared libraries (libraries
opened after process startup using dlopen(3DL)) are not
profiled.
On 32 bit Solaris systems, profiles generated using
prof(1) are limited to routines in the executable. 32
bit shared libraries can be profiled by linking the
executable with -xpg and using gprof(1).
The Solaris 10 software does not include system
libraries compiled with -p. As a result, profiles col-
lected on Solaris 10 platforms do not include call
counts for system library routines.
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.
-xport64[=v]
Use this option to help you port code to a 64-bit
environment. Specifically, this option warns against
problems such as truncation of types (including
pointers), sign extension, and changes to bit-packing
that are common when you port code from a 32-bit archi-
tecture such as V8 to a 64-bit architecture such as V9.
Values:
v must be one of the following values.
Value Meaning
no Generate no warnings related to the
porting of code from a 32 bit environ-
ment to a 64 bit environment.
implicit Generate warning only for implicit
conversions. Do not generate warnings
when an explicit cast is present.
full Generate all warnings related to the
porting of code from a 32 bit environ-
ment to a 64 bit environment. This
includes warnings for truncation of 64-
bit values, sign-extension to 64 bits
under ISO value-preserving rules, and
changes to packing of bitfields.
Defaults:
If you do not specify -xport64, the default is
-xport64=no. If you specify -xport64, but do not
specify a flag, the default is -xport64=full.
See Also: -xarch
-xprefetch[=a[,a]]
Enable and adjust prefetch instructions on those archi-
tectures that support prefetch. You must compile
with optimization level 3 or greater with this option.
a must be one of the following values.
Value Meaning
auto Enable automatic generation of prefetch
instructions.
no%auto Disable automatic generation
explicit Enable explicit prefetch macros
Explicit prefetching should only be used
under special circumstances that are
supported by measurements.
no%explicit Disable explicit prefectch macros.
latx:factor (SPARC) You can only combine this flag
with -xprefetch=auto. Adjust the
compiler's assumed prefetch-to-load and
prefetch-to-store latencies by the
specified factor. The factor must be a
positive floating-point or integer
number.
yes Obsolete - do not use. Use
-xprefetch=auto,explicit instead.
no Obsolete - do not use. Use
-xprefetch=no%auto,no%explicit instead.
With -xprefetch, and -xprefetch=auto the compiler is
free to insert prefetch instructions into the code it
generates. This may result in a performance improvement
on architectures that support prefetch.
If you are running computationally intensive codes on
large multiprocessors, you might find it advantageous
to use -xprefetch=latx:factor. This option instructs
the code generator to adjust the default latency time
between a prefetch and its associated load or store by
the specified factor.
The prefetch latency is the hardware delay between the
execution of a prefetch instruction and the time the
data being prefetched is available in the cache. The
compiler assumes a prefetch latency value when deter-
mining how far apart to place a prefetch instruction
and the load or store instruction that uses the pre-
fetched data.
Note -- the assumed latency between a prefetch and a
load may not be the same as the assumed latency between
a prefetch and a store.
The compiler tunes the prefetch mechanism for optimal
performance across a wide range of machines and appli-
cations. This tuning may not always be optimal. For
memory-intensive applications, especially applications
intended to run on large multiprocessors, you may be
able to obtain better performance by increasing the
prefetch latency values. To increase the values, use a
factor that is greater than 1 (one). A value between .5
and 2.0 will most likely provide the maximum perfor-
mance.
For applications with datasets that reside entirely
within the external cache, you may be able to obtain
better performance by decreasing the prefetch latency
values. To decrease the values, use a factor that is
less than 1 (one).
To use the -xprefetch=latx:factor option, start with a
factor value near 1.0 and run performance tests against
the application. Then increase or decrease the factor,
as appropriate, and run the performance tests again.
Continue adjusting the factor and running the perfor-
mance tests until you achieve optimum performance. When
you increase or decrease the factor in small steps, you
will see no performance difference for a few steps,
then a sudden difference, then it will level off again.
Defaults:
The default is -xprefetch=auto,explicit.
If automatic prefetching is enabled, such as with
-xprefetch or -xprefetch=auto, but a latency factor is
not specified, then latx:1.0 is assumed.
Interactions:
This option accumulates instead of overrides.
The sun_prefetch.h header file provides the macros for
specifying explicit prefetch instructions. The pre-
fetches will be approximately at the place in the exe-
cutable that corresponds to where the macros appear.
To use the explicit prefetch instructions, you must be
on the correct architecture, include sun_prefetch.h,
and either exclude -xprefetch from the compiler command
or use -xprefetch, -xprefetch=auto,explict,
-xprefetch=explicit.
If you call the macros and include the sun_prefetch.h
header file, but pass -xprefetch=no%explicit, the
explicit prefetches will not appear in your executable.
The -xchip setting effects the determination of the
assumed latencies and therefore the result of a
latx:factor setting.
The latx:factor suboption is valid only when automatic
prefetching is enabled. That is, latx:factor is ignored
unless it is used in conjunction with yes or auto.
Warnings:
Because the compiler tunes the prefetch mechanism for
optimal performance across a wide range of machines and
applications, you should only use the latx:factor
suboption when the performance tests indicate there is
a clear benefit. The assumed prefetch latencies may
change from release to release. Therefore, retesting
the effect of the latency factor on performance when-
ever switching to a different release is highly recom-
mended.
-xprefetch_auto_type=[a]
Where a is [no%]indirect_array_access.
Use this option to determine whether or not the com-
piler generates indirect prefetches for the loops indi-
cated by the option -xprefetch_level in the same
fashion the prefetches for direct memory accesses are
generated.
If you do not specify a setting for
-xprefetch_auto_type, the compiler sets it to
-xprefetch_auto_type=no%indirect_array_access.
Options such as -xalias_level can affect the aggres-
siveness of computing the indirect prefetch candidates
and therefore the aggressiveness of the automatic
indirect prefetch insertion due to better memory alias
disambiguation information.
-xprefetch_level=l
Controls the automatic insertion of prefetch instruc-
tions as determined with -xprefetch=auto. The default
is -xprefetch_level=1 when you specify -xprefetch=auto.
l must be 1, 2, or 3.
Prefetch levels 2 and 3 may not be effective on older
SPARC and x86 platforms.
-xprefetch_level=1 enables automatic generation of pre-
fetch instructions. -xprefetch_level=2 targets addi-
tional loops, beyond those targeted at level 1 and
-xprefetch=3 targets additional loops beyond those tar-
geted at level 2.
You must compile with optimization level 3 or greater
and generate code for a platform that supports pre-
fetch.
-xprofile=p
Collects data for a profile or use a profile to optim-
ize.
p must be collect[:profdir], use[:profdir], or
tcov[:profdir]
This option causes execution frequency data to be col-
lected and saved during execution, then the data can be
used in subsequent runs to improve performance. Profile
collection is safe for multithreaded applications. That
is, profiling a program that does its own multitasking
( -mt ) produces accurate results. This option is only
valid when you specify -xO2 or greater level of optimi-
zation.
If compilation and linking are performed in separate
steps, the same -xprofile option must appear on the
compile as well as the link step. See the C++ User's
Guide for a complete list of options that must be
specified at both compile time and link time.
collect[:profdir]
Collects and saves execution frequency for later
use by the optimizer with -xprofile=use. The com-
piler generates code to measure statement
execution-frequency.
-xMerge -ztext -xprofile=collect should not be
used together. While -xMerge forces statically
initialized data into read-only storage, -ztext
prohibits position-dependent symbol relocations in
read-only storage, and -xprofile=collect generates
statically initialized, position-dependent symbol
relocations in writable storage.
The profile directory name profdir, if specified,
is the pathname of the directory where profile
data are to be stored when a program or shared
library containing the profiled object code is
executed. If the pathname is not absolute, it is
interpreted relative to the current working direc-
tory when the program is compiled with the option
-xprofile=use:profdir.
If no profile directory name is specified, profile
data are stored in a directory named
program.profile where program is the basename of
the profiled process's main program.
Example[1]: to collect and use profile data in
the directory myprof.profile located in the same
directory where the program is built:
CC -xprofile=collect:myprof.profile -xO5 prog.cc -o prog
./prog
CC -xprofile=use:myprof.profile -xO5 prog.cc -o prog
Example[2]: to collect profile data in the direc-
tory /bench/myprof.profile and later use the col-
lected profile data in a feedback compilation at
optimization level -xO5:
CC -xprofile=collect:/bench/myprof.profile -xO5 prog.cc -o prog
...run prog from multiple locations...
CC -xprofile=use:/bench/myprof.profile -xO5 prog.cc -o prog
You can set the environment variables SUN_PROFDATA
and SUN_PROFDATA_DIR to control where a program
compiled with -xprofile=collect stores the profile
data. If set, the -xprofile=collect data is writ-
ten to SUN_PROFDATA_DIR/SUN_PROFDATA.
These environment variables similarly control the
path and names of the profile data files written
by tcov , as described in the tcov(1) man page.
If these environment variables are not set, the
profile data is written to the directory
profdir.profile in the current directory, where
profdir is the name of the executable or the name
specified in the -xprofile=collect:profdir flag.
-xprofile does not append .profile to profdir if
profdir already ends in .profile. If you run the
program several times, the execution frequency
data accumulates in the profdir.profile directory;
that is, output from prior executions is not lost.
If you are compiling and linking in separate
steps, make sure that any object files compiled
with -xprofile=collect are also linked with
-xprofile=collect. For a complete list of compiler
options that must be specified at both compile
time and at link time, see the C User's Guide.
See also the ENVIRONMENT section of this man page
below for descriptions of environment variables
that control asynchronous profile collections.
use[:profdir]
Uses execution frequency data collected from code
compiled with -xprofile=collect[:profdir] to
optimize for the work performed when the profiled
code was executed. profdir is the pathname of a
directory containing profile data collected by
running a program that was compiled with
-xprofile=collect[:profdir].
The profdir is optional. If profdir is not speci-
fied, the name of the executible binary is used.
a.out is used if -o is not specified. The compiler
looks for profdir.profile/feedback, or
a.out.profile/feedback without profdir specified.
For example:
CC -xprofile=collect -o myexe prog.c
CC -xprofile=use:myexe -xO5 -o myexe prog.c
The program is optimized by using the execution
frequency data previously generated and saved in
the feedback files written by a previous execution
of the program compiled with -xprofile=collect.
Except for the -xprofile option, the source files
and other compiler options must be exactly the
same as those used for the compilation that
created the compiled program which in turn gen-
erated the feedback file. The same version of the
compiler must be used for both the collect build
and the use build as well.
If compiled with -xprofile=collect:profdir, the
same profile directory name profdir must be used
in the optimizing compilation:
-xprofile=use:profdir.
See also -xprofile_ircache for speeding up compi-
lation between collect and use phases.
tcov[:profdir]
Instrument object files for basic block coverage
analysis using tcov(1).
If the optional :profdir argument is specified,
the compiler will create a profile directory at
the specified location. The data stored in the
profile directory can be used either by tcov(1) or
by the compiler with -xprofile=use:profdir .
If the optional :profdir argument is omitted, a
profile directory will be created when the pro-
filed program is executed. The data stored in the
profile directory can only be used by tcov(1).
The location of the profile directory can be con-
trolled using environment variables SUN_PROFDATA
and SUN_PROFDATA_DIR. See ENVIRONMENT below.
If the location specified by :profdir is not an
absolute pathname, it is interpreted at compila-
tion time relative to the directory in which the
current object file is to be written. If :profdir
is specified for any object file, the same loca-
tion must be specified for all object files in the
same program. The directory whose location is
specified by :profdir must be accessible from all
machines where the profiled program is to be exe-
cuted. The profile directory should not be
deleted until its contents are no longer needed,
because data stored there by the compiler cannot
be restored except by recompilation.
Example 1: if object files for one or more pro-
grams are compiled with
-xprofile=tcov:/test/profdata, a directory named
/test/profdata.profile will be created by the com-
piler and used to store data describing the pro-
filed object files. The same directory will also
be used at execution time to store execution data
associated with the profiled object files.
Example 2: if a program named "myprog" is compiled
with -xprofile=tcov and executed in the directory
/home/joe, the directory /home/joe/myprog.profile
will be created at run time and used to store run-
time profile data.
-xprofile_ircache[=path]
Use -xprofile_ircache[=path] with -xprofile=collect|use
to improve compilation time during the use phase by
reusing compilation data saved from the collect phase.
With large programs, compilation time in the use phase
can improve significantly because the intermediate data
is saved. Note that the saved data could increase disk
space requirements considerably.
When you use -xprofile_ircache[=path], path overrides
the location where the cached files are saved. By
default, these files are saved in the same directory as
the object file. Specifying a path is useful when the
collect and use phases happen in two different direc-
tories.
Here's a typical sequence of commands:
example% CC -xO5 -xprofile=collect -xprofile_ircache
t1.cc t2.cc
example% a.out // run collects feedback data
example% CC -xO5 -xprofile=use -xprofile_ircache t1.cc
t2.cc
-xprofile_pathmap=collect_prefix:use_prefix
Use the -xprofile_pathmap option when you are also
specifying the -xprofile=use command. Use
-xprofile_pathmap when both of the following are true
and the compiler is unable to find profile data for an
object file that is compiled with -xprofile=use.
o You are compiling the object file with -xprofile=use
in a directory that is different from the directory
in which the object file was previously compiled
with -xprofile=collect.
o Your object files share a common basename in the
profile but are distinguished from each other by
their location in different directories.
The collect-prefix is the prefix of the UNIX pathname
of a directory tree in which object files were compiled
using -xprofile=collect.
The use-prefix is the prefix of the UNIX pathname of a
directory tree in which object files are to be compiled
using -xprofile=use.
If you specify multiple instances of -xprofile_pathmap,
the compiler processes them in the order of their
occurrence. Each use-prefix specified by an instance
of -xprofile_pathmap is compared with the object file
pathname until either a matching use-prefix is identi-
fied or the last specified use-prefix is found not to
match the object file pathname.
-xreduction
Analyzes loops for reduction in automatic paralleliza-
tion. This option is valid only if -xautopar is also
specified. Otherwise the compiler issues a warning.
When a reduction recognition is enabled, the compiler
parallelizes reductions such as dot products, maximum
and minimum finding. These reductions yield different
roundoffs from those obtained by unparallelized code.
-xregs=r[,r...]
Specify the usage of registers for the generated code.
r is a comma-separated list of one or more of the fol-
lowing suboptions: appl, float, frameptr.
Prefixing a suboption with no% disables that suboption.
Example: -xregs=appl,no%float
Note that -xregs suboptions are restricted to specific
hardware platforms.
appl (SPARC)
Allow the compiler to generate code using the
application registers as scratch registers.
The application registers are:
g2, g3, g4 (on 32-bit platforms)
g2, g3 (on 64-bit platforms)
It is strongly recommended that all system
software and libraries be compiled using
-xregs=no%appl. System software (including
shared libraries) must preserve these regis-
ters' values for the application. Their use is
intended to be controlled by the compilation
system and must be consistent throughout the
application.
In the SPARC ABI, these registers are
described as application registers. Using
these registers can increase performance
because fewer load and store instructions are
needed. However, such use can conflict with
some old library programs written in assembly
code.
For more information on SPARC instruction
sets, see -xarch.
float (SPARC)
Allow the compiler to generate code by using
the floating-point registers as scratch regis-
ters for integer values. Use of floating-point
values may use these registers regardless of
this option. To generate binary code free of
all references to floating point registers,
use -xregs=no%float and make sure your source
code does not in any way use floating point
types.
frameptr (x86)
Allow the compiler to use the frame-pointer
register (%ebp on IA32, %rbp on x86 64-bit
platforms) as a general-purpose register.
The default is -xregs=no%frameptr.
The C++ compiler ignores -xregs=frameptr
unless exceptions are also disabled with
-features=no%except. Note also that
-xregs=frameptr is part of -fast, but is
ignored by the C++ compiler unless
-features=no%except is also specified.
With -xregs=frameptr the compiler is free to
use the frame-pointer register to improve pro-
gram performance. However, some features of
the debugger and performance measurement tools
may be limited. Stack tracing, debuggers, and
performance analyzers cannot report on func-
tions compiled with -xregs=frameptr.
Also, C++ calls to Posix pthread_cancel() will
fail trying to find cleanup handlers.
Mixed C, Fortran, and C++ code should not be
compiled with -xregs=frameptr if a C++ func-
tion, called directly or indirectly from a C
or Fortran function, can throw an exception.
If compiling such mixed source code with
-fast, add -xregs=no%frameptr after the -fast
option on the command line.
With more available registers on 64-bit plat-
forms, compiling with -xregs=frameptr has a
better chance of improving 32-bit code perfor-
mance than 64-bit code.
Note: -xregs=frameptr is ignored and a warn-
ing is issued by the compiler if you also
specify -xpg.
The SPARC default is -xregs=appl,float.
The x86 default is -xregs=no%frameptr.
-xregs=frameptr is included in the expansion of -fast
on x86.
It is strongly recommended that you compile code
intended for shared libraries that will link with
applications, with -xregs=no%appl,float. At the very
least, the shared library should explicitly document
how it uses the application registers so that applica-
tions linking with those libraries are aware of these
register assignments.
For example, an application using the registers in some
global sense (such as using a register to point to some
critical data structure) would need to know exactly how
a library with code compiled without -xregs=no%appl is
using the application registers in order to safely link
with that library.
-xrestrict[=f]
Treats pointer-valued function parameters as restricted
pointers. f is %all, %none, %source or a comma-
separated list of one or more function names. This
command-line option can be used on its own, but is best
used with optimization of -xO3 or greater.
Specifying -xrestrict=%source means that all functions
defined in the main source file, but not any header
files or template definition files, are restricted.
If you specify a function list with this option,
pointer parameters in the specified functions are
treated as restricted; if you specify -xrestrict=%all,
all pointer parameters in the entire C++ file are
treated as restricted.
The default is %none. Specifying -xrestrict is
equivalent to specifying -xrestrict=%source.
See Also: -xprefetch_auto_type, 'Restricted Pointers'
in the C++ User's Guide
-xs Allows debugging by dbx without object files.
This option causes all the debug information to be
copied into the executable. This has little impact on
dbx performance or the run-time performance of the pro-
gram, but it does take more disk space.
-xsafe=mem
(SPARC platform) Allow the compiler to assume that no
memory protection violations occur.
This option allows the compiler to use the non-faulting
load instruction in the SPARC V9 architecture.
Warnings:
Because non-faulting loads do not cause a trap when a
fault such as address misalignment or segmentation vio-
lation occurs, you should use this option only for pro-
grams in which such faults cannot occur. Because few
programs incur memory-based traps, you can safely use
this option for most programs. Do not use this option
for programs that explicitly depend on memory-based
traps to handle exceptional conditions.
Interactions:
This option takes effect only when used with optimiza-
tion level -xO5 and one of the following -xarch values:
sparc, sparcvis, sparcvis2, or sparcvis3 for both -m32
and -m64.
-xsb Deprecated - do not use. The source browser functional-
ity is obsolete.
-xsbfast
Deprecated - do not use. The source browser functional-
ity is obsolete.
-xspace
Does not allow optimizations that increase code size.
-xtarget=t
Specifies the target system for instruction set and
optimization.
t must be one of the folowing: native, native64, gen-
eric, generic64 or system-name.
This option is a macro. Each specific value for -xtar-
get expands into a specific set of values for the
-xarch, -xchip, and -xcache options. See the -dryrun
explanation for details on how to see the expansion of
macro options such as -xtarget.
Note: The expansion of -xtarget for a specific host
platform might not expand to the same -xarch, -xchip,
or -xcache settings as -xtarget=native when compiling
on that platform.
-xtarget=native is equivalent to -m32, -xarch=native,
-xchip=native, -xcache=native.
-xtarget=native64 is equivalent to -m64,
-xarch=native64, -xchip=native64, -xcache=native.
-xtarget=generic is equivalent to -m32,
-xarch=generic, -xchip=generic, -xcache=generic.
-xtarget=generic64 is equivalent to -m64,
-xarch=generic64, -xchip=generic64, -xcache=generic.
On SPARC platforms:
Compiling for 64-bit Solaris software on SPARC or
UltraSPARC V9 is indicated by the -m64 option. If you
specify -xtarget with a flag other than native64 or
generic64, you must also specify the -m64 option as
follows:
-xtarget=ultra4 ... -m64
otherwise the compiler uses a 32-bit memory model.
Value Meaning
native Gets the best performance on the host system.
The compiler generates code for the best per-
formance on the host system. This flag deter-
mines the available architecture, chip, and
cache properties of the machine on which the
compiler is running and assumes a 32-bit
architecture.
native64 Set the parameters for the best performance
on the host system. This flag determines the
available architecture, chip, and cache pro-
perties of the machine on which the compiler
is running and assumes a 64-bit architecture.
generic This is the default and yields the best per-
formance for generic architecture, chip and
cache on most 32-bit systems.
generic64 Gets the best performance for generic archi-
tecture, chip and cache on most 64-bit sys-
tems.
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,
ultraT3, sparc64vi, sparc64vii.
For more information about platform names, see the C++
User's Guide.
On x86 platforms:
Compiling for 64-bit Solaris software on 64-bit x86
64-bit platforms is indicated by the -m64 option. If
you specify -xtarget with a flag other than native64 or
generic64, you must also specify the -m64 option as
follows:
-xtarget=opteron ... -m64
otherwise the compiler uses a 32-bit memory model.
Value Meaning
generic This is the default and yields the best per-
formance for generic architecture, chip and
cache on most 32-bit systems.
generic64 Gets the best performance for generic archi-
tecture, chip and cache on most 64-bit sys-
tems.
native The compiler generates code for the best per-
formance on the host system. This flag
determines the available architecture, chip,
and cache properties of the machine on which
the compiler is running and assumes a 32-bit
architecture.
native64 Set the parameters for the best performance
on the host system. This flag determines the
available architecture, chip, and cache pro-
perties of the machine on which the compiler
is running and assumes a 64-bit architecture.
nehalem Directs the compiler to generate code for the
best performance on the Nehalem microproces-
sor.
barcelona Directs the compiler to generate code for the
best performance on the AMD Barcelona
microprocessor.
opteron Directs the compiler to generate code for the
best performance on the AMD Opteron micropro-
cessor.
Note: The -xtarget=opteron option does not
automatically generate 64-bit code. You must
specify -m64 to compile 64-bit code.
pentium Directs the compiler to generate code for the
best performance on the Pentium microproces-
sor.
pentium_pro
Directs the compiler to generate code for the
best performance on the Pentium Pro micropro-
cessor.
pentium3 Directs the compiler to generate code for the
best performance on the Pentium 3 micropro-
cessor.
pentium4 Directs the compiler to generate code for the
best performance on the Pentium 4 micropro-
cessor.
penryn Directs the compiler to generate code for the
best performance on the Penryn microproces-
sor.
woodcrest Directs the compiler to generate code for the
best performance on the Intel Woodcrest
microprocessor.
-xthreadvar[=o]
Works in conjunction with the __thread declaration
specifier to take advantage of the compiler's thread-
local storage facility. After you declare the thread
variables with the __thread specifier, use -xthreadvar
to enable the use of thread-local storage with position
dependent code (non-PIC code) in dynamic (shared)
libraries. For more information on how to use __thread,
see the C++ User's Guide.
Values
o can be one of the following:
Value Meaning
[no%]dynamic [[Do not] Compile variables for dynamic
loading. Access to thread variables is
significantly faster when
-xthreadvar=no%dynamic but you cannot
use the object file within a dynamic
library. That is, you can only use the
object file in an executable file.
Defaults
If you do not specify -xthreadvar, the default used by
the compiler depends upon whether or not position-
independent code is enabled. If position-independent
code is enabled, the option is set to
-xthreadvar=dynamic. If position- independent code is
disabled, the option is set to -xthreadvar=no%dynamic.
If you specify -xthreadvar but do not specify any argu-
ments, the option is set to -xthreadvar=dynamic.
Interactions
Using thread variables on different versions of Solaris
software requires different options on the command
line.
On Solaris 9 software, objects that use __thread must
be compiled and linked with -mt.
Warnings
If there is non-position-independent code within a
dynamic library, you must specify -xthreadvar.
The linker cannot support the thread-variable
equivalent of non-PIC code in dynamic libraries. Non-
PIC thread variables are significantly faster, and
hence should be the default for executables.
See Also
-xcode, -KPIC, -Kpic
-xtime
Causes the CC driver to report execution times for the
various compilation passes.
-xtrigraphs[={yes|no}]
Enables or disables recognition of trigraph sequences
as defined by the ISO/ANSI C standard.
-xtrigraphs=yes enables recognition of trigraph
sequences in the source code.
-xtrigraphs=no disables recognition of trigraph
sequences in the source code.
Defaults:
If the -xtrigraphs option is not specified,
-xtrigraphs=yes is assumed.
If only -xtrigraphs is specified -xtrigraphs=yes is
assumed.
-xunroll=n
Enables unrolling of loops where possible.
This option specifies whether or not the compiler
optimizes (unrolls) loops.
When n is 1, it is a suggestion to the compiler not to
unroll loops.
When n is an integer greater than 1, -xunroll=n causes
the compiler to unroll loops n times.
-xustr={ascii_utf16_ushort|no}
This option enables compiler recognition of UTF-16
character strings and literals. Since such strings and
literals are not yet part of any standard, this option
enables recognition of non-standard C++. Specify
-xustr=ascii_utf16_ushort if you need to support an
internationalized application that uses ISO10646 UTF-16
characters. In other words, use this option if your
code contains string characters that you want the com-
piler to convert to UTF-16 characters in the object
file. Without this option, the compiler neither
produces nor recognizes sixteen-bit characters. This
option enables recognition of the U"ASCII_string"
string literals as an array of unsigned short int. This
option also enables recognition of character literals.
For example: unsigned short character = U'Z';
You can turn off compiler recognition of
U"ASCII_string" string literals by specifying
-xustr=no. The rightmost instance of this option on the
command line overrides all previous instances.
The default is -xustr=no. If you specify -xustr without
an argument, the compiler won't accept it and instead
issues a warning. The default can change if the C or
C++ standards define a meaning for the syntax.
It is not an error to specify
-xustr=ascii_ustf16_ushort without also specifying a
U"ASCII_string" string literal.
Not all files have to be compiled with this option.
The following example shows a string literal in quotes
that is prepended by U. It also shows a command line
that specifies -xustr.
example% cat file.cc
const unsigned short *foo = U"foo";
const unsigned short bar[] = U"bar";
const unsigned short *fun() { return foo; }
example% CC -xustr=ascii_utf16_ushort file.cc -c
An 8-bit character literal can be prepended with U to
form a 16-bit UTF-16 character of type unsigned short.
Examples:
const unsigned short x = U'x';
const unsigned chart y = U';
-xvector[=a]
Enables automatic generation of calls to the vector
library and/or the generation of the SIMD (Single
Instruction Multiple Data) instructions. You must use
default rounding mode by specifying -fround=nearest
when you use this option.
The -xvector option requires optimization level -O3 or
greater. Compilation will not proceed if the optimiza-
tion level is unspecified or lower than -O3, and a mes-
sage is issued.
a is the equivalent of the following:
[no%]lib
(SOLARIS Only) Does [not]enable the compiler to
transform math library calls within loops into
single calls to the equivalent vector math rou-
tines when such transformations are possible. This
could result in a performance improvement for
loops with large loop counts.
[no%]simd
Does [not]direct the compiler to use the native
x86 SSE SIMD instructions to improve performance
of certain loops. Streaming extensions are used
on x86 by default at optimization level 3 and
above where beneficial. The suboption no%simd can
be used to disable it.
The compiler will use SIMD only if streaming
extensions exist in the target architecture; that
is, if target ISA is at least SSE2. For example,
you can specify -xtarget=woodcrest,
-xarch=generic64, -xarch=sse2, -xarch=sse3, or
-fast on a modern platform to use it. If the tar-
get ISA has no streaming extensions, the suboption
will have no effect.
yes This option is deprecated, specify -xvector=lib
instead.
no This option is deprecated, specify -xvector=none
instead.
The default is -xvector=simd on x86 and -xvector=%none
on SPARC platforms. If you specify -xvector without a
suboption, the compiler assumes -xvector=simd,lib on
x86, -xvector=lib on SPARC (Solaris), and -xvector=simd
(Linux).
This option overrides previous instances so
-xvector=%none undoes a previously specified
-xvector=lib.
The compiler includes the libmvec libraries in the
load step.
If you compile and link with separate commands, be sure
to use the same -xvector option in the linking CC com-
mand. For a complete list of compiler options that must
be specified at both compile time and at link time, see
the C++ User's Guide.
-xvis
(SPARC) Use the -xvis=[yes|no] command when you are
using the assembly-language templates defined in the
VIS[tm] instruction set Software Developers Kit (VSDK).
The default is -xvis=no. Specifying -xvis is equivalent
to specifying -xvis=yes.
The VIS instruction set is an extension to the SPARC v9
instruction set. Even though the UltraSPARC processors
are 64-bit, there are many cases, especially in mul-
timedia applications, when the data are limited to
eight or 16 bits in size. The VIS instructions can pro-
cess four 16-bit data with one instruction so they
greatly improve the performance of applications that
handle new media such as imaging, linear algebra, sig-
nal processing, audio, video and networking.
For more information on the VSDK, see
http://www.sun.com/processors/vis/.
-xvpara
Issues warnings about potential parallel-programming
related problems that may cause incorrect results when
using OpenMP. Use with -xopenmp and OpenMP API direc-
tives.
The compiler issues warnings when it detects the fol-
lowing situations:
o Loops are parallelized using MP directives with data
dependencies between different loop iterations
o OpenMP data-sharing attributes-clauses are prob-
lematic. For example, declaring a variable "shared"
whose accesses in an OpenMP parallel region may create
a data race, or declaring a variable "private" whose
value in a parallel region is used after the parallel
region.
No warnings appear if all parallelization directives
are processed without problems.
Example:
CC -xopenmp -xvpara any.cc
Note: Solaris Studio compilers support OpenMP 3.0 API
parallelization. Consequently, the MP pragmas are
deprecated. See the OpenMP API User's Guide for infor-
mation on migrating to the OpenMP API.
-xwe Converts all warnings to errors by returning non-zero
exit status.
-Yc,path
Specifies a new path for the location of component c.
If the location of a component is specified, then the
new path name for the component is path/component_name.
This option is passed to ld.
Values
c must be one of the following values.
p Changes the default directory for cpp.
0 Changes the default directory for ccfe.
a Changes the default directory for fbe.
2 Changes the default directory for iropt.
c Changes the default directory for cg (SPARC).
O Changes the default directory for ipo.
k Changes the default directory for CClink.
l Changes the default directory for ld.
f Changes the default directory for c++filt.
m Changes the default directory for mcs.
u Changes the default directory for ube (x86).
h Changes the default directory for ir2hf (x86).
A Specifies a directory to search for all compiler
components. If a component is not found in path,
the search reverts to the directory where the com-
piler is installed.
P Adds path to the default library search path. This
path will be searched before the default library
search paths.
S Changes the default directory for startup object
files
Interactions
You can have multiple -Y options on a command line. If
more than one -Y option is applied to any one com-
ponent, then the last occurrence holds.
See also
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
Solaris Linker and Libraries Guide.
PRAGMAS
The following #pragmas are recognized by the compilation
system:
#pragma align
#pragma does_not_read_global_data
#pragma does_not_return
#pragma does_not_write_global_data
#pragma dump_macros
#pragma end_dumpmacros
#pragma fini
#pragma hdrstop
#pragma ident
#pragma init
#pragma must_have_frame
#pragma pack
#pragma rarely_called
#pragma returns_new_memory
#pragma unknown_control_flow
#pragma weak
#pragma does_not_read_global_data
#pragma does_not_write_global_data
#pragma no_side_effect
SPARC Only:
#pragma no_side_effect
Refer to the C++ User's Guide for more information on these
pragmas.
ENVIRONMENT
SUN_PROFDATA=profdir
If set, store profile data collected from a pro-
gram compiled with -xprofile=collect in a direc-
tory named profdir in the current working direc-
tory at the time that the program is executed. If
the optional argument :profdir was specified in
-xprofile=collect[:profdir] at compilation time,
SUN_PROFDATA as no effect.
SUN_PROFDATA_DIR=dirname If set, store profile
data collected from a program compiled with
-xprofile=collect in a directory whose UNIX dir-
name is dirname. If dirname is not absolute, it
is interpreted relative to the current working
directory at the time that the program is exe-
cuted. If the optional argument :profdir was
specified in -xprofile=collect[:profdir] at compi-
lation time, SUN_PROFDATA_DIR has no effect.
SUN_PROFDATA_REPLACE={objfile,program,all}
SUN_PROFDATA_REPLACE indicates the scope of pro-
file data to be reset when a changed version of an
object file is detected at runtime. Use
SUN_PROFDATA_REPLACE to ensure that profile data
are consistent with the profiled program within
the specified unit of program scope.
The values of SUN_PROFDATA_REPLACE and their mean-
ings are as follows:
objfile
reset profile data of changed object file
program
reset profile data of all object files in
program containing changed object file
all reset entire contents of profile directory if
any object file has changed
The default setting of SUN_PROFDATA_REPLACE is
SUN_PROFDATA_REPLACE=objfile .
Example:
% setenv SUN_PROFDATA_REPLACE program (csh)
$ export SUN_PROFDATA_REPLACE=program (ksh)
With this setting, when a program containing a
changed object file is executed, all object files
in the program will have their profile data reset.
Relevant options include -xOn and -xipo=n.
SUN_PROFDATA_ASYNC_INTERVAL=async_interval
Set this environment variable to enable asynchro-
nous profile collection. In asynchronous profile
collection, profile data are collected from a run-
ning process at regular intervals whose duration
is specified in units of seconds.
SUN_PROFDATA_ASYNC_INTERVAL has no effect unless
one of the environment variables LD_AUDIT,
LD_AUDIT_32, or LD_AUDIT_64 is set to
/usr/lib/{,64}/libxprof_audit.so.1.
Asynchronous profile collection requires an MT-
safe, mmap based memory allocator, such as
libumem(3) with mmap-based allocation specified by
setting UMEM_OPTIONS to backend=mmap.
Example: to enable asynchronous profile collection
from a 64 bit process at 1 minute
intervals,specify the following environment vari-
ables:
$ env LD_AUDIT_64=/usr/lib/64/libxprof_audit.so.1 \
SUN_PROFDATA_ASYNC_INTERVAL=60 UMEM_OPTIONS=backend=mmap \
64-bit-program [program-args]
Asynchronous profile collection requires OpenSo-
laris 2009.06 or later.
SUN_PROFDATA_ASYNC_VERBOSE=verbose
If set nonzero, enables verbose messages from
asynchronous collector to stderr.
SUN_PROFDATA_ASYNC_VERBOSE has no effect unless
asynchronous profile collection is enabled.
NOTES
The C++ compiler includes the static libraries libC.a and
libCrun.a. However, the corresponding bundled shared
libraries, libC.so.5 and libCrun.so.1, are out of sync with
the C++ compiler on the Solaris 9 operating environment. For
the compiler to work correctly with the shared library on
the Solaris 9 operating environment you must install the
appropriate OS patch; see the C++ FAQ for a list of patches
or go directly to www.sunsolve.com and search for libCrun.
Limit the search to 'Patch Descriptions'.
For Solaris release 10, new shared libraries libxprof.so.1,
libxprof_audit.so.1, and libtdf.so.1 must be installed in
order to use the -xprofile option. These libraries are pre-
installed on the latest OpenSolaris and Solaris releases.
FILES
file.a Static library
file.C Input file
file.cc Input file
file.c++ Input file
file.cpp Input file
file.cxx Input file
file.o Object file
file.so Dynamic (shared) library
a.out Linked output
xprof_fini.o Initialization and finalization handlers
for programs compiled with
-xprofile=collect
SEE ALSO
analyzer(1), as(1), c++filt(1), cc(1), csh(1), dbx(1),
gprof(1), ld(1), more(1), nm(1), prof(1), tcov(1)
C++ User's Guide,
C++ Migration Guide,
The C++ Programming Language, Third Edition, Bjarne
Stroustrup, Addison-Wesley 1997
The C Programming Language, B. W. Kernighan and D. M.
Ritchie, Prentice-Hall 1988
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 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 after
floating-point library calls, you should compile with the
options
-xbuiltin=none -U__MATHERR_ERRNO_DONTCARE \
-xnolibmopt -xnolibmil
following -fast on the command line to inhibit the compiler
from optimizing out such library calls and to to ensure that
calls to math functions set errno as documented.