NAME
CC - C++ compiler
SYNOPSIS
CC [-386] [-486] [-a] [-B{dynamic|static|symbolic}] [-c]
[-cg{89|92}] [-compat[={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] [-fsimple[=n]] [-fstore]
[-ftrap=a[,a...]] [-G] [-g] [-g0] [-H] [-h[ ]lname]
[-help] [-Ipathname] [-I-] [-i] [-inline]
[-instances=i] [-instlib=file] [-KPIC] [-Kpic]
[-keeptmp] [-Lpath] [-llib] [-libmieee] [-libmil]
[-library=lib[,lib...]] [-m32|-m64] [-mc] [-migration]
[-misalign] [-mr[,string]] [-mt] [-native] [-noex]
[-nofstore] [-nolib] [-nolibmil] [-noqueue] [-norun-
path] [-O[n]] [-O[level]] [-o file] [+p] [-P] [-p]
[-pentium] [-pg] [-PIC] [-pic] [-pta] [-ptipath] [-pto]
[-ptrpath] [-ptv]
[{-Qoption|-qoption}phase[,option...]]
[{-Qproduce|-qproduce}type] [-qp] [-Rpath[:path...]]
[-readme] [-S] [-s] [-sb] [-sbfast]
[-staticlib=l[,l...]] [-sync_stdio=[yes|no]]
[-temp=path] [-template=a[,a...]] [-time] [-Uname]
[-unroll=n] [-V] [-v] [-vdelx] [-verbose=a[,a...]]
[+w] [+w2] [-w] [-Xm] [-xa] [-xalias_level[=n]] [-xar]
[-xarch=isa] [-xautopar] [-xbinopt={a}]
[-xbuiltin[={%all|%none}]] [-xcache=c] [-xcg{89|92}]
[-xchar[=o]] [-xcheck[=n]] [-xchip=c] [-xcode=v]
[-xcrossfile[=n]] [-xdebugformat=[stabs|dwarf]]
[-xdepend[={yes|no}]] [-xdumpmacros[=value[,value...]]
[-xe] [-xF[=v]] [-xhelp={flags|readme}]
[-xhwcprof[={enable|disable}]] [-xia]
[-xinline[=func_spec[,func_spec...]]
[-xinstrument=[no%]datarace] [-xipo[={0|1|2}]
[-xipo_archive[=a]] [-xjobs=n]
[-xlang=language[,language]] [-xldscope=[v]] [-xlib-
mieee] [-xlibmil] [-xlibmopt] [-xlic_lib=sunperf]
[-xlicinfo] [-xlinkopt[=level]] [-xloopinfo] [-xM]
[-xM1] [-xMerge] [-xmaxopt[=v]] [-xmemalign=ab]
[-xmodel=[a]] [-xnolib] [-xnolibmil] [-xnolibmopt]
[-xOn] [-xopenmp] [-xpagesize=n] [-xpagesize_heap=n]
[-xpagesize_stack=n] [-xpch=v] [-xpchstop] [-xpg]
[-xport64[=v]] [-xprefetch[=a[,a]]
[-xprefetch_auto_type=[a] [-xprefetch_level[=l]]
[-xprofile=p] [-xprofile_ircache[=path]]
[-xprofile_pathmap=collect_prefix:use_prefix] [-xreduc-
tion] [-xregs=r[,r...]] [-xrestrict[=f]] [-xs]
[-xsafe=mem] [-xsb] [-xsbfast] [-xspace] [-xtarget=t]
[-xthreadvar[=o]] [-xtime] [-xtrigraphs[={yes|no}]]
[-xunroll=n] [-xustr={ascii_utf16_ushort|no}]
[-xvector[=a]] [-xvis] [-xwe] [-Yc,path] [-z arg]
[file] ...
Sun Studio 12: C++ 5.9 Compiler
A man page, by definition, is a quick reference. For more
detailed information on the C++ compiler and its options,
see the C++ User's Guide.
See the online readme file, viewable by calling
CC -xhelp=readme
for the latest important information on platforms, environ-
ments, new features, and software corrections.
Access all the installed Sun compilers and tools documenta-
tion, including readme files, user guides, and reference
manuals by pointing an HTML browser to the default installa-
tion directory:
file:/opt/SUNWspro/docs/index.html
Note - If your Sun compilers and tools are not installed in
the default /opt directory, ask your system administrator
for the equivalent path on your system.
COMPILING FOR 64-BIT PLATFORMS:
The way to specify compilation of a 32-bit or 64-bit binary
has changed in this release. The -xarch option no longer
carries an implicit memory model, 32-bit ILP32 or 64-bit
LP64, with each definition, and is now used only to specify
the instruction set of the target processor.
Use the new -m32 and -m64 options to specify the memory
model of the target compilation.
The ILP32 model specifies that C-language int, long, and
pointer data types are all 32-bits wide. The LP64 model
specifies that long and pointer data types are all 64-bits
wide. The Solaris and Linux OS also support large files and
large arrays under the LP64 memory model.
When compiling with -m64, the resulting executable will work
only on 64-bit UltraSPARC(R) or x86 processors under Solaris
OS or Linux OS running a 64-bit kernel. Compilation, link-
ing, and execution of 64-bit objects can only take place in
a Solaris or Linux OS that supports 64-bit execution.
SPECIAL x86 NOTES
There are some important issues to be aware of when compil-
ing for x86 Solaris platforms.
The legacy Sun-style parallelization pragmas are not
available on x86. Use OpenMP instead. See the OpenMP API
User's Guide for information on converting legacy paralleli-
zation directives to OpenMP.
Programs compiled with -xarch set to sse, sse2, sse2a, or
sse3 must be run only on platforms that provide these exten-
sions and features.
OS releases starting with Solaris 9 4/04 are SSE/SSE2-
enabled on Pentium 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 compiler and with same -xarch setting to ensure that the
correct startup routine is linked.
Numerical results on x86 might differ from results on SPARC
due to the x86 80-bit floating-point registers. To minimize
these differences, use the -fstore option or compile with
-xarch=sse2 if the hardware supports SSE2.
Numerical results can also differ between Solaris and Linux
because the intrinsic math libraries (for example, sin(x))
are not the same.
Binary Compatibility Verification
Starting with Sun Studio 11 and the Solaris 10 OS, program
binaries compiled and built using these specialized -xarch
hardware flags are verified that they are being run on the
appropriate platform.
On systems prior to Solaris 10, no verification is done and
it is the user's responsibility to ensure objects built
using these flags are deployed on suitable hardware.
Running programs compiled with these -xarch options on plat-
forms that are not enabled with the appropriate features or
instruction set extensions could result in segmentation
faults or incorrect results occurring without any explicit
warning messages.
This warning extends also to programs that employ .il inline
assembly language functions or __asm() assembler code that
utilize SSE, SSE2, SSE2a, and SSE3 instructions and exten-
sions.
New Sun Studio 12 Features
This section describes the new and changed features intro-
duced in the Sun Studio 12: C++ 5.9 compiler. See the Sun
Studio 12 C++ User's Guide for more detailed descriptions of
the new features.
This section describes the new and changed features intro-
duced in the Sun Studio 12: C 5.9 compiler. See the Sun Stu-
dio 12 C User's Guide for more detailed descriptions of the
new features.
o The C++ compiler is now available on the following
Linux distributions(x86 and x64):
o SuSE Linux Enterprise Server 9 with Service Pack 3
(or later).
o Red Hat Enterprise Linux 4.
o Other Linux distributions based on the 2.6 kernel
though these are not officially supported.
o Use -m64 to create 64-bit executables and shared
libraries.
o New flags for -xarch replace obsolete flags.
o New values for -xtarget and -xchip provide code gen-
eration for the UltraSPARC T2 and SPARC64vi proces-
sors.
o New flag -fma=fused to enable generation of fused
multiply-add instructions on processors that support
them.
o -xregs=frameptr added to -fast on x86.
o Support for interval arithmetic on Solaris x86 plat-
form with the -xarch=sse2 -xia options.
o Explicit prefetch macros accepted on x86 platforms as
well as SPARC platforms. (-xprefetch=explicit)
Overview of the C++ Compiler
CC converts C++ and assembly source files to object files,
and links object files and libraries into executable pro-
grams.
Programs that contain C++ objects must be linked with CC.
CC takes arguments ending in .c, .C, .cc, .cxx, .c++, .cpp,
or .i to be C++ source programs. Arguments ending in .s are
presumed to be assembly source files. Arguments ending in
.o are presumed to be object files.
Files whose names do not end with the above suffixes are
treated as object programs or libraries and are handed over
to the link editor. Unless -c, -S, -E, or -P is specified,
these programs and libraries, together with the results of
any specified compilations or assemblies, are linked in the
order given to produce an output file named a.out. You can
specify a different name for the executable by using the -o
option.
If a single file is compiled and linked all at once, the
intermediate files are deleted.
Before you use the CC command, insert into your search path
the name of the directory in which you have chosen to
install the C++ compilation system. For instructions on set-
ting your search path, see the csh(1) or the sh(1) man page.
OPTIONS
In general, compiler options are processed from left to
right (with the exception that the -U options are processed
after all -D options), allowing selective overriding of
macro options (options that include other options). This
rule does not apply to linker options.
For a complete description of the C++ compiler options,
including examples, see the C++ User's Guide.
CC accepts the following options.
-386 (x86 platform) Use -xtarget=386.
-486 (x86 platform) Use -xtarget=486.
-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 -Bbinding option, you must
include the option in the link step.
Warning:
Never use -Bsymbolic with programs containing C++
code, use linker scoping instead. See the C++
User's Guide for more information on linker scop-
ing. See also the -xldscope option.
With -Bsymbolic, references in different modules
can bind to different copies of what is supposed
to be one global object.
The exception mechanism relies on comparing
addresses. If you have two copies of something,
their addresses won't compare equal, and the
exception mechanism can fail because the exception
mechanism relies on 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 generated.
o If you enter CC -c x.cc -o y.o, the object
file, y.o, is generated.
Warnings:
When the compiler produces object code for an
input file (for example, .cc, .c, or .i), the com-
piler 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 preprocessor symbols.
The C++ compiler has two principal modes. The com-
patibility mode accepts the Annotated C++ Refer-
ence Manual (ARM) semantics and language defined
by the 4.2 compiler (-compat[=4]). The standard
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 significant, 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 compatibility to that of
the 4.0.1, 4.1, and 4.2 compilers.
Sets the __cplusplus preprocessor
macro to 1 and the
__SUNPRO_CC_COMPAT preprocessor
macro to 4).
-compat=5 (Standard mode) Set the language
and binary compatibility 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, -com-
pat=4 is assumed.
Interactions:
You cannot use the standard libraries in compati-
bility mode (-compat[=4]).
Use of -compat[=4] with any of the following
options is not supported.
o -Bsymbolic
o -features=[no%]strictdestorder
o -features=[no%]tmplife
o -library=[no%]iostream
o -library=[no%]Cstd
o -library=[no%]Crun
o -library=[no%]rwtools7_std
o -xarch=v9
o -xarch=v9a
o -xarch=v9b
Use of -compat=5 with any of the following options
is not supported.
o -Bsymbolic
o +e
o -features=[no%]arraynew
o -features=[no%]explicit
o -features=[no%]namespace
o -features=[no%]rtti
o -library=[no%]complex
o -library=[no%]libC
o -vdelx
Warnings:
When building a shared library do not use -Bsym-
bolic.
+d Prevents the compiler from expanding C++ inline
functions.
Under the C++ language rules, a C++ inline func-
tion is a function for which one of the following
statements is true.
o The function is defined using the inline key-
word.
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++ compiler 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 = 0x590
__SUNPRO_CC_COMPAT = 4 or 5
__TIME__
__cplusplus
__`uname -s`_`uname -r` (replacing invalid charac-
ters with underscores, for example: -D__SunOS_5_8,
-D__SunOS_5_9)
__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:
i386
linux
__amd64
__gnu__linux__
__i386
__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) -dalign is equivalent to -xmemalign=8s.
For more information, see -xmemalign.
-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 compilation 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 (-compat[=4]). This option is invalid and
ignored in standard mode (the default mode).
Values:
o +e0 suppresses the generation of virtual tables,
and creates external references to those that
are needed.
o +e1 creates virtual tables for all defined
classes with virtual functions.
Interactions:
When you compile with this option, also use the
-features=no%except option. Otherwise the com-
piler generates virtual tables for internal
types used in exception handling.
If template classes have virtual functions,
ensuring that the compiler generates all needed
virtual tables, but does not duplicate these
tables, might not be possible.
-erroff[=t[,t...] ]
Suppresses compiler warning messages but has no
effect on error messages. This option applies to
all warning messages whether or not they have been
designated by -errwarn to cause a non-zero exit
status.
Values:
The -erroff values are members of a comma-
separated list that consists of one or more of the
following:
tag Suppresses the warning message specified
by this tag. You can display the tag for
a message by using the -errtags=yes
option.
no%tag Enables the warning message specified by
this tag.
%all Suppresses all warning messages.
%none Enables all warning messages. This is the
default.
Order is important; for example, %all,no%tag
suppresses all warning messages except tag.
Defaults:
The default is -erroff=%none. Specifying -erroff
is equivalent to specifying -erroff=%all.
Warnings:
Only warning messages from the C++ compiler
front-end that display a tag when the -errtags
option is used can be suppressed with the -erroff
option.
-errtags [ = a]
Displays the message tag for each warning message
of the C++ compiler front-end that can be
suppressed with the -erroff option or made a fatal
error with the -errwarn option. Messages from the
C++ compiler driver and other components of the
C++ compilation system do not have error tags and
cannot be suppressed with -erroff and made fatal
with -errwarn.
Values and Defaults:
a can be either yes or no. The default is
-errtags=no. Specifying -errtags is equivalent to
specifying -errtags=yes.
-errwarn [ = t[,t...]]
Use the -errwarn option to cause the C++ compiler
to exit with a failure status for the given warn-
ing 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 message specified by tag is
issued only as a warning message. Has no
effect if tag is not issued. Use this
option to revert a warning message that
was previously specified by this option
with tag or %all from causing CC to exit
with a fatal status when issued as a
warning message.
%all Cause CC to exit with a fatal status if
any warning messages are issued. %all can
be followed by no%tag to exempt specific
warning messages from this behavior.
%none Prevents any warning messages from caus-
ing 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 display a tag when the -errtags
option is used can be specified with the -errwarn
option to cause the C++ compiler to exit with a
failure status.
See Also:
-erroff, -errtags
-fast This option is a macro that you can effectively
use as a starting point for tuning an executable
for maximum run-time performance. The expansion of
-fast can change from one release of the compiler
to the next and includes options that are target
platform specific. Use the -# or the -xdryrun
options to examine the expansion of -fast, and
incorporate the appropriate options of -fast into
the ongoing process of tuning the executable.
The expansion of -fast now includes the new -xlib-
mopt 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 applications by expanding the
following compilation options:
-fns (SPARC, x86)
-fsimple=2 (SPARC, x86)
-nofstore (x86)
-xarch (SPARC, x86)
-xbuiltin=%all (SPARC, x86)
-xcache (SPARC, x86)
-xchip (SPARC, x86)
-xdepend (SPARC, x86)
-xlibmil (SPARC, x86)
-xlibmopt (SPARC)
-xmemalign (SPARC)
-xO5 (SPARC, x86)
-xregs=frameptr (x86)
-xtarget=native (SPARC, x86)
Note that this selection of component option flags
is subject to change with each release of the com-
piler. For details on the options set by -fast,
see the C++ User's Guide.
To determine the expansion of -fast on a running
system, execute the command CC -fast -dryrun |&
grep ###
Interactions:
The code generation option, the optimization
level, the optimization of built-in functions, and
the use of inline template files can be overridden
by subsequent flags. For example, although the
optimization level set by -fast is -xO5, if you
specify -fast, -xO3, the optimization level
becomes -xO3. The optimization level that you
specify overrides a previously set optimization
level.
The -fast macro expands into compilation options
that may affect other specified options. For exam-
ple, 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 interactions.
Warnings:
Code compiled with the -fast option is not port-
able. For example, compiling code using the fol-
lowing command on an UltraSPARC(TM) III system
will generate a binary that will not execute on an
UltraSPARC II system.
example% CC -fast test.cc
Do not use this option for programs that depend on
IEEE standard floating-point exception handling;
different numerical results, premature program
termination, or unexpected SIGFPE signals might
occur.
The -fast option includes -fns -ftrap=%none; that
is, this option turns off all trapping.
In previous SPARC releases, the -fast macro
included -fnonstd, now it does not.
In previous SPARC releases, the -fast macro
expanded to -fsimple=1. Now it expands to -fsim-
ple=2.
In previous releases, the -fast macro expanded to
-xO4. Now it expands to -xO5.
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 (-com-
pat[=4]) unless otherwise specified.
Value Meaning
%all All the -feature options that are
valid for the specified mode (com-
patibility mode or standard mode).
%none Turn off all the features that can
be turned off for the specified
mode (compatibility mode or stan-
dard 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 con-
structs. When disabled (that is
-feature=no%anachronisms), no
anachronistic constructs are
allowed. The default is anachron-
isms.
[no%]arraynew (Compatibility mode only) [Do not]
Recognize array forms of operator
new and operator delete (for exam-
ple, 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++ exceptions are disabled (that
is, -features=no%except), a throw-
specification on a function is
accepted but ignored; the compiler
does not generate exception code.
Note that the keywords try, throw,
and catch are always reserved. The
default is except.
[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 compatibility
mode and localfor in standard mode.
[no%]mutable [Do not] Recognize the keyword mut-
able. The default is no%mutable in
compatibility mode and mutable in
standard mode.
[no%]namespace (Compatibility mode only) [Do not]
Recognize keywords namespace and
using. The default is
no%namespace.
The purpose of -features=namespace
is to aid in converting code to
standard mode. By enabling this
option, you get error messages if
you use these keywords as identif-
iers. The keyword recognition
options allow you to find uses of
the added keywords without having
to compile in standard mode.
[no%]nestedaccess
(Standard mode only) [Do not] Allow
nested classes to access private
members of the enclosing class.
[no%]rtti [Do not] Allow runtime type iden-
tification (RTTI). RTTI must be
enabled to use the dynamic_cast<>
and typeid operators. For -compat=4
mode, the default is no%rtti. Oth-
erwise, the default is
-features=rtti, and the option
-features=no%rtti is not allowed.
[no%]split_init
[Do not] Put initializers for non-
local static objects into indivi-
dual functions. When you use
-features=no%split_init, the com-
piler puts all the initializers in
one function. Using
-features=no%split_init minimizes
code size at the possible expense
of compile time. The default is
split_init.
[no%]strictdestorder
(Standard mode only) [Do not] Fol-
low the requirements specified by
the C++ standard regarding the
order of the destruction of objects
with static storage duration. The
default is strictdestrorder.
[no%]tmplife (Standard mode only) [Do not] Clean
up the temporary objects that are
created by an expression at the end
of the full expression, as defined
in the ANSI/ISO C++ Standard.
(When -features=no%tmplife is in
effect, most temporary objects are
cleaned up at the end of their
block.) The default is no%tmplife.
[no%]tmplrefstatic
[Do not] allow function templates
to refer to dependent static func-
tions or static function templates.
The default is the standard confor-
mant no%tmplrefstatic.
[no%]transitions
[Do not] allow ARM language con-
structs that are problematic in
standard C++ and that may cause the
program to behave differently than
expected or that may be rejected by
future compilers. When you use
-features=no%transitions, the com-
piler issues warnings about these
constructs instead of error mes-
sages. When you use
-features=transitions in compati-
bility mode (-compate[=4]), the
compiler displays the warnings
about these constructs only if +w
or -w2 is specified. The following
constructs are considered to be
transition errors: redefining a
template after it was used, omit-
ting the typename directive when it
is needed in a template definition,
and implicitly declaring type int.
The set of transition errors may
change in a future release. The
default is transitions.
Defaults:
If -features is not specified, the following is
assumed for compatibility mode (-compat[=4]):
-features=%none,anachronisms,except,split_init,transitions
If -features is not specified, the following is
assumed for standard mode (the default mode):
-features=%all,no%iddollar,no%extensions,no%tmplife
Interactions:
This option accumulates instead of overrides.
Use of the following in standard mode (the
default) is not compatible with the standard
libraries and headers:
o no%bool
o no%except
o no%mutable
o no%explicit
Warnings:
Be careful when you specify -features=%all or
-features=%none. The set of features can change
with each compiler release and with each patch.
Consequently, you can get unintended behavior.
The behavior of a program might change when you
use -features=tmplife. Testing whether the pro-
gram works both with and without the
-features=tmplife option is one way to test the
program's portability.
The compiler assumes -features=split_init by
default in compat mode (-compt=4). If you use the
-features=%none option to turn off other features,
you may find it desirable to turn the splitting of
initializers into separate functions back on by
using -features=%none,split_init instead.
-filt[=filter[,filter...]]
Suppress the filtering that CC normally applies to
linker error messages.
filter must be one of the following values
[no%]errors [Do not] Show the C++ explanations
of the linker error messages. The
suppression of the explanations is
useful when the linker diagnostics
are provided directly to another
tool.
[no%]names [Do not] Demangle the C++ mangled
linker names.
[no%]returns [Do not] Demangle the return types
of functions. Suppression of this
demangling helps you to identify
function names more quickly, but
note that in the case of co-variant
returns, some functions differ only
in the return type.
[ no% ] stdlib [Do not] Simplify names from the
standard library in both the linker
and compiler error messages. This
makes it easier for you to recog-
nize 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 com-
piler assumes -filt=errors,names,returns,stdlib.
Interactions:
[no%]returns has no effect when used with
no%names. That is, the following options are
equivalent:
-filt=no%names
-filt=no%names,no%returns
-filt=no%names,returns
See also c++filt(1).
-flags Same as -xhelp=flags.
-fma [= { none|fused}]
(SPARC) Enables automatic generation of floating-
point, fused, multiply-add instructions. -fma=none
disables generation of these instructions.
-fma=fused allows the compiler to attempt to find
opportunities to improve the performance of the
code by using floating-point, fused, multiply-add
instructions.
The default is -fma=none.
The minimum requirements are -xarch=sparcfmaf and
an optimization level of at least -xO2 for the
compiler to generate fused multiply-add instruc-
tions. 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 support them.
-fnonstd
This option causes hardware traps to be enabled
for floating-point overflow, division by zero, and
invalid operations exceptions.
These results are converted into SIGFPE signals.
If the program has no SIGFPE handler, it ter-
minates with a memory dump (unless you limit the
core dump size to 0).
SPARC: In addition, -fnonstd selects SPARC non-
standard floating point.
Defaults:
If -fnonstd is not specified, IEEE 754 floating-
point arithmetic exceptions do not abort the pro-
gram, 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 Numeri-
cal 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
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 gra-
dual underflow and subnormal numbers in hardware,
use of this option can significantly improve the
performance of some programs.
Optional use of =yes or =no provides a way of tog-
gling the -fns flag following some other macro
flag that includes -fns, such as -fast.
-fns is the same as -fns=yes.
-fns=yes selects non-standard floating point.
-fns=no selects standard floating point.
Defaults:
If -fns is not specified, the nonstandard
floating-point mode is not enabled automatically.
Standard IEEE 754 floating-point computation takes
place, that is, underflows are gradual.
If only -fns is specified -fns=yes is assumed.
Warnings:
When nonstandard mode is enabled, floating-point
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 unexpected results.
-fprecision=a
(x86 platform) Sets floating-point rounding preci-
sion mode. a must be one of: single, double,
extended.
The -fprecision flag sets the rounding precision
mode bits in the Floating Point Control Word.
These bits control the precision to which the
results of basic arithmetic operations (add, sub-
tract, 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 avail-
able
When a is single or double, this flag causes the
rounding precision mode to be set to single or
double precision, respectively, when a program
begins execution. When p is extended or the -fpre-
cision 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
significant bits. This mode controls only the pre-
cision 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 precision 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 con-
stant expressions.
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 unex-
pected 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 optimize completely without
regard to roundoff or exceptions. In
particular, a floating point computation
cannot be replaced by one that produces
different results with rounding modes
held constant at runtime.
With -fsimple=1, the optimizer can
assume the following:
o IEEE 754 default rounding/trapping
modes do not change after process ini-
tialization.
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 -fsim-
ple=1, and also enables the use of SIMD
instructions to compute reductions when
-xvector=simd is in effect.
Also permits aggressive floating point
optimization that may cause many pro-
grams to produce different numeric
results due to changes in rounding. For
example, permits the optimizer to
replace all computations of x/y in a
given loop with x*z, where x/y is
guaranteed to be evaluated at least once
in the loop, z=1/y , and the values of y
and z are known to have constant values
during execution of the loop.
Defaults:
If -fsimple is not designated, the compiler uses
-fsimple=0.
If -fsimple is designated but no value is given
for n, the compiler uses -fsimple=1.
Warnings:
This option can break IEEE 754 conformance.
See Also:
Techniques for Optimizing Applications: High Per-
formance Computing written by Rajat Garg and Ilya
Sharapov for a more detailed explanation of how
optimization can impact precision.
-fstore (x86 platform) Forces precision of floating-point
expressions.
This option causes the compiler to convert the
value of a floating-point expression or function
to the type on the left side of an assignment -
when that expression or function is assigned to a
variable, or when that expression is cast to a
shorter floating-point type rather than leaving
the value in a register.
To turn off this option, use the -nofstore option.
Warnings:
Due to roundoffs and truncation, the results may
be different from those that are generated from
the 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 simul-
taneously 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 par-
ticular trap to be disabled.
Defaults:
If you do not specify -ftrap, the compiler assumes
-ftrap=%none.
Example: -ftrap=%all,no%inexact means to set all
traps except inexact.
Warnings:
If you compile one routine with -ftrap, compile
all routines of the program with the same -ftrap
option; otherwise, you can get unexpected results.
Use the -ftrap=inexact trap with caution, as it
will result in the trap being issued whenever a
floating-point value cannot be represented
exactly. For example, the following statement may
generate this condition:
x = 1.0 / 3.0;
-G Build a dynamic shared library instead of an exe-
cutable 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 tem-
plates, it is necessary in most cases to include
in the shared library those template functions
that are instantiated in the template database.
Using this option automatically adds those tem-
plates 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 docu-
mented under the description of -xcode.
The following options are passed to ld if -c is
not specified:
o -dy
o -G
o -R
Do not use ld -G to build shared libraries; use CC
-G. The CC driver automatically passes several
options to ld that are needed for C++.
When you use the -G option, the compiler does not
pass any default -l options to ld. If you want the
shared library to have a dependency on another
shared library, you must pass the necessary -l
option on the command line. For example, if you
want the shared library to be dependent upon lib-
Crun, 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 lim-
ited debugging information. For more information,
see the entry for -xO.
If you specify -gO and the optimization level is
-xO3 or lower, the compiler provides best-effort
symbolic information with almost full optimiza-
tion. 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 optimiza-
tion.
When you specify this option, the +d option is
specified automatically.
To use the full capabilities of the Performance
Analyzer, compile with the -g option. While some
performance analysis features do not require -g,
you must compile with -g to view annotated source,
some function level information, and compiler com-
mentary messages. See the analyzer(1) man page and
the Performance Analyzer manual for more informa-
tion.
The commentary messages that are generated with -g
describe the optimizations and transformations
that the compiler made while compiling your pro-
gram. 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 pro-
gram for debugging, but not to disable inlining.
This option is the same as -g, except that +d is
disabled and dbx cannot step into inlined func-
tions.
See also:
+d
-H On the standard error output (stderr), prints, one
per line, the path name of each #include file con-
tained in the current compilation.
-h[ ]lname
Assigns the name lname to the generated shared
dynamic library.
This is a loader option that is passed to ld. In
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 #include files with relative file
names - those that do not begin with a slash.
The compiler searches for quote-included files (of
the form #include "foo.h") in this order:
1. In the directory containing the source
2. In the directories named with -I options, if
any
3. In the include directories for compiler-
provided C++ header files, ANSI C header
files, and special-purpose files
4. In /usr/include
The compiler searches for bracket-included files
(of the form #include <foo.h>) in this order:
1. In the directories named with -I options, if
any
2. In the include directories for compiler-
provided C++ header files, ANSI C header
files, and special-purpose files
3. In /usr/include
Note - If the spelling matches the name of a stan-
dard 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 recom-
mended that you use -Ipathname instead of
-ptipath.
Warnings
Never specify the compiler installation area,
/usr/include, /lib, /usr/lib, as search direc-
tories.
-I- Change the include-file search rules to the fol-
lowing:
o For include files of the form #include
"foo.h", search the directories in the fol-
lowing 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 fol-
lowing 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 direc-
tories.
Only the first -I- in a command line causes the
described behavior.
-i Tells the linker, ld(1), to ignore any
LD_LIBRARY_PATH setting.
-inline Same as -xinline.
-instances=a
Controls the placement and linkage of template
instances. The following table shows the meanings
of the values of a.
Value Meaning
extern Places all needed instances into the
template repository within comdat sec-
tions 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 compilation
step, you must also specify it for the
link step.
explicit Places explicitly instantiated instances
into the current object file within com-
dat sections and gives them global link-
age. Does not generate any other needed
instances.
global Places all needed instances into the
current object file within comdat sec-
tions 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 disad-
vantages. 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 informa-
tion.
-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 contains the existing template instances.
The filename argument must contain a forward slash
'/' character. For paths relative to the current
directory, use dot-slash './'.
Defaults:
The -instlib=file option has no default and is
only used if you specify it. This option can be
specified multiple times and accumulates.
Example:
Assume that the libfoo.a and libbar.so libraries
instantiate many template instances that are
shared with your source file a.cc. Adding
-instlib=file and specifying the libraries helps
reduce compile time by avoiding the redundancy.
example% CC -c -instlib=./libfoo.a
-instlib=./libbar.so a.cc
Interactions:
When you compile with -g, if the library specified
with -instlib=file is not compiled with -g, those
template instances will not be debuggable. The
workaround is to avoid -instlib=file when you use
-g.
The -L path is not searched to find file.
Warning
If you specify a library with -instlib, you must
link with that library.
See Also:
-template, -instances, -pti
-KPIC (SPARC) Obsolete. You should not use this option.
Use -xcode=pic32 instead.
(x86) Same as -Kpic on x86 architectures.
-Kpic (SPARC) Obsolete. You should not use this option.
Use -xcode=pic13 instead.
(x86) Produces position-independent code. Use this
option to compile source files when building a
shared library. Each reference to a global datum
is generated as a dereference of a pointer in the
global offset table. Each function call is gen-
erated in pc-relative addressing mode through a
procedure linkage table.
-keeptmp Retains the temporary files that are created dur-
ing 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 direc-
tories.
-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 appli-
cation 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 dur-
ing 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 arithmetic.
[no%]interval Deprecated. Do not use. Use
-xia.
[no%]libC [Do not] Use libC, the C++
support library.
[no%]gc [Do not] Use libgc, garbage
collection.
[no%]sunperf [Do not] Use the Sun Perfor-
mance 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-provided
C++ standard library header
files.
[no%]stlport4 [Do not] Use STLport's imple-
mentation 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%]Crun [Do not] Use libCrun, the C++
runtime library
[no%]gc [Do not] Use libgc, garbage
collection.
[ no% ]sunperf [Do not] Use the Sun Perfor-
mance Library (TM).
%none Use no C++ libraries except
for libCrun.
Defaults:
For compatibility mode (-compat[=4]), if -library
is not specified, -library=libC is assumed.
The libC library is always included unless it is
specifically excluded using -library=no%libC.
For standard mode (the default mode), the libCstd
library is always included unless it is specifi-
cally excluded by using -library=%none,
-library=no%Cstd, or -library=stlport4.
Also, regardless of standard or compat mode, the
libm and libc libraries are always included, even
if you specify -library=%none. In standard mode,
libCrun is always included.
Examples:
To link in standard mode (the default mode)
without any C++ libraries (except libCrun), use:
example% CC -library=%none
To include the classic-iostreams Rogue Wave
tools.h++ library in standard mode, use:
example% CC -library=rwtools7,iostream
To include the standard-iostreams Rogue Wave
tools.h++ library in standard mode, use:
example% CC -library=rwtools7_std
To include the classic-iostreams Rogue Wave
tools.h++ library in compatibility mode, use:
example% CC -compat -library=rwtools7
When you include the classic-iostreams Rogue Wave
tools library in standard mode (the default mode),
you must also include libiostream (see the C++
Migration Guide for additional information). You
can use the standard-iostreams Rogue Wave tools
library in standard mode only. The following com-
mand 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 stan-
dard iostream code.
Programs linking neither libC nor libCrun might
not use all features of the C++ language.
If -xnolib is specified, -library is ignored.
Interactions:
If a library is specified with -library, the
proper -I paths are set during compilation. The
proper -L, -Y, -P, -R, paths and -l options are
set during linking.
This option accumulates instead of overrides.
Only one rwtool library can be used at a time and
you cannot use any rwtool library with
-library=stlport4.
You cannot use -library=stlport4 and -library=Cstd
on the same command line.
You cannot use -library=sunperf and
-xlic_lib=sunperf on the same command line.
Use of the -library option ensures that the -l
options for the specified libraries are emitted in
the right order. For example, the -l options are
passed to ld in the order -lrwtool -liostream for
both -library=rwtools7,iostream and
-library=iostream,rwtools7.
When you use the interval arithmetic libraries,
you must include one of the following libraries:
libC, libCstd, or libiostreams.
The specified libraries are linked before the sys-
tem 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-
operate so modifying the configuration macros
results in programs that will not compile, will
not link, or do not run properly.
If you compile and link in separate steps, the set
of -library options that appear in the compile
command must appear in the link command.
The set of libraries is not stable and might
change from release to release.
The stlport4, Cstd and iostream libraries provide
their own implementation of I/O streams. Specify-
ing more than one of these with the -library
option can result in undefined program behavior.
See also:
-I,-l,-R, -staticlib, -xia, -xlang, -xnolib,
C++ 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 plat-
forms 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 plat-
forms 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 can-
not be linked with object files or libraries com-
piled 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.
Note that in previous compiler releases, the
memory model, ILP32 or LP64, was implied by the
choice of the instruction set with -xarch. Start-
ing with the Sun Studio 12 compilers, this is no
longer the case. On most platforms, just adding
-m64 to the command 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 sec-
tion 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 platform) Permits misaligned data, which
would otherwise generate an error, in memory.
This option informs the compiler that some data in
your program is not properly aligned. Thus, very
conservative loads and stores must be used for any
data that might be misaligned, that is, one byte
at a time. Using this option may cause significant
degradation in runtime performance. The amount of
degradation is application dependent.
If you compile and link in separate steps and are
using the -misalign option, you must include the
option in both steps.
If possible, do not link aligned and misaligned
parts of the program.
Interactions:
o When using #pragma pack on a SPARC platform to
pack denser than the type's default alignment,
the -misalign option must be specified for both
the compilation and the linking of the applica-
tion.
o Misaligned data is handled by a trap mechanism
that is provided by ld(1) at run-time. If an
optimization flag (-xO{1|2|3|4|5} or an
equivalent flag) is used with the -misalign
option, the additional instructions required for
alignment of misaligned data are inserted into
the resulting object file and will not generate
runtime misalignment traps.
-mr[,string]
Removes all strings from the .comment section of
the object file and, if string is supplied, places
string in that section. If the string contains
blanks, the string must be enclosed in quotation
marks. When you use this option, the command mcs
-d [-a string] is invoked.
Interactions:
This option is not valid when either -S, -xsbfast,
or -sbfast is specified.
-mt Compile and link for multithreaded code.
This option passes -D_REENTRANT to the preproces-
sor and passes -lthread in the correct order to
ld.
The -mt option is required if the application or
libraries are multithreaded.
Warnings:
To ensure proper library linking order, you must
use this option, rather than -lthread, to link
with libthread.
If you are using POSIX threads, you must link with
the options -mt -lpthread. The -mt option is
necessary because libC (compatibility mode) and
libCrun (standard mode) need libthread for a mul-
tithreaded application.
If you compile and link in separate steps and you
compile with -mt, you might get unexpected
results. If you compile one translation unit with
-mt, compile all units of the program with -mt.
If you are mixing parallel Fortran objects with
C++ objects, the link line must specify the -mt
flag.
C99 support is not available in compat mode (-com-
pat=4).
See also:
-xnolib
-native Use -xtarget=native.
-noex Use -features=no%except.
-nofstore (x86 platform) Disables forced precision of
expression.
This option does not force the value of a
floating-point expression or function to the type
on the left side of an assignment but leaves the
value in a 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 compiling. A nonzero
status is returned for testing makefiles.
-norunpath
Does not build the path for shared libraries into
the executable.
If an executable file uses shared libraries, then
the compiler normally builds in a path that points
the 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 execut-
ables 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
/opt/SUNWspro/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 loca-
tion of the shared libraries. This will allow the
runtime linker to find the shared libraries.
-O The -O macro now expands to -xO3 instead of -xO2.
The change in default yields higher run-time per-
formance. However, -xO3 may be inappropriate for
programs that rely on all variables being automat-
ically considered volatile. Typical programs that
might have this assumption are device drivers and
older multi-threaded applications that implement
their own synchronization primitives. The work
around is to compile with -xO2 instead of -O.
-O[level] Use -xOlevel.
-o filename
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 reposi-
tory in the output file's directory.
Warning:
filename must have the appropriate suffix for the
type of file to be produced by the compilation
(see FILES). It cannot be the same file as the
source file, since the CC driver does not
overwrite the source file.
+p Ignore non-standard preprocessor asserts.
Defaults:
If +p is not present, the compiler asserts.
Interactions:
If +p is used, the sun, unix, sparc, and i386 mac-
ros are not defined.
-P Only preprocesses source: does not compile. (Out-
puts 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 tem-
plate 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 pro-
duces less confusion.
Interactions:
This option accumulates instead of overrides.
-pto Use -instances=static.
-ptrpath This option is obsolete and is ignored by the com-
piler.
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 dif-
ferent behavior.
-ptv Use -verbose=template.
-Qoptionphase[,option...]
Passes option to the compilation phase.
To pass multiple options, specify them in order as
a comma-separated list. Options that are passed to
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
-zdefaultextract ... // error
the -z options can be reordered, giving incorrect
results.
The following table shows the possible values for
phase.
SPARC x86
ccfe ccfe
iropt 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 exam-
ple
-Qoption ccfe -features=bool,iddollar
is interpreted as
-Qoption ccfe -features=bool -Qoption ccfe iddol-
lar
The correct usage is
-Qoption ccfe -features=bool,-features=iddollar
-qoption phase option
Use -Qoption.
-qp Same as -p.
-Qproduce sourcetype
Causes the CC driver to produce source code of the
type sourcetype. Source code types are shown in
the following table.
Value Meaning
.i Preprocessed C++ source from ccfe
.o Object file from the code generator
.s Assembler source from the code gen-
erator
-qproduce sourcetype
Use -Qproduce.
-Rpath[:path...]
Builds dynamic library search paths into the exe-
cutable file.
This option is passed to ld.
Defaults:
If the -R option is not present, the library
search path that is recorded in the output object
and passed to the runtime linker depends upon the
target architecture instruction specified by the
-xarch option (when -xarch is not present) are
concatenated, with each -xarch-generic is
assumed).
For -xarch=v9, -xarch=v9a, or -xarch=v9b:
<install-directory>/SUNWspro/lib/v9
For any other -xarch value:
<install-directory>/SUNWspro/lib
In a default installation, <install-directory> is
/opt.
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 assem-
ble 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 func-
tionality is obsolete.
-sbfast Deprecated - do not use. The source browser func-
tionality is obsolete.
-staticlib=l[,l...]
Indicates which C++ libraries specified by the
-library option (including its defaults), by the
-xlang option, and by the -xia option are to be
linked statically.
Values:
l must be one of the following values.
Value Meaning
[no%]library [Do not] link library statically.
The valid values for library are
all valid values for -library
(except %all and %none ) all the
valid values for -xlang, and inter-
val (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 interval libraries statically.
Defaults:
If -staticlib is not specified, -staticlib=%none
is assumed.
Interactions:
This option accumulates instead of overrides.
The -staticlib option only works for the C++
libraries that are selected explicitly with the
-xia, the -xlang option, and the -library option,
in addition to the C++ libraries that are selected
implicitly by default. In compatibility mode
(-compat=[4]), libC is selected by default. In
standard mode (the default mode), Cstd and Crun
are selected by default.
Examples:
The following command links libCrun statically
because Crun is a default value for -library.
(correct)
example% CC -staticlib=Crun test.cc
However, the following command does not link libgc
because libgc is not linked unless explicitly
specified with the -library option.
(incorrect)
example% CC -staticlib=gc test.cc
With the following command, the librwtool library
is linked dynamically. Because librwtool is not a
default library and is not selected using the
-library option, -staticlib has no effect.
(incorrect)
example% CC -lrwtool -library=iostream \
-staticlib=rwtools7
This command links the Tools.h++ library stati-
cally.
(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 stati-
cally on any platform. In some cases, static link-
ing can prevent a program from working.
-sync_stdio=[yes|no]
Use this option when your run-time performance is
degraded due to the synchronization between C++
iostreams and C stdio. Synchronization is needed
only when you use iostreams to write to cout and
stdio to write to stdout in the same program. The
C++ standard requires synchronization so the C++
compiler turns it on by default. However, applica-
tion performance is often much better without syn-
chronization. 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 scram-
bled.
Warnings:
This option is only effective for linking of exe-
cutables, not for libraries.
-temp=path
Defines the directory for temporary files.
This option sets path as the directory for the
temporary files generated during the compilation
process.
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 expli-
citly 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 com-
mand line by the command-line driver, add the
-dryrun option to your command line.
You can specify multiple -U options on the command
line.
Examples:
The following command undefines the predefined
symbol __sun. Preprocessor statements in test.cc
such as #ifdef(__sun) will sense that the symbol
is undefined.
example% CC -U__sun test.cc
Interactions:
This option accumulates instead of overrides.
All -U options are processed after any -D options
that are present.
-unroll=n Same as -xunroll=n.
-V Same as -verbose=version.
-v Same as -verbose=diags.
-vdelx Deprecated, do not use. This flag is available
only for compatibility mode (-compat[=4]).
For expressions using delete[], this option gen-
erates a call to the runtime library function
_vector_deletex_ instead of generating a call to
_vector_delete_.
The function _vector_delete_ takes two arguments:
the pointer to be deleted and the size of each
array element.
The function _vector_deletex_ behaves the same as
_vector_delete_ except that it takes an addi-
tional third argument: the address of the des-
tructor 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 gen-
erates 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 ven-
dor 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 instan-
tiation as it occurs during
compilation.
[no%]diags [Do not] Print the command
line for each compilation
pass.
[no%]version [Do not) Direct the CC driver
to print the names and version
numbers of the programs it
invokes.
%all Invokes all the above.
%none Invokes none of the above.
Defaults:
If -verbose is not specified, the compiler assumes
-verbose=%none.
Interactions:
This option accumulates instead of overrides.
+w Identifies code that might have unintended conse-
quences. The +w option no longer generates a warn-
ing 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 technical violations that are probably harm-
less, but that might reduce the maximum portabil-
ity 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 warn-
ing messages. Some warnings, particularly warn-
ings regarding serious anachronisms, cannot be
suppressed.
-Xm Use -features=iddollar.
-xa Generates code for profiling.
If set at compiler time, the TCOVDIR environment
variable specifies the directory where the cover-
age (.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 coverage 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 compati-
ble 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 sin-
gle 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.
-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 com-
piler 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 fun-
damental 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 layout compatible with the
dynamic type of the corresponding storage
object. Two types are layout-compatible under
the following conditions:
* If two types are the same type, then they are
layout-compatible types.
* If two types differ only in constant or
volatile qualification, then they are
layout-compatible types.
* For each of the signed integer types, there
exists a corresponding (but different)
unsigned integer type. These corresponding
types are layout compatible.
* Two enumeration types are layout-compatible if
they have the same underlying type.
* Two Plain Old Data (POD) struct types are
layout compatible if they have the same number
of members, and corresponding members
(in order) have layout compatible types.
* Two POD union types are layout compatible
if they have the same number of members, and
corresponding members (in any order) have
layout compatible types.
References may be non-layout-compatible with the
dynamic type of the storage object under limited
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 optimization level -xO2 and below.
-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 instan-
tiated 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 func-
tions 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 com-
piler 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 instruc-
tions. 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 compatibil-
ity with previous releases, as indicated below.
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 implementation-specific
ISA extensions. This option enables the
compiler to generate code for good per-
formance 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
extensions.
sparcfmaf Compile for the sparcfmaf version of the
SPARC-V9 ISA.
Enables the compiler to use instructions
from the SPARC-V9 instruction set, plus
the UltraSPARC extensions, including the
Visual Instruction Set (VIS) version
1.0, the UltraSPARC-III extensions,
including the Visual Instruction Set
(VIS) version 2.0, and the SPARC64 VI
extensions for floating-point multiply-
add.
Note that you must use -xarch=sparcfmaf
in conjunction with -fma=fused and some
optimization level to get the compiler
to attempt to find opportunities to use
the multiply-add instructions automati-
cally.
v9 Is equivalent to -m64 -xarch=sparc
Legacy makefiles and scripts that use
-xarch=v9 to obtain the 64-bit memory
model need only use -m64.
v9a Is equivalent to -m64 -xarch=sparcvis
and is provided for compatibility with
earlier releases.
v9b Is equivalent to -m64 -xarch=sparcvis2
and is provided for compatibility with
earlier releases.
Notes:
o Legacy 32-bit SPARC instruction set architec-
tures V7 and V8 imply -m32 and cannot be com-
bined 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 compa-
tible platform.
For any particular choice, the generated execut-
able 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
386 Limits the instruction set to the Intel
32-bit 386/486 architecture.
pentium_pro
Limits the instruction set to the 32-bit
pentium_pro architecture.
sse Adds the SSE instruction set to the
pentium_pro instruction set.
sse2 Adds the SSE2 instruction set to the
pentium_pro instruction set.
amd64 Is equivalent to -m64 -xarch=sse2
(Solaris only)
Legacy makefiles and scripts that use
-xarch=amd64 to obtain the 64-bit memory
model need only use -m64.
pentium_proa
Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the
pentium_pro architecture.
ssea Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the
32-bit SSE architecture.
sse2a Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the
SSE2 architecture.
amd64a Is equivalent to -m64 -xarch=sse2a
(Solaris only)
sse3 Adds the SSE3 instruction set to SSE2
instruction set.
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.
Defaults:
If -xarch=isa is not specified, the defaults
are:
-xarch=sparc on SPARC platforms
-xarch=386 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 paral-
lelization directives.
Avoid -xautopar if you do your own thread manage-
ment.
To get faster execution, this option requires a
multiple processor system. On a single-processor
system, the resulting binary usually runs slower.
To run a parallelized program in a multithreaded
environment, you must set the OMP_NUM_THREADS
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 run-
time 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 compila-
tion, 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 stan-
dard 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 func-
tions can be generated inline directly by the com-
piler. See the er_src(1) man page for an explana-
tion of how to read compiler commentary in object
files to determine for which functions the com-
piler actually makes a substitution.
-xbuiltin=%all asks the compiler to recognize as
many of the built-in standard functions as possi-
ble. The exact list of recognized functions
varies with the version of the compiler code gen-
erator.
-xbuiltin=%none is the default behavior.
Defaults:
If the -xbuiltin option is not specified, the com-
piler assumes -xbuiltin=%none. If only -xbuiltin
is specified, the compiler assumes -xbuiltin=%all.
-xcache=c Defines the cache properties for use by the optim-
izer.
This option specifies the cache properties that
the optimizer can use. It does not guarantee that
any particular cache property is used.
Although this option can be used alone, it is part
of the expansion of the -xtarget option; its pri-
mary 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 proper-
ties, s1/l1/a1.
The following table shows the -xcache values.
Value Meaning
generic Defines the cache properties for
good performance on most SPARC pro-
cessors.
This is the default value which
directs the compiler to use cache
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 environ-
ment.
s1/l1/a1 Defines level 1 cache properties.
s1/l1/a1:s2/l2/a2
Defines levels 1 and 2 cache pro-
perties.
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 sup-
port SPARC V7 architecture. 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 vari-
ables 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 specified. Therefore, CHAR_MAX
and CHAR_MIN no longer represent the range of
values encodable in a plain char.
Warnings:
If you use -xchar, be particularly careful when
you compare a char against a predefined system
macro because the value in the macro may be
signed. This is most common for any routine that
returns an error code which is accessed through a
macro. Error codes are typically negative values
so when you compare a char against the value from
such a macro, the result is always false. A nega-
tive 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 speci-
fies type char as signed, and system libraries
behave accordingly. The effect of making char
unsigned has not been extensively tested with sys-
tem 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 mul-
tithreaded program. If a stack
overflow is detected, a SIGSEGV is
generated. If your application
needs to handle a SIGSEGV caused by
a stack overflow differently than
it handles other address-space vio-
lations, 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 expansion of the -xtarget option; its pri-
mary use is to override a value supplied by the
-xtarget option.
This option specifies timing properties by speci-
fying the target processor.
This option affects:
o The ordering of instructions, that is, schedul-
ing
o The way the compiler uses branches
o The instructions to use in cases where semanti-
cally 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 pro-
perties for good performance on most
SPARC processors, without major perfor-
mance degradation on any of them.
native Set the parameters for the best perfor-
mance on the host environment.
sparc64vi Optimize for the SPARC64 VI processor.
super Optimize for the SuperSPARC processor.
super2 Optimize for the SuperSPARC II proces-
sor.
micro Optimize for the MicroSPARC(TM) proces-
sor.
micro2 Optimize for the MicroSPARC II proces-
sor.
hyper Optimize for the HyperSPARC(TM) proces-
sor.
hyper2 Optimize for the HyperSPARC II proces-
sor.
ultra Optimize for the UltraSPARC(TM) proces-
sor.
ultra2 Optimize for the UltraSPARC II proces-
sor.
ultra2e Optimize for the UltraSPARC IIe proces-
sor.
ultra2i Optimize for the UltraSPARC IIi proces-
sor.
ultra3 Optimize for the UltraSPARC III proces-
sor.
ultra3cu Optimize for the UltraSPARC IIIcu pro-
cessor.
ultra3i Optimize for the UltraSPARC IIIi proces-
sor.
ultra4 Optimize for the UltraSPARC IV
processor.
ultra4plus
Optimize for the UltraSPARC IVplus pro-
cessor.
ultraT1 Optimize for the UltraSPARC T1 proces-
sor.
ultraT2 Optimize for the UltraSPARC T2 proces-
sor.
The -xchip values for x86 platforms are:
Value Meaning
generic Optimize for good performance on most
x86 processors.
native Optimize for this host processor.
386 Optimize for the Intel 386 processor.
486 Optimize for the Intel 486 processor.
opteron Optimize for the AMD Opteron processor.
pentium Optimize for the Intel Pentium proces-
sor.
pentium_pro
Optimize for the Intel Pentium Pro pro-
cessor.
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 and
with -xarch=v8 -xcode=abs32, but these will be
inefficient. Shared objects built with -xarch=v9
-xcode=abs32 or -xarch=v9 -xcode=abs44 will not
work.
The following table shows the -xcode values.
Value Meaning
abs32 Generate 32-bit absolute addresses,
which are fast, but have limited range.
Code + data + bss size is limited to
2**32 bytes. This is the default on
32-bit architectures.
abs44 SPARC: Generate 44-bit absolute
addresses, which have moderate speed and
moderate range. Code + data + bss size
is limited to 2**44 bytes. This is the
default on 64-bit 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 archi-
tectures.
pic13 Generates position-independent code
(small model), which is fast, but has
limited range. Equivalent to -Kpic. Per-
mits references to at most 2**11 unique
external symbols on 32-bit architec-
tures, 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 architec-
tures, 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 elf-
dump(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 deter-
mine 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 architec-
tures.
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]
(SPARC Platform) Enables optimization and inlining
across source files. -xcrossfile works at compile
time and involves only the files that appear on
the compilation command. Consider the following
command-line example:
example% CC -xcrossfile -xO4 -c f1.cc f2.cc
example% CC -xcrossfile -xO4 -c f3.cc f4.cc
Cross-module optimizations occur between files
f1.cc and f2.cc, and between f3.cc and f4.cc. No
optimizations occur between f1.cc and f3.cc or
f4.cc.
Values:
n must be one of the following values.
Value Meaning
0 Do not perform cross-file optimiza-
tions or cross-file inlining.
1 Perform optimization and inlining
across source files.
Normally the scope of the compiler's analysis is
limited to each separate file on the command line.
For example, when the -xO4 option is passed,
automatic inlining is limited to subprograms
defined and referenced within the same source
file. With -xcrossfile or -xcrossfile=1, the com-
piler analyzes all the files named on the command
line as if they had been concatenated into a sin-
gle source file.
However, this option has no effect when you direct
the compiler to produce assembly source by speci-
fying the -S option. Assembly (.s) files do not
participate in optimizations and inlining across
source files.
Defaults:
If -xcrossfile is not specified, -xcrossfile=0 is
assumed and no cross-file optimizations or inlin-
ing are performed. -xcrossfile is the same as
-xcrossfile=1.
Interactions:
The -xcrossfile option is effective only when it
is used with -xO4 or -xO5.
Warnings:
The files produced from this compilation are
interdependent due to possible inlining, and must
be used as a unit when they are linked into a pro-
gram. If any one routine is changed and the files
recompiled, they must all be recompiled. As a
result, using this option affects the construction
of makefiles.
See Also:
-xldscope, -xipo
-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 format to the dwarf for-
mat.
Use this option as a way of accessing the new for-
mat 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 informa-
tion using the stabs standard format.
-xdebugformat=dwarf generates debugging informa-
tion using the dwarf standard format.
If you do not specify -xdebugformat, the compiler
assumes -xdebugformat=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 con-
trolled with this option. So -xdebugformat has a
an effect even when -g is not used.
The dbx and Performance Analyzer software under-
stand both stabs and dwarf format so using this
option does not have any effect on the functional-
ity 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 dependen-
cies and performs loop restructuring.
Loop restructuring includes loop interchange, loop
fusion, scalar replacement, and elimination of
"dead" array assignments. If optimization is not
at -xO3 or higher, the compiler raises the optimi-
zation to -xO3 and issues a warning.
If you do not specify -xdepend, the default is
-xdepend=no which means the compiler does not
analyze loops for data dependencies. If you
specify -xdepend but do not specify an argument,
the compiler sets the option to -xdepend=yes which
means the compiler analyzes loops for data depen-
dencies.
Dependency analysis is included in -xautopar. The
dependency analysis is done at compile time.
Dependency analysis may help on single-processor
systems. However, if you try -xdepend on single-
processor systems, you should not use -xautopar.
If you do so, the -xdepend optimization is done
for multiple-processor systems.
See Also: -xprefetch_auto_type
-xdumpmacros[=value[,value...]]
Use this option when you want to see how macros
are behaving in your program. This option provides
information such as macro defines, undefines, and
instances of usage. It prints output to the stan-
dard error (stderr), based on the order macros are
processed. The -xdumpmacros option is in effect
until the end of the file or until it is overrid-
den by the dumpmacros or end_dumpmacros pragma.
Values:
Value Meaning
[no%]defs [Do not] Print all macro defines
[no%]undefs [Do not] Print all macro undefines
[no%]use [Do not] Print information about
macros used
[no%]loc [Do not] Print location (path name
and line number) also for defs,
undefs, and use
[no%]conds [Do not] Print use information for
macros used in conditional direc-
tives
[no%]sys [Do not] Print all macros defines,
undefines, and use information for
macros in system header files
%all Sets the option to
-xdumpmacros=defs,undefs,use,loc,conds,sys.
A good way to use this argument is
in conjunction with the [no%] form
of the other arguments. For exam-
ple, -xdumpmacros=%all,no%sys would
exclude system header macros from
the output but still provide infor-
mation for all other macros.
%none Do not print any macro information
The option values accumulate so specifying
-xdumpmacros=sys -xdumpmacros=undefs has the same
effect as -xdumpmacros=undefs,sys.
Note: The sub-options loc, conds, and sys are
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 -xdumpmacros,
it defaults to -xdumpmacros=%none.
-xe Check only for syntax and semantic errors. When
you specify -xe the compiler does not produce any
object code. The output for -xe is directed to
stderr.
Use the -xe option if you do not need the object
files produced by compilation. For example, if you
are trying to isolate the cause of an error mes-
sage 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 func-
tions and/or data variables into separate section
fragments, which enables the linker, using direc-
tions 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 program 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 map-
file 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 sections.
[no%]gbldata [Do not] fragment global data
(variables with external linkage)
into separate sections.
[no%]lcldata [Do not] fragment local data (vari-
ables 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 argu-
ments, the default is -xF=%none,func.
Interactions:
Using -xF=lcldata inhibits some address calcula-
tion optimizations, so you should only use this
flag when it is experimentally 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 variable, PAGER. If PAGER is
not set, the default paging command is more.
-xhwcprof[={enable|disable}]
(SPARC) Use the -xhwcprof option to enable com-
piler 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 sym-
bolic 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 profil-
ing.
You can compile a specified set of object files
with -xhwcprof however, -xhwcprof is most useful
when applied to all object files in the applica-
tion. This will provide coverage to identify and
correlate all memory references distributed in the
application's object files.
If you are compiling and linking in separate
steps, use -xhwcprof at link time as well. Future
extensions to -xhwcprof may require its use at
link time. For a complete list of compiler options
that must be specified at both compile time and at
link time, see the C User's Guide.
An instance of -xhwcprof=enable or
-xhwcprof=disable overrides all previous instances
of -xhwcprof in the same command line.
-xhwcprof is disabled by default. Specifying
-xhwcprof without any arguments is the equivalent
to -xhwcprof=enable.
-xhwcprof requires that optimization be turned on
and that the debug data format be set to dwarf
(-xdebugformat=dwarf), which is the default with
current Sun Studio compilers.
The combination of -xhwcprof and -g increases com-
piler 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 (SPARC platform) Link the appropriate interval
arithmetic libraries and set a suitable floating-
point environment.
The -xia option is a macro that expands to
-fsimple=0 -ftrap=%none -fns=no -library=interval.
Interactions:
To use the interval arithmetic libraries, include
<suninterval.h>.
When you use the interval arithmetic libraries,
you must include one of the following libraries:
libC, Cstd, or iostreams. See -library for infor-
mation on including these libraries.
Warnings:
If you use intervals and you specify different
values for -fsimple, -ftrap, or -fns, then your
program may have incorrect behavior.
C++ interval arithmetic is experimental and evolv-
ing. The specifics may change from release to
release.
See also:
C++ Interval Arithmetic Programming Reference,
Interval Arithmetic Solves Nonlinear Problems
While Providing Guaranteed Results
(http://www.sun.com/software/sundev/news/features/intervals.html),
-library
-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 choos-
ing. Note that without the
%auto specification, automatic
inlining is normally turned
off when explicit inlining is
specified on the command line
by -xinline=[no%]func_name...
func_name Strongly request that the
optimizer inline the function.
If the 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 con-
sidered for inlining unless you use
-xcrossfile[=1]. The optimizer decides which of
these routines are appropriate for inlining.
Defaults:
If the -xinline option is not specified, the com-
piler 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 func-
tions 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 optim-
izer 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 not inline if any of the following
conditions apply. No warnings will be omitted.
o Optimization is less than -xO3
o The routine cannot be found
o Inlining is not profitable or safe
o The source is not in the file being com-
piled, or, if you use -xcrossfile[=1], the
source is not in the files named on the
command line.
Warnings:
If you force the inlining of a function with
-xinline, you might actually diminish perfor-
mance.
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 instrumented program with collect -r races to
create a data-race-detection experiment. You can
run the instrumented code standalone but it runs
more slowly.
Values
Value Meaning
instrument Prepare the code for analysis by
the Thread Analyzer and define
__THA_NOTIFY.
no%instrument This is the default. Do not prepare
the code for analysis by the Thread
Analyzer and do not define
__THA_NOTIFY.
Interactions
If you compile and link in seperate steps, you
must specify -xinstrument=datarace in both the
compilation and linking steps.
This option defines the preprocessor token
__THA_NOTIFY. You can specify #ifdef __THA_NOTIFY
to guard calls to libtha(3) routines.
This option also sets -g0.
Warnings
It is illegal to specify -xinstrument without an
argument.
-xipo[={0|1|2}]
Performs interprocedural optimizations.
The -xipo option performs partial-program optimi-
zations by invoking an interprocedural analysis
pass. Unlike -xcrossfile, -xipo performs optimiza-
tions across all object files in the link step,
and the optimizations are not limited to just the
source files on the compile command. However, just
like -xcrossfile, whole-program optimizations per-
formed with -xipo do not include assembly (.s)
source files.
The -xipo option is particularly useful when com-
piling and linking large multifile applications.
Object files compiled with this flag have analysis
information compiled within them that enables
interprocedural analysis across source and precom-
piled program files. However, analysis and optim-
ization 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 optimiza-
tions.
2 Perform interprocedural aliasing
analysis as well as optimization of
memory allocation and layout to
improve cache performance.
Defaults:
If -xipo is not specified, -xipo=0 is assumed.
If only -xipo is specified, -xipo=1 is assumed.
Examples:
The following example compiles and links in the
same step.
example% CC -xipo -xO4 -o prog part1.cc part2.cc
part3.cc
The optimizer performs crossfile inlining across
all three source files. This is done in the final
link step, so the compilation of the source files
need not all take place in a single compilation
and could be over a number of separate compila-
tions, each specifying the -xipo option.
The following example compiles and links in
separate steps.
example% CC -xipo -xO4 -c part1.cc part2.cc
example% CC -xipo -xO4 -c part3.cc
example% CC -xipo -xO4 -o prog part1.o part2.o
part3.o
The object files created in the compile steps have
additional analysis information compiled within
them to permit crossfile optimizations to take
place at the link step.
Interactions:
The -xipo option requires at least optimization
level -xO4. You cannot use both the -xipo option
and the -xcrossfile option in the same compile
command.
Warnings:
When compiling and linking are performed in
separate steps, -xipo must be specified in both
steps to be effective. Objects that are compiled
without -xipo can be linked freely with objects
that are compiled with -xipo. Libraries do not
participate in crossfile 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 warn-
ings about undefined symbols, but the interpro-
cedural 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 per-
formed.
When Not To Use -xipo=2 Interprocedural Analysis
The compiler tries to perform whole-program
analysis and optimizations as it works with the
set of object files in the link step. The compiler
makes the following two assumptions for any func-
tion (or subroutine) foo() defined in this set of
object files:
(1) foo() is not called explicitly by another rou-
tine 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 dif-
ferent 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 func-
tion 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 parti-
cipate 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. Further-
more, 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. Other-
wise, 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 dur-
ing the compilation are replaced with their optim-
ized 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 produc-
ing 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 produc-
ing 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_archive=writeback must be specified at link
time.
It is illegal to specify -xipo_archive without a
flag.
-xjobs=n Compile with multiple processors.
Specify the -xjobs option to set how many
processes the compiler creates to complete its
work. This option can reduce the build time on a
multi-cpu machine. Currently, -xjobs works only
with the -xipo option. When you specify -xjobs=n,
the interprocedural optimizer uses n as the max-
imum number of code generator instances it can
invoke to compile different files.
Generally, a safe value for n is 1.5 multiplied by
the number of available processors. Using a value
that is many times the number of available proces-
sors 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. Oth-
erwise an error diagnostic is issued and compila-
tion 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 Per-
formance 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 hidden.
Values
v must be one of the following:
Value Meaning
global Symbol definitions have global
linker scoping which is the least
restrictive linker scoping. All
references to the symbol bind to
the definition in the first dynamic
load module that defines the sym-
bol. This linker scoping is the
current linker scoping for extern
symbols.
symbolic Symbol definitions have symbolic
linker scoping which is more res-
trictive than global linker scop-
ing. 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 problems.
hidden Hidden linker scoping is more res-
trictive than symbolic and global
linker scoping. All references
within a dynamic load module will
bind to a definition within that
module. The symbol will not be
visible outside of the module.
Defaults
If you do not specify -xldscope, the compiler
assumes -xldscope=global. If you specify -xldscope
without any values, the compiler issues an error.
Multiple instances of this option on the command
line override each other until the rightmost
instance is reached.
Warnings
If you intend to allow a client to override a
function in a library, you must be sure that the
function is not generated inline during the
library build. The compiler inlines a function if
you specify the function name with -xinline, if
you compile at -xO4 or higher in which case inlin-
ing can happen automatically, if you use the
inline specifier, or if you are using cross-file
optimization.
For example, suppose library ABC has a default
allocator function that can be used by library
clients, and is also used internally in the
library:
void* ABC_allocator(size_t size) { return
malloc(size); }
If you build the library at -xO4 or higher, the
compiler inlines calls to ABC_allocator that occur
in library components. If a library client wants
to replace ABC_allocator with a customized ver-
sion, the replacement will not occur in library
components that called ABC_allocator. The final
program will include different versions of the
function.
Library functions declared with the __hidden or
__symbolic specifiers can be generated inline when
building the library. They are not supposed to be
overridden by clients. For more information, see
chapter 4 "Language Extensions" of the C++ User's
Guide.
Library functions declared with the __global
specifier, should not be declared inline, and
should be protected from inlining by use of the
-xinline compiler option.
See Also
-xinline, -xO, -xcrossfile, ld(1).
-xlibmieee
Causes libm to return IEEE 754 values for math
routines in exceptional cases. The default
behavior of libm is XPG-compliant.
-xlibmil Inlines selected library routines for optimiza-
tion.
There are inline templates for some of the libm
library routines. This option selects those inline
templates that produce the fastest executables for
the floating-point option and platform currently
being used.
Note - This option does not affect C++ inline
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 performance, and usually generates faster
code. The results may be slightly different from
those produced by the normal math library. If so,
they usually differ in the last bit.
The order on the command line for this library
option is not significant.
Interactions:
This option is implied by the -fast option.
See also:
-fast
-xnolibmopt
-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 relo-
catable 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 optimizations,
at link time.
2 Perform additional data flow analysis,
including dead-code elimination and
address computation simplification, at
link time.
Specifying -xlinkopt without a level parameter
implies -xlinkopt=1.
These optimizations are performed at link time by
analyzing the object binary code. The object files
are not rewritten but the resulting executable
code may differ from the original object codes.
This option is most effective when used to compile
the whole program, and with profile feedback.
When compiling in separate steps, -xlinkopt must
appear on both compile and link steps:
example% CC -c -xlinkopt a.cc b.cc
example% CC -o myprog -xlinkopt=2 a.o
Note that the level parameter is only used when
the compiler is linking. In the example above, the
link optimizer level is 2 even though the object
binaries were compiled with an implied level of 1.
Do not use the -zcompreloc linker option when you
compile with -xlinkopt.
You must use -xlinkopt on at least some of the
compilation commands for -xlinkopt to be useful at
link time. The optimizer can still perform some
limited optimizations on object binaries not com-
piled 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 com-
ing 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 accord-
ingly. This is particularly important with large
applications where optimal placement of code per-
formed at link time can reduce instruction cache
misses. Typically, this would be compiled as fol-
lows:
example% CC -o progt -xO5 -xprofile=collect:prog file.cc
example% progt
example% CC -o prog -xO5 -xprofile=use:prog -xlinkopt file.cc
For details on using profile feedback, see -xpro-
file
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++ pro-
grams, requesting that it generate makefile depen-
dencies and send the result to the standard output
(see make (1) for details about makefiles and
dependencies).
See also:
-xM1
See make(1) for details about makefiles and depen-
dencies.
-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.
-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 ld
-N.
-xmaxopt[=v]
This command limits the level of pragma opt to the
level specified. v must be one of the following:
off, 1, 2, 3, 4, or 5. The default value is
-xmaxopt=off which causes pragma opt to be
ignored. If you specify -xmaxopt without supplying
an argument, that is the equivalent of specifying
-xmaxopt=5.
-xmemalign[=ab]
(SPARC) This command specifies the maximum assumed
memory alignment and the behavior of misaligned
data accesses.
For memory accesses where the alignment is deter-
minable at compile time, the compiler generates
the appropriate load/store instruction sequence
for that alignment of data.
For memory accesses where the alignment cannot be
determined at compile time, the compiler must
assume an alignment to generate the needed
load/store sequence.
Use the -xmemalign option to specify the maximum
memory alignment of data to be assumed by the com-
piler in these indeterminable situations. You can
also specify the error behavior to be followed at
run-time when a misaligned memory access does take
place.
Values:
Accepted values for a are:
1 Assume at most 1 byte alignment.
2 Assume at most 2 byte alignment.
4 Assume at most 4 byte alignment.
8 Assume at most 8 byte alignment.
16 Assume at most 16 byte alignment.
Accepted values for b are:
i Interpret access and continue execution.
s Raise signal SIGBUS.
f For variants of -xarch=v9 only. Raise
signal SIGBUS for alignments less than
or equal to 4, otherwise interpret
access and continue execution. For all
other -xarch values, the f flag is
equivalent to i.
Defaults:
If you do not specify -xmemalign, the default is
-xmemalign=8i for all v8 architectures and
-xmemalign=8s for all v9 architectures.
If you do specify -xmemalign but do not provide a
value, the default is -xmemalign=1i for all plat-
forms.
-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 speci-
fied 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 sym-
bols 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 command-line.
If you do not specify -xmodel, the compiler
assumes -xmodel=small. Specifying -xmodel without
an argument is an error.
It is not necessary to compile all translation
units with this option. You can compile select
files as long as you ensure the object you are
accessing is within reach.
Be aware that not all Linux system support the
medium model.
-xnolib Disables linking with default system libraries.
Normally (without this option), the C++ compiler
links with several system support libraries to
support C++ programs. With this option, the -llib
options to link the default system support
libraries are not passed to ld.
Normally, the compiler links with the system sup-
port 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 com-
piler normally links with -lthread just before it
links with -lm.
To determine which system support libraries will
be linked by default, compile with the -dryrun
option. For example, the output from the following
command:
example% CC foo.cc -xarch=v9 -dryrun
includes the following
-lCstd -lCrun -lm -lc
Examples:
For minimal compilation to meet the C application
binary interface, that is, a C++ program with only
C support required, use:
example% CC -xnolib test.cc -lc
To link libm statically into a single threaded
application with the generic instruction set, use:
o Standard mode:
example% CC -xnolib test.cc -lCstd -lCrun
-Bstatic -lm -Bdynamic -lc"
o Compatibility mode:
example% CC -compat -xnolib test.cc -lc -Bstatic
-lm -Bdynamic -lc"
Interactions:
Some static system libraries, such as libm.a and
libc.a are not available when linking with
-xarch=v9, -xarch=v9a, or -xarch=v9b.
If you specify -xnolib, you must manually link all
required system support libraries in the given
order. You must link the system support libraries
last.
If -xnolib is specified, -library is ignored.
Warnings:
Many C++ language features require the use of libC
(compatibility mode) or libCrun (standard mode).
The set of system support libraries is not stable
and might change from release to release.
-xnolibmil
Cancels -xlibmil on the command line.
Use this option with -fast to override linking
with the optimized math library.
-xnolibmopt
Does not use the math routine library by turning
off any previously specified -xlibmopt options.
Interactions:
Use this option after the -fast option on the com-
mand 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 optimiza-
tion level. If you specify an optimization level,
there is no option for turning optimization off.
If you are trying to avoid setting an optimization
level, be sure not to specify any option that
implies an optimization level. For example, -fast
is a macro option that sets optimization at -xO5.
All other options that imply an optimization level
give a warning message that optimization has been
set. The only way to compile without any optimiza-
tion is to delete all options from the command
line or make file that specify an optimization
level.
Generally, the higher the level of optimization
with which a program is compiled, the better run-
time performance obtained. However, higher optimi-
zation levels may result in increased compilation
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 optimi-
zation, resuming compilation of subsequent rou-
tines 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 elimi-
nation, algebraic simplification, copy propa-
gation, constant propagation, loop-invariant
optimization, 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 vari-
ables.
-xO3 Optimizes references and definitions for
external variables in addition to optimiza-
tions performed at the -xO2 level. This level
does not trace the effects of pointer assign-
ments. 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 con-
tained in the same file in addition to per-
forming -xO3 optimizations. This automatic
inlining can improve execution speed, though
sometimes it results in worse performance. In
general, 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. Optimization at this level is
more likely to improve performance if it is
done with profile feedback. See
-xprofile=collect|use.
On x86 platforms:
-xO1 Does basic optimization. This includes alge-
braic simplification, 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 subex-
pression 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 reduc-
tion, induction variable elimination, and
loop-variant optimization.
-xO4 Does automatic inlining of functions con-
tained in the same file in addition to per-
forming -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 optimization algorithms that may take
more compilation time and may not have as
high a certainty of improving execution 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 optimiza-
tion. 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 optim-
ization options reduce the utility of debugging so
that you cannot display variables from dbx, but
you can still use the dbx where command to get a
symbolic traceback. For more information, see
Debugging a Program With dbx.
The -xcrossfile option is effective only if it is
used with -xO4 or -xO5.
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 -xinline
option. At -xO4, the compiler also attempts to
determine which functions will improve performance
if they are inlined. If you force the inlining of
a function with -xinline, you might actually
diminish performance.
Warnings:
If you optimize at -xO3 or -xO4 with very large
procedures, thousands of lines of code in a single
procedure, the optimizer might require an unrea-
sonable 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 avail-
able 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 optimization requested, the amount of
real memory, and virtual memory available.
To find the actual swap space, type: swap -1
To find the actual real memory, type: dmesg | grep
mem
See also:
-xldscope, -fast, -xprofile=p, csh(1) man page
Performance Analyzer discusses the effects of the
different levels of optimization on the Perfor-
mance Analyzer's data.
-xopenmp [=i]
Use the -xopenmp option to enable explicit paral-
lelization with OpenMP directives. To run a
parallelized program in a multithreaded environ-
ment, you must set the OMP_NUM_THREADS environment
variable prior to execution. To enable nested
parallelism, you must set the OMP_NESTED environ-
ment variable to TRUE. Nested parallelism is dis-
abled 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 com-
piler 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 recog-
nized, the program is parallelized accordingly,
but no optimization is done. This flag also
defines the preprocessor token _OPENMP.
o -xopenmp=none
The -xopenmp=none command does not enable recog-
nition 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 break-
point within parallel regions and display the con-
tents 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 com-
pile the executable must not be any older than the
compiler that built the .so with -xopenmp. This is
especially important when you compile libraries
that contain OpenMP directives.
Make sure that the latest patch of the OpenMP run-
time library, libmtsk.so, is installed on the sys-
tem 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:
4k 8K 64K 512K 2M 4M 32M 256M 2G 16G or default.
You must specify a valid page size for the target
platform. If you do not specify a valid pagesize,
the request is silently ignored at run-time.
Use the getpagesize(3C) command on the Solaris
operating environment to determine the number of
bytes in a page. The Solaris operating environment
offers no guarantee that the page size request
will be honored. You can use pmap(1) or mem-
info(2) to determine page size of the target plat-
form.
The -xpagesize option has no effect unless you use
it at compile time and at link time.
If you specify -xpagesize=default, the Solaris
operating environment sets the page size.
This option is a macro for -xpagesize_heap and
-xpagesize_stack. These two options accept the
same arguments as -xpagesize. You can set them
both with the same value by specifying
-xpagesize=n or you can specify them individually
with different values.
Compiling with this option has the same effect as
setting the LD_PRELOAD environment variable to
mpss.so.1 with the equivalent options, or running
the Solaris command ppgsz(1) with the equivalent
options before running the program. See the
Solaris man pages for details.
-xpagesize_heap=n
Set the page size in memory for the heap.
The n value must be one of the following:
4k 8K 64K 512K 2M 4M 32M 256M 2G 16G or default.
You must specify a valid page size for the target
platform. If you do not specify a valid pagesize,
the request is silently ignored at run-time.
Use the getpagesize(3C) command on the Solaris
operating environment to determine the number of
bytes in a page. The Solaris operating environment
offers no guarantee that the page size request
will be honored.
You can use pmap(1) or meminfo(2) to determine
page size at the target platform.
If you specify -xpagesize_heap=default, the
Solaris operating environment sets the page size.
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 equivalent
options before running the program. See the
Solaris man pages for details.
The -xpagesize_heap option has no effect unless
you use it at compile time and at link time.
-xpagesize_stack=n
Set the page size in memory for the stack.
The n value must be one of the following:
4k 8K 64K 512K 2M 4M 32M 256M 2G 16G or default.
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.
Use the getpagesize(3C) command on the Solaris
operating environment to determine the number of
bytes in a page. The Solaris operating environment
offers no guarantee that the page size request
will be honored. You can use pmap(1) or mem-
info(2) to determine page size at the target plat-
form.
If you specify -xpagesize_stack=default, the
Solaris operating environment sets the page size.
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 equivalent
options before running the program. See the
Solaris man pages for details.
The -xpagesize_stack option has no effect unless
you use it at compile time and at link time.
-xpch=v This compiler option activates the precompiled-
header feature. v can be auto, autofirst,
collect:pch_filename, or use:pch_filename. You can
take advantage of this feature through the -xpch
and -xpchstop options in combination with the
#pragma hdrstop directive.
Use the -xpch option to create a precompiled-
header file and improve your compilation time. The
precompiled-header file is designed to reduce com-
pile time for applications whose source files
share a common set of include files containing a
large amount of source code. A precompiled header
works by collecting information about a sequence
of header files from one source file, and then
using that information when recompiling that
source file, and when compiling other source files
that have the same sequence of headers.
Creating a Precompiled-Header File Automatically
You can let the compiler generate the
precompiled-header file for you automatically.
Choose between one of the following two ways to do
this. One way is for the compiler to create the
precompiled-header file from the first include
file it finds in the source file. The other way is
for the compiler to select from the set of include
files found in the source file starting with the
first include file and extending through a well-
defined point that determines which include file
is the last one. Use one of the following two
flags to 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 con-
sists of the largest possible number of
header files.
-xpch=autofirst
This flag produces a precompiled-header file
that contains only the first header found in
the source file.
Creating the Precompiled-Header File Manually
If you decide to create your precompiled-header
file manually, you must start by first using -xpch
and specify the collect mode. The compilation
command that specifies -xpch=collect must only
specify one source file. In the following example,
the -xpch option creates a precompiled-header file
called myheader.Cpch based on the source file
a.cc:
CC -xpch=collect:myheader a.cc
A valid precompiled-header filename always has the
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 symbols
and the directives appear in the same order
- The associated values for #define are identi-
cal
- 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 dif-
ferent 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 exam-
ple, 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 fol-
lowing is not true, you should recreate the
precompiled-header file:
- The compiler that you are using to access the
precompiled-header file is the same as the
compiler that created the precompiled-header file.
A precompiled-header file created by one version
of the compiler may not be usable by another ver-
sion 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 con-
tents 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 precompiled-header file) is the
same as the directory in which the precompiled-
header file was created.
- The initial sequence of pre-processing direc-
tives, including #include directives, in the file
you specified with -xpch=collect are the same as
the sequence of pre-processing directives in the
files you specify with -xpch=use.
The Viable Prefix
In order to share a precompiled-header file across
multiple source files, those source files must
share a common set of include files as their ini-
tial 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 pre-
fix 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 automatically when you specify
-xpch=auto or -xpch=autofirst and is defined as
follows. For -xpch=collect or -xpch=use, the
viable prefix ends with a #pragma hdrstop.
- The first declaration/definition statement
- The first #line directive
- A #pragma hdrstop directive
- After the named include file if you specify
-xpch=auto and -xpchstop
- The first include file if you specify
-xpch=autofirst
Note: An end point within a conditional statement
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 ear-
lier 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 appear-
ance within each viable prefix must be the same as
well. Each corresponding pragma must also be the
same and appear in the same order across all the
files sharing a precompiled header.
Screening Header Files for Problems
What makes a header file precompilable? A header
file is precompilable when it is interpreted
consistently across different source files.
Specifically, when it contains only complete
declarations. That is, a declaration in any one
file must stand alone as a valid declaration.
Incomplete type declarations, such as struct S;,
are valid declarations. The complete type 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 fol-
lowing. 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 automatically, the compiler writes it to the
SunWS_cache directory. This directory always
resides in the location where the object file is
created. Updates to the file are preformed under a
lock so that it works properly under dmake.
If you need to force the compiler to rebuild
automatically-generated precompiled-header files,
you can clear the PCH cache directory with the
CCadmin tool. See the CCadmin(1) man page for more
information.
Warnings
o Do not specify conflicting -xpch flags on the
command line. For example, specifying both
-xpch=collect and -xpch=auto, or specifying both
-xpch=autofirst with -xpchstop=<include> generates
an error.
o If you specify -xpch=autofirst or you specify
-xpch=auto without -xpchstop, any declaration,
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 generation 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:
%.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 gen-
erated by the compiler, force a manually created
precompiled-header file to be recreated if any
source file you used with -xpch=collect, or any of
the headers that are part of the precompiled-
header file, have changed. This prevents the use
of an out of date precompiled-header file.
For -xpch=auto or -xpch=autofirst, you do not have
to create any additional make rules in your
makefiles.
See Also: -xpchstop
-xpchstop=file
where file is the last include file to be con-
sidered in creating a precompiled-header file.
Using -xpchstop on the command line is equivalent
to placing a hdrstop pragma (See -xhelp=readme)
after the first include-directive that references
file in each of the source files that you specify
with the cc command.
Use -xpchstop=<include> with -xpch=auto to create
a precompiled-header file that is based on header
files up through and including <include>. This
flag overrides the default -xpch=auto behavior of
using all header files contained in the entire
viable prefix.
See Also: -xpch, -xhelp=readme
-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 recording mechanism that pro-
duces 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 sample data
(see pcsample(2)) for routines in the main execut-
able 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 pro-
filed.
On 32 bit Solaris systems, profiles generated
using prof(1) are limited to routines in the exe-
cutable. 32 bit shared libraries can be profiled
by linking the executable with -xpg and using
gprof(1).
The Solaris 10 software does not include system
libraries compiled with -p. As a result, profiles
collected on Solaris 10 platforms do not include
call counts for system library routines.
You can also perform this task with the Perfor-
mance Analyzer. Refer to the analyzer(1) man page.
Warnings:
If you compile and link separately, and you com-
pile with -xpg, then be sure to link with -xpg.
-xport64[=v]
Use this option to help you port code to a 64-bit
environment. Specifically, this option warns
against problems such as truncation of types
(including pointers), sign extension, and changes
to bit-packing that are common when you port code
from a 32-bit 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 environ-
ment.
implicit Generate warning only for implicit
conversions. Do not generate warn-
ings 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 environ-
ment. This includes warnings for
truncation of 64-bit values, sign-
extension to 64 bits under ISO
value-preserving rules, and changes
to packing of bitfields.
Defaults:
If you do not specify -xport64, the default is
-xport64=no. If you specify -xport64, but do not
specify a flag, the default is -xport64=full.
See Also: -xarch
-xprefetch[=a[,a]]
Enable and adjust prefetch instructions on those
architectures that support prefetch. You must com-
pile with optimization level 3 or greater with
this option.
a must be one of the following values.
Value Meaning
auto Enable automatic generation of pre-
fetch instructions.
no%auto Disable automatic generation
explicit Enable explicit prefetch macros
Explicit prefetching should only be
used under special circumstances
that are supported by measurements.
no%explicit Disable explicit prefectch macros.
latx:factor (SPARC) You can only combine this
flag with -xprefetch=auto. Adjust
the compiler's assumed prefetch-
to-load and prefetch-to-store
latencies by the specified factor.
The factor must be a positive
floating-point or integer number.
yes Obsolete - do not use. Use
-xprefetch=auto,explicit instead.
no Obsolete - do not use. Use
-xprefetch=no%auto,no%explicit
instead.
With -xprefetch, and -xprefetch=auto the compiler
is free to insert prefetch instructions into the
code it generates. This may result in a perfor-
mance improvement on architectures that support
prefetch.
If you are running computationally intensive codes
on large multiprocessors, you might find it advan-
tageous 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 performance 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 multiprocessors, you may be able to obtain
better performance by increasing the prefetch
latency values. To increase the values, use a fac-
tor 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 application. 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 performance. When you increase or
decrease the factor in small steps, you will see
no performance difference for a few steps, then a
sudden difference, then it will level off again.
Defaults:
The default is -xprefetch=auto,explicit.
If automatic prefetching is enabled, such as with
-xprefetch or -xprefetch=auto, but a latency fac-
tor is not specified, then latx:1.0 is assumed.
Interactions:
This option accumulates instead of overrides.
The sun_prefetch.h header file provides the macros
for specifying explicit prefetch instructions. The
prefetches will be approximately at the place in
the executable that corresponds to where the mac-
ros 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 or
-xprefetch=yes.
If you call the macros and include the
sun_prefetch.h header file, but pass
-xprefetch=no%explicit or -xprefetch=no, the
explicit prefetches will not appear in your exe-
cutable.
The -xchip setting effects the determination of
the assumed latencies and therefore the result of
a latx:factor setting.
The latx:factor suboption is valid only when
automatic prefetching is enabled. That is,
latx:factor is ignored unless it is used in con-
junction with yes or auto.
Warnings:
Because the compiler tunes the prefetch mechanism
for optimal performance across a wide range of
machines and applications, you should only use the
latx:factor suboption when the performance tests
indicate there is a clear benefit. The assumed
prefetch latencies may change from release to
release. Therefore, retesting the effect of the
latency factor on performance 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 generates 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%indirect_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 0, 1, or 2.
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 enables
additional generation beyond level 1 and -xpre-
fetch=3 enables additional generation beyond level
2.
You must compile with optimization level 3 or
greater and generate code for a platform that sup-
ports prefetch.
-xprofile=p
Collects or optimizes with runtime profiling data.
p must be collect[:name], use[:name], 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 pro-
gram that does its own multitasking ( -mt ) pro-
duces accurate results. This option is only valid
when you specify an optimization level of -xO2 or
higher.
If compilation and linking are performed in
separate steps, the same -xprofile option must
appear on the compile step as well as the link
step.
Values:
collect[:name]
Collects and saves execution frequency for
later use by the optimizer with
-xprofile=use. The compiler generates code to
measure statement execution frequency.
Note: Do not specify -xprofile=collect when
you build shared libraries on Linux.
The name is optional. If name is not speci-
fied, the name of the executable binary is
used. a.out is used if -o is not specified.
At runtime, a program compiled with
-xprofile=collect:name will create the sub-
directory name.profile to hold the runtime
feedback information. Data is written to the
file feedback in this subdirectory. You can
use the $SUN_PROFDATA and $SUN_PROFDATA_DIR
environment variables to change the location
of the feedback information. See Environment
Variables at the end of this section.
If you run the program several times, the
execution frequency data accumulates in the
feedback file; that is, output from prior
runs is not lost.
If you are compiling and linking in separate
steps, make sure that any object files com-
piled with -xprofile=collect are also linked
with -xprofile=collect.
use[:name]
Uses execution frequency data to optimize
strategically. The name is the name of the
executable that is being analyzed.
The name is optional. If name is not speci-
fied, the name of the executable binary is
used. a.out is used if -o is not specified.
The compiler looks for name.profile/feedback,
or a.out.profile/feedback without name speci-
fied. 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 execu-
tion frequency data previously generated and
saved in the feedback files written by a pre-
vious execution of the program compiled with
-xprofile=collect.
The source files and other compiler options
must be exactly the same as those used for
the compilation that created the compiled
program that generated the feedback file. If
compiled with -xprofile=collect:name, the
same program name name must appear in the
optimizing compilation: -xprofile=use:name.
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 simi-
lar functionality to the -xa option, but
correctly collects data for programs that
have source code in header files or make use
of C++ templates. See also -xa for informa-
tion on the old style of profiling, the
tcov(1) man page, and the Performance Profil-
ing Tools manual for more details.
Note: Do not specify -xprofile=collect when
you build shared libraries on Linux.
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.
The -xprofile=tcov and the -xa 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 with -xa. You can-
not compile a single file with both options.
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 environ-
ment variable has no effect at compile-time.
However, its value is used at program run-
time. See tcov(1) and the Performance Pro-
filing Tools manual for more details.
Note - The code coverage report produced by
-xprofile=tcov can be unreliable if there is
inlining of functions due to use of -xO4.
Environment Variables:
You can set the environment variables
$SUN_PROFDATA and $SUN_PROFDATA_DIR to control
where a program compiled with -xprofile=collect
puts the profile data. If these variables are not
set, the profile data is written to
name.profile/feedback in the current directory,
where name is the name of the executable or the
name specified in the -xprofile=collect:name flag.
If set, the -xprofile=collect data is written to
$SUN_PROFDATA_DIR/$SUN_PROFDATA
These environment variables similarly control the
path and names of the profile data files written
by tcov, and this is described in the tcov(1) man
page.
-xprofile_ircache[=path]
Use -xprofile_ircache[=path] with
-xprofile=collect|use to improve compilation time
during the use phase by reusing compilation data
saved from the collect phase.
With large programs, compilation time in the use
phase can improve significantly because the inter-
mediate data is saved. Note that the saved data
could increase disk space requirements consider-
ably.
When you use -xprofile_ircache[=path], path over-
rides the location where the cached files are
saved. By default, these files are saved in the
same directory as the object file. Specifying a
path is useful when the collect and use phases
happen in two different 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 profile
data for an object file that is compiled with
-xprofile=use.
o You are compiling the object file with -xprofile=use
in a directory that is different from the
directory in which the object file was previ-
ously compiled with -xprofile=collect.
o Your object files share a common basename in the
profile but are distinguished from each other
by their location in different directories.
The collect-prefix is the prefix of the UNIX path-
name of a directory tree in which object files
were compiled using -xprofile=collect.
The use-prefix is the prefix of the UNIX pathname
of a directory tree in which object files are to
be compiled using -xprofile=use.
If you specify multiple instances of
-xprofile_pathmap, the compiler processes them in
the order of their occurrence. Each use-prefix
specified by an instance of -xprofile_pathmap is
compared with the object file pathname until
either a matching use-prefix is identified or the
last specified use-prefix is found not to match
the object file pathname.
-xreduction
Analyzes loops for reduction in automatic paral-
lelization. This option is valid only if -xautopar
is also specified. Otherwise the compiler issues a
warning.
When a reduction recognition is enabled, the com-
piler parallelizes reductions such as dot pro-
ducts, maximum and minimum finding. These reduc-
tions 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 sys-
tem 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 appli-
cation.
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 con-
flict 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 regis-
ters 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 unallocated
callee-saves register.
Using this register as an unallocated
callee-saves register may improve program
run time. However, it also reduces the
capacity of some tools, such as the Per-
formance Analyzer and dtrace, to inspect
and follow the stack. This stack inspec-
tion capability is important for system
performance measurement and tuning.
Therefor, using this optimization may
improve local program performance at the
expense of global system performance.
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 pointers. f is %all, %none, %source or
a comma-separated list of one or more function
names. This command-line option can be used on its
own, but is best used with optimization of -xO3 or
greater.
Specifying -xrestrict=%source means that all func-
tions defined in the main source file, but not any
header files or template definition files, are
restricted.
If you specify a function list with this option,
pointer parameters in the specified functions are
treated as restricted; if you specify
-xrestrict=%all, all pointer parameters in the
entire C++ file are treated as restricted.
The default is %none. Specifying -xrestrict is
equivalent to specifying -xrestrict=%source.
See Also: -xprefetch_auto_type, 'Restricted
Pointers' in the C++ User's Guide
-xs Allows debugging by dbx without object files.
This option causes all the debug information to be
copied into the executable. This has little
impact on dbx performance or the run-time perfor-
mance 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 archi-
tecture.
Warnings:
Because non-faulting loads do not cause a trap
when a fault such as address misalignment or seg-
mentation violation occurs, you should use this
option only for programs in which such faults can-
not occur. Because few programs incur memory-
based traps, you can safely use this option for
most programs. Do not use this option for pro-
grams 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 func-
tionality is obsolete.
-xsbfast Deprecated - do not use. The source browser func-
tionality is obsolete.
-xspace Does not allow optimizations that increase code
size.
-xtarget=t
Specifies the target system for instruction set
and optimization.
t must be one of the folowing: native, native64,
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 available architec-
ture, 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 perfor-
mance 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 speci-
fied 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,
sparc64vi.
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 platforms is indicated by the -m64
option. If you specify -xtarget with a flag other
than native64 or generic64, you must also specify
the -m64 option as follows:
-xtarget=opteron ... -m64
otherwise the compiler uses a 32-bit memory model.
Value Meaning
386, 486 Obsolete, do not use these flags. Use
-xtarget=generic instead. For a complete
list of obsolete options and flags, see
the C++ User's Guide.
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 available architec-
ture, 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 perfor-
mance 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.
opteron Directs the compiler to generate code
for the best performance on the AMD
Opteron microprocessor.
Note: The -xtarget=opteron option does
not automatically generate 64-bit code.
You must specify -m64 to compile 64-bit
code.
pentium Directs the compiler to generate code
for the best performance on the Pentium
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.
-xthreadvar[=o]
Works in conjunction with the __thread declaration
specifier to take advantage of the compiler's
thread-local storage facility. After you declare
the thread variables with the __thread specifier,
use -xthreadvar to enable the use of thread-local
storage with position dependent code (non-PIC
code) in dynamic (shared) libraries. For more
information on how to use __thread, see the C++
User's Guide.
Values
o can be one of the following:
Value Meaning
[no%]dynamic
[[Do not] Compile variables for dynamic
loading. Access to thread variables is
significantly faster when
-xthreadvar=no%dynamic but you cannot
use the object file within a dynamic
library. That is, you can only use the
object file in an executable file.
Defaults
If you do not specify -xthreadvar, the default
used by the compiler depends upon whether or not
position-independent code is enabled. If
position-independent code is enabled, the option
is set to -xthreadvar=dynamic. If position-
independent code is disabled, the option is set to
-xthreadvar=no%dynamic.
If you specify -xthreadvar but do not specify any
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 compiled and linked with -mt.
Warnings
If there is non-position-independent code within a
dynamic library, you must specify -xthreadvar.
The linker cannot support the thread-variable
equivalent of non-PIC code in dynamic libraries.
Non-PIC thread variables are significantly faster,
and hence should be the default for executables.
See Also
-xcode, -KPIC, -Kpic
-xtime Causes the CC driver to report execution times for
the various compilation passes.
-xtrigraphs[={yes|no}]
Enables or disables recognition of trigraph
sequences as defined by the ISO/ANSI C standard.
-xtrigraphs=yes enables recognition of trigraph
sequences in the source code.
-xtrigraphs=no disables recognition of trigraph
sequences in the source code.
Defaults:
If the -xtrigraphs option is not specified,
-xtrigraphs=yes is assumed.
If only -xtrigraphs is specified -xtrigraphs=yes
is assumed.
-xunroll=n
Enables unrolling of loops where possible.
This option specifies whether or not the compiler
optimizes (unrolls) loops.
When n is 1, it is a suggestion to the compiler
not to unroll loops.
When n is an integer greater than 1, -xunroll=n
causes the compiler to unroll loops n times.
-xustr={ascii_utf16_ushort|no}
This option enables compiler recognition of UTF-16
character strings and literals. Since such strings
and literals are not yet part of any standard,
this option enables recognition of non-standard
C++. Specify -xustr=ascii_utf16_ushort if you need
to support an internationalized application that
uses ISO10646 UTF-16 characters. In other words,
use this option if your code contains string char-
acters that you want the compiler to convert to
UTF-16 characters in the object file. Without this
option, the compiler neither produces nor recog-
nizes sixteen-bit characters. This option enables
recognition of the U"ASCII_string" string literals
as an array of unsigned short int. This option
also enables recognition of character literals.
For example: unsigned short character = U'Z';
You can turn off compiler recognition of
U"ASCII_string" string literals by specifying
-xustr=no. The rightmost instance of this option
on the command line overrides all previous
instances.
The default is -xustr=no. If you specify -xustr
without an argument, the compiler won't accept it
and instead issues a warning. The default can
change if the C or C++ standards define a meaning
for the syntax.
It is not an error to specify
-xustr=ascii_ustf16_ushort without also specifying
a U"ASCII_string" string literal.
Not all files have to be compiled with this
option.
The following example shows a string literal in
quotes that is prepended by U. It also shows a
command line that specifies -xustr.
example% cat file.cc
const unsigned short *foo = U"foo";
const unsigned short bar[] = U"bar";
const unsigned short *fun() { return
example% CC -xustr=ascii_utf16_ushort file.cc -c
-xvector[=a]
Enables automatic generation of calls to the vec-
tor library and/or the generation of the SIMD
(Single Instruction Multiple Data) instructions.
You must use default rounding mode by specifying
-fround=nearest when you use this option.
a is the equivalent of the following:
[no%]lib
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 improvement for
loops with large loop counts.
[no%]simd
Does [not]direct the compiler to use the
native x86 SSE SIMD instructions to improve
performance of certain loops. 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 may be depracated in a future
release. Specify -xvector=lib instead.
no This option may be deprecated in a future
release. 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 specifying -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 -xvec-
tor option in the linking CC command. For a com-
plete list of compiler options that must be speci-
fied at both compile time and at link time, see
the C++ User's Guide.
-xvis (SPARC) Use the -xvis=[yes|no] command when you
are using the assembly-language templates defined
in the VIS[tm] instruction set Software Developers
Kit (VSDK). The default is -xvis=no. Specifying
-xvis is equivalent to specifying -xvis=yes.
The VIS instruction set is an extension to the
SPARC v9 instruction set. Even though the
UltraSPARC processors are 64-bit, there are many
cases, especially in 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 process-
ing, audio, video and networking.
For more information on the VSDK, see
http://www.sun.com/processors/vis/.
-xwe Converts all warnings to errors by returning non-
zero exit status.
-Yc,path Specifies a new path for the location of component
c.
If the location of a component is specified, then
the new path name for the component is
path/component_name. This option is passed to ld.
Values
c must be one of the following values.
p Changes the default directory for cpp.
0 Changes the default directory for ccfe.
a Changes the default directory for fbe.
2 Changes the default directory for iropt
(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).
i Changes the default directory for ube_ipa
(x86).
h Changes the default directory for ir2hf (x86).
A Specifies a directory to search for all com-
piler 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.
For more information see the ld(1) man page and
the Solaris Linker and Libraries Guide.
PRAGMAS
The following #pragmas are recognized by the compilation
system:
#pragma align
#pragma does_not_read_global_data
#pragma does_not_return
#pragma does_not_write_global_data
#pragma dump_macros
#pragma end_dumpmacros
#pragma fini
#pragma hdrstop
#pragma ident
#pragma init
#pragma pack
#pragma rarely_called
#pragma returns_new_memory
#pragma unknown_control_flow
#pragma weak
SPARC Only:
#pragma no_side_effect
Refer to the C++ User's Guide for more information on these
pragmas.
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.
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
SEE ALSO
analyzer(1), as(1), c++filt(1), cc(1), csh(1), dbx(1),
gprof(1), ld(1), more(1), nm(1), prof(1), tcov(1)
C++ User's Guide,
C++ Migration Guide,
The C++ Programming Language, Third Edition, Bjarne
Stroustrup, Addison-Wesley 1997
The C Programming Language, B. W. Kernighan and D. M.
Ritchie, Prentice-Hall 1988
Solaris Linker and Libraries Guide
International Standard (ISO/IEC FDIS 14882), Programming
Languages - C++