CC(1)CC(1)NAMECC - C++ compiler
SYNOPSISCC [-a] [-B{dynamic|static|symbolic}] [-c] [-cg{89|92}] [-com‐
pat[={4|5}]] [+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] [-fsim‐
ple[=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] [-mis‐
align] [-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|-qop‐
tion}phase[,option...]] [{-Qproduce|-qproduce}type] [-qp]
[-Rpath[:path...]] [-readme] [-S] [-s] [-sb] [-sbfast] [-stati‐
clib=l[,l...]] [-sync_stdio=[yes|no]] [-temp=path] [-tem‐
plate=a[,a...]] [-time] [-Uname] [-unroll=n] [-V] [-v] [-vdelx]
[-verbose=a[,a...]] [+w] [+w2] [-w] [-Xm] [-xa]
[-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] [-xcross‐
file[=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...]] [-xinstru‐
ment=[no%]datarace] [-xipo[={0|1|2}] [-xipo_archive[=a]]
[-xjobs=n] [-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] [-xpage‐
size=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_pre‐
fix:use_prefix] [-xreduction] [-xregs=r[,r...]] [-xre‐
strict[=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] ...
Sun Studio 12 Update 1
This man page details the options or flags for the Sun Studio 12 Update
1 C++ compiler. For the complete description of all new features and
functionality in the Sun Studio suite, see the readmes at http://devel‐
opers.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, environments, 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, linking, 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 compiling for x86
Solaris platforms.
The legacy Sun-style parallelization pragmas are not available on x86.
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 extensions and features.
OS releases starting with Solaris 9 4/04 are SSE/SSE2- enabled on Pen‐
tium 4-compatible platforms. Earlier versions of Solaris OS are not
SSE/SSE2-enabled. If an instruction set selected by -xarch is not
enabled in the running Solaris OS, the compiler will not be able to
generate or link code for that instruction set.
If you compile and link in separate steps, always link using the com‐
piler and with same -xarch setting to ensure that the correct startup
routine is linked.
Numerical results on x86 might differ from results on SPARC due to the
x86 80-bit floating-point registers. To minimize these differences, use
the -fstore option or compile with -xarch=sse2 if the hardware supports
SSE2.
Numerical results can also differ between 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 platforms that
are not enabled with the appropriate features or instruction set exten‐
sions could result in segmentation faults or incorrect results occur‐
ring 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 extensions.
Overview of the C++ CompilerCC converts C++ and assembly source files to object files, and links
object files and libraries into executable programs.
Programs that contain C++ objects must be linked with CC.
CC takes arguments ending in .c, .C, .cc, .cxx, .c++, .cpp, or .i to be
C++ source programs. Arguments ending in .s are presumed to be assem‐
bly source files. Arguments ending in .o are presumed to be object
files.
Files whose names do not end with the above suffixes are treated as
object programs or libraries and are handed over to the link editor.
Unless -c, -S, -E, or -P is specified, these programs and libraries,
together with the results of any specified compilations or assemblies,
are linked in the order given to produce an output file named a.out.
You can specify a different name for the executable by using the -o
option.
If a single file is compiled and linked all at once, the intermediate
files are deleted.
Before you use the CC command, insert into your search path the name of
the directory in which you have chosen to install the C++ compilation
system. For instructions on setting your search path, see the csh(1)
or the sh(1) man page.
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 exam‐
ples, see the C++ User's Guide.
CC accepts the following options.
-a Use -xa.
See also:
tcov(1) man page
-Bbinding
Specifies whether a library binding for linking is symbolic,
dynamic (shared), or static (nonshared).
-Bdynamic is the default. You can use the -B option several
times on a command line.
For more information on the -Bbinding option, see the ld(1) man
page and the Solaris documentation.
-Bdynamic directs the link editor to look for liblib.so files.
Use this option if you want shared library bindings for linking.
If the liblib.so files are not found, it looks for liblib.a
files.
-Bstatic directs the link editor to look only for liblib.a
files. The .a suffix indicates that the file is static, that
is, nonshared. Use this option if you want nonshared library
bindings for linking.
-Bsymbolic forces symbols to be resolved within a shared library
if possible, even when a symbol is already defined elsewhere.
For an explanation of -Bsymbolic, see the ld(1) man page.
This option and its arguments are passed to the linker, ld. If
you compile and link in separate steps and are using the -Bbind‐
ing option, you must include the option in the link step.
Warning:
Never use -Bsymbolic with programs containing C++ code, use
linker scoping instead. See the C++ User's Guide for more infor‐
mation on linker scoping. See also the -xldscope option.
With -Bsymbolic, references in different modules can bind to
different copies of what is supposed to be one global object.
The exception mechanism relies on comparing addresses. If you
have two copies of something, their addresses won't compare
equal, and the exception mechanism can fail because the excep‐
tion mechanism relies on comparing what are supposed to be
unique addresses.
-c 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 gener‐
ated.
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}
Use -xcg{89|92}.
See also:
-xtarget=native
-compat[={4|5}]
Sets the major release compatibility mode of the compiler. This
option controls the __cplusplus and __SUNPRO_CC_COMPAT pre‐
processor symbols.
The C++ compiler has two principal modes. The compatibility mode
accepts the Annotated C++ Reference Manual (ARM) semantics and
language defined by the 4.2 compiler (-compat[=4]). The stan‐
dard mode accepts constructs according to the ANSI/ISO standard
(standard mode, -compat=5). These two modes are incompatible
with each other because the ANSI/ISO standard forces signifi‐
cant, incompatible changes in name mangling, vtable layout, and
other ABI details. These two modes are differentiated by the
-compat option as shown in the following table.
Value Meaning
-compat[=4] (Compatibility mode) Set language and binary com‐
patibility 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).
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 sup‐
ported.
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 sup‐
ported.
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
Warnings:
When building a shared library do not use -Bsymbolic.
+d Prevents the compiler from expanding C++ inline functions.
Under the C++ language rules, a C++ inline function is a func‐
tion for which one of the following statements is true.
o The function is defined using the inline keyword.
o The function is defined (not just declared) inside a class
definition
o The function is a compiler-generated class member function
Under the C++ language rules, the compiler can choose whether
actually to inline a call to an inline function. The C++ com‐
piler inlines calls to an inline function unless:
o The function is too complex
o The +d option is selected
o The -g option is selected
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 = 0x510
__SUNPRO_CC_COMPAT = 4 or 5
__TIME__
__cplusplus
__`uname -s`_`uname -r | tr . _` (replacing invalid characters
with underscores, for example: -D__SunOS_5_9, -D__SunOS_5_10)
__unix
_BOOL if type bool is enabled
(see "-features=[no%]bool")
_WCHAR_T
unix
SPARC only:
sparc
sun
__SUN_PREFETCH = 1
__SunOS_OSversion _OSversion
__SVR4
__sun
__sparc
SPARC V9 only:
__sparcv9 (64-bit compilation modes only)
x86 only:
linux
__amd64
__gnu__linux__
__linux
__linux__
__x86_64
Defaults:
If you do not use [=def], name is defined as 1.
Interactions:
If +p is used, sun, unix, sparc and i386 are not defined.
-d{y|n}
Allows or disallows dynamic libraries for the entire executable.
-dy specifies dynamic linking, which is the default, in the link
editor.
-dn specifies static linking in the link editor.
This option and its arguments are passed to ld.
Interactions:
This option causes fatal errors if you use it in combination
with dynamic libraries. Most system libraries are only available
as dynamic libraries.
-dalign
(SPARC) Obsolete. You should not use this option. Use -xmema‐
lign=8s instead. For a complete list of obsolete options, see
the C++ User's Guide. On x86/x64 platforms, the option is
passed to the linker.
-dryrun
Directs the CC driver to show, but not execute, the commands
constructed by the compilation driver.
-E Directs the CC driver to only preprocess the C++ source files,
and to send the result to stdout (standard output). No compila‐
tion is done; no .o files are generated.
This option causes preprocessor-type line number information to
be included in the output.
Output from this option is not supported as input to the C++
compiler when templates are used.
+e{0|1}
Controls virtual table generation in compatibility mode (-com‐
pat[=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 vir‐
tual functions.
Interactions:
When you compile with this option, also use the -fea‐
tures=no%except option. Otherwise the compiler generates vir‐
tual 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 message by using the
-errtags=yes option.
no%tag Enables the warning message specified by this tag.
%all Suppresses all warning messages.
%none Enables all warning messages. This is the default.
Order is important; for example, %all,no%tag suppresses all
warning messages except tag.
Defaults:
The default is -erroff=%none. Specifying -erroff is equivalent
to specifying -erroff=%all.
Warnings:
Only warning messages from the C++ compiler front-end that dis‐
play a tag when the -errtags option is used can be suppressed
with the -erroff option.
-errtags [ = a]
Displays the message tag for each warning message of the C++
compiler front-end that can be suppressed with the -erroff
option or made a fatal error with the -errwarn option. Messages
from the C++ compiler driver and other components of the C++
compilation system do not have error tags and cannot be sup‐
pressed with -erroff and made fatal with -errwarn.
Values and Defaults:
a can be either yes or no. The default is -errtags=no. Specify‐
ing -errtags is equivalent to specifying -errtags=yes.
-errwarn [ = t[,t...]]
Use the -errwarn option to cause the C++ compiler to exit with a
failure status for the given warning messages.
Values:
t is a comma-separated list that consists of one or more of the
following: tag, no%tag, %all, %none. Order is important; for
example %all,no%tag causes the C++ compiler to exit with a fatal
status if any warning except tag is issued.
The following table details the -errwarn values:
tag Cause CC to exit with a fatal status if the message
specified by tag is issued as a warning message. Has no
effect if tag in not issued.
no%tag Prevent CC from exiting with a fatal status if the mes‐
sage specified by tag is issued only as a warning mes‐
sage. Has no effect if tag is not issued. Use this
option to revert a warning message that was previously
specified by this option with tag or %all from causing
CC to exit with a fatal status when issued as a warning
message.
%all Cause CC to exit with a fatal status if any warning
messages are issued. %all can be followed by no%tag to
exempt specific warning messages from this behavior.
%none Prevents any warning messages from causing CC to exit
with a fatal status should any warning tag be issued.
This is the default.
Defaults:
The default is -errwarn=%none. If you specify -errwarn alone, it
is equivalent to -errwarn=%all.
Warnings:
The warning messages generated by the C++ compiler change from
release to release as the compiler error checking improves and
features are added. Code that compiles using -errwarn=%all
without error may not compile without error in the next release
of the compiler.
Only warning messages from the C++ compiler front-end that dis‐
play a tag when the -errtags option is used can be specified
with the -errwarn option to cause the C++ compiler to exit with
a failure status.
See Also:
-erroff, -errtags
-fast This option is a macro that you can effectively use as a start‐
ing point for tuning an executable for maximum run-time perfor‐
mance. The expansion of -fast can change from one release of the
compiler to the next and includes options that are target plat‐
form specific. Use the -dryrun option to examine the expansion
of -fast, and incorporate the appropriate options of -fast into
the ongoing process of tuning the executable.
Modules that are compiled with -fast must also be linked with
-fast. For a complete list of compiler options that must be
specified at both compile time and at link time, see the C++
User's Guide.
The expansion of -fast now includes the new -xlibmopt option.
This option enables the compiler to use a library of optimized
math routines. For more information, see the description of
-xlibmopt in this man page.
This option provides near maximum performance for most applica‐
tions by expanding the following compilation options:
-fns (SPARC, x86)
-fsimple=2 (SPARC, x86)
-nofstore (x86)
-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)
Note that this selection of component option flags is subject to
change with each release of the compiler. For details on the
options set by -fast, see the C++ User's Guide.
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 possible inter‐
actions.
Warnings:
Code compiled with the -fast option is not portable. For exam‐
ple, compiling code using the following command on an Ultra‐
SPARC(TM) III system will generate a binary that will not exe‐
cute on an UltraSPARC II system.
example% CC-fast test.cc
Do not use this option for programs that depend on IEEE standard
floating-point exception handling; different numerical results,
premature program termination, or unexpected SIGFPE signals
might occur.
The -fast option includes -fns -ftrap=%none; that is, this
option turns off all trapping.
In previous SPARC releases, the -fast macro included -fnonstd,
now it does not.
In previous SPARC releases, the -fast macro expanded to -fsim‐
ple=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_MATH‐
ERR_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 (compatibility mode or
standard mode).
[no%]altspell [Do not] Recognize alternative token spellings
(for example, and for &&). The default is
no%altspell in compatibility 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, operator 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
compatibility 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++ excep‐
tions are disabled (that is, -fea‐
tures=no%except), a throw-specification on a
function is accepted but ignored; the compiler
does not generate exception code. Note that the
keywords try, throw, and catch are always
reserved. The default is except.
[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 compatibility mode and
export in standard mode.
[no%]extensions
[Do not] Allow non-standard code that is commonly
accepted by other C++ compilers. See chapter 4 of
the C++ User's Guide for an explanation of the
invalid code that is accepted by the compiler
when you use the -features=extensions option.
The default is -features=no%extensions.
[no%]iddollar [Do not] Allow $ as a non-initial identifier
character. The default is no%iddollar.
[no%]localfor [Do not] Use new 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 compatibility mode and
mutable in standard mode.
[no%]namespace (Compatibility mode only) [Do not] Recognize key‐
words 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 recog‐
nition options allow you to find uses of the
added keywords without having to compile in stan‐
dard mode.
[no%]nestedaccess
(Standard mode only) [Do not] Allow nested
classes to access private members of the enclos‐
ing class.
[no%]rtti [Do not] Allow runtime type identification
(RTTI). RTTI must be enabled to use the
dynamic_cast<> and typeid operators. For -com‐
pat=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 functions. When you use
-features=no%split_init, the compiler puts all
the initializers in one function. Using -fea‐
tures=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 require‐
ments specified by the C++ standard regarding the
order of the destruction of objects with static
storage duration. The default is strictde‐
strorder.
[no%]tmplife (Standard mode only) [Do not] Clean up the tempo‐
rary objects that are created by an expression at
the end of the full expression, as defined in the
ANSI/ISO C++ Standard. (When -fea‐
tures=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 compiler
issues warnings about these constructs instead of
error messages. When you use -features=transi‐
tions in compatibility mode (-compate[=4]), the
compiler displays the warnings about these con‐
structs only if +w or -w2 is specified. The fol‐
lowing constructs are considered to be transition
errors: redefining a template after it was used,
omitting the typename directive when it is needed
in a template definition, and implicitly declar‐
ing type int. The set of transition errors may
change in a future release. The default is tran‐
sitions.
Defaults:
If -features is not specified, the following is assumed for com‐
patibility 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 com‐
patible 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. Consequently, you can get unintended behavior.
The behavior of a program might change when you use -fea‐
tures=tmplife. Testing whether the program works both with and
without the -features=tmplife option is one way to test the pro‐
gram's portability.
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 split‐
ting 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 suppression of the explana‐
tions 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 demangling helps you to iden‐
tify function names more quickly, but note that
in the case of co-variant returns, some functions
differ only in the return type.
[ no% ] stdlib [Do not] Simplify names from the standard library
in both the linker and compiler error messages.
This makes it easier for you to recognize the
name of standard-library functions.
%all Equivalent to -filt=errors,names,returns,stdlib.
This is the default behavior.
%none Equivalent to
-filt=no%errors,no%names,no%returns,no%stdlib.
Defaults:
If you do not specify the -filt option, or if you specify -filt
without any values, then the compiler assumes
-filt=errors,names,returns,stdlib.
Interactions:
[no%]returns has no effect when used with no%names. That is,
the following options are equivalent:
-filt=no%names
-filt=no%names,no%returns
-filt=no%names,returns
See also c++filt(1).
-flags Same as -xhelp=flags.
-fma [= { none|fused}]
(SPARC) Enables automatic generation of floating-point, fused,
multiply-add instructions. -fma=none disables generation of
these instructions. -fma=fused allows the compiler to attempt
to find opportunities to improve the performance of the code by
using floating-point, fused, multiply-add instructions.
The default is -fma=none.
The minimum requirements are -xarch=sparcfmaf and an optimiza‐
tion level of at least -xO2 for the compiler to generate fused
multiply-add instructions. The compiler marks the binary program
if fused multiply-add instructions are generated in order to
prevent the program from executing on platforms that do not sup‐
port them.
Fused multiply-adds eliminate the intermediate rounding step
between the multiply and the add. Consequently, programs may
produce different results when compiled with -fma=fused,
although precision will tend to be increased rather than
decreased.
-fnonstd
This option causes hardware traps to be enabled for floating-
point overflow, division by zero, and invalid operations excep‐
tions.
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 subnormal operands to be treated as zero.
This option has no effect on traditional x86 floating-point
operations that do not utilize the SSE or SSE2 instruction set.
On some SPARC platforms, the nonstandard floating-point mode
disables "gradual underflow," causing tiny results to be flushed
to zero rather than to produce subnormal numbers. It also causes
subnormal operands to be silently replaced by zero.
On those SPARC platforms that do not support gradual underflow
and subnormal numbers in hardware, use of this option can sig‐
nificantly improve the performance of some programs.
Optional use of =yes or =no provides a way of toggling the -fns
flag following some other macro flag that includes -fns, such as
-fast.
-fns is the same as -fns=yes.
-fns=yes selects non-standard floating point.
-fns=no selects standard floating point.
Defaults:
If -fns is not specified, the nonstandard floating-point mode is
not enabled automatically. Standard IEEE 754 floating-point com‐
putation takes place, that is, underflows are gradual.
If only -fns is specified -fns=yes is assumed.
Warnings:
When nonstandard mode is enabled, floating-point arithmetic may
produce results that do not conform to the requirements of the
IEEE 754 standard.
On SPARC systems, this option is effective only if used when
compiling the main program.
If you compile one routine with -fns, then compile all routines
of the program with the -fns option; otherwise you can get unex‐
pected results.
-fprecision=a
(x86 platform) Sets floating-point rounding precision mode. a
must be one of: single, double, extended.
The -fprecision flag sets the rounding precision mode bits in
the Floating Point Control Word. These bits control the preci‐
sion to which the results of basic arithmetic operations (add,
subtract, multiply, divide, and square root) are rounded.
The following table shows the meanings of the values of a.
Value Meaning
single Rounds to an IEEE single-precision value
double Rounds to an IEEE double-precision value
extended Rounds to the maximum precision available
When a is single or double, this flag causes the rounding preci‐
sion mode to be set to single or double precision, respectively,
when a program begins execution. When p is extended or the
-fprecision flag is not used, the rounding precision mode
remains as the extended precision.
The single precision rounding mode causes results to be rounded
to 24 significant bits, and double precision rounding mode
causes results to be rounded to 53 significant bits. In the
default extended precision mode, results are rounded to 64 sig‐
nificant bits. This mode controls only the precision to which
results in registers are rounded, and it does not affect the
range. All results in register are rounded using the full range
of the extended double format. Results that are stored in memory
are rounded to both the range and precision of the destination
format.
The nominal precision of the float type is single. The nominal
precision of the long double type is extended.
Defaults:
When the -fprecision flag is not specified, the rounding preci‐
sion mode defaults to extended.
Warnings:
This option is effective only on x86 devices and only if used
when compiling the main program. On SPARC devices, this option
is ignored.
-fround=a
Sets the IEEE rounding mode in effect at startup.
a must be one of: nearest, tozero, negative, positive.
Value Meaning
nearest Rounds towards the nearest number and breaking ties to
even numbers.
tozero Round-to-zero.
negative Round-to-negative-infinity.
positive Round-to-positive-infinity.
This option sets the IEEE 754 rounding mode that:
o Can be used by the compiler in evaluating constant expres‐
sions.
o Is established at runtime during the program initialization.
The meanings are the same as those for the ieee_flags function,
which may be used to change the mode at runtime.
Defaults:
When the -fround option is not specified, the rounding mode
defaults to -fround=nearest.
Warnings:
If you compile one routine with -fround=a, compile all routines
of the program with the same -fround=a option; otherwise, you
can get unexpected results. This option is effective only if
used when compiling the main program.
-fsimple[=n]
Selects floating-point optimization preferences.
If n is present, it must be 0, 1 or 2.
The following table shows the -fsimple values.
Value Meaning
0 Permits no simplifying assumptions. Preserves strict
IEEE 754 conformance.
1 Allows conservative simplification. The resulting code
does not strictly conform to IEEE 754, but numeric
results of most programs are unchanged.
With -fsimple=1, the optimizer is not allowed to opti‐
mize completely without regard to roundoff or excep‐
tions. In particular, a floating point computation
cannot be replaced by one that produces different
results with rounding modes held constant at runtime.
With -fsimple=1, the optimizer can assume the follow‐
ing:
o IEEE 754 default rounding/trapping modes do not
change after process initialization.
o Computation producing no visible result other than
potential floating-point exceptions may be deleted.
o Computation with Infinity or NaNs as operands need
not propagate NaNs to their results. For example,
x*0 may be replaced by 0.
o Computations do not depend on sign of zero.
2 Includes all the functionality of -fsimple=1, and also
enables the use of SIMD instructions to compute reduc‐
tions when -xvector=simd is in effect.
Also permits aggressive floating point optimization
that may cause many programs to produce different
numeric results due to changes in rounding. For exam‐
ple, permits the optimizer to replace all computations
of x/y in a given loop with x*z, where x/y is guaran‐
teed to be evaluated at least once in the loop, z=1y ,
and the values of y and z are known to have constant
values during execution of the loop.
Defaults:
If -fsimple is not designated, the compiler uses -fsimple=0.
If -fsimple is designated but no value is given for n, the com‐
piler uses -fsimple=1.
Warnings:
This option can break IEEE 754 conformance.
See Also:
Techniques for Optimizing Applications: High Performance Comput‐
ing written by Rajat Garg and Ilya Sharapov for a more detailed
explanation of how optimization can impact precision.
-fstore
(x86 platform) Forces precision of floating-point expressions.
This option causes the compiler to convert the value of a float‐
ing-point expression or function to the type on the left side of
an assignment - when that expression or function is assigned to
a variable, or when that expression is cast to a shorter float‐
ing-point type rather than leaving the value in a register.
To turn off this option, use the -nofstore option.
Warnings:
Due to roundoffs and truncation, the results may be different
from those that are generated from the register values.
-ftrap=a[,a...]
Sets the IEEE trapping mode in effect at startup but does not
install a SIGFPE handler. You can use ieee_handler(3M) or
fex_set_handling(3M) to simultaneously enable traps and install
a SIGFPE handler. If you specify more than one value, the list
is processed sequentially from left to right.
a must be one of the following values.
Value Meaning
[no%]division [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 compiled with
-xcode=pic13 by default.
When building a shared library that uses templates, it is neces‐
sary in most cases to include in the shared library those tem‐
plate functions that are instantiated in the template database.
Using this option automatically adds those templates to the
shared library as needed.
If you are creating a shared object by specifying -G along with
other compiler options that must be specified at both compile
time and link time, make sure that those same options are also
specified at both compile time and link time when you link with
the resulting shared object.
When you create a shared object, all the object files that are
compiled 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 neces‐
sary -l option on the command line. For example, if you want the
shared library to be dependent upon libCrun, you must pass
-lCrun on the command line.
-g Instructs both the compiler and the linker to prepare the file
or program for debugging. The tasks include:
o Producing more detailed information, known as stabs, in the
symbol table of the object files and the executable
o Producing some "helper functions," which the Debugger can call
to implement some of its features
o Disabling the inline generation of functions; that is, using
this option implies the +d option
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 limited debugging informa‐
tion. For more information, see the entry for -xO.
If you specify -gO and the optimization level is -xO3 or lower,
the compiler provides best-effort symbolic information with
almost full optimization. Tail-call optimization and back-end
inlining are disabled.
If you use this option and the optimization level is -xO4 or
higher, the compiler provides best effort symbolic information
with full optimization.
When you specify this option, the +d option is specified auto‐
matically unless you also specify -O or -xO.
To use the full capabilities of the Performance Analyzer, com‐
pile with the -g option. While some performance analysis fea‐
tures do not require -g, you must compile with -g to view anno‐
tated source, some function level information, and compiler com‐
mentary messages. See the analyzer(1) man page and the Perfor‐
mance Analyzer manual for more information.
The commentary messages that are generated with -g describe the
optimizations and transformations that the compiler made while
compiling your program. Use the er_src(1) command to display the
messages which are interleaved with the source code.
Warnings
If you compile and link your program in separate steps, then
including the -g option in one step and excluding it from the
other step will not affect the correctness of the program, but
it will affect the ability to debug the program. Any module that
is not compiled with -g (or -g0), but is linked with -g (or -g0)
will not be prepared properly for debugging. Note that compiling
the module that contains the function main with the -g option
(or the -g0 option) is usually necessary for debugging.
See also:
For more information, see the explanations for -g0, -xs, and +d,
as well as the ld(1) man page.
-g0 Instructs the compiler to prepare the file or program for debug‐
ging, but not to disable inlining. This option is the same as
-g, except that +d is disabled and dbx cannot step into inlined
functions.
See also:
+d
-H On the standard error output (stderr), prints, one per line, the
path name of each #include file contained in the current compi‐
lation.
-h[ ]lname
Assigns the name lname to the generated shared dynamic library.
This is a loader option that is passed to ld. In general, the
name after -h should be exactly the same as the one after -o. A
space between the -h and lname is optional.
The compile-time loader assigns the specified name to the shared
dynamic library you are creating. It records the name in the
library file as the intrinsic name of the library. If there is
no
-hlname option, then no intrinsic name is recorded in the
library file.
Every executable file has a list of needed shared library files.
When the runtime linker links the library into an executable
file, the linker copies the intrinsic name from the library into
that list of needed shared library files. If there is no
intrinsic name of a shared library, then the linker copies the
path of the shared library file instead. This command line is
an example:
% CC-G -o libx.so.1 -h libx.so.1 a.o b.o c.o
Interactions:
This option accumulates instead of overrides.
-help Same as -xhelp=flags.
-Ipathname
Adds pathname to the list of directories that are searched for
files with relative file names — those that do not begin with a
slash.
The compiler searches for quote-included files (of the form
#include "foo.h") in this order:
1. In the directory containing the source
2. In the directories named with -I options, if any
3. In the include directories for compiler-provided C++
header files, ANSI C header files, and special-purpose
files
4. In usrinclude
The compiler searches for bracket-included files (of the form
#include <foo.h>) in this order:
1. In the directories named with -I options, if any
2. In the include directories for compiler-provided C++
header files, ANSI C header files, and special-purpose
files
3. In usrinclude
Note — If the spelling matches the name of a standard header
file, also refer to "Standard Header Implementation" in the C++
User's Guide.
Interactions:
This option accumulates instead of overrides.
The -I- option allows you to override the default search rules.
If -library=no%Cstd is specified, then the compiler-provided
Cstd header files are not searched.
Note — If -ptipath is not used, the compiler looks for template
files in -Ipathname. It is recommended that you use -Ipathname
instead of -ptipath.
Warnings
Never specify the compiler installation area, /usr/include,
/lib, /usr/lib, as search directories.
-I- Change the include-file search rules to the following:
o For include files of the form #include "foo.h", search
the directories in the following order:
1. The directories named with -I options (both before
and after -I-)
2. The directories for compiler-provided C++ header
files, ANSI C header files, and special-purpose
files.
3. The /usr/include directory.
o For include files of the form #include <foo.h>, search
the directories in the following order:
1. The directories named with the -I options that
appear after -I-.
2. The directories for compiler-provided C++ header
files, ANSI C header files, and special-purpose
files.
3. The /usr/include directory.
Warnings
Never specify the compiler installation area, /usr/include,
/lib, /usr/lib, as search directories.
Only the first -I- in a command line causes the described behav‐
ior.
-i Tells the linker, ld(1), to ignore any LD_LIBRARY_PATH setting.
-include filename
This option causes the compiler to treat filename as if it
appears in the first line of a primary source file as a #include
preprocessor directive.
The first directory the compiler searches for filename is the
current working directory and not the directory containing the
main source file, as is the case when a file is explicitly
included. If the compiler cannot find filename in the current
working directory, it searches the normal directory paths. If
you specify multiple -include options, the files are included in
the order they appear on the command line.
-inline
Same as -xinline.
-instances=a
Controls the placement and linkage of template instances. The
following table shows the meanings of the values of a.
Value Meaning
extern Places all needed instances into the template reposi‐
tory within comdat sections and gives them global
linkage. (If an instance in the repository is out of
date, it is reinstantiated.)
Note: If you are compiling and linking in separate
steps and you specify -instance=extern for the compi‐
lation step, you must also specify it for the link
step.
explicit Places explicitly instantiated instances into the cur‐
rent object file within comdat sections and gives them
global linkage. Does not generate any other needed
instances.
global Places all needed instances into the current object
file within comdat sections and gives them global
linkage.
semiexplicit
Places explicitly instantiated instances and all
instances needed by the explicit instances into the
current object file within comdat sections and gives
them global linkage.
static Note: -instances=static is deprecated. There is no
longer any reason to use -instances=static, because
-instances=global now gives you all the advantages of
static without the disadvantages. This option was
provided in earlier compilers to overcome problems
that do not exist in this version of the compiler.
Places all needed instances into the current object
file and gives them static linkage.
Defaults:
If instances is not specified, -instances=global is assumed.
Warnings:
static and semiexplicit values may produce invalid results. See
C++ User's Guide for more information.
-instlib=file
Use this option to inhibit the generation of a template
instances that are duplicated in a library, either static or
shared, and the current object. In general, if your program
shares large numbers of instances with libraries, try
-instlib=file and see whether compilation time improves.
Values:
Use the file argument to specify the library that you know con‐
tains 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 refer‐
ence to a global datum is generated as a dereference of a
pointer in the global offset table. Each function call is gener‐
ated in pc-relative addressing mode through a procedure linkage
table.
-keeptmp
Retains the temporary files that are created during compilation.
Along with -verbose=diags, this option is useful for debugging.
-Lpath Adds path to the library search paths.
This option is passed to ld. The linker searches the directory
specified by path before it searches the compiler-provided
directories.
Interactions:
This option accumulates instead of overrides.
Warnings
Never specify the /usr/include, lib, /usr/lib, or the compiler
installation area as search directories.
-llib Add library liblib.a or liblib.so to linker's list of search
libraries.
This option is passed to ld. Normal libraries have names such
as liblib.a or liblib.so where the lib and .a or .so parts are
required. You can specify the lib part with this option. Put as
many libraries as you want on a single command line; they are
searched in the order specified with -Lpath.
Use this option after your object file names.
Interactions:
This option accumulates instead of overrides.
Warnings:
If you are building a multithreaded application or linking your
application to a multithreaded library, you must compile and
link your program with the -mt option instead of linking your
application directly with -lthread.
See also:
-mt
-libmieee
Use -xlibmieee.
-libmil
Use -xlibmil.
-library=lib[,lib...]
Incorporates specified CC-provided libraries into compilation
and linking.
When the -library option is used to specify a CC-provided
library, the proper -I paths are set during compilation and the
proper -L, -Y, -P, and -R paths and -l options are set during
linking.
Values:
The 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 complex arith‐
metic.
[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 collection.
[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++ version 7.
[no%]interval Deprecated. Do not use. Use -xia.
[no%]iostream [Do not] Use libiostream, the classic
iostreams library.
[no%]Cstd [Do not] Use libCstd, the C++ standard
library. [Do not] include the compiler-pro‐
vided C++ standard library header files.
[no%]stlport4 [Do not] Use STLport's implementation 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 version 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=stl‐
port4.
[no%]Crun [Do not] Use libCrun, the C++ runtime
library
[no%]gc [Do not] Use libgc, garbage collection.
[ no% ]sunperf [Do not] Use the Sun Performance Library
(TM).
%none Use no C++ libraries except for libCrun.
Defaults:
For compatibility mode (-compat[=4]), if -library is not speci‐
fied, -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 informa‐
tion). You can use the standard-iostreams Rogue Wave tools
library in standard mode only. The following command examples
show both valid and invalid use of the Rogue Wave tools.h++
library options.
Valid:
example% CC-compat -library=rwtools7 foo.cc
Invalid:
example% CC-compat -library=rwtools7_std foo.cc
Valid, classic iostreams
example% CC -library=rwtools7,iostream foo.cc
Invalid example% CC -library=rwtools7 foo.cc
Valid, standard iostreams
example% CC -library=rwtools7_std foo.cc
Invalid
example% CC -library=rwtools7_std,iostream foo.cc
If you include both libCstd and libiostream, you must be careful
to not use the old and new forms of iostreams (for example, cout
and std::cout) within a program to access the same file. Mixing
standard iostreams and classic iostreams in the same program is
likely to cause problems if the same file is accessed from both
classic and standard iostream code.
Programs linking neither libC nor libCrun might not use all fea‐
tures 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 exam‐
ple, the -l options are passed to ld in the order -lrwtool
-liostream for both -library=rwtools7,iostream and
-library=iostream,rwtools7.
When you use the interval arithmetic libraries, you must include
one of the following libraries: libC, libCstd, or libiostreams.
The specified libraries are linked before the system support
libraries are linked.
Warnings:
Do not redefine or modify any of the configuration macros for
STLport, Rogue Wave or Sun Microsystems C++ libraries. The
libraries are configured and built in a way that works with the
C++ compiler. libCstd and Tool.h++ are configured to inter-oper‐
ate 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 behav‐
ior.
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 Studio 12 compilers, this is no
longer the case. On most platforms, just adding -m64 to the com‐
mand line is sufficient to create 64-bit objects.
On Solaris, -m32 is the default. On Linux systems supporting
64-bit programs, -m64 -xarch=sse2 is the default.
See also -xarch.
-mc Removes duplicate strings from the .comment section of the
object file. If the string contains blanks, the string must be
enclosed in quotation marks. 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 -xmema‐
lign=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 quo‐
tation 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 Use this option to compile and link multithreaded code. The -mt
option assures that libraries are linked in the appropriate
order.
This option passes -D_REENTRANT to the preprocessor and passes
-lthread in the correct order to ld.
Warnings:
If you are using POSIX threads, you must link with the options
-mt -lpthread.
Use this option consistently. If you compile with -mt and link
in a separate step, you must use the -mt option in the link step
as well as the compile step. If you compile and link one trans‐
lation unit with -mt, you must compile and link all units of the
program with -mt.
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 expres‐
sion or function to the type on the left side of an assignment
but leaves the value in a register when that expression or func‐
tion 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 compil‐
ing. A nonzero status is returned for testing makefiles.
-norunpath
Does not build the path for shared libraries into the exe‐
cutable.
If an executable file uses shared libraries, then the compiler
normally builds in a path that points the runtime linker to
those shared libraries. To do so, the compiler passes the -R
option to ld. The path depends on the directory where you have
installed the compiler.
This option is recommended for building executables that will be
shipped to customers who may have a different path for the
shared libraries that are used by the program.
Interactions:
If you use any shared libraries under the compiler installed
area (default location <installpath>/lib ) and you also use
-norunpath, then you should either use the -R option at link
time or set the environment variable LD_LIBRARY_PATH at run time
to specify the location of the shared libraries. This will allow
the runtime linker to find the shared libraries.
-O The -O macro 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 assumption are device drivers and older multi-threaded
applications 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 over‐
write the source file.
+p Ignore non-standard preprocessor asserts.
Defaults:
If +p is not present, the compiler recognizes nonstandard pre‐
processor asserts.
Interactions:
If +p is used, the sun, unix, sparc, and i386 macros are not
defined.
-P Only preprocesses source: does not compile. (Outputs a file with
a .i suffix.)
This option does not include preprocessor-type line number
information in the output.
-p Obsolete See -xpg.
-pentium
(x86 platform) Use -xtarget=pentium.
-pg Use -xpg.
-PIC SPARC: Same as -xcode=pic32.
x86: Same as -KPIC.
-pic SPARC: Same as -xcode=pic13.
x86: Same as -Kpic.
-pta Use -template=wholeclass.
-ptipath
Specifies an additional search directory for template source.
This option is an alternative to the normal search path set by
-Ipathname. If the -ptipath flag is used, the compiler looks
for template definition files on this path and ignores the
-Ipathname flag.
Using the -Ipathname flag instead of -ptipath produces less con‐
fusion.
Interactions:
This option accumulates instead of overrides.
-pto Use -instances=static.
-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.
-Qoptionphase[,option...]
Passes option to the compilation phase.
To pass multiple options, specify them in order as a comma-sepa‐
rated list. Options that are passed to components with -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 -zdefaultex‐
tract ... // error
the -z options can be reordered, giving incorrect results.
The following table shows the possible values for phase.
SPARC x86
ccfe ccfe
iropt cg386
cg codegen
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 source‐
type. Source code types are shown in the following table.
Value Meaning
.i Preprocessed C++ source from ccfe
.o Object file from the code generator
.s Assembler source from the code generator
-qproduce sourcetype
Use -Qproduce.
-Rpath[:path...]
Builds dynamic library search paths into the executable file.
This option is passed to ld.
Defaults:
If the -R option is not present, the default library search path
is recorded in the output object and passed to the runtime
linker. The default library search order can be seen by using
the -dryrun option and examining the -Y option of the ld invoca‐
tion.
Interactions:
This option accumulates instead of overrides.
If both the LD_RUN_PATH environment variable and the -R option
are specified, then the path from -R is scanned, and the path
from LD_RUN_PATH is ignored.
See also:
-norunpath
-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 functionality is
obsolete.
-sbfast
Deprecated - do not use. The source browser functionality 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 val‐
ues 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 specified by
the -library option, all the library specified in
the -xlang option, and, if -xia is specified, the
interval libraries.
%none Link no libraries specified in the -library
option and the -xlang option statically. If -xia
is specified in the command line, link no inter‐
val libraries statically.
Defaults:
If -staticlib is not specified, -staticlib=%none is assumed.
Interactions:
This option accumulates instead of overrides.
The -staticlib option only works for the C++ libraries that are
selected explicitly with the -xia, the -xlang option, and the
-library option, in addition to the C++ libraries that are
selected implicitly by default. In compatibility mode (-com‐
pat=[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. Sun recommends against linking
these libraries statically on any platform. In some cases,
static linking can prevent a program from working.
-sync_stdio=[yes|no]
Use this option when your run-time performance is degraded due
to the synchronization between C++ iostreams and C stdio. Syn‐
chronization is needed only when you use iostreams to write to
cout and stdio to write to stdout in the same program. The C++
standard requires synchronization so the C++ compiler turns it
on by default. However, application performance is often much
better without synchronization. If your program does not write
to both cout and stdout, you can use the option -sync_stdio=no
to turn off synchronization.
Defaults:
If you do not specify -sync_stdio, the compiler sets it to
-sync_stdio=yes.
Examples:
Consider the following example:
#include <stdio.h>
#include <iostream>
int main()
{
std::cout << "\nHello ";
printf("beautiful ");
std::cout << "world!";
printf("\n");
}
With synchronization, the program prints on a line by itself
Hello beautiful world!
Without synchronization, the output gets scrambled.
Warnings:
This option is only effective for linking of executables, not
for libraries.
-temp=path
Defines the directory for temporary files.
This option sets path as the directory for the temporary files
which are generated during the compilation process. The compiler
gives precedence to the value set by -temp over the value of
TMPDIR.
See also:
-keeptmp
-template=a[,a...]
Enables/disables various template options.
a must be one of the following values.
Value Meaning
[no%]extdef [Do not] search for template definitions in
separate source files.
[no%]geninlinefuncs [Do not] instantiate inline member functions
of the explicitly instantiated class tem‐
plate which were not generated previously.
[no%]wholeclass [Do not] Instantiate a whole template class,
rather than only those functions that are
used. You must reference at least one member
of the class; otherwise, the compiler does
not instantiate any members for the class.
Defaults:
-template=no%wholeclass,extdef,no%geninlinefuncs
-time Use -xtime.
-Uname Deletes initial definition of the preprocessor symbol name. This
option removes any initial definition of the macro symbol name
that was created by -D on the same command line, including those
implicitly placed there by the command-line driver.
This option has no effect on any other predefined macros nor on
macro definitions in source files.
To see the -D options that are placed on the command line by the
command-line driver, add the -dryrun option to your command
line.
You can specify multiple -U options on the command line.
Examples:
The following command undefines the predefined symbol __sun.
Preprocessor statements in test.cc such as #ifdef(__sun) will
sense that the symbol is undefined.
example% CC-U__sun test.cc
Interactions:
This option accumulates instead of overrides.
All -U options are processed after any -D options that are
present.
-unroll=n
Same as -xunroll=n.
-V Same as -verbose=version.
-v Same as -verbose=diags.
-vdelx Deprecated, do not use. This flag is available only for compati‐
bility mode (-compat[=4]).
For expressions using delete[], this option generates a call to
the runtime library function _vector_deletex_ instead of gener‐
ating a call to _vector_delete_.
The function _vector_delete_ takes two arguments: the pointer to
be deleted and the size of each array element.
The function _vector_deletex_ behaves the same as _vec‐
tor_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, sometimes called the verify
mode. The verbose mode displays each phase
of instantiation as it occurs during compi‐
lation.
[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 -ver‐
bose=%none.
Interactions:
This option accumulates instead of overrides.
+w Identifies code that might have unintended consequences. The +w
option no longer generates a warning if a function is too large
to inline or if a declared program element is unused. These
warnings do not identify real problems in the source, and were
thus inappropriate to some development environments. 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 constructs that
are:
o Nonportable
o Likely to be mistakes
o Inefficient
Defaults:
If +w is not specified, the compiler warns about constructs that
are almost certainly problems.
Interactions:
Some C++ standard headers result in warnings when compiled with
+w.
+w2 Emits the same warnings as +w as well as warnings about techni‐
cal violations that are probably harmless, but that might reduce
the maximum portability of your program.
The +w2 option no longer warns about the use of implementation-
dependent constructs in the system header files. Because the
system header files are the implementation, the warning was
inappropriate. Removing these warnings from +w2 enables more
aggressive use of the option.
Warnings:
Some Solaris software and C++ standard header files result in
warnings when compiled with +w2.
-w Suppresses warning messages.
This option causes the compiler not to print warning messages.
Some warnings, particularly warnings regarding serious anachro‐
nisms, cannot be suppressed.
-Xm Use -features=iddollar.
-xa Generates code for profiling.
If set at compiler time, the TCOVDIR environment variable speci‐
fies the directory where the coverage (.d) files are located. If
TCOVDIR is not set, then the coverage (.d) files remain in the
same directory as the source files.
Use this option only for backward compatibility with old cover‐
age files. See -xprofile=tcov for information on the new style
of profiling, and the tcov (1) man page, and Profiling Tools for
more details.
Interactions:
The -xprofile=tcov and the -a options are compatible in a single
executable. That is, you can link a program that contains some
files that have been compiled with -xprofile=tcov, and others
that have been compiled with -xa. You cannot compile a single
file with both options.
-xa is incompatible with -g.
Warnings:
If you compile and link in separate steps, and you compile with
-xa, then be sure to link with -xa, or you might get unexpected
results.
-xaddr32[={yes|no}]
(x86/x64 only) The -xaddr32=yes compilation flag restricts the
resulting executable or shared object to a 32-bit address space.
An executable that is compiled in this manner results in the
creation of a process that is restricted to a 32-bit address
space.
When -xaddr32=no is specified a usual 64 bit binary is produced.
If the -xaddr32 option is not specified, -xaddr32=no is assumed.
If only -xaddr32 is specified -xaddr32=yes is assumed.
This option is only applicable to -m64 compilations and only on
Solaris platforms supporting SF1_SUNW_ADDR32 software capabil‐
ity.
Since Linux kernel does not support addres space limitation this
option is not available on Linux. The -xaddr32 option is
ignored on Linux.
When linking, if a single object file was compiled with
-xaddr32=yes the whole output file is assumed to be compiled
with -xaddr32=yes.
A shared object that is restricted to a 32-bit address space
must be loaded by a process that executes within a restricted
32-bit mode address space.
For more information refer to the SF1_SUNW_ADDR32 software capa‐
bilities definition, described in the Linker and Libraries
Guide.
-xalias_level[= n]
Allows the compiler to perform type-based alias-analysis.
Defaults:
n must be any, simple, or compatible.
o -xalias_level
If you do not specify -xalias_level, the compiler sets it to
-xalias_level=any. If you specify -xalias_level without any
values, the compiler sets it to -xalias_level=compatible.
o -xalias_level=any
At this level of analysis, the compiler assumes that any type
may alias any other type. However, despite this assumption,
some optimization is possible.
o -xalias_level=simple
The compiler assumes that fundamental types are not aliased.
Specifically, a storage object with a dynamic type that is one
of the following fundamental types:
* char, signed char, and unsigned char,
* wchar_t
* short int, unsigned short int,
* int, unsigned int,
* long int, unsigned long int,
* long long int, unsigned long long int,
* float, double, long double,
* enumeration types,
* data pointer types,
* function pointer types,
* data member pointer types, or
* function member pointer types
will only be accessed through lvalues of the following types:
* the dynamic type of the object,
* a constant or volatile qualified version
of the dynamic type of the object,
* a type that is the signed or unsigned type
corresponding to the dynamic type of the
object,
* a type that is the signed or unsigned type
corresponding to a constant or volatile
qualified version of the dynamic type of
the object,
* an aggregate or union type that includes
one of the aforementioned types among its
members (including, recursively, a member of
a subaggregate or contained union), or
* a char or unsigned char type.
o -xalias_level=compatible
The compiler assumes that layout-incompatible types are not
aliased. A storage object is only accessed through lvalues of
the following types:
* the dynamic type of the object,
* a constant or volatile qualified version of
the dynamic type of the object,
* a type that is the signed or unsigned type
which corresponds to the dynamic type of
the object,
* a type that is the signed or unsigned type
which corresponds to the constant or volatile
qualified version of the dynamic type of
the object,
* an aggregate or union type that includes one
of the aforementioned types among its members
(including, recursively, a member of a
subaggregate or contained union),
* a type that is (possibly constant or volatile
qualified) base class type of the dynamic
type of the object, or
* a char or unsigned char type.
The compiler assumes that the types of all references are lay‐
out compatible with the dynamic type of the corresponding
storage object. Two types are layout-compatible under the fol‐
lowing conditions:
* If two types are the same type, then they are
layout-compatible types.
* If two types differ only in constant or
volatile qualification, then they are
layout-compatible types.
* For each of the signed integer types, there
exists a corresponding (but different)
unsigned integer type. These corresponding
types are layout compatible.
* Two enumeration types are layout-compatible if
they have the same underlying type.
* Two Plain Old Data (POD) struct types are
layout compatible if they have the same number
of members, and corresponding members
(in order) have layout compatible types.
* Two POD union types are layout compatible
if they have the same number of members, and
corresponding members (in any order) have
layout compatible types.
References may be non-layout-compatible with the dynamic type
of the storage object under limited circumstances:
* If a POD union contains two or more POD
structs that share a common initial sequence,
and if the POD union object currently contains
one of those POD structs, it is permitted to
inspect the common initial part of any of
them. Two POD structs share a common initial
sequence if corresponding members have layout
compatible types and, as applicable to bit
fields, the same widths, for a sequence of
one or more initial members.
* A pointer to a POD struct object, suitably
converted using a reinterpret_cast, points
to its initial member, or if that member is
a bit field, to the unit in which it resides.
Interactions:
The compiler does not perform type-based alias analysis at opti‐
mization level -xO2 and below.
-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 coverage and memory
error detection tools will also work with binaries built with
this option.
Use the -xannotate=no option to prevent the modification of the
binary file by these tools.
The -xannotate=yes option must be used with optimization level
-xO1 or higher to be effective, and it is only effective on sys‐
tems with the new linker support library interface - ld_open().
If the compiler is used on a system without this linker inter‐
face (for example Solaris 9), it silently will revert to -xanno‐
tate=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 condi‐
tions 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 template 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 instantiations are automatically
included in the archive.
See Also:
ar(1)
-xarch= isa
Specifies the target architecture instruction set (ISA).
This option limits the code generated by the compiler to the
instructions of the specified instruction set architecture by
allowing only the specified set of instructions. This option
does not guarantee use of any target-specific instructions.
However, use of this option can affect the portability of a
binary program. See the Notes and Warnings sections at the end
of this entry.
Note: Use the -m64 or -m32 option to specify the intended memory
model, LP64 (64-bits) or ILP32 (32-bits) respectively. The
-xarch flag no longer indicates the memory model, except for
compatibility with previous releases, as indicated below.
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 earlier
releases. Use -m64 to specify 64-bit compilation
instead of -xarch=generic64
native Compile for good performance on this system
The compiler chooses the appropriate setting for the
current system processor it is running on.
native64 Compile for good performance on this system (Solaris
only)
This option is equivalent to
-m64 -xarch=native and is provided for compatibility
with earlier releases.
Values on SPARC platforms:
sparc Compile for the SPARC-V9 ISA.
Compile for the V9 ISA, but without the Visual
Instruction Set (VIS), and without other implementa‐
tion-specific ISA extensions. This option enables the
compiler to generate code for good performance on the
V9 ISA.
sparcvis Compile for the SPARC-V9 ISA plus VIS.
Compile for SPARC-V9 plus the Visual Instruction Set
(VIS) version 1.0, and with UltraSPARC extensions.
This option enables the compiler to generate code for
good performance on the UltraSPARC architecture.
sparcvis2 Compile for the SPARC-V9 ISA with UltraSPARC III
extensions.
Enables the compiler to generate object code for the
UltraSPARC architecture, plus the Visual Instruction
Set (VIS) version 2.0, and with UltraSPARC III exten‐
sions.
sparcfmaf Compile for the sparcfmaf version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the
SPARC-V9 instruction set, plus the UltraSPARC exten‐
sions, including the Visual Instruction Set (VIS) ver‐
sion 1.0, the UltraSPARC-III extensions, including the
Visual Instruction Set (VIS) version 2.0, and the
SPARC64 VI extensions for floating-point multiply-add.
Note that you must use -xarch=sparcfmaf in conjunction
with -fma=fused and some optimization level to get the
compiler to attempt to find opportunities to use the
multiply-add instructions automatically.
sparcima Compile for the sparcima version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the
SPARC-V9 instruction set, plus the UltraSPARC exten‐
sions, including the Visual Instruction Set (VIS) ver‐
sion 1.0, the UltraSPARC-III extensions, including the
Visual Instruction Set (VIS) version 2.0, the SPARC64
VI extensions for floating-point multiply-add, and the
SPARC64 VII extensions for integer multiply-add.
v9 Is equivalent to -m64 -xarch=sparc
Legacy makefiles and scripts that use -xarch=v9 to
obtain the 64-bit memory model need only use -m64.
v9a Is equivalent to -m64 -xarch=sparcvis and is provided
for compatibility with earlier releases.
v9b Is equivalent to -m64 -xarch=sparcvis2 and is pro‐
vided for compatibility with earlier releases.
Notes:
o Legacy 32-bit SPARC instruction set architectures V7 and V8
imply -m32 and cannot be combined with -m64.
o Object binary files (.o) compiled with sparc and sparcvis can
be linked and can execute together, but only on a sparcvis
compatible platform.
o Object binary files (.o) compiled with sparc, sparcvis, and
sparcvis2 can be linked and can execute together, but only on
a sparcvis2 compatible platform.
For any particular choice, the generated executable could run
much more slowly on earlier architectures. Also, although
quad-precision floating-point instructions are available in
many of these instruction set architectures, the compiler does
not use these instructions in the code it generates.
Values specific for x86 platforms:
Value Meaning
pentium_pro
Limits the instruction set to pentium_pro architec‐
ture.
sse Adds the SSE instruction set to the pentium_pro
instruction set.
sse2 Supplements the pentium_pro and SSE instruction sets
with the SSE2 instruction set.
sse3 Supplements the pentium_pro, SSE, and SSE2 instruction
sets with the SSE3 instruction set.
ssse3 Supplements the pentium_pro, SSE, SSE2, and SSE3
instruction sets with the SSSE3 instruction set.
sse4_1 Supplements the pentium_pro, SSE, SSE2, SSE3, and
SSSE3 instruction sets with the SSE4.1 instruction
set.
sse4_2 Supplements the pentium_pro, SSE, SSE2, SSE3, SSSE3,
and SSE4.1 instruction sets with the SSE4.2 instruc‐
tion set.
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://devel‐
oper.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=sparcvis -xcache=64/32/4:8192/128/2 -xchip=ultra4
In the following command
example% CC -xtarget=ultra4 -xarch=sparcvis2 ...
example% CC -xtarget=ultra4 -xarch=sparcvis2 ...
-xarch=sparcvis2 overrides the -xarch setting in the expansion
of -xtarget=ultra2.
Warnings:
If this option is used with optimization, the appropriate
choice can provide good performance of the executable on the
specified architecture. An inappropriate choice, however,
might result in serious degradation of performance or in in a
binary program that is not executable on all intended target
platforms.
-xautopar
Turns on automatic parallelization for multiple processors. Does
dependence analysis (analyze loops for inter- iteration data
dependence) and loop restructuring. If optimization is not at
-xO3 or higher, optimization is raised to -xO3 and a warning is
emitted.
Note that -xautopar does not accept OpenMP parallelization
directives.
Avoid -xautopar if you do your own thread management.
To get faster execution, this option requires a multiple proces‐
sor system. On a single-processor system, the resulting binary
usually runs slower.
To run a parallelized program in a multithreaded environment,
you must set the OMP_NUM_THREADS environment 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.c b.c
example% cc -o myprog -xbinopt=prepare a.o
If some source code is not available for compilation, this
option may still be used to compile the remainder of the code.
It should then be used in the link step that creates the final
binary. In such a situation, only the code compiled with this
option can be optimized, transformed or analyzed.
Compiling with -xbinopt=prepare and -g increases the size of the
executable by including debugging information. The default is
-xbinopt=off.
-xbuiltin[={%all|%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 compiler. However, some
of those functions can be recognized 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 explanation 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 rec‐
ognized functions varies with the version 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 specified, the compiler
assumes -xbuiltin=%all.
-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 particular cache prop‐
erty is used.
Although this option can be used alone, it is part of the expan‐
sion of the -xtarget option; its primary use is to override a
value supplied by the -xtarget option.
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 kilobytes
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, s1l1a1.
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 com‐
piler to use cache properties for good perfor‐
mance on most SPARC processors, without major
performance degradation on any of them.
native Set the parameters for the best performance on
the host environment.
s1/l1/a1 Defines level 1 cache properties.
s1/l1/a1:s2/l2/a2
Defines levels 1 and 2 cache properties.
s1/l1/a1:s2/l2/a2:s3/l3/a3
Defines levels 1, 2, and 3 cache properties.
Example:
-xcache=16/32/4:1024/32/1 specifies the following:
Level 1 cache has: Level 2 cache has:
16K bytes 1024K bytes
32-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 architec‐
ture. Compiling with this option generates code that runs slower
on current SPARC platforms.
-xchar=o
The option is provided solely for the purpose of easing the
migration of code from systems where the char type is defined as
unsigned. Unless you are migrating from such a system, do not
use this option. Only code that relies on the sign of a char
type needs to be rewritten to explicitly specify signed or
unsigned.
Values:
You can substitute one of the following values for o:
o signed: Treat character constants and variables declared as
char as signed. This impacts the behavior of compiled code, it
does not affect the behavior of library routines.
o s: equivalent to signed.
o unsigned: Treat character constants and variables declared as
char as unsigned. This impacts the behavior of compiled code,
it does not affect the
behavior of library routines.
o u: equivalent to unsigned.
Defaults:
If you do not specify -xchar, the compiler assumes -xchar=s. If
you specify -xchar, but do not specify a value, the compiler
assumes -xchar=s.
Interactions:
The -xchar option changes the range of values for the type char
only for code compiled with -xchar. This option does not change
the range of values for type char in any system routine or
header file. In particular, the value of CHAR_MAX and CHAR_MIN,
as defined by limits.h, do not change when this option is speci‐
fied. Therefore, CHAR_MAX and CHAR_MIN no longer represent the
range of values encodable in a plain char.
Warnings:
If you use -xchar, be particularly careful when you compare a
char against a predefined system macro because the value in the
macro may be signed. This is most common for any routine that
returns an error code which is accessed through a macro. Error
codes are typically negative values so when you compare a char
against the value from such a macro, the result is always false.
A negative number can never be equal to any value of an unsigned
type.
It is strongly recommended that you never use -xchar to compile
routines for any interface exported through a library. The
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]
(SPARC Platform) Enables a runtime check for stack overflow.
Values:
n must be one of the following values.
Value Meaning
%all Perform all checks.
%none Does not perform any checks.
stkovf Perform a runtime check for stack overflow of the
main thread in a singly-threaded program as well
as slave-thread stacks in a multithreaded pro‐
gram. If a stack overflow is detected, a SIGSEGV
is generated. If your application needs to handle
a SIGSEGV caused by a stack overflow differently
than it handles other address-space violations,
see sigaltstack(2).
no%stkovf Turns off stack-overflow checking.
Interactions:
If you specify -xcheck without any arguments, the compiler
defaults to -xcheck=%none.
-xchip=c
Specifies the target processor for use by the optimizer.
Although this option can be used alone, it is part of the expan‐
sion of the -xtarget option; its primary use is to override a
value supplied by the -xtarget option.
This option specifies timing properties by specifying the target
processor.
This option affects:
o The ordering of instructions, that is, scheduling
o The way the compiler uses branches
o The instructions to use in cases where semantically equivalent
alternatives are available
The -xchip values for SPARC platforms are:
Value Meaning
generic Uses timing properties for good performance on most
SPARC processors.
This is the default value that directs the compiler to
use the best timing properties for good performance on
most SPARC processors, without major performance
degradation on any of them.
native Set the parameters for the best performance on the
host environment.
sparc64vi Optimize for the SPARC64 VI processor.
sparc64vii
Optimize for the SPARC64 VII processor.
super Optimize for the SuperSPARC processor.
super2 Optimize for the SuperSPARC II processor.
micro Optimize for the MicroSPARC(TM) processor.
micro2 Optimize for the MicroSPARC II processor.
hyper Optimize for the HyperSPARC(TM) processor.
hyper2 Optimize for the HyperSPARC II processor.
ultra Optimize for the UltraSPARC(TM) processor.
ultra2 Optimize for the UltraSPARC II processor.
ultra2e Optimize for the UltraSPARC IIe processor.
ultra2i Optimize for the UltraSPARC IIi processor.
ultra3 Optimize for the UltraSPARC III processor.
ultra3cu Optimize for the UltraSPARC IIIcu processor.
ultra3i Optimize for the UltraSPARC IIIi processor.
ultra4 Optimize for the UltraSPARC IV processor.
ultra4plus
Optimize for the UltraSPARC IVplus processor.
ultraT1 Optimize for the UltraSPARC T1 processor.
ultraT2 Optimize for the UltraSPARC T2 processor.
ultraT2plus
Optimize for the UltraSPARC T2+ processor.
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 lim‐
ited to 2**32 bytes. This is the default on 32-bit
architectures.
abs44 SPARC: Generate 44-bit absolute addresses, which have
moderate speed and moderate range. Code + data + bss
size is limited to 2**44 bytes. This is the default
on 64-bit architectures. Do not use this value with
dynamic (shared) libraries.
abs64 SPARC: Generate 64-bit absolute addresses, which are
slow, but have full range. Available only on 64-bit
architectures.
pic13 Generates position-independent code (small model),
which is fast, but has limited range. Equivalent to
-Kpic. Permits references to at most 2**11 unique
external symbols on 32-bit architectures, 2**10 on
64-bit architectures.
pic32 Generates position-independent code (large model),
which is slow, but has full range. Equivalent to
-KPIC. Permits references to at most 2**30 unique
external symbols on 32-bit architectures, 2**29 on
64-bit architectures.
To determine whether to use -xcode=pic13 or -xcode=pic32, check
the size of the Global Offset Table (GOT) by using elfdump -c
(see the elfdump(1) man page for more information) and for the
section header, sh_name: .got. The sh_size value is the size of
the GOT. If the GOT is less than 8,192 bytes, specify
-xcode=pic13, otherwise specify -xcode=pic32.
In general, use the following guidelines to determine how you
should use -xcode:
o If you are building an executable you should not use
-xcode=pic13 or -xcode=pic32.
o If you are building an archive library only for linking into
executables you should not use -xcode=pic13 or -xcode=pic32.
o If you are building a shared library, start with -xcode=pic13
and once the GOT size exceed 8,192 bytes, use -xcode=pic32.
o If you are building an archive library for linking into
shared libraries you should just use -xcode=pic32.
Defaults:
The default is -xcode=abs32 for 32-bit architectures.
The default is -xcode=abs44 for 64-bit processors.
Warnings:
When you compile and link in separate steps, you must use the
same -xarch option in the compile step and the link step.
-xcrossfile[=n]
Oboslete - do not use. Use -xipo instead.
-xdebugformat=[stabs|dwarf]
The C++ compiler is migrating the format of debugger information
from the stabs format to the dwarf format. The default setting
for this release is -xdebugformat=stabs.
If you maintain software which reads debugging information, you
now have the option to transition your tools from the stabs for‐
mat to the dwarf format.
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.
-xdebugformat=dwarf generates debugging information using the
dwarf standard format.
If you do not specify -xdebugformat, the compiler assumes -xde‐
bugformat=stabs. This option requires an argument.
This option affects the format of the data that is recorded with
the -g option. Some small amount of debugging information is
recorded even without -g, and the format of that information is
also controlled with this option. So -xdebugformat has a an
effect even when -g is not used.
The dbx and Performance Analyzer software understand both stabs
and dwarf format so using this option does not have any effect
on the functionality of either tool.
This is a transitional interface so expect it to change in
incompatible ways from release to release, even in a minor
release.
The details of any specific fields or values in either stabs or
dwarf are also evolving.
See also the dumpstabs(1) and dwarfdump(1) man pages for more
information.
-xdepend[=[yes|no] ]
Analyzes loops for inter-iteration data dependencies and per‐
forms loop restructuring. Loop restructuring includes loop
interchange, loop fusion, scalar replacement, and elimination of
"dead" array assignments.
On SPARC, -xdepend is turned on for all optimization levels -xO3
and above, and is off for lower opt levels. Also, an explicit
setting of -xdepend overrides any implicit setting.
On x86, if optimization is not at -xO3 or higher, the compiler
raises the optimization to -xO3 and issues a warning.
If you do not specify -xdepend, the default is -xdepend=no which
means the compiler does not analyze loops for data dependencies.
If you specify -xdepend but do not specify an argument, the com‐
piler sets the option to -xdepend=yes which means the compiler
analyzes loops for data dependencies.
Dependency analysis is included in -xautopar. The dependency
analysis is done at compile time.
Dependency analysis may help on single-processor systems. How‐
ever, if you try -xdepend on single-processor systems, you
should not use -xautopar. If you do so, the -xdepend optimiza‐
tion is done for multiple-processor systems.
See Also: -xprefetch_auto_type
-xdumpmacros[=value[,value...]]
Use this option when you want to see how macros are behaving in
your program. This option provides information such as macro
defines, undefines, and instances of usage. It prints output to
the standard error (stderr), based on the order macros are pro‐
cessed. The -xdumpmacros option is in effect until the end of
the file or until it is overridden by the dumpmacros or
end_dumpmacros pragma.
Values:
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 num‐
ber) also for defs, undefs, and use
[no%]conds [Do not] Print use information for macros used in
conditional directives
[no%]sys [Do not] Print all macros defines, undefines, and
use information for macros in system header files
%all Sets the option to -xdump‐
macros=defs,undefs,use,loc,conds,sys. A good way
to use this argument is in conjunction with the
[no%] form of the other arguments. For example,
-xdumpmacros=%all,no%sys would exclude system
header macros from the output but still provide
information for all other macros.
%none Do not print any macro information
The option values accumulate so specifying -xdumpmacros=sys
-xdumpmacros=undefs has the same effect as -xdump‐
macros=undefs,sys.
Note: The sub-options loc, conds, and sys are qualifiers for
defs, undefs and use options. By themselves, loc, conds, and sys
have no effect. For example, -xdumpmacros=loc,conds,sys has no
effect.
Defaults:
If you specify -xdumpmacros without any arguments, it means
-xdumpmacros=defs,undefs,sys. If you do not specify -xdump‐
macros,
it defaults to -xdumpmacros=%none.
-xe Check only for syntax and semantic errors. When you specify -xe
the compiler does not produce any object code. The output for
-xe is directed to stderr.
Use the -xe option if you do not need the object files produced
by compilation. For example, if you are trying to isolate the
cause of an error message by deleting sections of code, you can
speed the edit and compile cycle by using -xe.
-xF[=v]
The -xF option enables the optimal reordering of functions and
variables by the linker.
This option instructs the compiler to place functions and/or
data variables into separate section fragments, which enables
the linker, using directions in a mapfile specified by the
linker's -M option, to reorder these sections to optimize pro‐
gram performance. Generally, this optimization is only effective
when page fault time constitutes a significant fraction of pro‐
gram run time.
Reordering functions and variables for optimal performance
requires the following operations:
1. Compiling and linking with -xF.
2. Following the instructions in the Performance Analyzer manual
regarding how to generate a mapfile for functions or following
the instructions in the Linker and Libraries Guide regarding how
to generate a mapfile for data.
3. Relinking with the new mapfile by using the linker's -M
option.
4. Re-executing under the Analyzer to verify improvement.
Values:
v can be one of the following values:
Value Meaning
[no%]func [Do not] fragment functions into separate sec‐
tions.
[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 optimiza‐
tions, so you should only use this flag when it is experimen‐
tally justified.
See Also:
analyzer(1), debugger(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 vari‐
able, 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 structure members (in conjunction with
symbolic information produced with -g) to which they refer. It
associates profile data with the data space of the target,
rather than the instruction space, and provides insight into
behavior that is not easily obtained from only instruction pro‐
filing.
You can compile a specified set of object files with -xhwcprof
however, -xhwcprof is most useful when applied to all object
files in the application. This will provide coverage to identify
and correlate all memory references distributed in the applica‐
tion's object files.
If you are compiling and linking in separate steps, use
-xhwcprof at link time as well. Future extensions to -xhwcprof
may require its use at link time. 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.
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 Sun Studio compilers.
The combination of -xhwcprof and -g increases compiler temporary
file storage requirements by more than the sum of the increases
due to -xhwcprof and -g specified alone.
The following command compiles example.cc and specifies support
for hardware counter profiling and symbolic analysis of data
types and structure members using DWARF symbols:
example% CC-c -O -xhwcprof -g example.cc
For more information on hardware counter-based profiling, see
the Performance Analyzer manual.
-xia Link the appropriate interval arithmetic libraries and set a
suitable floating-point environment.
The -xia option is a macro that expands to
-fsimple=0 -ftrap=%none -fns=no -library=interval.
Interactions:
To use the interval arithmetic libraries, include <suninter‐
val.h>.
When you use the interval arithmetic libraries, you must include
one of the following libraries: libC, Cstd, or iostreams. See
-library for information on including these libraries.
Warnings:
If you use intervals and you specify different values for -fsim‐
ple, -ftrap, or -fns, then your program may have incorrect
behavior.
C++ interval arithmetic is experimental and evolving. The
specifics may change from release to release.
On x86 platforms, -xarch=sse2 must be specified for 32-bit com‐
pilations. Also, -xia is not available on Linux platforms.
See also:
-library
C++ Interval Arithmetic Programming Reference,
Interval Arithmetic Solves Nonlinear Problems While Providing
Guaranteed Results (http://www.sun.com/software/sundev/news/fea‐
tures/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 optimization
level -xO4 or higher. This argument tells
the optimizer that it can inline functions
of its choosing. Note that without the %auto
specification, automatic inlining is nor‐
mally turned off when explicit inlining is
specified on the command line by -xin‐
line=[no%]func_name...
func_name Strongly request that the optimizer inline
the function. If the function is not
declared as extern "C", the value of
func_name must be mangled. You can use the
nm command on the executable file to find
mangled function names. For functions
declared as extern "C", the names are not
mangled by the compiler.
no%func_name When you prefix the name of a routine on the
list with no%, the inlining of that routine
is inhibited. The rule about mangled names
for func_name applies to no%func_name as
well.
Only routines in the file being compiled are considered for
inlining unless you use -xipo[=1|2]. The optimizer decides which
of these routines are appropriate for inlining.
Defaults:
If the -xinline option is not specified, the compiler assumes
-xinline=%auto. If -xinline= is specified with no arguments, no
functions are inlined regardless of the optimization level.
Examples:
To enable automatic inlining while disabling inlining of the
function declared int foo(), use
example% CC-xO5 -xinline=%auto,no%__1cDfoo6F_i_ -c a.cc
To strongly request the inlining of the function declared as int
foo(), and to make all other functions as the candidates for
inlining, use:
example% CC-xO5 -xinline=%auto, __1cDfoo6F_i_ -c a.cc
To strongly request the inlining of the function declared as int
foo(), and to not allow inlining of any other functions use:
example% CC-xO5 -xinline=__1cDfoo6F_i_ -c a.cc
Interactions:
The -xinline option has no effect for optimization levels below
-xO3. At -xO4 and higher, the optimizer decides which functions
should be inlined, and does so without the -xinline option being
specified. At -xO4 or higher, the compiler also attempts to
determine which functions will improve performance if inlined.
A routine is inlined if any of the following conditions apply.
o Optimization is set at -xO3 or higher
o Inlining is judged to be profitable and safe
o The function is in the file being compiled, or the
function is in a file that was compiled with
-xipo[=1|2].
Warnings:
If you force the inlining of a function with -xinline,
you might actually diminish performance.
See Also:
-xldscope
-xinstrument=[no%]datarace]
Specify this option to compile and instrument your program for
analysis by the Thread Analyzer. For more information on the
Thread Analyzer, see tha(1) for details.
You can then use the Performance Analyzet to run the instru‐
mented program with collect -r races to create a data-race-
detection experiment. You can run the instrumented code stand‐
alone but it runs more slowly.
Values
Value Meaning
instrument Prepare the code for analysis by the Thread Ana‐
lyzer 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) rou‐
tines.
This option also sets -g0.
Warnings
It is illegal to specify -xinstrument without an argument.
-xipo[={0|1|2}]
Performs interprocedural optimizations.
The -xipo option performs partial-program optimizations by
invoking an interprocedural analysis pass. It performs opti‐
mizations across all object files in the link step, and the
optimizations are not limited to just the source files on the
compile command. However, whole-program optimizations performed
with -xipo do not include assembly (.s) source files.
The -xipo option is particularly useful when compiling and link‐
ing large multifile applications. Object files compiled with
this flag have analysis information compiled within them that
enables interprocedural analysis across source and precompiled
program files. However, analysis and optimization is limited to
the object files compiled with -xipo, and does not extend to
object files or libraries.
Values:
Value Meaning
0 Do not perform interprocedural optimizations.
1 Perform interprocedural optimizations.
2 Perform interprocedural aliasing analysis as well
as optimization of memory allocation and layout
to improve cache performance.
Defaults:
If -xipo is not specified, -xipo=0 is assumed.
If only -xipo is specified, -xipo=1 is assumed.
Examples:
The following example compiles and links in the same step.
example% CC-xipo -xO4 -o prog part1.cc part2.cc part3.cc
The optimizer performs crossfile inlining across all three
source files. This is done in the final link step, so the com‐
pilation of the source files need not all take place in a single
compilation and could be over a number of separate compilations,
each specifying the -xipo option.
The following example compiles and links in separate steps.
example% CC-xipo -xO4 -c part1.cc part2.cc
example% CC-xipo -xO4 -c part3.cc
example% CC-xipo -xO4 -o prog part1.o part2.o part3.o
The object files created in the compile steps have additional
analysis information compiled within them to permit crossfile
optimizations to take place at the link step.
Interactions:
The -xipo option requires at least optimization level -xO4. 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 partici‐
pate in crossfile interprocedural analysis, even when they are
compiled with -xipo as shown in this example:
example% CC-xipo -xO4 one.cc two.cc three.cc
example% CC-xar -o mylib.a one.o two.o three.o
example% CC-xipo -xO4 -o myprog main.cc four.cc mylib.a
In this example, interprocedural optimizations will be performed
between one.cc, two.cc, and three.cc, and between main.cc and
four.cc, but not between main.cc or four.cc and the routines in
mylib.a. The first compilation may generate warnings about unde‐
fined symbols, but the interprocedural optimizations will be
performed because it is a compile and link step.
The -xipo option generates significantly larger object files due
to the additional information needed to perform optimizations
across the files. However, this additional information does not
become part of the final executable binary file. Any increase in
the size of the executable program will be due to the additional
optimizations performed.
When Not To Use -xipo=2 Interprocedural Analysis
The compiler tries to perform whole-program analysis and opti‐
mizations as it works with the set of object files in the link
step. The compiler makes the following two assumptions for any
function (or subroutine) foo() defined in this set of object
files:
(1) foo() is not called explicitly by another routine that is
defined outside this set of object files at runtime.
(2) The calls to foo() from any routine in the set of object
files are not interposed upon by a different version of foo()
defined outside this set of object files.
Do not compile with -xipo=2 if assumption (1) is not true for
the given application.
Do not compile with either -xipo=1 or -xipo=2 if assumption (2)
is not true.
As an example, consider interposing on the function malloc()
with your own version and compiling with -xipo=2. Consequently,
all the functions in any library that reference malloc() that
are linked with your code have to be compiled with -xipo=2 also
and their object files need to participate in the link step.
Since this might not be possible for system libraries, do not
compile your version of malloc() with -xipo=2.
As another example, suppose that you build a shared library with
two external calls, foo() and bar() inside two different source
files. Furthermore, suppose that bar() calls foo(). If there is
a possibility that foo() could be interposed at runtime, then do
not compile the source file for foo() or for bar() with -xipo=1
or -xipo=2. Otherwise, foo() could be inlined into bar(), which
could cause incorrect results.
-xipo_archive[=a]
The -xipo_archive option enables the compiler to optimize object
files that are passed to the linker with object files that were
compiled with -xipo and that reside in the archive library (.a)
before producing an executable. Any object files contained in
the library that were optimized during the compilation are
replaced with their optimized version.
a is one of the following:
writeback
The compiler optimizes object files passed to the linker with
object files compiled with -xipo that reside in the archive
library (.a) before producing an executable. Any object files
contained in the library that were optimized during the compi‐
lation are replaced with an optimized version.
For parallel links that use a common set of archive
libraries,each link should create its own copy of archive
libraries to be optimized before linking.
readonly
The compiler optimizes object files passed to the linker with
object files compiled with -xipo that reside in the archive
library (.a) before producing an executable.
The option -xipo_archive=readonly enables cross-module inlining
and interprocedural data flow analysis of object files in an
archive library specified at link time. However, it does not
enable cross-module optimization of the archive library's code
except for code that has been inserted into other modules by
cross module inlining.
To apply cross-module optimization to code within an archive
library, -xipo_archive=writeback is required. Note that doing
so modifies the contents of the archive library from which the
code was extracted.
none
Default. There is no processing of archive files. The compiler
does not apply cross-module inlining or other cross-module
optimizations to object files compiled using -xipo and
extracted from an archive library at link time. To do that,
both -xipo and either -xipo_archive=readonly or -xipo_ar‐
chive=writeback must be specified at link time.
It is illegal to specify -xipo_archive without a flag.
-xjobs=n
Compile with multiple processors.
Specify the -xjobs option to set how many processes the compiler
creates to complete its work. This option can reduce the build
time on a multi-cpu machine. Currently, -xjobs works only with
the -xipo option. When you specify -xjobs=n, the interprocedural
optimizer uses n as the maximum number of code generator
instances it can invoke to compile different files.
Generally, a safe value for n is 1.5 multiplied by the number of
available processors. Using a value that is many times the num‐
ber of available processors can degrade performance because of
context switching overheads among spawned jobs. Also, using a
very high number can exhaust the limits of system resources such
as swap space.
You must always specify -xjobs with a value. Otherwise an error
diagnostic is issued and compilation aborts.
Multiple instances of -xjobs on the command line override each
other until the rightmost instance is reached.
The following example compiles more quickly on a system with two
processors than the same command without the -xjobs option.
example% CC-xipo -xO4 -xjobs=3 t1.cc t2.cc t3.cc
-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 Libraries, use the -library=sunperf
instead.
Warnings:
Do not use -xnolib with -xlang.
If you are mixing parallel Fortran objects with C++ objects, the
link line must specify the -mt flag.
See also:
-library, -staticlib"
-xldscope={v}
Changes the default linker scoping for the definition of extern
symbols. Changing the default can result in faster and safer
shared libraries because the implementation will be better hid‐
den.
Values
v must be one of the following:
Value Meaning
global Symbol definitions have global linker scoping
which is the least restrictive linker scoping.
All references to the symbol bind to the defini‐
tion in the first dynamic load module that
defines the symbol. This linker scoping is the
current linker scoping for extern symbols.
symbolic Symbol definitions have symbolic linker scoping
which is more restrictive than global linker
scoping. All references to the symbol from within
the dynamic load module being linked bind to the
symbol defined within the module. Outside of the
module, the symbol appears as though it is
global. This linker scoping corresponds to the
linker option -Bsymbolic. Although you cannot use
-Bsymbolic with C++ libraries, you can use the
-xldscope=symbolic option without causing prob‐
lems.
hidden Hidden linker scoping is more restrictive than
symbolic and global linker scoping. All refer‐
ences within a dynamic load module will bind to a
definition within that module. The symbol will
not be visible outside of the module.
Defaults
If you do not specify -xldscope, the compiler assumes -xld‐
scope=global. If you specify -xldscope without any values, the
compiler issues an error. Multiple instances of this option on
the command line override each other until the rightmost
instance is reached.
Warnings
If you intend to allow a client to override a function in a
library, you must be sure that the function is not generated
inline during the library build. The compiler inlines a function
if you specify the function name with -xinline, if you compile
at -xO4 or higher in which case inlining can happen automati‐
cally, if you use the inline specifier, or if you are using
cross-file optimization.
For example, suppose library ABC has a default allocator func‐
tion that can be used by library clients, and is also used
internally in the library:
void* ABC_allocator(size_t size) { return malloc(size); }
If you build the library at -xO4 or higher, the compiler inlines
calls to ABC_allocator that occur in library components. If a
library client wants to replace ABC_allocator with a customized
version, the replacement will not occur in library components
that called ABC_allocator. The final program will include dif‐
ferent versions of the function.
Library functions declared with the __hidden or __symbolic spec‐
ifiers can be generated inline when building the library. They
are not supposed to be overridden by clients. For more informa‐
tion, see chapter 4 "Language Extensions" of the C++ User's
Guide.
Library functions declared with the __global specifier, should
not be declared inline, and should be protected from inlining by
use of the -xinline compiler option.
See Also
-xinline, -xO, -xcrossfile, ld(1).
-xlibmieee
Causes libm to return IEEE 754 values for math routines in
exceptional cases. The default behavior of libm is XPG-compli‐
ant.
-xlibmil
Inlines selected library routines for optimization.
There are inline templates for some of the libm library rou‐
tines. This option selects those inline templates that produce
the fastest executables for the floating-point option and plat‐
form currently being used.
Note — This option does not affect C++ inline functions.
-xlibmopt
Uses a library of optimized math routines. You must use default
rounding mode by specifying -fround=nearest when you use this
option.
This option uses a math routine library optimized for perfor‐
mance, and usually generates faster code. The results may be
slightly different from those produced by the normal math
library. If so, they usually differ in the last bit.
The order on the command line for this library option is not
significant.
Interactions:
This option is implied by the -fast option.
See also:
-fast
-xnolibmopt
-xlic_lib=sunperf
Deprecated, do not use. Specify -library=sunperf instead.
-xlicinfo
This option is silently ignored by the compiler.
-xlinkopt[=level]
(SPARC) Perform link-time optimizations on relocatable object
files.
The link optimizer performs a number of advanced performance
optimizations on the binary object code at link-time. The value
level sets the level of optimizations performed, and must be 0,
1, or 2.
The optimization levels are:
0 The link optimizer is disabled. (This is the default.)
1 Perform optimizations based on control flow analysis,
including instruction cache coloring and branch opti‐
mizations, at link time.
2 Perform additional data flow analysis, including dead-
code elimination and address computation simplifica‐
tion, at link time.
Specifying -xlinkopt without a level parameter implies
-xlinkopt=1.
These optimizations are performed at link time by analyzing the
object binary code. The object files are not rewritten but the
resulting executable code may differ from the original object
codes.
This option is most effective when used to compile the whole
program, and with profile feedback.
When compiling in separate steps, -xlinkopt must appear on both
compile and link steps:
example% CC-c -xlinkopt a.cc b.cc
example% CC-o myprog -xlinkopt=2 a.o b.o
Note that the level parameter is only used when the compiler is
linking. In the example above, the link optimizer level is 2
even though the object binaries were compiled with an implied
level of 1.
Do not use the -zcombreloc linker option when you compile with
-xlinkopt.
You must use -xlinkopt on at least some of the compilation com‐
mands for -xlinkopt to be useful at link time. The optimizer can
still perform some limited optimizations on object binaries not
compiled with -xlinkopt.
-xlinkopt will optimize code coming from static libraries that
appear on the compiler command line, but it will skip and not
optimize code coming from shared (dynamic) libraries that appear
on the command line. You can also use -xlinkopt when building
shared libraries (compiling with -G ).
The link optimizer is most effective when used with run-time
profile feedback. Profiling reveals the most and least used
parts of the code and directs the optimizer to focus its effort
accordingly. This is particularly important with large applica‐
tions where optimal placement of code performed at link time can
reduce instruction cache misses. Typically, this would be com‐
piled as follows:
example% CC-o progt -xO5 -xprofile=collect:profdir file.cc
example% progt
example% CC-o prog -xO5 -xprofile=use:profdir -xlinkopt file.cc
For details on using profile feedback, see -xprofile
Note that compiling with this option increases link time
slightly. Object file sizes also increase, but the size of the
executable remains the same. Compiling with -xlinkopt and -g
increases the size of the executable by including debugging
information.
-xloopinfo
Shows which loops are parallelized and which are not. This
option is normally for use with the -xautopar and -xexplicitpar
options.
-xM Runs only the preprocessor on the named C++ programs, requesting
that it generate makefile dependencies and send the result to
the standard output (see make (1) for details about makefiles
and dependencies).
However, -xM only reports dependencies of the included headers
and not the associated template definition files. You can use
the .KEEP_STATE feature in your makefile to generate all the
dependencies in the .make.state file that is created by make.
See make(1) for details about makefiles and dependencies.
-xM1 This option is the same as -xM, except that this option does not
report dependencies for the /usr/include header files and it
does not report dependencies for compiler-supplied header files.
-xMD Generates makefile dependencies like -xM but includes compila‐
tion. -xMD generates an output file for the makefile-dependency
information based on the input filename but with the addition of
a .d suffix. If you specify -xMD and -xMF, the preprocessor
appends all makefile dependency information to the file speci‐
fied with -xMF.
-xMF filename
Use this option to specify a file for the makefile-dependency
output. There is no way to specify individual filenames for mul‐
tiple input files with -xMF on one command line.
-xMMD Use this option to generate makefile dependencies excluding sys‐
tem header files. This is the same functionality as -xM1, but
includes compilation.-xMMD generates an output file for the
makefile-dependency information based on the input filename but
with the addition of .d suffix. If you specify -xMF, the com‐
piler uses the filename you provide instead.
-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 speci‐
fied. v must be one of the following: off, 1, 2, 3, 4, or 5.
The default value is -xmaxopt=off which causes pragma opt to be
ignored. If you specify -xmaxopt without supplying an argument,
that is the equivalent of specifying -xmaxopt=5.
-xmemalign[=ab]
(SPARC) Use the -xmemalign option to control the assumptions the
compiler makes about the alignment of data. By controlling the
code generated for potentially misaligned memory accesses and by
controlling program behavior in the event of a misaligned
access, you can more easily port your code to SPARC.
Specify the maximum assumed memory alignment and behavior of
misaligned data accesses. There must be a value for both a
(alignment) and b (behavior). a specifies the maximum assumed
memory alignment and b specifies the behavior for misaligned
memory accesses.
For memory accesses where the alignment is determinable at com‐
pile time, the compiler generates the appropriate load/store
instruction sequence for that alignment of data.
For memory accesses where the alignment cannot be determined at
compile time, the compiler must assume an alignment to generate
the needed load/store sequence.
If actual data alignment at runtime is less than the specified
alignment, the misaligned access attempt (a memory read or
write) generates a trap. The two possible responses to the trap
are as follows:
o The OS converts the trap to a SIGBUS signal. If the program
does not catch the signal, the program aborts. Even if the pro‐
gram catches the signal, the misaligned access attempt will not
have succeeded.
o The OS handles the trap by interpreting the misaligned access
and returning control to the program as if the access had suc‐
ceeded normally.
Values:
Accepted values for a are:
1 Assume at most 1 byte alignment.
2 Assume at most 2 byte alignment.
4 Assume at most 4 byte alignment.
8 Assume at most 8 byte alignment.
16 Assume at most 16 byte alignment.
Accepted values for b are:
i Interpret access and continue execution.
s Raise signal SIGBUS.
f For variants of -xarch=v9 only. Raise signal SIG‐
BUS for alignments less than or equal to 4, other‐
wise 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 compiler 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 compiling with -m64.
This option is not cumulative so the compiler sets the model
value according to the rightmost instance of -xmodel on the com‐
mand-line.
If you do not specify -xmodel, the compiler assumes
-xmodel=small. Specifying -xmodel without an argument is an
error.
It is not necessary to compile all translation units with this
option. You can compile select files as long as you ensure the
object you are accessing is within reach.
Be aware that not all Linux system support the medium model.
-xnolib
Disables linking with default system libraries.
Normally (without this option), the C++ compiler links with sev‐
eral system support libraries to support C++ programs. With this
option, the -llib options to link the default system support
libraries are not passed to ld.
Normally, the compiler links with the system support libraries
in the following order:
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 out‐
put 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 inter‐
face, 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 application with
the generic instruction set, use:
o Standard mode:
example% CC-xnolib test.cc -lCstd -lCrun -Bstatic -lm -Bdy‐
namic -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 sys‐
tem support libraries in the given order. You must link the sys‐
tem support libraries last.
If -xnolib is specified, -library is ignored.
Warnings:
Many C++ language features require the use of libC (compatibil‐
ity 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 opti‐
mized math library.
-xnolibmopt
Does not use the math routine library by turning off any previ‐
ously 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 optimiza‐
tion at -xO5. All other options that imply an optimization level
give a warning message that optimization has been set. The only
way to compile without any optimization is to delete all options
from the command line or makefile that specify an optimization
level.
Generally, the higher the level of optimization with which a
program is compiled, the better the runtime performance. How‐
ever, higher optimization levels may result in increased compi‐
lation time and larger executable files.
There are five levels that you can use with -xOn. The following
sections describe each level for SPARC platforms and for x86
platforms. The actual optimizations performed by the compiler
at each level may change with each compiler release.
If the optimizer runs out of memory, it attempts to proceed over
again at a lower level of optimization, resuming compilation of
subsequent routines at the original level.
Values:
On SPARC Platforms:
-xO1 Performs basic local optimization (peephole).
-xO2 Does basic local and global optimization. This includes
induction variable elimination, local and global common
subexpression elimination, algebraic simplification, copy
propagation, constant propagation, loop-invariant opti‐
mization, register allocation, basic block merging, tail
recursion elimination, dead code elimination, tail call
elimination and complex expression expansion.
This level does not optimize references or definitions
for external or indirect variables.
-xO3 Optimizes references and definitions for external vari‐
ables in addition to optimizations performed at the -xO2
level. This level does not trace the effects of pointer
assignments. When compiling either device drivers that
are not properly protected by volatile, or programs that
modify external variables from within signal handlers,
use -xO2.
In general, this level, and -xO4, result in the minimum
code size when used with the -xspace option.
-xO4 Performs automatic inlining of functions contained in the
same file in addition to performing -xO3 optimizations.
This automatic inlining can improve execution speed,
though sometimes it results in worse performance. In gen‐
eral, this level results in increased code size unless
combined with -xspace.
-xO5 Performs the highest level of optimization, suitable only
for the small fraction of a program that uses the largest
fraction of computer time. Uses optimization algorithms
that take more compilation time or that do not have as
high a certainty of improving execution time. Optimiza‐
tion at this level is more likely to improve performance
if it is done with profile feedback. See -xprofile=col‐
lect|use.
On x86 platforms:
-xO1 Does basic optimization. This includes algebraic simpli‐
fication, register allocation, basic block merging, dead
code and store elimination, and peephole optimization.
-xO2 In addition to optimizations performed at the -x01 level,
also performs local common subexpression elimination,
local copy and constant propagation, and tail recursion
elimination.
-xO3 In addition to optimization performed at the -x02 level,
also performs global common subexpression elimination,
global copy and constant propagation, loop strength
reduction, induction variable elimination, and loop-vari‐
ant optimization.
-xO4 Does automatic inlining of functions contained in the
same file in addition to performing -xO3 optimizations.
This automatic inlining usually improves execution speed,
but sometimes makes it worse. This level also frees the
frame pointer register (ebp) for general purpose use. In
general, this level results in increased code size.
-xO5 Generates the highest level of optimization. Uses opti‐
mization algorithms that may take more compilation time
and may not have as high a certainty of improving execu‐
tion time.
Interactions:
If you use -g or -g0 and the optimization level is -xO3 or
lower, the compiler provides best-effort symbolic information
with almost full optimization. Tail-call optimization and back-
end inlining are disabled.
If you use -g or -g0 and the optimization level is -xO4 or
higher, the compiler provides best-effort symbolic information
with full optimization.
Debugging with -g does not suppress -xOn, but -xOn limits -g in
certain ways. For example, the optimization options reduce the
utility of debugging so that you cannot display variables from
dbx, but you can still use the dbx where command to get a sym‐
bolic traceback. For more information, see Debugging a Program
With dbx.
The -xinline option has no effect for optimization levels below
-xO3. At -xO4, the optimizer decides which functions should be
inlined, and does so regardless of whether you specify the -xin‐
line option. At -xO4, the compiler also attempts to determine
which functions will improve performance if they are inlined.
If you force the inlining of a function with -xinline, you might
actually diminish performance.
Warnings:
If you optimize at -xO3 or -xO4 with very large procedures,
thousands of lines of code in a single procedure, the optimizer
might require an unreasonable amount of memory. In such cases,
machine performance can be degraded.
To prevent this degradation from taking place, use the limit
command to limit the amount of virtual memory available to a
single process (see the csh(1) man page). For example, to limit
virtual memory to 16 megabytes:
example% limit datasize 16M
This command causes the optimizer to try to recover if it
reaches 16 megabytes of data space.
The limit cannot be greater than the total available swap space
of the machine, and should be small enough to permit normal use
of the machine while a larger compilation is in progress.
The best setting for data size depends on the degree of opti‐
mization requested, the amount of real memory, and virtual mem‐
ory available.
To find the actual swap space, type: swap -1
To find the actual real memory, type: dmesg | grep mem
See also:
-xldscope, -fast, -xprofile=p, csh(1) man page
Performance Analyzer discusses the effects of the different lev‐
els of optimization on the Performance Analyzer's data.
-xopenmp [=i]
Use the -xopenmp option to enable explicit parallelization with
OpenMP directives. To run a parallelized program in a multi‐
threaded environment, you must set the OMP_NUM_THREADS environ‐
ment variable prior to execution. To enable nested parallelism,
you must set the OMP_NESTED environment variable to TRUE. Nested
parallelism 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 optimization level
under -xopenmp=parallel is -x03. The compiler 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.
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 compiler issues an error. If you do not
specify an optimization level with -xopenmp=noopt, the OpenMP
pragmas are recognized, the program is parallelized accord‐
ingly, 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 optimization 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, compile with -g
-xopenmp=noopt so you can breakpoint within parallel regions and
display the contents of variables.
Do not specify -xopenmp, with -xexplicitpar.
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 executable must not be any older than the com‐
piler that built the .so with -xopenmp. This is especially
important when you compile libraries that contain OpenMP direc‐
tives.
Make sure that the latest patch of the OpenMP runtime library,
libmtsk.so, is installed on the system for best performance.
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 platform. 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 introduced in Sun Studio
12 patch 126498-02.
Use the getpagesize(3C) command on the Solaris operating envi‐
ronment 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 compile time and at link time,
see the C++ User's Guide.
If you specify -xpagesize=default, the Solaris operating envi‐
ronment sets the page size.
This option is a macro for -xpagesize_heap and -xpagesize_stack.
These two options accept the same arguments as -xpagesize. You
can set them both with the same value by specifying -xpagesize=n
or you can specify them individually with different values.
Compiling with this option has the same effect as setting the
LD_PRELOAD environment variable to mpss.so.1 with the equivalent
options, or running the Solaris command ppgsz(1) with the equiv‐
alent 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 platform. If
you do not specify a valid pagesize, the request is silently
ignored at run-time.
For details, see -xpagesize.
-xpagesize_stack=n
Set the page size in memory for the stack.
The n value is the same as -xpagesize.
You must specify a valid page size for the 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_file‐
name. You can take advantage of this feature through the -xpch
and -xpchstop options in combination with the #pragma hdrstop
directive.
Use the -xpch option to create a precompiled-header file and
improve your compilation time. The precompiled-header file is
designed to reduce compile time for applications whose source
files share a common set of include files containing a large
amount of source code. A precompiled header works by collecting
information about a sequence of header files from one source
file, and then using that information when recompiling that
source file, and when compiling other source files that have the
same sequence of headers.
Creating a Precompiled-Header File Automatically
You can let the compiler generate the precompiled-header file
for you automatically. Choose between one of the following two
ways to do this. One way is for the compiler to create the pre‐
compiled-header file from the first include file it finds in the
source file. The other way is for the compiler to select from
the set of include files found in the source file starting with
the first include file and extending through a well-defined
point that determines which include file is the last one. Use
one of the following two flags to determine which method the
compiler uses to automatically generate a precompiled header:
-xpch=auto
The contents of the precompiled-header file is based on
the longest viable prefix (see the following section for
an explanation of how a viable prefix is identified) that
the compiler finds in the source file. This flag produces
a precompiled header file that consists of the largest
possible number of header files.
-xpch=autofirst
This flag produces a precompiled-header file that con‐
tains only the first header found in the source file.
Creating the Precompiled-Header File Manually
If you decide to create your precompiled-header file manually,
you must start by first using -xpch and specify the collect
mode. The compilation command that specifies -xpch=collect must
only specify one source file. In the following example, the
-xpch option creates a precompiled-header file called
header.Cpch based on the source file a.cc:
CC -xpch=collect:myheader a.cc
A valid precompiled-header filename always has the suffix .Cpch.
When you specify pch_filename, you can add the suffix or let the
compiler add it for you. For example, if you specify CC
-xpch=collect:foo a.cc, the precompiled-header file is called
foo.Cpch.
How the Compiler Handles an Existing Precompiled-Header File
Here are the rules the compiler uses to determine how it handles
an existing precompiled-header file.
If the compiler finds an existing precompiled-header file, it
only uses the file when the following attributes of the file
match the same information derived from the current compilation:
- The viable prefix matches
- The command line options are exactly the same
- The current working directory is the same
- The source-directory path-name is the same
- The compiler and precompiled header version numbers match
The following must be true for a viable prefix to qualify as a
match:
- The #include filenames are all the same
- All #define and #undef directives reference the same sym‐
bols
and the directives appear in the same order
- The associated values for #define are identical
- Any pragmas that are present appear in their original order
Note that #ident/#pragma idents are passed through "as is" in
the viable prefix and are unchecked for equality. The string
argument is typically different for each source file and, if
checked, would inhibit use of the existing precompiled-header
file.
The compiler version used in the match condition is the same as
that returned by the compiler's -V option.
Directing the Compiler to Use a Specific Precompiled-Header File
You can also direct the compiler to use a specific precompiled
header. Specify -xpch=use:pch_filename to do this. You can
specify any number of source files with the same sequence of
include files as the source file used to create the precompiled-
header file. For example, your command in use mode could look
like this:
CC -xpch=use:foo.Cpch foo.cc bar.cc foobar.cc
You should only use an existing precompiled-header file if the
following is true. If any of the following is not true, you
should recreate the precompiled-header file:
- The compiler that you are using to access the precompiled-
header file is the same as the compiler that created the precom‐
piled-header file. A precompiled-header file created by one ver‐
sion of the compiler may not be usable by another version of the
compiler.
- Except for the -xpch option, the compiler options you specify
with -xpch=use must match the options that were specified when
the precompiled-header file was created.
- The set of included headers you specify with -xpch=use is
identical to the set of headers that were specified when the
precompiled header was created.
- The contents of the included headers that you specify with
-xpch=use is identical to the contents of the included headers
that were specified when the precompiled header was created.
- The current directory (that is, the directory in which the
compilation is occurring and attempting to use a given precom‐
piled-header file) is the same as the directory in which the
precompiled-header file was created.
- The initial sequence of pre-processing directives, including
#include directives, in the file you specified with -xpch=col‐
lect are the same as the sequence of pre-processing directives
in the files you specify with -xpch=use.
The Viable Prefix
In order to share a precompiled-header file across multiple
source files, those source files must share a common set of
include files as their initial sequence of tokens. A token is a
keyword, name or punctuation mark. Comments and code that is
excluded by #if directives are not recognized by the compiler as
tokens. This initial sequence of tokens is known as the viable
prefix. In other words, the viable prefix is the top portion of
the source file that is common to all source files. The compiler
uses this viable prefix as the basis for creating a precompiled-
header file and thereby determining which header files from the
source are pre-compiled.
The viable prefix that the compiler finds during the current
compilation must match the viable prefix that it used to create
the precompiled-header file. In other words, the viable prefix
must be interpreted consistently by the compiler across all the
source files that use the same precompiled-header file.
The viable prefix consists of any of the following pre-processor
directives:
#include
#if/ifdef/ifndef/else/elif/endif
#define/undef
#ident
#pragma
Any of these may reference macros. The #else, #elif, and #endif
directives must match within the viable prefix. Comments are
ignored.
The compiler determines the end point of the viable prefix auto‐
matically when you specify -xpch=auto or -xpch=autofirst and is
defined as follows. For -xpch=collect or -xpch=use, the viable
prefix ends with a #pragma hdrstop.
- The first declaration/definition statement
- The first #line directive
- A #pragma hdrstop directive
- After the named include file if you specify -xpch=auto and
-xpchstop
- The first include file if you specify -xpch=autofirst
Note: An end point within a conditional statement generates a
warning and disables the automatic creation of a precompiled-
header file. Also, if you specify both the #pragma hdrstop and
the -xpchstop option, then the compiler uses the earlier of the
two stop points to terminate the viable prefix.
Within the viable prefix of each file that shares a precompiled-
header file, each corresponding #define and #undef directive
must reference the same symbol (in the case of #define, each one
must reference the same value). Their order of appearance within
each viable prefix must be the same as well. Each corresponding
pragma must also be the same and appear in the same order across
all the files sharing a precompiled header.
Screening Header Files for Problems
What makes a header file precompilable? A header file is precom‐
pilable when it is interpreted consistently across different
source files. Specifically, when it contains only complete dec‐
larations. That is, a declaration in any one file must stand
alone as a valid declaration. Incomplete type declarations, such
as struct S;, are valid declarations. The complete type declara‐
tion can appear in some other file. Consider these example
header files:
file a.h
struct S {
#include "x.h" /* not allowed */
};
file b.h
struct T; // ok, complete declaration
struct S {
int i;
[end of file, continued in another file] /* not allowed */
file c.h
namespace N {
int foo();
[end of file, continued in another file] /* not allowed */
file d.h
extern "C" {
int foo();
[end of file, continued in another file] /* not allowed */
file e.h
namespace N {
int foo();
} /* OK, a stand-alone namespace declaration */
file f.h
namespace N {
int bar();
} /* OK, namespace re-opened, but still stand-alone */
A header file that is incorporated into a precompiled-header
file must not violate the following. The results of compiling a
program that violate any of these constraints is undefined.
- The header file must not use __DATE__ and __TIME__.
- The header file must not contain #pragma hdrstop.
The Precompiled-Header File Cache
When the compiler creates a precompiled-header file automati‐
cally, the compiler writes it to the SunWS_cache directory. This
directory always resides in the location where the object file
is created. Updates to the file are preformed under a lock so
that it works properly under dmake.
If you need to force the compiler to rebuild automatically-gen‐
erated precompiled-header files, you can clear the PCH cache
directory with the CCadmin tool. See the CCadmin(1) man page for
more information.
Warnings
o Do not specify conflicting -xpch flags on the command line.
For example, specifying both -xpch=collect and -xpch=auto, or
specifying both -xpch=autofirst with -xpchstop=<include> gener‐
ates an error.
o If you specify -xpch=autofirst or you specify -xpch=auto with‐
out -xpchstop, any declaration, definition, or #line directive
that appears prior to the first include file, or appears prior
to the include file that is specified with -xpchstop for
-xpch=auto, generates a warning and disables the automatic gen‐
eration of the precompiled-header file.
o A #pragma hdrstop before the first include file under
-xpch=autofirst or -xpch=auto disables the automatic generation
of the precompiled-header file.
Precompiled-Header File Dependencies and make Files
The compiler generates dependency information for precompiled-
header files when you specify -xpch=collect. You need to create
the appropriate rules in your make files to take advantage of
these dependencies. Consider this sample make file:
.KEEP_STATE:
%.o : %.cc shared.Cpch
$(CC) -xpch=use:shared -xpchstop=foo.h -c $<
default : a.out
foo.o + shared.Cpch : foo.cc
$(CC) -xpch=collect:shared -xpchstop=foo.h foo.cc -c
a.out : foo.o bar.o foobar.o
$(CC) foo.o bar.o foobar.o
clean :
rm -f *.o shared.Cpch .make.state a.out
These make rules, along with the dependencies generated by the
compiler, force a manually created precompiled-header file to be
recreated if any source file you used with -xpch=collect, or any
of the headers that are part of the precompiled-header file,
have changed. This prevents the use of an out of date precom‐
piled-header file.
For -xpch=auto or -xpch=autofirst, you do not have to create any
additional make rules in your makefiles.
See Also: -xpchstop
-xpchstop=file
where file is the last include file to be considered in creating
a precompiled-header file. Using -xpchstop on the command line
is equivalent to placing a hdrstop pragma (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 includ‐
ing <include>. This flag overrides the default -xpch=auto behav‐
ior of using all header files contained in the entire viable
prefix.
See Also: -xpch, -xhelp=readme
-xpec[={yes|no}]
(Solaris) Generates a Portable Executable Code (PEC) binary.
PEC binaries can be used with the Automatic Tuning System (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.sun‐
source.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 collect data
for profiling with gprof. This option invokes a runtime record‐
ing mechanism that produces a gmon.out file when the program
normally terminates.
Note: There is no advantage for -xprofile if you specify -xpg.
The two do not prepare or use data provided by the other.
Profiles are generated by using prof or gprof on 64 bit Solaris
platforms or just gprof on 32 bit Solaris platforms include
approximate user CPU times. These times are derived from PC sam‐
ple data (see pcsample(2)) for routines in the main executable
and routines in shared libraries specified as linker arguments
when the executable is linked. Other shared libraries
(libraries opened after process startup using dlopen(3DL)) are
not profiled.
On 32 bit Solaris systems, profiles generated using prof(1) are
limited to routines in the executable. 32 bit shared libraries
can be profiled by linking the executable with -xpg and using
gprof(1).
The Solaris 10 software does not include system libraries com‐
piled with -p. As a result, profiles collected on Solaris 10
platforms do not include call counts for system library rou‐
tines.
You can also perform this task with the Performance Analyzer.
Refer to the analyzer(1) man page.
Warnings:
If you specify -xpg at compile time, you must also specify it at
link time. See the C++ User's Guide for a complete list of
options that must be specified at both compile time and link
time.
-xport64[=v]
Use this option to help you port code to a 64-bit environment.
Specifically, this option warns against problems such as trunca‐
tion of types (including pointers), sign extension, and changes
to bit-packing that are common when you port code from a 32-bit
architecture 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 environment to a 64 bit envi‐
ronment.
implicit Generate warning only for implicit conversions.
Do not generate warnings when an explicit cast is
present.
full Generate all warnings related to the porting of
code from a 32 bit environment to a 64 bit envi‐
ronment. This includes warnings for truncation of
64-bit values, sign-extension to 64 bits under
ISO value-preserving rules, and changes to pack‐
ing of bitfields.
Defaults:
If you do not specify -xport64, the default is -xport64=no. If
you specify -xport64, but do not specify a flag, the default is
-xport64=full.
See Also: -xarch
-xprefetch[=a[,a]]
Enable and adjust prefetch instructions on those architectures
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 instruc‐
tions.
no%auto Disable automatic generation
explicit Enable explicit prefetch macros
Explicit prefetching should only be used under
special circumstances that are supported by mea‐
surements.
no%explicit Disable explicit prefectch macros.
latx:factor (SPARC) You can only combine this flag with
-xprefetch=auto. Adjust the compiler's assumed
prefetch-to-load and prefetch-to-store latencies
by the specified factor. The factor must be a
positive floating-point or integer number.
yes Obsolete - do not use. Use
-xprefetch=auto,explicit instead.
no Obsolete - do not use. Use
-xprefetch=no%auto,no%explicit instead.
With -xprefetch, and -xprefetch=auto the compiler is free to
insert prefetch instructions into the code it generates. This
may result in a performance improvement on architectures that
support prefetch.
If you are running computationally intensive codes on large mul‐
tiprocessors, you might find it advantageous to use
-xprefetch=latx:factor. This option instructs the code generator
to adjust the default latency time between a prefetch and its
associated load or store by the specified factor.
The prefetch latency is the hardware delay between the execution
of a prefetch instruction and the time the data being prefetched
is available in the cache. The compiler assumes a prefetch
latency value when determining how far apart to place a prefetch
instruction and the load or store instruction that uses the
prefetched data.
Note -- the assumed latency between a prefetch and a load may
not be the same as the assumed latency between a prefetch and a
store.
The compiler tunes the prefetch mechanism for optimal perfor‐
mance across a wide range of machines and applications. This
tuning may not always be optimal. For memory-intensive applica‐
tions, especially applications intended to run on large multi‐
processors, you may be able to obtain better performance by
increasing the prefetch latency values. To increase the values,
use a factor that is greater than 1 (one). A value between .5
and 2.0 will most likely provide the maximum performance.
For applications with datasets that reside entirely within the
external cache, you may be able to obtain better performance by
decreasing the prefetch latency values. To decrease the values,
use a factor that is less than 1 (one).
To use the -xprefetch=latx:factor option, start with a factor
value near 1.0 and run performance tests against the applica‐
tion. Then increase or decrease the factor, as appropriate, and
run the performance tests again. Continue adjusting the factor
and running the performance tests until you achieve optimum per‐
formance. When you increase or decrease the factor in small
steps, you will see no performance difference for a few steps,
then a sudden difference, then it will level off again.
Defaults:
The default is -xprefetch=auto,explicit.
If automatic prefetching is enabled, such as with -xprefetch or
-xprefetch=auto, but a latency factor is not specified, then
latx:1.0 is assumed.
Interactions:
This option accumulates instead of overrides.
The sun_prefetch.h header file provides the macros for specify‐
ing explicit prefetch instructions. The prefetches will be
approximately at the place in the executable that corresponds to
where the macros appear.
To use the explicit prefetch instructions, you must be on the
correct architecture, include sun_prefetch.h, and either exclude
-xprefetch from the compiler command or use -xprefetch,
-xprefetch=auto,explict, -xprefetch=explicit.
If you call the macros and include the sun_prefetch.h header
file, but pass -xprefetch=no%explicit, the explicit prefetches
will not appear in your executable.
The -xchip setting effects the determination of the assumed
latencies and therefore the result of a latx:factor setting.
The latx:factor suboption is valid only when automatic prefetch‐
ing is enabled. That is, latx:factor is ignored unless it is
used in conjunction with yes or auto.
Warnings:
Because the compiler tunes the prefetch mechanism for optimal
performance across a wide range of machines and applications,
you should only use the latx:factor suboption when the perfor‐
mance tests indicate there is a clear benefit. The assumed
prefetch latencies may change from release to release. There‐
fore, retesting the effect of the latency factor on performance
whenever switching to a different release is highly recommended.
-xprefetch_auto_type=[a]
Where a is [no%]indirect_array_access.
Use this option to determine whether or not the compiler gener‐
ates indirect prefetches for the loops indicated by the option
-xprefetch_level in the same fashion the prefetches for direct
memory accesses are generated.
If you do not specify a setting for -xprefetch_auto_type, the
compiler sets it to -xprefetch_auto_type=no%indi‐
rect_array_access.
Options such as -xalias_level can affect the aggressiveness of
computing the indirect prefetch candidates and therefore the
aggressiveness of the automatic indirect prefetch insertion due
to better memory alias disambiguation information.
-xprefetch_level=l
Controls the automatic insertion of prefetch instructions as
determined with -xprefetch=auto. The default is
-xprefetch_level=1 when you specify -xprefetch=auto.
l must be 1, 2, or 3.
Prefetch levels 2 and 3 may not be effective on older SPARC and
x86 platforms.
-xprefetch_level=1 enables automatic generation of prefetch
instructions. -xprefetch_level=2 targets additional loops,
beyond those targeted at level 1 and -xprefetch=3 targets addi‐
tional loops beyond those targeted at level 2.
You must compile with optimization level 3 or greater and gener‐
ate code for a platform that supports prefetch.
-xprofile=p
Collects data for a profile or use a profile to optimize.
p must be collect[:profdir], use[:profdir], or tcov.
This option causes execution frequency data to be collected and
saved during execution, then the data can be used in subsequent
runs to improve performance. Profile collection is safe for mul‐
tithreaded applications. That is, profiling a program that does
its own multitasking ( -mt ) produces accurate results. This
option is only valid when you specify -xO2 or greater level of
optimization.
If compilation and linking are performed in separate steps, the
same -xprofile option must appear on the compile as well as the
link step. See the C++ User's Guide for a complete list of
options that must be specified at both compile time and link
time.
collect[:profdir]
Collects and saves execution frequency for later use by the
optimizer with -xprofile=use. The compiler generates code
to measure statement execution-frequency.
-xMerge -ztext -xprofile=collect should not be used
together. While -xMerge forces statically initialized
data into read-only storage, -ztext prohibits position-
dependent symbol relocations in read-only storage, and
-xprofile=collect generates statically initialized, posi‐
tion-dependent symbol relocations in writable storage.
The profile directory name profdir, if specified, is the
pathname of the directory where profile data are to be
stored when a program or shared library containing the pro‐
filed object code is executed. If the pathname is not
absolute, it is interpreted relative to the current working
directory when the program is compiled with the option
-xprofile=use:profdir.
If no profile directory name is specified, 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 direc‐
tory myprof.profile located in the same directory where the
program is built:
CC -xprofile=collect:myprof.profile -xO5 prog.cc -o prog
./prog
CC -xprofile=use:myprof.profile -xO5 prog.cc -o prog
Example[2]: to collect profile data in the directory
/bench/myprof.profile and later use the collected profile
data in a feedback compilation at optimization level -xO5:
CC -xprofile=collect:/bench/myprof.profile -xO5 prog.cc -o prog
...run prog from multiple locations...
CC -xprofile=use:/bench/myprof.profile -xO5 prog.cc -o prog
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 written to SUN_PROF‐
DATA_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 profdir.profile/feedback 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
feedback file; 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 asyn‐
chronous 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 col‐
lected by running a program that was compiled with -xpro‐
file=collect[:profdir].
The profdir is optional. If profdir is not specified, the
name of the executible binary is used. a.out is used if -o
is not specified. The compiler looks for profdir.pro‐
file/feedback, or a.out.profile/feedback without profdir
specified. For example:
CC -xprofile=collect -o myexe prog.cc
CC -xprofile=use:myexe -xO5 -o myexe prog.cc
The program is optimized by using the execution frequency
data previously generated and saved in the feedback files
written by a previous execution of the program compiled
with -xprofile=collect.
Except for the -xprofile option, the source files and other
compiler options must be exactly the same as those used for
the compilation that created the compiled program which in
turn generated the feedback file. The same version of the
compiler must be used for both the collect build and the
use build as well. If compiled with -xprofile=col‐
lect:profdir, the same profile directory name profdir must
be used in the optimizing compilation: -xpro‐
file=use:profdir.
See also -xprofile_ircache for speeding up compilation
between collect and use phases.
tcov
Basic block coverage analysis using "new" style tcov.
The -xprofile=tcov option is the new style of basic block
profiling for tcov. It has similar functionality to the -xa
option, but correctly collects data for programs that have
source code in header files. See also -xa for information
on the old style of profiling, the tcov(1) man page, and
the Performance Analyzer manual for more details.
Code instrumentation is performed similarly to that of the
-xa option, but .d files are no longer generated. instead,
a single file is generated, the name of which is based on
the final executable. for example, if the program is run
out of /foo/bar/myprog.profile, the data file is stored in
/foo/bar/myprog.profile/myprog.tcovd.
When running tcov, you must pass it the -x option to make
it use the new style of data. If not, tcov uses the old .d
files, if any, by default for data, and produces unexpected
output.
Unlike the -xa option, the TCOVDIR environment variable has
no effect at compile-time. However, its value is used at
program runtime. See tcovf1(1) and the Performance Ana‐
lyzer manual for more details.
Note: tcov's code coverage report can be unreliable if
functions are inlined due to the use of -xO4 or higher
optimization or -xinline.
Counter values generated by -xprofile=tcov are not guaran‐
teed to be accurate in multi-threaded applications, because
if two threads simultaneously attempt to increment the same
counter, one of the increments may be lost. However, since
increments do not cancel one another, the resulting data
are still valid for coverage analysis.
-xprofile_ircache[=path]
Use -xprofile_ircache[=path] with -xprofile=collect|use to
improve compilation time during the use phase by reusing compi‐
lation data saved from the collect phase.
With large programs, compilation time in the use phase can
improve significantly because the intermediate data is saved.
Note that the saved data could increase disk space requirements
considerably.
When you use -xprofile_ircache[=path], path overrides the loca‐
tion where the cached files are saved. By default, these files
are saved in the same directory as the object file. Specifying a
path is useful when the collect and use phases happen in two
different directories.
Here's a typical sequence of commands:
example% CC-xO5 -xprofile=collect -xprofile_ircache t1.cc t2.cc
example% a.out // run collects feedback data
example% CC-xO5 -xprofile=use -xprofile_ircache t1.cc t2.cc
-xprofile_pathmap=collect_prefix:use_prefix
Use the -xprofile_pathmap option when you are also specifying
the -xprofile=use command. Use -xprofile_pathmap when both of
the following are true and the compiler is unable to find pro‐
file data for an object file that is compiled with -xpro‐
file=use.
o You are compiling the object file with -xprofile=use
in a directory that is different from the directory in which
the object file was previously compiled with -xprofile=col‐
lect.
o Your object files share a common basename in the
profile but are distinguished from each other by their loca‐
tion in different directories.
The collect-prefix is the prefix of the UNIX pathname of a
directory tree in which object files were compiled using -xpro‐
file=collect.
The use-prefix is the prefix of the UNIX pathname of a directory
tree in which object files are to be compiled using -xpro‐
file=use.
If you specify multiple instances of -xprofile_pathmap, the com‐
piler processes them in the order of their occurrence. Each
use-prefix specified by an instance of -xprofile_pathmap is com‐
pared with the object file pathname until either a matching use-
prefix is identified or the last specified use-prefix is found
not to match the object file pathname.
-xreduction
Analyzes loops for reduction in automatic parallelization. This
option is valid only if -xautopar is also specified. Otherwise
the compiler issues a warning.
When a reduction recognition is enabled, the compiler paral‐
lelizes reductions such as dot products, maximum and minimum
finding. These reductions yield different roundoffs from those
obtained by unparallelized code.
-xregs=r[,r...]
Controls scratch register usage.
The compiler can generate faster code if it has more registers
available for temporary storage (scratch registers). This option
makes available additional scratch registers that might not
always be appropriate.
r is a comma-separated list of one or more of the following:
[no%]appl (SPARC only)
[Does not] 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 registers' values for the application. Their use
is intended to be controlled by the compilation system
and must be consistent throughout the application.
In the SPARC ABI, these registers are described as
application registers. Using these registers can
increase performance because fewer load and store
instructions are needed. However, such use can conflict
with some old library programs written in assembly
code.
For more information on SPARC instruction sets, see
-xarch.
[no%]float (SPARC only)
[Does not] Allow the compiler to generate code by using
the floating-point registers as scratch registers for
integer values. Use of floating-point values may use
these registers regardless of this option. If you want
your code to be free of all references to floating
point registers, you need to use -xregs=no%float and
also make sure your code does not use floating point
types in any way.
[no%]frameptr (x86 only)
[Does not] Allow the compiler to use the frame-pointer
register (%ebp on IA32, %rbp on x86 64-bit) as an unal‐
located callee-saves register.
Using this register as an unallocated callee-saves reg‐
ister may improve program run time. However, it also
reduces the capacity of some tools, such as the Perfor‐
mance Analyzer and dtrace, to inspect and follow the
stack. This stack inspection capability is important
for system performance measurement and tuning. There‐
for, using this optimization may improve local program
performance at the expense of global system perfor‐
mance.
Note: -xregs=frameptr is ignored and a warning is
issued by the compiler if you also specify -xpg. Also,
the compiler ignores this option for 32-bit x86 compi‐
lation unless exceptions are disabled with the -noex
option.
Defaults:
The SPARC default is -xregs=appl,float.
The x86 default is -xregs=no%frameptr unless you specify -fast
or an optimization of -xO5 in which case -xregs=frameptr.
-xrestrict[=f]
Treats pointer-valued function parameters as restricted point‐
ers. f is %all, %none, %source or a comma-separated list of one
or more function names. This command-line option can be used on
its own, but is best used with optimization of -xO3 or greater.
Specifying -xrestrict=%source means that all functions defined
in the main source file, but not any header files or template
definition files, are restricted.
If you specify a function list with this option, pointer parame‐
ters in the specified functions are treated as restricted; if
you specify -xrestrict=%all, all pointer parameters in the
entire C++ file are treated as restricted.
The default is %none. Specifying -xrestrict is equivalent to
specifying -xrestrict=%source.
See Also: -xprefetch_auto_type, 'Restricted Pointers' in the C++
User's Guide
-xs Allows debugging by dbx without object files.
This option causes all the debug information to be copied into
the executable. This has little impact on dbx performance or
the run-time performance of the program, but it does take more
disk space.
-xsafe=mem
(SPARC platform) Allow the compiler to assume that no memory
protection violations occur.
This option allows the compiler to use the non-faulting load
instruction in the SPARC V9 architecture.
Warnings:
Because non-faulting loads do not cause a trap when a fault such
as address misalignment or segmentation violation occurs, you
should use this option only for programs in which such faults
cannot occur. Because few programs incur memory-based traps,
you can safely use this option for most programs. Do not use
this option for programs that explicitly depend on memory-based
traps to handle exceptional conditions.
Interactions:
This option takes effect only when used with optimization level
-xO5 and one of the following -xarch values: sparc, sparcvis, or
sparcvis2 for both -m32 and -m64.
-xsb Deprecated - do not use. The source browser functionality is
obsolete.
-xsbfast
Deprecated - do not use. The source browser functionality is
obsolete.
-xspace
Does not allow optimizations that increase code size.
-xtarget=t
Specifies the target system for instruction set and optimiza‐
tion.
t must be one of the folowing: native, native64, generic,
generic64 or system-name.
This option is a macro. Each specific value for -xtarget expands
into a specific set of values for the -xarch, -xchip, and
-xcache options. See the -dryrun explanation for details on how
to see the expansion of macro options such as -xtarget.
Note: The expansion of -xtarget for a specific host platform
might not expand to the same -xarch, -xchip, or -xcache settings
as -xtarget=native when compiling on that platform.
-xtarget=native is equivalent to -m32, -xarch=native,
-xchip=native, -xcache=native.
-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=ultra ... -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 performance
on the host system. This flag determines the avail‐
able 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 properties of the
machine on which the compiler is running and assumes a
64-bit architecture.
generic This is the default and yields the best performance
for generic architecture, chip and cache on most
32-bit systems.
generic64 Gets the best performance for generic architecture,
chip and cache on most 64-bit systems.
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, sparc64vi,
sparc64vii.
The following target platforms are equivalent to
-xtarget=ultra.
entr2, entr2/1170, entr2/2170, entr2/1200, entr2/2200,
entr3000, entr4000, entr5000, entr6000
The following are less commonly used but still valid
values for platform name:
sun4/15, sun4/30, sslc, sslx, sslx2, ss4, ss4/85,
ss4/110, ss5, ss5/85, ss5/110, ssvyger, ss10,
ss10/hs11, ss10/hs12, ss10/hs14, ss10/20, ss10/hs21,
ss10/hs22, ss10/30, ss10/40, ss10/41, ss10/50,
ss10/51, ss10/61, ss10/71, ss10/402, ss10/412,
ss10/512, ss10/514, ss10/612, ss10/712, ss20,
ss20/hs11, ss20/hs12, ss20/hs14, ss20/hs21, ss20/hs22,
ss20/50, ss20/51, ss20/61, ss20/71, ss20/151,
ss20/152, ss20/502, ss20/512, ss20/514, ss20/612,
ss20/712, ss600/41, ss600/51, ss600/61, ss600/412,
ss600/512, ss600/514, ss600/612, ss1000, sc2000,
cs6400, solb6
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 plat‐
forms is indicated by the -m64 option. If you specify -xtarget
with a flag other than native64 or generic64, you must also
specify the -m64 option as follows:
-xtarget=opteron ... -m64
otherwise the compiler uses a 32-bit memory model.
Value Meaning
generic This is the default and yields the best performance
for generic architecture, chip and cache on most
32-bit systems.
generic64 Gets the best performance for generic architecture,
chip and cache on most 64-bit systems.
native The compiler generates code for the best performance
on the host system. This flag determines the avail‐
able 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 properties 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 microprocessor.
opteron Directs the compiler to generate code for the best
performance on the AMD Opteron microprocessor.
Note: The -xtarget=opteron option does not automati‐
cally 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 microprocessor.
pentium_pro
Directs the compiler to generate code for the best
performance on the Pentium Pro microprocessor.
pentium3 Directs the compiler to generate code for the best
performance on the Pentium 3 microprocessor.
pentium4 Directs the compiler to generate code for the best
performance on the Pentium 4 microprocessor.
penryn Directs the compiler to generate code for the best
performance on the Penryn microprocessor.
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 speci‐
fier, use -xthreadvar to enable the use of thread-local storage
with position dependent code (non-PIC code) in dynamic (shared)
libraries. For more information on how to use __thread, see the
C++ User's Guide.
Values
o can be one of the following:
Value Meaning
[no%]dynamic [[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 com‐
piler depends upon whether or not position-independent code is
enabled. If position-independent code is enabled, the option is
set to -xthreadvar=dynamic. If position- independent code is
disabled, the option is set to -xthreadvar=no%dynamic.
If you specify -xthreadvar but do not specify any arguments, the
option is set to -xthreadvar=dynamic.
Interactions
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 com‐
piled and linked with -mt.
Warnings
If there is non-position-independent code within a dynamic
library, you must specify -xthreadvar.
The linker cannot support the thread-variable equivalent of non-
PIC code in dynamic libraries. Non-PIC thread variables are sig‐
nificantly faster, and hence should be the default for executa‐
bles.
See Also
-xcode, -KPIC, -Kpic
-xtime Causes the CC driver to report execution times for the various
compilation passes.
-xtrigraphs[={yes|no}]
Enables or disables recognition of trigraph sequences as defined
by the ISO/ANSI C standard.
-xtrigraphs=yes enables recognition of trigraph sequences in the
source code.
-xtrigraphs=no disables recognition of trigraph sequences in the
source code.
Defaults:
If the -xtrigraphs option is not specified, -xtrigraphs=yes is
assumed.
If only -xtrigraphs is specified -xtrigraphs=yes is assumed.
-xunroll=n
Enables unrolling of loops where possible.
This option specifies whether or not the compiler optimizes
(unrolls) loops.
When n is 1, it is a suggestion to the compiler not to unroll
loops.
When n is an integer greater than 1, -xunroll=n causes the com‐
piler to unroll loops n times.
-xustr={ascii_utf16_ushort|no}
This option enables compiler recognition of UTF-16 character
strings and literals. Since such strings and literals are not
yet part of any standard, this option enables recognition of
non-standard C++. Specify -xustr=ascii_utf16_ushort if you need
to support an internationalized application that uses ISO10646
UTF-16 characters. In other words, use this option if your code
contains string characters that you want the compiler to convert
to UTF-16 characters in the object file. Without this option,
the compiler neither produces nor recognizes sixteen-bit charac‐
ters. This option enables recognition of the U"ASCII_string"
string literals as an array of unsigned short int. This option
also enables recognition of character literals. For example:
unsigned short character = U'Z';
You can turn off compiler recognition of U"ASCII_string" string
literals by specifying -xustr=no. The rightmost instance of this
option on the command line overrides all previous instances.
The default is -xustr=no. If you specify -xustr without an argu‐
ment, the compiler won't accept it and instead issues a warning.
The default can change if the C or C++ standards define a mean‐
ing for the syntax.
It is not an error to specify -xustr=ascii_ustf16_ushort without
also specifying a U"ASCII_string" string literal.
Not all files have to be compiled with this option.
The following example shows a string literal in quotes that is
prepended by U. It also shows a command line that specifies
-xustr.
example% cat file.cc
const unsigned short *foo = U"foo";
const unsigned short bar[] = U"bar";
const unsigned short *fun() { return foo; }
example% CC -xustr=ascii_utf16_ushort file.cc -c
An 8-bit character literal can be prepended with U to form a
16-bit UTF-16 character of type unsigned short. Examples:
const unsigned short x = U'x';
const unsigned chart y = U'9';
-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 speci‐
fying -fround=nearest when you use this option.
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 routines when such transformations
are possible. This could result in a performance improve‐
ment 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.
The compiler can only accept this switch if the target
architecture supports SIMD instructions. For example, you
must specify -xarch=sse2 -m64 or -xarch=generic64. You must
also specify an optimization level of -xO3 or above as well
as -xdepend when you specify -xvector=simd.
yes This option is depracated, specify -xvector=lib instead.
no This option is deprecated, specify -xvector=none instead.
The default is -xvector=%none. If you specify -xvector, but do
not provide a flag, the compiler assumes -xvector=lib.
This option overrides previous instances so -xvector=%none
undoes a previously specified -xvector=lib.
If you use -xvector on the command line without previously spec‐
ifying -xdepend, -xvector triggers -xdepend. The -xvector option
also raises the optimization level to -O3 if optimization is not
specified or optimization is set lower than -O3.
The compiler includes the libmvec libraries in the load step.
If you compile and link with separate commands, be sure to use
the same -xvector option in the linking CC command. 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.
-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 instruc‐
tion set. Even though the UltraSPARC processors are 64-bit,
there are many cases, especially in multimedia applications,
when the data are limited to eight or 16 bits in size. The VIS
instructions can process four 16-bit data with one instruction
so they greatly improve the performance of applications that
handle new media such as imaging, linear algebra, signal pro‐
cessing, audio, video and networking.
For more information on the VSDK, see http://www.sun.com/proces‐
sors/vis/.
-xvpara
Issues warnings about potential parallel-programming related
problems that may cause incorrect results when using OpenMP. Use
with -xopenmp and OpenMP API directives.
The compiler issues warnings when it detects the following situ‐
ations:
o Loops are parallelized using MP directives with data dependen‐
cies between different loop iterations
o OpenMP data-sharing attributes-clauses are problematic. For
example, declaring a variable "shared" whose accesses in an
OpenMP parallel region may create a data race, or declaring a
variable "private" whose value in a parallel region is used
after the parallel region.
No warnings appear if all parallelization directives are pro‐
cessed without problems.
Example:
CC-xopenmp -xvpara any.cc
Note: Sun Studio compilers support OpenMP 2.5 API paralleliza‐
tion. Consequently, the MP pragmas are deprecated. See the
OpenMP API User's Guide for information on migrating to the
OpenMP API.
-xwe Converts all warnings to errors by returning non-zero exit sta‐
tus.
-Yc,path
Specifies a new path for the location of component c.
If the location of a component is specified, then the new path
name for the component is path/component_name. This option is
passed to ld.
Values
c must be one of the following values.
p Changes the default directory for cpp.
0 Changes the default directory for ccfe.
a Changes the default directory for fbe.
2 Changes the default directory for iropt (SPARC).
c Changes the default directory for cg (SPARC).
O Changes the default directory for ipo (SPARC).
k Changes the default directory for CClink.
l Changes the default directory for ld.
f Changes the default directory for c++filt.
m Changes the default directory for mcs.
u Changes the default directory for ube (x86).
h Changes the default directory for ir2hf (x86).
A Specifies a directory to search for all compiler components.
If a component is not found in path, the search reverts to
the directory where the compiler is installed.
P Adds path to the default library search path. This path will
be searched before the default library search paths.
S Changes the default directory for startup object files
Interactions
You can have multiple -Y options on a command line. If more than
one -Y option is applied to any one component, then the last
occurrence holds.
See also
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 .nf
SPARC Only:
Refer to the C++ User's Guide for more information on these pragmas.
ENVIRONMENT
SUN_PROFDATA=profdir
If set, store profile data collected from a program compiled
with -xprofile=collect in a directory named profdir in the
current working directory at the time that the program is
executed. If the optional argument :profdir was specified in
-xprofile=collect[:profdir] at compilation time, SUN_PROF‐
DATA as no effect.
SUN_PROFDATA_DIR=dirname If set, store profile data collected
from a program compiled with -xprofile=collect in a directory
whose UNIX dirname is dirname. If dirname is not absolute,
it is interpreted relative to the current working directory
at the time that the program is executed. If the optional
argument :profdir was specified in -xprofile=col‐
lect[:profdir] at compilation time, SUN_PROFDATA_DIR has no
effect.
SUN_PROFDATA_REPLACE={objfile,program,all}
If set, specifies the subset of data in the profile directory
to be reset if a program change is detected at runtime when
the current process's profile data are merged with data
already stored in the profile directory. If not set, the sub‐
set of profile data to be reset is determined by the opti‐
mization flags specified with -xprofile=collect. Relevant
options include -xOn and -xipo=n.
SUN_PROFDATA_REPLACE={objfile,program,all}
If set, specifies the subset of data in the profile directory
to be reset if a program change is detected at runtime when
the current process's profile data are merged with data
already stored in the profile directory. If not set, the sub‐
set of profile data to be reset is determined by the opti‐
mization flags specified with -xprofile=collect. Relevant
options include -xOn and -xipo=n.
SUN_PROFDATA_ASYNC_INTERVAL=async_interval
Set this environment variable to enable asynchronous profile
collection. In asynchronous profile collection, profile data
are collected from a running process at regular intervals
whose duration is specified in units of seconds.
SUN_PROFDATA_ASYNC_INTERVAL has no effect unless one of the
environment variables LD_AUDIT, LD_AUDIT_32, or LD_AUDIT_64
is set to /usr/lib/{,64}/libxprof_audit.so.1.
Asynchronous profile collection requires an MT-safe, mmap
based memory allocator, such as libumem(3) with mmap-based
allocation specified by setting UMEM_OPTIONS to backend=mmap.
Example: to enable asynchronous profile collection from a 64
bit process at 1 minute intervals,specify the following envi‐
ronment variables:
$ env LD_AUDIT_64=/usr/lib/64/libxprof_audit.so.1 \
SUN_PROFDATA_ASYNC_INTERVAL=60 UMEM_OPTIONS=backend=mmap \
64-bit-program [program-args]
Asynchronous profile collection requires OpenSolaris 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' instead of 'All Sun Internal Collections' which
is the default for the Search list box.
For Solaris release 10, new shared libraries libxprof.so.1, libx‐
prof_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 Open‐
Solaris 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 pro‐
grams compiled with -xprofile=collect
SEE ALSOanalyzer(1), as(1), c++filt(1), cc(1), csh(1), dbx(1), gprof(1), ld(1),
more(1), nm(1), prof(1), tcov(1)
C++ User's Guide,
C++ Migration Guide,
The C++ Programming Language, Third Edition, Bjarne Stroustrup, Addi‐
son-Wesley 1997
The C Programming Language, B. W. Kernighan and D. M. Ritchie, Pren‐
tice-Hall 1988
Solaris Linker and Libraries Guide
International Standard (ISO/IEC FDIS 14882), Programming Languages —
C++
4th Berkeley Distribution April 2009 CC(1)
