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] [-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...]] [-mc] [-migration]
[-misalign] [-mr[,string]] [-mt] [-native] [-noex]
[-nofstore] [-nolib] [-nolibmil] [-noqueue]
[-norunpath] [-O[n]] [-O[level]] [-o file] [+p] [-P]
[-p] [-pentium] [-pg] [-PIC] [-pic] [-pta] [-ptipath]
[-pto] [-ptrpath] [-ptv]
[{-Qoption|-qoption}phase[,option...]]
[{-Qproduce|-qproduce}type] [-qp] [-Rpath[:path...]]
[-readme] [-S] [-s] [-sb] [-sbfast]
[-staticlib=l[,l...]] [-sync_stdio=[yes|no]]
[-temp=path] [-template=a[,a...]] [-time] [-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] [-xhelp={flags|readme}] [-xia]
[-xinline[=func_spec[,func_spec...]] [-xipo[={0|1|2}]
[-xjobs=n] [-xlang=language[,language]] [-xldscope={v}]
[-xlibmieee] [-xlibmil] [-xlibmopt] [-xlic_lib=sunperf]
[-xlicinfo] [-xlinkopt[=level]] [-xM] [-xM1] [-xMerge]
[-xmaxopt[=v]] [-xmemalign=ab] [-xmodel=[a]]
[-xnativeconnect[=n]] [-xnolib] [-xnolibmil] [-xnolib-
mopt] [-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]
[-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 11: C++ 5.8 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.
New Features
This section describes the new and changed features for the
Sun Studio 11: C++ 5.8 compiler. See the Sun Studio 11 C++
User's Guide for more detailed descriptions of the new
features.
o New -xarch Flags For x86 Development
The -xarch option now supports the following new flags
for development on the x86 platform: amd64a,
pentium_proa, ssea, sse2a. See the -xarch option
description in this man page for more information.
o Support For x86 -xpagesize Options
The -xpagesize, -xpagesize_heap, -xpagesize_stack
options are now enabled for x86 platforms as well as
SPARC.
o A New -xmodel Option To Specify x86 Memory Models
The new -xmodel option lets you specify the kernel,
small, or medium memory models on the 64-bit AMD archi-
tecture. If the size of your global and static vari-
ables exceeds two gigabytes, specify -xmodel=medium.
Otherwise, use the default -xmodel=small setting. See
the -xmodel option description in this man page for
more information.
o Support For SSE/SSE2 Integral Media Intrinsics
This release supports intrinsic functions for SSE2
128-bit XMM register integral media-instructions.
Include the sunmedia_intrin.h header file in the source
code and specify the -xbuiltin option to take advantage
of these functions. Furthermore, these intrinsic func-
tions require SSE2 support so specify options such as
-xarch=sse2, -xarch=amd64, or -xtarget=opteron.
Essentially, the compiler generates inline code for
these instrinsic functions. This is easier than manipu-
lating the instructions through assembly language and
it can be optimized by the compiler.
For more information about intrinsics, explanations for
the function prototypes contained in the header files,
and the data types used by these functions, see the
'Intel C++ Intrinsics Reference' section of the
Intel(R) C++ Compiler for Linux Systems manual.
o New -xvector Flags for x86 SSE2 Platforms
The -xvector option enables automatic generation of
calls to the vector library functions and/or the gen-
eration of the SIMD (Single Instruction Multiple Data)
instructions.
See the -xvector option description in this man page
for more information.
o Binary Optimizer for SPARC
A new -xbinopt option allows the compiler to prepare
the binary file for further optimization by the
binopt(1) binary optimizer.
o Calling Dependent Static Functions From a Function Template
The C++ standard says that function calls that depend
on a template parameter can refer only to visible func-
tion declarations having external linkage. Specify
-features=[no%]tmplrefstatic if your application code
depends on the compiler ignoring this rule and calling
a dependent static function from a function template.
See the C++ User's Guide for examples of
-features=[no%]tmplrefstatic.
o New SPARC -xtarget and -xchip Values
The new -xtarget flags ultra3iplus, ultra4plus, and
ultraT1 along with the new -xchip flags ultra3iplus,
ultra4plus, and ultraT1 provide code generation for the
UltraSPARC IIIiplus, UltraSPARC T1, and UltraSPARC
IVplus processors.
o A New Format For Debugger Information
The C++ compiler can now generate debugger information
in the dwarf format. The default is still the stabs
format, but you can generate dwarf data by setting the
new option -xdebugformat to -xdebugformat=dwarf.
o Enhancements to the STACKSIZE Environment Variable
The syntax of the STACKSIZE environment variable has
been enhanced to accept a units keyword for denoting
the slave thread stacksize: B for Bytes, K for Kilo-
bytes, M for Megabytes, G for Gigabytes.
For example, setenv STACKSIZE 8192 sets the slave
thread stack size to 8 MB. 1235B sets the slave thread
stack size for for 1235 Bytes. 1235G sets it for 1235
Gigabytes. The default for an integer value without a
suffix letter is still Kilobytes.
o OpenMP Autoscoping
Autoscoping is now available for C++ programs. This
feature is described in chapter 3 of the Sun Studio
OpenMP API User's Guide.
New Features In Sun Studio 10
This section describes the new and changed features for the
Sun Studio 10: C++ 5.7 compiler. See the C++ readme or the
Sun Studio 10 C++ User's Guide for more detailed descrip-
tions of these new features.
o A new -xarch option, -xarch=amd64, specifies compilation
for the 64-bit AMD instruction set.
o A new -xtarget option, -xtarget=opteron, specifies the
-xarch, -xchip, and -xcache settings for 32-bit AMD compila-
tion.
o A new x86-only flag for the -xregs option,
-xregs=[no%]frameptr, lets you use the frame-pointer regis-
ter as an unallocated callee-saves register to increase the
run-time performance of applications.
o The C++ compiler now predefines __amd64 and __x86_64 when
you specify -xarch=amd64.
o The existing -xarch=generic64 option now supports the x86
platform in addition to the traditional SPARC platform.
o The compiler now supports template-template parameters.
This means that you can specify a template definition with
parameters that are themselves templates, rather than types
or values. For more information, see the C++ readme or the
Sun Studio 10 C++ User's Guide.
o The compiler, in default standard mode, now allows nested
classes to access private members of the enclosing class. To
restore the old compiler behavior, disallowing the access,
specify -features=no%nestedaccess. The default is
-features=nestedaccess. For more information, see the C++
readme or the Sun Studio 10 C++ User's Guide.
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.
COMPILING FOR 64-BIT:
This version of the compiler can produce 64-bit object
binaries on 32-bit or 64-bit Solaris platforms. The result-
ing executable will run only on 64-bit SPARC UltraSPARC(R)
or x86 processors under Solaris OS with the 64-bit kernel.
Compilation, linking, and execution of 64- bit objects can
only take place in a Solaris OS environment that supports
64-bit execution.
The 64-bit Solaris OS provides support for 64-bit integer
and pointer data as well as support for large files and
large arrays.
On SPARC Platforms:
Compiling for a 64-bit Solaris OS on SPARC platforms is
indicated by one of the variants of the -xarch=v9 option.
You must specify one of these options even if you also
specify -xtarget or -fast. In such a case, the -xarch=v9
option must appear after any -xtarget or other option that
sets -xarch. For example:
-xtarget=ultra -xarch=v9
Note that -xtarget=ultra, -xtarget=ultra2, and
-xtarget=ultra3 imply -xarch=v8 and do not automatically
cause 64-bit compilations.
If you are building shared dynamic libraries with -xarch=v9,
v9a, or v9b in a 64-bit Solaris OS, you must specify
-xcode=pic13 or -xcode=pic32. -xcode=abs44 will not work.
See the -xcode option for information on how to specify code
address sizes.
For general information on 64-bit Solaris software for
software developers, see the "Solaris 64-bit Developer's
Guide" on http://docs.sun.com .
For more specific information regarding the migration of C
programs to a 64-bit environment, see the C User's Guide.
On x86 Platforms
On x86 platforms, -xarch=amd64 specifies compilation for the
64-bit AMD instruction set.
A new -xtarget option, -xtarget=opteron, specifies the
-xarch, -xchip, and -xcache settings for 32-bit AMD compila-
tion.
You must specify -xarch=amd64 after -fast and -xtarget on
the command line to generate 64-bit code. The new
-xtarget=opteron option does not automatically generate 64-
bit code. It expands to -xarch=sse2, -xchip=opteron, and
-xcache=64/64/2:1024/64/16 which result in 32-bit code. The
-fast option also results in 32-bit code because it is a
macro which also defines an -xtarget value. All the current
-xtarget values result in 32-bit code so be sure to specify
-xarch=amd64 after (to the right of) -fast or -xtarget if
you want to compile 64-bit code, as in:
CC -fast -xarch=amd64or CC -xtarget=opteron -xarch=amd64
Also, the existing -xarch=generic64 option now supports the
x86 platform in addition to the traditional SPARC platform.
The compilers now predefine __amd64 and __x86_64 when you
specify -xarch=amd64.
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:
__BUILTIN_VA_ARG_INCR
__cplusplus
__DATE__
__FILE__
__LINE__
__STDC__ = 0
__SVR4
__SUNPRO_CC = 0x580
__SUNPRO_CC_COMPAT = 4 or 5
__sun
sun
__TIME__
__`uname -s`_`uname -r` (replacing invalid charac-
ters with underscores, for example: -D__SunOS_5_8,
-D__SunOS_5_9)
__unix
unix
_WCHAR_T
__ARRAYNEW if the "array" forms of operators new
and delete are enabled
(see "-features=[no%]arraynew")
_BOOL if type bool is enabled
(see "-features=[no%]bool")
SPARC only:
__SUN_PREFETCH = 1
__sparc
sparc
SPARC V9 only:
__sparcv9 (64-bit compilation modes only)
x86 only:
__i386
i386
__amd64
__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 only)
-xlibmil (SPARC, x86)
-xlibmopt (SPARC, x86)
-xmemalign (SPARC only)
-xO5 (SPARC, x86)
-xtarget=native (SPARC, x86)
-xbuiltin=%all (SPARC, x86)
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
-flags Same as -xhelp=flags.
-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 Enables use of SIMD instructions to com-
pute reductions when -xvector=simd is in
effect.
Permits aggressive floating point optim-
ization that may cause many programs 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 platform) Same as -xcode=pic32.
(x86 platform) Same as -Kpic.
-Kpic (SPARC platform) Same as -xcode=pic13.
(x86 platform) Produces position-independent code.
Use this option to compile source files when
building a shared library. Each reference to a
global datum is generated as a dereference of a
pointer in the global offset table. Each function
call is generated in pc-relative addressing mode
through a procedure linkage table.
-keeptmp Retains the temporary files that are created 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
-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:
o Passes -D_REENTRANT to the preprocessor
o Passes -lthread in the correct order to ld
o Ensures that, for standard mode (the default
mode), libthread is linked before libCrun
o Ensures that, for compatibility mode (-compat),
libthread is linked before libC
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. This option does not
guarantee use of any target-specific instructions.
However, use of this option may affect the porta-
bility of a binary program. See the Notes and
Warnings sections.
If you compile and link in separate steps, make
sure you specify the same value for -xarch in both
steps.
Values:
For SPARC platforms:
Value Meaning
generic Produce 32-bit object binaries for good
performance on most systems.
This is no longer the default. The new
default is -xarch=v8plus. This option
uses the best instruction set for good
performance on most processors without
major performance degradation on any of
them. With each new release, the defini-
tion of "best" instruction set may be
adjusted, if appropriate. Use the
-xdryrun option to see the
-xarch=generic value for this release.
generic64 Product 64-bit object binaries for good
performance on most 64-bit platform
architectures.
This option uses the best instruction
set for good performance on Solaris
operating environments with 64-bit ker-
nels, without major performance degrada-
tion on any of them. With each new
release, the definition of "best"
instruction set may be adjusted, if
appropriate. Currently, this is
equivalent to -xrach=v9.
native Produce 32-bit object binaries for good
performance on this system.
This is the default for the -fast
option. The compiler chooses the
appropriate setting for the system on
which the processor is running.
native64 Produce 64-bit object binaries for good
performance on this system.
The compiler chooses the appropriate
setting for producing 64-bit binaries
for the system on which the processor is
running.
v7 Compile for the SPARC-V7 ISA. (Obsolete)
Current Solaris operating systems no
longer support the SPARC V7 architec-
ture, and programs compiled with this
option run slower on current platforms.
The default is -xarch=v8plus.
Examples: SPARCstation 1, SPARCstation
2.
v8a Compile for the V8a version of the
SPARC-V8 ISA.
By definition, V8a means the V8 ISA, but
without the fsmuld instruction. This
option enables the compiler to generate
code for good performance on the V8a
ISA.
Example: Any system based on the
microSPARC I chip architecture
v8 Compile for the SPARC-V8 ISA.
Enables the compiler to generate code
for good performance on the V8 architec-
ture.
Example: SPARCstation 10
v8plus This is the default and it means the
compiler uses the instruction set for
the V8plus version of the SPARC-V9 ISA.
By definition, V8plus means the V9 ISA,
but limited to the 32-bit subset defined
by the V8plus ISA specification, without
the Visual Instruction Set (VIS), and
without other implementation-specific
ISA extensions. This option enables the
compiler to generate code for good
performance on the V8plus ISA. The
resulting object code is in SPARC-V8+
ELF32 format and only executes in a
Solaris UltraSPARC environment -- it
does not run on a V8 processor.
Example: Any system based on the
UltraSPARC chip architecture
v8plusa Compile for the V8plusa version of the
SPARC-V9 ISA.
By definition, V8plusa means the V8plus
architecture, plus the Visual Instruc-
tion Set (VIS) version 1.0, and with
UltraSPARC extensions. This option
enables the compiler to generate code
for good performance on the UltraSPARC
architecture, but limited to the 32-bit
subset defined by the V8plus specifica-
tion. The resulting object code is in
SPARC-V8+ ELF32 format and only executes
in a Solaris UltraSPARC environment --
it does not run on a V8 processor.
Example: Any system based on the
UltraSPARC chip architecture
v8plusb Compile for the V8plusb version of the
SPARC-V8plus 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. The resulting object code is
in SPARC-V8+ ELF32 format and executes
only in a Solaris UltraSPARC III
environment. Compiling with this option
uses the best instruction set for good
performance on the UltraSPARC III archi-
tecture.
v9 Compile for the SPARC-V9 ISA.
Enables the compiler to generate code
for good performance on the V9 SPARC
architecture. The resulting .o object
files are in ELF64 format and can only
be linked with other SPARC-V9 object
files in the same format. The resulting
executable can only be run on an
UltraSPARC processor running a 64-bit
enabled Solaris operating environment
with the 64-bit kernel.
-xarch=v9 is only available when compil-
ing in a 64-bit enabled Solaris operat-
ing environment.
v9a Compile for the SPARC-V9 ISA with
UltraSPARC extensions.
Adds to the SPARC-V9 ISA the Visual
Instruction Set (VIS) and extensions
specific to UltraSPARC processors, and
enables the compiler to generate code
for good performance on the V9 SPARC
architecture. The resulting .o object
files are in ELF64 format and can only
be linked with other SPARC-V9 object
files in the same format. The resulting
executable can only be run on an
UltraSPARC processor running a 64-bit
enabled Solaris operating environment
with the 64-bit kernel.
-xarch=v9a is only available when com-
piling in a 64-bit enabled Solaris
operating environment.
v9b Compile for the SPARC-V9 ISA with
UltraSPARC III extensions.
Adds UltraSPARC III extensions and VIS
version 2.0 to the V9a version of the
SPARC-V9 ISA. Compiling with this option
uses the best instruction set for good
performance in a Solaris UltraSPARC III
environment. The resulting object code
is in SPARC-V9 ELF64 format and can only
be linked with other SPARC V9 object
files in the same format. The resulting
executable can only be run on an
UltraSPARC III processor running a 64-
bit enabled Solaris operating environ-
ment with the 64-bit kernel.
-xarch=v9b is only available when com-
piling in a 64-bit enabled Solaris
operating environment.
Notes:
o SPARC instruction set architectures V8 and V8a
are binary compatible.
o Object binary files (.o) compiled with v8plus
and v8plusa can be linked and can execute
together, but only on a SPARC V8plusa compatible
platform.
o Object binary files (.o) compiled with v8plus,
v8plusa, and v8plusb can be linked and can exe-
cute together, but only on a SPARC V8plusb com-
patible platform.
o -xarch values generic64 native64 v9, v9a, and
v9b are only available on UltraSPARC 64-bit
Solaris operating environments.
o Object binary files (.o) compiled with v9 and
v9a can be linked and can execute together, but
will run only on a SPARC V9a compatible plat-
form.
o Object binary files (.o) compiled with generic64
native64 v9, v9a, and v9b can be linked and can
execute together, but will run only on a SPARC
V9b compatible platform.
For any particular choice, the generated execut-
able may run much more slowly on earlier architec-
tures. Also, although quad-precision (REAL*16 and
long double) floating-point instructions are
available in many of these instruction set archi-
tectures, the compiler does not use these instruc-
tions in the code it generates.
For x86 platforms:
Value Meaning
amd64 Compile for 64-bit Solaris x86
platforms.
amd64a Adds the AMD extensions (3DNow!,
3DNow! extensions, and MMX exten-
sions) to the AMD64 architecture
and generates 64-bit ELF format
binary file.
generic Compile for good performance on
most systems.
This is the default. This option
uses the best instruction set for
good performance on most processors
without major performance degrada-
tion on any of them. With each new
release, the definition of "best"
instruction set may be adjusted, if
appropriate.
generic64 Product 64-bit object binaries for
good performance on most 64-bit
platform architectures.
This option uses the best instruc-
tion set for good performance on
Solaris operating environments with
64-bit kernels, without major per-
formance degradation on any of
them. With each new release, the
definition of "best" instruction
set may be adjusted, if appropri-
ate.
386 generic and 386 are equivalent in
this release.
pentium_pro Compile for the Intel Pentium Pro
chip.
pentium_proa Adds the AMD extensions (3DNow!,
3DNow! extensions, and MMX exten-
sions) to the 32-bit pentium_pro
architecture.
sse Adds the SSE instruction set to the
pentium_pro architecture.
ssea Adds the AMD extensions (3DNow!,
3DNow! extensions, and MMX exten-
sions) to the 32-bit SSE architec-
ture.
sse2 Adds the SSE2 instruction set to
the pentium_pro architecture.
sse2a Adds the AMD extensions (3DNow!,
3DNow! extensions, and MMX exten-
sions) to the 32-bit SSE2 architec-
ture.
Caution
Programs that are compiled with
-xarch= set to sse (Pentium 3) or
sse2 (Pentium 4) to run on Solaris
x86 SSE or SSE2 compatible plat-
forms must be run only on platforms
that are SSE or SSE2 enabled.
Programs compiled with -xarch set
to pentium_proa must be run on
platforms supporting AMD 3DNow! and
3DNow! extensions.
Programs compiled with -xarch set
to ssea, or sse2a must be run on
platforms supporting AMD 3DNow! and
3DNow! extensions as well as SSE or
SSE2 enabled.
OS releases starting with Solaris 9
4/04 are SSE/SSE2-enabled on Pen-
tium 3 or 4 compatible platforms.
Earlier versions of Solaris OS are
not SSE/SSE2-enabled.
Similarly, programs compiled with
-xarch=amd64 for Solaris x86 AMD64
platforms must be on run platforms
that support the AMD 64-bit archi-
tecture. Note that AMD64 architec-
ture supports SSE/SSE2.
Programs compiled with
-xarch=amd64a must be run on plat-
forms supporting the AMD 64-bit
architecture as well as AMD 3DNOW!
and AMD 3DNow! extensions.
Program binaries compiled and built
using these specialized -xarch
hardware flags are checked by the
operating system to verify that
they are being run on appropriately
enabled hardware. This verifica-
tion is available with Sun Studio
11 running on the Solaris 10
operating system.
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 flags on platforms
that are not enabled with the
appropriate features or instruction
set extensions can result in "Ille-
gal Instruction" errors, segmenta-
tion 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, AMD 64, and
AMD 3DNow! instructions and AMD
3DNow! extensions.
If you compile and link in separate
steps, always link using the com-
piler and using the same -xarch
setting to ensure that the correct
startup routine is linked.
Arithmetic results on x86 may
differ from results on SPARC due to
the x86 80-byte floating-point
registers. To minimize these
differences, use the -fstore option
or compile with -xarch=sse2 if the
hardware supports SSE2.
Defaults:
If -xarch=isa is not specified, -xarch=generic is
assumed.
Interactions:
Although this option can be used alone, it is part
of the expansion of the -xtarget option and may be
used to override the -xarch value that is set by a
specific -xtarget option. For example,
-xtarget=ultra2 expands to -xarch=v8 -xchip=ultra2
-xcache=16/32/1:512/64/1. In the following command
-xarch=v8plusb overrides the -xarch=v8 that is set
by the expansion of -xtarget=ultra2.
example% CC -xtarget=ultra2 -xarch=v8plusb ...
Use of -compat[=4] with -xarch=v9, -xarch=v9a,
or-xarch=v9b is not supported.
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 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. See the OpenMP API User's
Guide for migration information to the directives
of the standard.
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 determine how many processors you have, use the
psrinfo command.
To request a number of processors, set the PARAL-
LEL environment variable. The default is 1.
o Do not request more processors than are avail-
able.
o If N is the number of processors on the machine,
then for a one-user, multiprocessor system, try
PARALLEL=N-1.
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 perfor-
mance 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.
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.
ultra3i Optimize for the UltraSPARC IIIi proces-
sor.
ultra3iplus
Optimize for the UltraSPARC IIIiplus
processor.
ultra4 Optimize for the UltraSPARC IV proces-
sor.
ultra4plus
Optimize for the UltraSPARC IVplus pro-
cessor.
ultraT1 Optimize for the UltraSPARC T1 proces-
sor.
The -xchip values for x86 platforms are:
Value Meaning
generic Optimize for good performance on most
x86 processors.
386 Optimize for the Intel 386 processor.
486 Optimize for the Intel 486 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
For more information on how the compiler uses the
new pentium3 and pentium4 flags, see the section
'New -xarch, -xtarget, and -xchip Flags on x86' at
the beginning of this man page.
-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 such as
-xarch=generic or -xarch=v8plusb.
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 such as
-xarch=v9 or -xarch=v9b. 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: -xarch={v9|v9a|v9b}.
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.
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.
To determine whether to use -xcode=pic13 or
-xcode=pic32, check the size of the Global Offset
Table (GOT) by using elfdump -c (see the
elfdump(1) man page for more information) and for
the section header, sh_name: .got. The sh_size
value is the size of the GOT. If the GOT is less
than 8,192 bytes, specify -xcode=pic13, otherwise
specify -xcode=pic32.
In general, use the following guidelines to 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 SPARC V8 proces-
sors.
The default is -xcode=abs44 for SPARC and
UltraSPARC V9 processors (with
-xarch={v9|v9a|v9b}).
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
-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 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.
-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
-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.
-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 defini-
tion 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.
-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]
The -xmodel option enables the compiler to modify
the form of 64-bit objects for the Solaris x86
platforms and should only be specified for the
compilation of such objects.
This option is valid only when -xarch=generic64,
-xarch=amd64, or -xarch=amd64a are also specified.
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.
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.
-xnativeconnect [=n]
This option may be removed in a future release of
Sun Studio.
Use the -xnativeconnect option when you want to
include interface information inside object files
and subsequent shared libraries so that the shared
library can interface with Java. You must also
include -xnativeconnect when you build the shared
library with CC -G.
When you compile with -xnativeconnect, you are
providing the maximum, external, visibility of the
native code interfaces. The NCT enables the
automatic generation of Java and JNI code. Using
-xnativeconnect with the NCT can make functions in
C++ shared libraries callable from Java. For more
information on how to use the NCT, see the online
help.
This option does not accumulate. The compiler uses
the last setting that is issued. For example, if
you specify CC -xnativeconnect=inlines first.o
-xnativeconnect=interfaces second.o -O -G -o
library.so, the compiler sets the option to
-xnativeconnect=no%inlines,interfaces.
If your program does not compile when you use both
-g and -xnativeconnect, try compiling without the
-g option.
Defaults:
n must be
[{%all|%none}][,][[no%]inlines][,][[no%]interfaces]]
o If you do not specify -xnativeconnect, the
compiler sets the option to
-xnativeconnect=%none.
o -xnativeconnect
If you specify only -xnativeconnect, the com-
piler sets the option to
-xnativeconnect=inlines,interfaces.
o -xnativeconnect=inlines
The -xnativeconnect=inlines command forces the
generation of out-of-line instances of refer-
enced inline functions. External functions gen-
erated as part of a native connector may be
bound to these out-of-line instances. The normal
inlining of these functions at call sites is
unaffected
o -xnativeconnect=intefraces
The -xnative=interfaces command forces the gen-
eration of Binary Interface Descriptors (BIDS).
Warnings:
Do not compile with -compat=4 if you plan to use
-xnativeconnect. Remember that if you specify
-compat without any arguments, the compiler sets
it to -compat=4. If you do not specify -compat,
the compiler sets it to -compat=5. You can also
explicitly set the compatibility mode by issuing
-compat=5.
-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 Does 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.
-O and -xO2 are equivalent.
-xO3 In addition to optimizations performed at the
-xO2 level, also optimizes references and
definitions for external variables. This
level does not trace the effects of pointer
assignments. When compiling either device
drivers that are not properly protected by
volatile, or programs that modify external
variables from within signal handlers, use
-xO2.
In general, this level, and -xO4, usually
result in the minimum code size when used
with the -xspace option.
-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. In general,
this level results in increased code size
unless combined with -xspace.
-xO5 Does the highest level of optimization, suit-
able 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 pro-
file 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.
-O and -xO2 are equivalent.
-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
Values
i must be parallel, stubs, or none.
o -xopenmp=parallel
If you specify only -xopenmp, the compiler sets
the option to -xopenmp=parallel which enables
recognition of OpenMP pragmas and applies to
SPARC only. The optimization level under
-xopenmp=parallel is -x03. The compiler issues a
warning if the optimization level of your pro-
gram is changed from a lower level to -x03.
o -xopenmp=stubs
This option is no longer supported. An OpenMP
stubs library is provided for users' convenvi-
ence. To compile an OpenMP program that calls
OpenMP library functions but ignores the OpenMP
pragmas, compile the program without an -xopenmp
option, and link the object files with the
libompstubs.a library. For example,
% CC omp_ignore.c -lompstubs
Linking with both libompstubs.a and the OpenMP
runtime library libmtsk.so is unsupported and
may result in unexpected behavior.
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 -xopenmp, but without an argument,
the compiler sets the option to -xopenmp=parallel.
Warnings
If you compile and link in separate steps, also
specify -xopenmp on the link step. This is espe-
cially important when you compile libraries that
contain OpenMP directives.
Known Limitations
The following list details the known limitations
of the OpenMP functionality in the C++ compiler:
o No support for nested parallelism
The C++ compiler does not support nested paral-
lelism as defined in the OpenMP 2.5 draft stan-
dard.
o No checks for loop index modification
The compiler does not confirm that OpenMP for
loop indices are not modified within the body of
the loop.
o No checks for chunksize
The compiler neglects to check for zero or nega-
tive values at compile time, causing runtime
problems.
o No checks for overloaded operators used in
reduction clause
The compiler does not detect when operators used
as arguments in the reduction clause are
overloaded.
o Error message text still in review
The OpenMP error message system is under review
and revision. Some messages may be inaccurate or
unhelpful.
-xpagesize=n
Set the preferred page size for the stack and the
heap.
The n value must be one of the following:
8K, 64K, 512K, 4M, 32M, 256M, 2G, 16G, 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.
Note that this feature is not available on the
Solaris 8 operating system. A program compiled
with this option will not link on the Solaris 8
software.
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: 8K, 64K, 512K, 4M,
32M, 256M, 2G, 16G, default. 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: n can be
8K, 64K, 512K, 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.
Note that this feature is not available on the
Solaris 8 operating system. A program compiled
with this option will not link on the Solaris 8
software.
-xpagesize_stack=n
Set the page size in memory for the stack.
The n value must be one of the following: n can be
8K, 64K, 512K, 4M, 32M, 256M, 2G, 16G, 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.
Note that this feature is not available on the
Solaris 8 operating system. A program compiled
with this option will not link on the Solaris 8
software.
-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 fol-
lowing 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 com-
piler that created the precompiled-header file. A
precompiled-header file created by one version of
the compiler may not be usable by another version
of the compiler.
- Except for the -xpch option, the compiler
options you specify with -xpch=use must match the
options that were specified when the precompiled-
header file was created.
- The set of included headers you specify with
-xpch=use is identical to the set of headers that
were specified when the precompiled header was
created.
- The contents of the included headers that you
specify with -xpch=use is identical to the 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 con-
sistently across different source files. Specifi-
cally, when it contains only complete declara-
tions. That is, a declaration in any one file must
stand alone as a valid declaration. Incomplete
type declarations, such as struct S;, are valid
declarations. The complete type declaration can
appear in some other file. Consider these example
header files:
file a.h
struct S {
#include "x.h" /* not allowed */
};
file b.h
struct T; // ok, complete declaration
struct S {
int i;
[end of file, continued in another file] /* not
allowed */
file c.h
namespace N {
int foo();
[end of file, continued in another file] /* not
allowed */
file d.h
extern "C" {
int foo();
[end of file, continued in another file] /* not
allowed */
file e.h
namespace N {
int foo();
} /* OK, a stand-alone namespace declaration
*/
file f.h
namespace N {
int bar();
} /* OK, namespace re-opened, but still
stand-alone */
A header file that is incorporated into a
precompiled-header file must not violate the 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, such as
UltraSPARC II (-xarch=v8plus, v8plusa, v8plusb,
v9, v9a, or v9b)
a must be one of the following values.
Value Meaning
auto Enable automatic generation of pre-
fetch instructions.
no%auto Disable automatic generation
explicit (SPARC) Enable explicit prefetch
macros
no%explicit (SPARC) Disable explicit prefectch
macros.
latx:factor 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:
Explicit prefetching should only be used under
special circumstances that are supported by meas-
urements.
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.
-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 (-xO3) and generating code for a platform
that supports prefetch (v8plus, v8plusa, v9, v9a,
v9b, generic64, native64).
-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.
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.
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.
-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 (v8a, v8, v8plus, v8plusa,
v8plusb)
g2, g3 (v9, v9a, v9b)
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 AMD64) 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.
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 res-
tricted 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: v8plus, v8plusa, v8plusb, v9, v9a,
or v9b.
-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.
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
-xdryrun 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 -xarch=native,
-xchip=native, -xcache=native.
-xtarget=native64 is equivalent to
-xarch=native64, -xchip=native64, -xcache=native.
-xtarget=generic is equivalent to -xarch=generic,
-xchip=generic, -xcache=generic.
-xtarget=generic64 is equivalent to
-xarch=generic64, -xchip=generic64,
-xcache=generic.
Values:
On SPARC platforms:
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.
The compiler expands -xtarget=generic
to:
-xarch=generic -xchip=generic
-xcache=generic
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,
ultra3iplus, ultra4, ultra4plus,
ultraT1.
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:
Value Meaning
386 Directs the compiler to generate
code for the best performance on
the Intel 80386 microprocessor.
486 Directs the compiler to generate
code for the best performance on
the Intel 80486 microprocessor.
generic This is the default and yields the
best performance for generic archi-
tecture, chip and cache on most
32-bit systems.
generic64 Gets the best performance for gen-
eric architecture, chip and cache
on most 64-bit systems.
native The compiler generates code for the
best performance on the host sys-
tem. This flag determines the
available architecture, chip, and
cache properties of the machine on
which the compiler is running and
assumes a 32-bit architecture.
native64 Set the parameters for the best
performance on the host system.
This flag determines the available
architecture, chip, and cache pro-
perties of the machine on which the
compiler is running and assumes a
64-bit architecture.
opteron Directs the compiler to generate
code for the best performance on
the 32-bit AMD microprocessor.
Note: The new -xtarget=opteron
option does not automatically gen-
erate 64-bit code. It expands to
-xarch=sse2, -xchip=opteron, and
-xcache=64/64/2:1024/64/16 which
results in 32-bit code. You must
specify -xarch=amd64 after (to the
right of) -xtarget 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.
For more information on how the compiler uses
the new pentium3 and pentium4 flags, see the
section 'New -xarch, -xtarget, and -xchip
Flags on x86' at the beginning of this man
page.
Interactions:
Compiling for 64-bit Solaris software on SPARC or
UltraSPARC V9 is indicated by the -xarch=v9,
-xarch=v9a, or -xarch=v9b flag. Setting
-xtarget=ultra, ultra2, or ultra3 is not necessary
or sufficient. If -xtarget is specified, then
-xarch=v9, -xarch=v9a, or -xarch=v9b must appear
AFTER -xtarget, as in:
-xtarget=ultra2 ... -xarch=v9
Otherwise the -xtarget setting will revert the
-xarch value to v8.
-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 8 software, objects that use __thread
must be compiled with -mt and must be linked with
-mt -L/usr/lib/lwp -R/usr/lib/lwp.
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=amd64,
-xarch=amd64a 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 version 8 and 9 of the Solaris operating
system. For the compiler to work correctly with the shared
library on the Solaris 8 and 9 operating system 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++