Man Page CC.1
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}] [-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] [-keeptmp] [-KPIC]
[-Kpic] [-Lpath] [-llib] [-libmieee] [-libmil]
[-library=lib[,lib...]] [-mc] [-migration] [-misalign]
[-mr[,string]] [-mt] [-native] [-noex] [-nofstore]
[-nolib] [-nolibmil] [-noqueue] [-norunpath] [-O[n]]
[-o file] [+p] [-P] [-p] [-pentium] [-pg] [-PIC] [-pic]
[-pta] [-ptipath] [-pto] [-ptrpath] [-ptv]
[{-Qoption|-qoption} phase option[,option...]]
[{-Qproduce|-qproduce} type] [-qp] [-Rpath[:path...]]
[-readme] [-S] [-s] [-sb] [-sbfast]
[-staticlib=l[,l...]] [-temp=path]
[-template=a[,a...]] [-time] [-Uname] [-unroll=n] [-V]
[-v] [-vdelx] [-verbose=a[,a...]] [+w] [+w2] [-w]
[-xa] [-xar] [-xarch=isa] [-xbuiltin[={%all|%none}]]
[-xcache=c] [-xcg{89|92}] [-xchip=c] [-xcode=v]
[-xcrossfile[=n]] [-xF] [-xhelp={flags|readme}] [-xia]
[-xild{off|on}] [-xinline[=func_spec[,func_spec...]]
[-xipo[={1|0}] [-xlang=language[,language]] [-xlib-
mieee] [-xlibmil] [-xlibmopt] [-xlic_lib=sunperf]
[-xlicinfo] [-Xm] [-xM] [-xM1] [-xMerge] [-xnolib]
[-xnolibmil] [-xnolibmopt] [-xOn] [-xpg]
[-xprefetch[=a[,a]] [-xprofile=p] [-xregs=r[,r...]]
[-xs] [-xsafe=mem] [-xsb] [-xsbfast] [-xspace]
[-xtarget=t] [-xtime] [-xtrigraphs[={yes|no}]]
[-xunroll=n] [-xwe] [-z arg] [file] ...
Sun WorkShop(TM) Release 6 update 1
Be sure to read the C++ Readme file by using the command:
example% CC -xhelp=readme
Note - In this document the term "IA" refers to the Intel
32-bit processor architecture, which includes the Pentium,
Pentium Pro, Pentium II, Pentium II Xeon, Celeron, Pentium
III, and Pentium III Xeon processors and compatible
microprocessor chips made by AMD and Cyrix.
DESCRIPTION
CC converts C++ and assembly source files to object files,
and links object files and libraries into executable pro-
grams.
Programs containing 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.
The Incremental Link Editor (ild) is sometimes used in place
of linker ld for incremental linking. See -xildon and -xild-
off for more information.
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:
Sun WorkShop Compilers C++ 6 can produce 64-bit object
binaries on the Solaris(TM) 7 and Solaris 8 operating
environments (SPARC(TM) Platform Edition) with a 64-bit ker-
nel. The resulting executable will run only on a SPARC V9
(64-bit) processor under a Solaris 7 or Solaris 8 operating
environment with a 64-bit kernel.
To create a 64-bit application, use the -xarch=v9,
-xarch=v9a, or -xarch=v9b option. Note that one of these
options must be specified even if -xtarget or -fast is also
specified. In such a case, the -xarch=v9, -xarch=v9a, or
-xarch=v9b option must appear AFTER -xtarget or any other
option that sets -xtarget (such as -fast). For example:
-xtarget=ultra -xarch=v9
Note that -xtarget=ultra and -xtarget=ultra2 imply -xarch=v8
and do not automatically signal -xarch=v9, -xarch=v9a, or
-xarch=v9b.
See also the -xcode=abs32|abs44|abs64|pic13|pic32 option for
specifying code address forms.
For more details, see:
<install-directory>/SUNWspro/READMEs/64bit_Compilers
Replace <install-directory> with the path to your Sun
WorkShop installation directory. In a default installation,
<install-directory> is /opt.
For general information on 64-bit Solaris for software
developers, see the "Solaris 64-bit Developer's Guide" on
http://docs.sun.com.
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 (IA platform) Use -xtarget=386.
-486 (IA 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.
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:
When building a shared library in compatiblity
mode (-compat[=4]), do not use -Bsymbolic if the
library has exceptions in it. Exceptions that
should be caught might be missed.
-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-
patabiity mode accepts the Annotated C++ Reference
Manual (ARM) semantics and language defined by the
4.2 compiler (-compat[=4]). The standard mode
accepts constructs according to the ANSI/ISO stan-
dard (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] (Compatiblity 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. Regardless of the -compat set-
ting, __SUNPRO_CC_COMPAT is set to 0x530.
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 when the library has exceptions
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 +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 in compatibility
mode, (-compat[=4]) do not use (-Bsymbolic) if the
library has exceptions in it. Exceptions that
should be caught might be missed.
+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 -gO degubbing 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 IA platforms:
__BUILTIN_VA_ARG_INCR
__cplusplus
__DATE__
__FILE__
__LINE__
__STDC__
__SVR4
__SUNPRO_CC = 0x530
__SUNPRO_CC_COMPAT = 4 or 5
__sun
sun
__TIME__
__`uname -s`_`uname -r` (replacing invalid charac-
ters with underscores, for example: -D__SunOS_5_7,
-D__SunOS_5_8)
__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:
__sparc
sparc (32-bit compilation modes only)
SPARC V9 only:
__sparcv9 (64-bit compilation modes only)
IA platform only:
__i386
i386
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:
In a 64-bit environment, many system libraries are
available only as shared dynamic libraries. These
include libm.so and libc.so. libm.a and libc.a are
not provided. As a result, -Bstatic and -dn may
cause linking errors in 64-bit Solaris environ-
ments. Applications must link with the dynamic
libraries in these cases.
-dalign (SPARC platform) Generates double-word load and
store instructions whenever possible for improved
performance. This option assumes that all
double-typed data are double-word-aligned. If you
compile one unit with -dalign, compile all units
of a program with -dalign, or you might get unex-
pected results.
-dryrun Directs the driver CC 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.
-fast Selects a combination of compilation options for
optimum execution speed on the system upon which
the code is being compiled. This option provides
near maximum performance for most applications by
expanding the following compilation options:
-dalign (SPARC only)
-fns (SPARC only)
-fsimple=2 (SPARC only)
-ftrap=%none (SPARC, IA)
-xlibmil (SPARC, IA)
-nofstore (IA only)
-xO5 (SPARC, IA)
-xlibmopt (SPARC, IA)
-xtarget=native (SPARC, IA)
-xbuiltin=%all (SPARC, IA)
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
will override 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 (-
compat[=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 (compatiblity mode or standard
mode).
[no%]altspell [Do not] Recognize alternative
token spellings (for example, and
for &&). The default is
no%altspell in compatibility mode
and altspell in standard mode.
[no%]anachronisms
[Do not] Allow anachronistic 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%extenstions.
[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.
[no%]rtti (Compatibility mode only) [Do not]
Allow runtime type identification
(RTTI). RTTI must be enabled to
use the dynamic_cast<> and typeid
operators. The default is no%rtti.
[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%]strictdestrorder
(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 tmplife.
[no%]transitions
[Do not] allow ARM language
contsructs that are problematic in
standard C++ and that may cuase 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
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:
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.
-filt[=filter[,filter...]]
Suppress the filtering that CC normally applies to
linker error messages.
filter must be one of the following values
[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%]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.
%all Equivalent to
-filt=errors,names,returns. This
is the default behavior.
%none Equivalent to
-filt=no%errors,no%names,no%returns.
Defaults:
If you do not specify the -filt option, or if you
specify -filt without any values, then the
compiler assumes -filt=errors,names,returns.
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-
strandard 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:
IA: -fnonstd expands to -ftrap=common.
SPARC: -fnonstd expands to -fns -ftrap=common.
See the Numerical Computation Guide for more
information.
-fns[={no|yes}]
SPARC: Selects SPARC nonstandard floating-point
mode.
This flag causes the nonstandard floating-point
mode to be enabled when a program begins execu-
tion.
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.
This option is effective only on SPARC platforms
and only if used when compiling the main program.
On IA platforms, the option is ignored.
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
(IA 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 IA 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 might be deleted.
o Computation with infinities or NaNs as
operands needs to propagate NaNs to
their results; e.g., x*0 might be
replaced by 0.
o Computations do not depend on sign of
zero.
2 Permits aggressive floating point optim-
ization that may cause many programs to
produce different numeric results due to
changes in rounding. For example, per-
mits the optimizer to replace all compu-
tations 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.
Interactions:
-fast implies -fsimple=2.
Warnings:
This option can break IEEE 754 conformance.
-fstore (IA 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.
This option sets the IEEE 754 trapping modes that
are established at program initialization, but
does not install a SIGFPE handler. You can use
ieee_handler to simultaneously enable traps and
install a SIGFPE handler. When more than one value
is used, 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 and must be used with one of these
values, as shown in the example. The [no%] form of
the option by itself does not explicitly cause a
particular trap to be disabled.
If you wish to enable the IEEE traps,
-ftrap=common is the recommended setting.
Defaults:
If -ftrap is not specified, the -ftrap=%none value
is assumed. (Traps will not be enabled automati-
cally.)
Examples:
When one or more terms are given, the list is pro-
cessed sequentially from left to right, thus
-ftrap=%all,no%inexact means to set all traps
except inexact.
Interactions:
The mode may be changed at runtime with
ieee_handler(3M).
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;
This option is effective only if used when compil-
ing the main program.
-G Instructs the linker to build a dynamic shared
library instead of an executable file; see the
ld(1) man page and the C++ User's Guide. All
source files specified in the command line are
compiled with -Kpic 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.
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 use this option and the optimization level
is -xO3 or lower, the compiler provides best-
effort symbolic information with almost full
optimization. Tail call optimizatio 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.
This option makes -xildon the default incremental
linker option in order to speed up the compile-
edit-debug cycle. See the description for -xildon
and -xildoff. This option invokes ild in place of
ld unless any of the following are true:
o The -G option is present
o The -xildoff option is present
o Any source files are named on the command line.
To use the full capabilities of the Sun WorkShop 6
Performance Analyzer, compile with the -g option.
While some performance analysis features do not
require -g, you must compile with -g to view anno-
tated source, some function level information, and
compiler commentary messages. See the analyzer(1)
man page and "Compiling Your Program for Data Col-
lection and Analysis" in Analyzing Program Perfor-
mance with Sun WorkShop for more information.
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.
See also:
For more information, see the explanations for -g0
and +d, as well as the ld(1) man page. The
Debugging a Program with dbx guide provides
details about dbx stabs and "lazy stabs."
-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.
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.
-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:
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 and gives them glo-
bal linkage. (If an instance in the
repository is out of date, it will be
reinstantiated.)
explicit Places explicitly instantiated instances
into the current object file and gives
them global linkage. Does not generate
any other needed instances.
global Places all needed instances into the
current object file and gives them glo-
bal linkage.
semiexplicit
Places explicitly instantiated instances
into the current object file and gives
them global linkage. Places all
instances needed by the explicit
instances into the current object file
and gives them static linkage. Does not
generate any other needed instances.
static Places all needed instances into the
current object file and gives them
static linkage.
Defaults:
If instances is not specified, -instances=extern
is assumed.
Warnings:
static and semiexplicit values may produce invalid
results. See C++ User's Guide for more informa-
tion.
-keeptmp Retains the temporary files that are created dur-
ing compilation. Along with -verbose=diags, this
option is useful for debugging.
-KPIC (SPARC platform) Same as -xcode=pic32.
(IA platform) Same as -Kpic.
-Kpic (SPARC platform) Same as -xcode=pic13.
(IA 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.
-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.
-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.
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.
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
-xlang=f77.
[no%]f90 Deprecated. Do not use
-xlang=f90.
[no%]f95 Deprecated. Do not 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%]gc_dbg [Do not] Use debug-enabled
libgc, garbage collection.
[no%]sunperf SPARC: [Do not] Use the Sun
Performance Library(TM).
%all Deprecated. -library=%all is
the same as specifying
-library=f77, f90, rwtools7,
complex, interval, gc. Note
that the libC library is
always included unless it is
specifically excluded using
-library=no%libC.
%none Use no C++ libraries except
for libC.
For standard mode (the default mode):
Value Meaning
[no%]f77 Deprecated. Do not use
-xlang=f77.
[no%]f90 Deprecated. Do not use
-xlang=f90.
[no%]f95 Deprecated. Do not 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%]Crun [Do not] Use libCrun, the C++
runtime library
[no%]gc [Do not] Use libgc, garbage
collection.
[no%]gc_dbg [Do not] Use debug-enabled
libgc, garbage collection.
[ no% ]sunperf SPARC: [Do not] Use the Sun
Performance Library (TM).
%all Deprecated. -library=%all is
the same as -library=f77, f90,
rwtools7, gc, interval, ios-
tream, Cstd. Note that the
libCrun library always is
included unless it is specifi-
cally excluded using
-library=no%Crun.
%none Use no C++ libraries except
for libC run.
Defaults:
For compability 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), if -library
is not specified, -library=Cstd,Crun is assumed.
The libCstd library is always included unless it
is specifically excluded using -library=%none or
-library=no%Cstd.
The libCrun library is always included unless it
is specifically excluded using -library=no%Crun.
Examples:
To link in standard mode (the default mode)
without any C++ libraries (except libCrun), use:
example% CC -library=%none
To include the Rogue Wave tools.h++ V7 and ios-
tream libraries in standard mode, use:
example% CC -library=rwtools7,iostream
Interactions:
This option accumulates instead of overrides.
Only one rwtool library can be used at a time.
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:
If you compile and link in separate steps, the set
of -library options that appear in the the link
command.
The set of libraries is not stable and might
change from release to release.
We recommend against using the -library=%all
option because of the following reasons:
o The exact set of libraries that will be
included by using this command may vary from
release to release.
o You might not get a library you were
expecting.
o You might get a library you were not
expecting.
o Other developers who look at the makefile
command line will not know what you were
expecting to link.
o This option will be removed in a future
release of the compiler.
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
section of the object file. When you use the -mc
option, the -mcs -c command is invoked.
-migration
Explains where to get information about migrating
source code that was built for earlier versions of
the compiler.
Note - This option might cease to exist in the
next release.
-misalign (SPARC 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 peformance. 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 occurences of string from the .comment
section of the object file and, if string is sup-
plied, places string in that section. 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 compability 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.
See also:
-xnolib
-native Use -xtarget=native.
-noex Use -features=no%except.
-nofstore (IA 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 Same as -xO2
-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 Prepares the object code to collect data for pro-
filing with prof. This option invokes a runtime
recording mechanism that produces a mon.out file
at normal termination.
Warnings:
If you compile and link in separate steps, the -p
option must appear in both command. Including -p
in one step and excluding it from the other step
will not effect the correctness of the program,
but you will not be able to do profiling.
See Also:
-xpg -xprofile analyzer(1) man page.
Analyzing Program Performance with Sun WorkShop
-pentium (IA platform) Use -xtarget=pentium.
-pg Use -xpg.
-PIC SPARC: Same as -xcode=pic32.
IA: Same as -KPIC.
-pic SPARC: Same as -xcode=pic13.
IA: 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.
-Qoption phase option[,option...]
Passes option to the compilation phase.
The following table shows the possible values for
phase.
SPARC platforms IA platforms
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 isnot present, the library search
path that is recorded in the output object and
passed to the runtime linker depends upon the tar-
get architecture instruction specified by the
-xarch option (when -xarch is not presentare con-
catenated, 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 Use -xsb.
-sbfast Use -xsbfast.
-staticlib=l[,l...]
Indicates which C++ libraries specified by the
-library option (including its defaults), which
libraries specified in the -xlang option, and
which libraries specified by use of 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.
-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%]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.
[no%]extdef [Do not] search for template
definitions in separate source
files.
Defaults:
-template=no%wholeclass,extdef
-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 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[].
-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 Prints extra warnings where necessary.
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.
Warnings:
Some Solaris 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.
-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.
-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.
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.
-xarch=isa
Specifies the target architecture instruction set
(ISA).
This option limits the code generated by the com-
piler to the instructions of the specified
instruction set architecture by allowing only the
specified set of instructions. This option does
not guarantee use of any target-specific instruc-
tions. However, use of this option may affect the
portability of a binary program. See the Notes
and Warnings sections.
Values:
For SPARC platforms:
Value Meaning
generic Produce 32-bit object binaries for good
performance on most systems.
This is the default. This option uses
the best instruction set for good per-
formance 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. Currently,
this is equivalent to -xarch=v7.
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.
Enables the compiler to generate code
for good performance on the V7 ISA. This
is equivalent to using the best instruc-
tion set for good performance on the V8
ISA, but without integer mul and div
instructions, and the fsmuld instruc-
tion.
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 Compile 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 per-
formance on the V8plus ISA. The result-
ing object code is in SPARC-V8+ ELF32
format and only executes in a Solaris
UltraSPARC environment -- it does not
run on a V7 or 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 V7 or 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 environ-
ment.
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 V7, V8, and
V8a are all 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 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 IA platforms:
Value Meaning
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.
386 generic and 386 are equivalent in
this release.
pentium_pro Compile for the Intel Pentium Pro
chip.
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 -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.
-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.
-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 (SPARC platforms) Defines the cache properties for
use by the optimizer.
This option specifies the cache properties that
the optimizer can use. It does not guarantee that
any particular cache 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 environment
(assumes a 32-bit architecture). e
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
-xcg89 Same as -xtarget=ss2.
Warnings:
If you compile and link in separate steps and you
compile with -xcg89, be sure to link with the same
option, or you might get unexpected results.
-xcg92 Same as -xtarget=ss1000.
Warnings:
If you compile and link in separate steps and you
compile with -xcg92, be sure to link with the same
option, or you might get unexpected results.
-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 (assumes a
32-bit architecture).
old Optimize for processors older than
SuperSPARC(TM).
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.
powerup Optimize for the Weitek PowerUp 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.
The -xchip values for IA platforms are:
Value Meaning
generic Optimize for good performance on most IA
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.
-xcode=a (SPARC platform) Specifies code address space.
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.
abs44 SPARC: Generate 44-bit absolute
addresses, which have moderate speed and
moderate range. Code + data + bss size
is limited to 2**44 bytes. Available
only on 64-bit architectures:
-xarch={v9|v9a|v9b}.
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.
Defaults:
The default is -xcode=abs32 for SPARC V8 and V7
processors.
The default is -xcode=abs64 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.
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.
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.
-xF If you compile with the -xF option, and then run
the Analyzer, you generate a map file that shows
an optimized order for the functions. The subse-
quent link to build the executable file can be
directed to use that map by using the linker
-Mmapfile option. It places each function from the
executable file into a separate section.
Reordering the subprograms in memory is useful
only when the application text page fault time is
consuming a large percentage of the application
time. Otherwise, reordering may not improve the
overall performance of the application.
Interactions:
When you use -xF, your program will not work
unless you also specify -features=no%except.
The analyzer(1) and ld(1) man pages provide
further details on this option.
-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/forte/info/features/intervals.html),
-library
-xildoff Turns off the Incremental Linker.
This option is assumed if you do not use the -g
option. It is also assumed if you do use the -G
option, or name any source file on the command
line. Override this default by using the
-xildon option.
-xildon Turns on the Incremental Linker. This option is
assumed if you use the -g option and not -G, and
do not name any source file on the command line.
Override this default by using the -xildoff
option.
-xinline[=func_spec[,func_spec...]]
Specifies which user-written routines can be
inlined by the optimizer at -xO3 or higher.
Values:
func_spec 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 -xin-
line, you might actually diminish performance.
-xipo[={0|1}]
Performs interprocedural optimizations.
The -xipo option performs whole-program optimiza-
tions 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.
The -xipo option is particularly useful when
compiling and linking large multifile applica-
tions. Object files compiled with this flag have
analysis information compiled within them that
enables interprocedural analysis across source and
precompiled program files. However, analysis and
optimization is limited to the object files com-
piled with -xipo, and does not extend to object
files on libraries.
Values
Value Meaning
0 Do not perform interprocedural
optimizations.
1 Perform interprocedural optimiza-
tions.
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.
-xlang=language[,language]
Include the appropriate runtime libraries and
insure the proper runtime environment for the
specified language.
language must be either f77, f90, or f95.
The -f90 and -f95 arguments are equivalent.
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
heirarchy:
1. C++
2. Fortran 95 (or Fortran 90)
3. Fortran 77
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 Fortan 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
-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.
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
SPARC: Links in the Sun Performance Library(TM).
This option, like -l, should appear at the end of
the command line, after source and object files.
The -library=sunperf option is recommended for
linking the Sun Performance Library because this
option ensures that the libraries are linked in
the correct order. In addition, the
-library=sunperf option is not position dependent
(it can appear anywhere on the command line), and
it enables you to use -staticlib to statically
link the Sun Performance Library. The -staticlib
option is more convenient to use than the -Bstatic
-xlic_lib=sunperf -Bdynamic combination.
Interactions
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 Library, use -library=sunperf instead.
You cannot use -library=sunperf and
-xlic_lib=sunperf in the same compiler command.
The recommeded method for statically linking the
Sun Performance Library is to use the
-library=sunperf and -staticlib=sunperf options,
as in the following example:
example% CC -library=sunperf -staticlib=sunperf
...
If you choose to use the -xlic_lib=sunperf option
instead of -library=sunperf, then use the -Bstatic
option as shown in the following example:
example% CC ... -Bstatic -xlic_lib=sunperf
-Bdynamic ...
See also:
-staticlib
-xlicinfo Shows license server information.
This option returns the license-server name and
the user ID for each user who has a license
checked out.
-Xm Use -features=iddollar.
-xM Outputs makefile dependency information.
Examples:
The program foo.cc contains the following state-
ment:
#include "foo.h"
When foo.cc is compiled with the -xM option, the
output includes the following line:
foo.o : foo.h
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.
-xnolib Disables linking with default system libraries.
Normally, the C++ compiler links with several sys-
tem libraries to support C++ programs. With this
option, the -llib options to link the default sys-
tem support libraries are not passed to ld.
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 -lw -lcx -lc
o Compatibility mode (-compat[=4]):
-lC -lm -lw -lcx -lc
The order of the -l options is significant. The
-lm, -lw, and -lcx options 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 in the outputP
-lCstd -lCrun -lm -lw -lc
Note that when -xarch=v9 is specified, -lcx is not
linked.
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 -lw -lcx -lc"
o Compatibility mode:
example% CC -compat -xnolib test.cc -lc -Bstatic
-lm -Bdynamic -lw -lcx -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.
-lcx is not present in 64-bit compilation mode.
-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.
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)
If the -xO option is not specified, only a very
basic level of optimization, limited to local com-
mon subexpression elimination and dead code
analysis, is performed. Compiling with an optimi-
zation level can improve a program's performance
significantly.
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 IA 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 IA 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:
-fast, -xprofile=p, csh(1) man page
Analyzing Program Performance With Sun WorkShop
discusses the effects of the different levels of
optimization on the Analyzer's data.
-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
produces a gmon.out file when the program normally
terminates.
You can also perform this task with the 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.
-xprefetch[=a[,a]]
(SPARC platform) 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 Enable explicit prefetch macros
no%explicit Disable explicit prefectch macros.
latx:factor Adjust the compiler's assumed
prefetch-to-load and prefetch-to-
store latencies by the specified
factor. The factor must be a posi-
tive floating-point or integer
number.
yes Same as -xprefetch=auto,explicit.
no Same as
-xprefetch=no%auto,no%explicit.
With -xprefetch, -xprefetch=auto, and
-xprefetch=yes, the compiler is free to insert
prefetch instructions into the code it generates.
This may result in a performance improvement on
architectures that support prefetch.
If you are running computationally intensive codes
on large multiprocessors, you might find it 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 prefetcha and a store.
The compiler tunes the prefetch mechanism for
optimal performance across a wide range of
machines and applications. This tuning may not
laways be optimal. For memory-intensive applica-
tions, expecially applications intended ro 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:
If -xprefetch is not specified,
-xprefetch=no%auto,explicit is assumed.
If only -xprefetch is specified,
-xprefetch=auto,explicit is assumed.
The default of no%auto is assumed unless expli-
citly overridden with the use of -xprefetch
without any arguments or with an argument of auto
or yes. For example, -xprefetch=explicit is the
same as -xprefetch=explicit,no%auto.
The default of explicit is assumed unless expli-
citly overriden with no%explicit or no. For exam-
ple, -xprefetch=auto is the same as
-xprefetch=auto,explicit.
If automatic prefetching is enabled, such as with
-xprefetch or -xprefetch=yes, but a latency factor
is not specified, then latx:1.0 is assumed.
Interactions:
This option accumulates instead of overrides.
The sun_prefetch.h header file provides the macros
for specifying explicit prefetch instructions. The
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.
-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. This option is only valid when a
level of optimization is specified.
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 the name of the program that is
being analyzed. This name is optional. If
name is not specified, a.out is assumed to be
the name of the executable.
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.
use[:name]
Uses execution frequency data to optimize
strategically. The name is the name of the
executable that is being analyzed. This name
is optional. If name is not specified, a.out
is assumed to be the name of the executable.
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 prfiling, 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.
-xregs=r[,r...]
(SPARC platform) 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 must be one of the following values.
appl Allow use of specific registers depending
upon the specified -xarch value.
v8, v8a -- Allow use of registers g2, g3,
and g4.
v8plus, v8plusa, v8plusb -- Allow use of
registers g2, g3, and g4.
v9, v9a, v9b -- Allow use of registers g2
and g3.
See -xarch for more information about the
meaning of each -xarch value.
no%appl Do not use appl registers.
float Allow using floating-point registers as
specified in the SPARC ABI.
no%float Do not use floating-point registers.
Defaults:
If -xregs is not specified, then -xregs=appl,float
is assumed.
-xs Allows debugging by dbx without object ( .o)
files.
This option disables Auto-Read for dbx. Use this
option when you cannot keep the .o files around.
This option passes -s to the assembler.
"No Auto-Read" is the older way of loading symbol
tables. It places all symbol tables for dbx in the
executable file. The linker links more slowly,
and dbx initializes more slowly.
Auto-Read is the newer and default way of loading
symbol tables. With Auto-Read, the information is
distributed in the .o files, so that dbx loads the
symbol table information only when it is needed.
Hence, the linker links faster, and dbx initial-
izes faster.
With -xs, if you move executables to another
directory, you do not have to move the object
files in order to use dbx.
Without -xs, if you move the executables, then you
must move both the source files and the object (
.o ) files in order to use dbx.
-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 Produces information for the WorkShop source code
browser.
This option causes the CC driver to generate extra
symbol table information in the SunWS_cache sub-
directory for the source browser.
See also:
-xsbfast
-xsbfast Produces only source browser information, no
compilation.
This option runs only the ccfe phase to generate
extra symbol table information in the SunWS_cache
subdirectory for the source browser. No object
file is generated.
-xspace (SPARC platform) 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. Refer to
the entry for -xtarget in the C++ User's Guide for
the list of expanded values.
The -xtarget option permits a quick and easy
specification of the -xarch, -xchip, and -xcache
combinations that occur on real systems. The only
meaning of -xtarget is in its expansion.
-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. It
determines the available architecture,
chip, and cache properties of the
machine on which the compiler is
running.
native64 Set the parameters for the best perfor-
mance on the host environment (assumes a
64-bit architecture).
generic Gets the best performance for generic
architecture, chip and cache.
The compiler expands -xtarget=generic
to:
-xarch=generic -xchip=generic
-xcache=generic
This is the default value.
generic64 Set the parameters for the best perfor-
mance over most 64-bit platform archi-
tectu res.
platform-name
Gets the best performance for the speci-
fied platform.
Valid platform-name values are:
sun4/15, sun4/20, sun4/25, sun4/30,
sun4/40, sun4/50, sun4/60, sun4/65,
sun4/75, sun4/110, sun4/150, sun4/260,
sun4/280, sun4/330, sun4/370, sun4/390,
sun4/470, sun4/490, sun4/630, sun4/670,
sun4/690, sselc, ssipc, ssipx, sslc,
sslt, sslx, sslx2, ssslc, ss1, ss1plus,
ss2, ss2p, 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/120, ss600/140, ss600/412,
ss600/512, ss600/514, ss600/612, ss1000,
sc2000, cs6400, solb5, solb6, ultra,
ultra2, ultra2e, ultra2i, ultra1/140,
ultra1/170, ultra1/200, ultra2/1170,
ultra2/1200, ultra2/1300, ultra2/2170,
ultra2/2200, ultra2/2300, ultra3, entr2,
entr2/1170, entr2/2170, entr2/1200,
entr2/2200, entr150, entr3000, entr4000,
entr5000, entr6000.
For more information about platform
names, see the entry for -xtarget in the
C++ User's Guide
On IA platforms:
o native or generic
o 386 (Directs the compiler to generate code
for the best performance on the Intel 80386
microprocessor.)
o 486 (Directs the compiler to generate code
for the best performance on the Intel 80486
microprocessor.)
o pentium (Directs the compiler to generate
code for the best performance on the Pen-
tium microprocessor.)
o pentium_pro (Directs the compiler to gen-
erate code for the best performance on the
Pentium Pro microprocessor.)
Interactions:
Compiling for 64-bit Solaris 7 or Solaris 8
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.
-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.
-xwe Converts all warnings to errors by returning non-
zero exit status.
-z arg Link editor option.
For more information see the ld(1) man page and
the Solaris Linker and Libraries Guide.
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 Sun WorkShop C++ compiler 5.0 and the Sun WorkShop 6 C++
compiler on versions 2.6, 7, and 8 of the Solaris operating
enviroment. For the compiler to work correctly with the
shared library on Solaris OS versions 2.6, 7, and 8 you must
install the appropriate OS patch; see the README.
Type CC -xhelp=readme for details.
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), ild(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++