NAME
cc - C compiler
SYNOPSIS
cc [-#] [-###] [-Aname[(tokens)]] [-B[static|dynamic]]
[-C] [-c] [-Dname[=tokens]] [-d[y|n]] [-dalign] [-E]
[-errfmt[=[no%]error]] [-erroff[=t[,t...]]]
[-errshort[=i]] [-errtags=a] [-errwarn[=t[,t...]]]
[-fast] [-fd] [-features=[[no%]extinl|%none]] [-flags]
[-flteval[={any|2}]] [-fnonstd] [-fns=[no|yes]]
[-fprecision=p] [-fround=r] [-fsimple[=n]] [-fsingle]
[-fstore] [-ftrap[=t[,t...]]] [-G] [-g] [-H] [-hname]
[-I[-|dir]] [-i] [-KPIC] [-Kpic] [-keeptmp] [-Ldir]
[-lname] [-mc] [-misalign] [-misalign2] [-mr[,string]]
[-mt] [-native] [-nofstore] [-O] [-ofilename] [-P] [-p]
[-Q[y|n]] [-qp] [-Rdir[:dir...]] [-S] [-s] [-Uname]
[-V] [-v] [-Wc,arg] [-w] [-X[c|a|t|s]] [-x386] [-x486]
[-xa] [-xalias_level[=a]] [-xarch=a] [-xautopar]
[-xbinopt={a}] [-xbuiltin[=a]] [-xCC] [-xc99[=o]]
[-xcache=c] [-xcg{89|92}] [-xchar[=o]]
[-xchar_byte_order[=o]] [-xcheck=n] [-xchip=c]
[-xcode=v] [-xcrossfile[=n]] [-xcsi]
[-xdebugformat=[stabs|dwarf]] [-xdepend[={yes|no}]]
[-xdryrun] [-xe] [-xexplicitpar] [-xF] [-xhelp=f]
[-xhwcprof=[enable|disable]] [-xinline=[v[,v...]]]
[-xipo[=a]] [-xipo_archive[=a]] [-xjobs=n]
[-xldscope={v}] [-xlibmieee] [-xlibmil] [-xlibmopt]
[-xlic_lib=sunperf] [-xlicinfo] [-xlinkopt[=level]]
[-xloopinfo] [-xM] [-xM1] [-xMerge] [-xmaxopt[=v]]
[-xmemalign=ab] [-xmodel=[a]]
[-xnativeconnect[=a[,a]...]] [-xnolib] [-xnolibmil]
[-xnolibmopt] [-xOn] [-xopenmp[=i]] [-xP]
[-xpagesize=n] [-xpagesize_heap=n] [-xpagesize_stack=n]
[-xparallel] [-xpch=v] [-xpchstop] [-xpentium] [-xpg]
[-xprefetch[=val[,val]]] [-xprefetch_auto_type=[a]
[-xprefetch_level=l] [-xprofile=p]
[-xprofile_ircache[=path]]
[-xprofile_pathmap=collect_prefix:use_prefix] [-xreduc-
tion] [-xregs=r[,r...]] [-xrestrict[=f]] [-xs]
[-xsafe=mem] [-xsb] [-xsbfast] [-xsfpconst] [-xspace]
[-xstrconst] [-xtarget=t] [-xtemp=dir] [-xthreadvar[=o]
[-xtime] [-xtransition] [-xtrigraphs[=[yes|no]]
[-xunroll=n] [-xustr={ascii_utf16_ushort|no}]
[-xvector[=a]] [-xvis] [-xvpara] [-Yc,dir] [-YA,dir]
[-YI,dir] [-YP,dir] [-YS,dir] [-Zll]
DESCRIPTION
Sun Studio 11: C 5.8 compiler
A man page, by definition, is a quick reference. For more
detailed information on the C compiler and its options, see
the C User's Guide.
See the online readme file, viewable by calling
cc -xhelp=readme
for the latest important information on platforms, environ-
ments, new features, and software corrections.
Access all the installed documentation, including readme
files, user guides, and reference manuals by pointing an
HTML browser to the default installation directory:
file:/opt/SUNWspro/docs/index.html
Note- If your Sun compilers and tools are not installed in
the default /opt directory, ask your system administrator
for the equivalent path on your system.
New Features
This section describes the new and changed features for the
Sun Studio 11: C 5.8 compiler. See the Sun Studio 11 C
User's Guide for more detailed descriptions of the new
features.
o New -xarch Flags For x86 Development
The -xarch option now supports the following new flags
for development on the x86 platform: amd64a,
pentium_proa, ssea, sse2a. See the -xarch option
description in this man page for more information.
o Support For x86 -xpagesize Options
The -xpagesize, -xpagesize_heap, -xpagesize_stack
options are now enabled for x86 platforms as well as
SPARC.
o A New -xmodel Option To Specify x86 Memory Models
The new -xmodel option lets you specify the kernel,
small, or medium memory models on the 64-bit AMD archi-
tecture. If the size of your global and static vari-
ables exceeds two gigabytes, specify -xmodel=medium.
Otherwise, use the default -xmodel=small setting. See
the -xmodel option description in this man page for
more information.
o Support For SSE/SSE2 Integral Media Intrinsics
This release supports intrinsic functions for SSE2
128-bit XMM register integral media-instructions.
Include the sunmedia_intrin.h header file in the source
code and specify the -xbuiltin option to take advantage
of these functions. Furthermore, these intrinsic func-
tions require SSE2 support so specify options such as
-xarch=sse2, -xarch=amd64, or -xtarget=opteron.
Essentially, the compiler generates inline code for
these instrinsic functions. This is easier than manipu-
lating the instructions through assembly language and
it can be optimized by the compiler.
For more information about intrinsics, explanations for
the function prototypes contained in the header files,
and the data types used by these functions, see the
'Intel C++ Intrinsics Reference' section of the
Intel(R) C++ Compiler for Linux Systems manual.
o New -xvector Flags for x86 SSE2 Platforms
The -xvector option enables automatic generation of
calls to the vector library functions and/or the gen-
eration of the SIMD (Single Instruction Multiple Data)
instructions.
See the -xvector option description in this man page
for more information.
o Binary Optimizer for SPARC
A new -xbinopt option allows the compiler to prepare
the binary file for further optimization by the
binopt(1) binary optimizer.
o New SPARC -xtarget and -xchip Values
The new -xtarget flags ultra3iplus, ultra4plus, and
ultraT1 along with the new -xchip flags ultra3iplus,
ultra4plus, and ultraT1 provide code generation for the
UltraSPARC IIIiplus, UltraSPARC T1, and UltraSPARC
IVplus processors.
o A New Default Format For Debugger Information
The C compiler now generates debugger information in
the dwarf format by default. This change should be
transparent, as the dbx and Performance Analyzer
readily accept and prefer the dwarf format. You can
generate debugger information in the stabs format by
specifying -xdebugformat=stabs.
o Enhancements to the STACKSIZE Environment Variable
The syntax of the STACKSIZE environment variable has
been enhanced to accept a units keyword for denoting
the slave thread stacksize: B for Bytes, K for Kilo-
bytes, M for Megabytes, G for Gigabytes.
For example, setenv STACKSIZE 8192 sets the slave
thread stack size to 8 MB. 1235B sets the slave thread
stack size for 1235 Bytes. 1235G sets it for 1235
Gigabytes. The default for an integer value without a
suffix letter is still Kilobytes.
o OpenMP Autoscoping
Autoscoping is now available for C programs. This
feature is described in chapter 3 of the Sun Studio
OpenMP API User's Guide.
o New Pragmas
There are three new pragmas in this release of the C
compiler. Use the c99 (implicit | no%implicit) pragma
to find implicit function declarations. Use the
[no_]warn_missing_parameter_info pragma to find func-
tion declarations which contain no parameter-type
information. Use the struct_align pragma to align
struct elements on 128 bits when you are compiling with
x86 64-bit SIMD instructions. See the C User's Guide
for detailed descriptions of these new pragmas.
New Features In Sun Studio 10
This section describes the new and changed features for the
Sun Studio 10: C 5.7 compiler. See the C readme or the Sun
Studio 10 C User's Guide for more detailed descriptions of
these new features.
o A new -xarch option, -xarch=amd64, specifies compilation
for the 64-bit AMD instruction set.
o A new -xtarget option, -xtarget=opteron, specifies the
-xarch, -xchip, and -xcache settings for 32-bit AMD compila-
tion.
o The C compiler now predefines __amd64 and __x86_64 when
you specify -xarch=amd64.
o The existing -xarch=generic64 option now supports the x86
platform in addition to the traditional SPARC platform.
o A new x86-only flag for the -xregs option,
-xregs=[no%]frameptr, lets you use the frame-pointer regis-
ter as an unallocated callee-saves register to increase the
run-time performance of applications.
Overview of the C Compiler
The cc (1) manual page describes the ISO C compiler options
that are SVID compliant under Solaris 8, Solaris 9, and
Solaris 10 operating environments. Take note that the C com-
piler recognizes by default some of the constructs of the
1999 ISO/IEC C standard. Specifically, the supported are
detailed in the C User's Guide. Use the -xc99=none command
if you want to limit the compiler to the 1990 ISO/IEC C
standard.
cc uses getopt to parse command-line options. Options are
treated as a single letter or as a single letter followed by
an argument. See getopt(3c).
cc is the interface to the C compilation system. The compi-
lation process incorporates a preprocessor, compiler, code
generator, optimizer, assembler, and link editor. cc
processes the supplied options and then executes the various
components with the proper arguments. cc accepts several
types of files as arguments.
Files with .c suffix are taken to be C source files and may
be preprocessed, compiled, optimized, instrumented for pro-
filing, assembled, and link edited. Although the preproces-
sor can be used as a macro processor, this is not recom-
mended, as its output is geared toward that which would be
acceptable as input to a valid C compiler. The compilation
process may be stopped after the completion of any pass if
the appropriate options are supplied.
If the compilation process runs through the assembler, then
an object file is produced in the current working directory
with .o suffix substituted for .c. However, the .o file is
normally deleted if a single C file is compiled and then
immediately link edited.
Files with .s suffix are taken to be assembly source files;
they may be assembled and link edited. Files with a .S suf-
fix are treated as -Xs mode of the compiler and passed to
/usr/ccs/lib/cpp for preprocessing before being passed to
the assembler.
Files with an .i are taken to be preprocessed C source
files, and may be compiled, optimized, instrumented for pro-
filing, assembled, and link edited. Files whose names do not
end in .c, .s, .S or executable whose name by default is
a.out.
See option -Yc, dir to change the default directories used
for finding libraries. dir is a colon-separated path list.
The default library search order for cc is:
/opt/SUNWspro/prod/lib
/usr/ccs/lib
/usr/lib
COMPILING FOR 64-BIT SOLARIS:
This version of the compiler can produce 64-bit object
binaries on 32-bit or 64-bit Solaris platforms. The result-
ing executable will run only on 64-bit SPARC UltraSPARC(R)
or x86 processors under Solaris OS with the 64-bit kernel.
Compilation, linking, and execution of 64- bit objects can
only take place in a Solaris OS environment that supports
64-bit execution.
The 64-bit Solaris OS provides support for 64-bit integer
and pointer data as well as support for large files and
large arrays.
On SPARC Platforms:
Compiling for a 64-bit Solaris OS on SPARC platforms is
indicated by one of the variants of the -xarch=v9 option.
You must specify one of these options even if you also
specify -xtarget or -fast. In such a case, the -xarch=v9
option must appear after any -xtarget or other option that
sets -xarch. For example:
-xtarget=ultra -xarch=v9
Note that -xtarget=ultra, -xtarget=ultra2, and
-xtarget=ultra3 imply -xarch=v8 and do not automatically
cause 64-bit compilations.
If you are building shared dynamic libraries with -xarch=v9,
v9a, or v9b in a 64-bit Solaris OS, you must specify
-xcode=pic13 or -xcode=pic32. -xcode=abs44 will not work.
See the -xcode option for information on how to specify code
address sizes.
For general information on 64-bit Solaris software for
software developers, see the "Solaris 64-bit Developer's
Guide" on http://docs.sun.com .
For more specific information regarding the migration of C
programs to a 64-bit environment, see the C User's Guide.
On x86 Platforms
On x86 platforms, -xarch=amd64 specifies compilation for the
64-bit AMD instruction set.
A new -xtarget option, -xtarget=opteron, specifies the
-xarch, -xchip, and -xcache settings for 32-bit AMD
compilation.
You must specify -xarch=amd64 after -fast and -xtarget on
the command line to generate 64-bit code. The new
-xtarget=opteron option does not automatically generate 64-
bit code. It expands to -xarch=sse2, -xchip=opteron, and
-xcache=64/64/2:1024/64/16 which result in 32-bit code. The
-fast option also results in 32-bit code because it is a
macro which also defines an -xtarget value. All the current
-xtarget values result in 32-bit code so be sure to specify
-xarch=amd64 after (to the right of) -fast or -xtarget if
you want to compile 64-bit code, as in:
cc -fast -xarch=amd64or cc -xtarget=opteron -xarch=amd64
Also, the existing -xarch=generic64 option now supports the
x86 platform in addition to the traditional SPARC platform.
The compilers now predefine __amd64 and __x86_64 when you
specify -xarch=amd64.
OPTIONS
All platform-specific options are silently accepted on all
platforms. Any exceptions to this rule are noted under the
specific option.
The following options are interpreted by cc:
-# Turns on verbose mode, showing how command options
expand. Shows each component as it is invoked.
-### Shows each component as it would be invoked, but does
not actually execute it. Also shows how command options
would expand.
-Aname[(tokens)]
Associate name as a predicate with the specified tokens
as if by a #assert preprocessing directive.
Preassertions:system(unix)
machine(sparc) (SPARC)
machine(i386) (x86)
cpu(sparc) (SPARC)
cpu(i386) (x86)
The above are not predefined in -Xc mode.
If -A is followed by a dash (-) only, it causes all
predefined macros (other than those that begin with __)
and predefined assertions to be forgotten.
-B [static|dynamic]
Specifies whether bindings of libraries for linking are
static or dynamic, indicating whether libraries are
non-shared or shared, respectively. -B dynamic causes
the link editor to look for files named libx.so and
then for files named libx.a when given the -lx option.
-B static causes the link editor to look only for files
named libx.a. This option may be specified multiple
times on the command line as a toggle.
Note: Many system libraries, such as libc, are only
available as dynamic libraries in the Solaris 64-bit
compilation environment. Therefore, do not use -Bstatic
as the last toggle on the command line.
This option and its argument are passed to ld.
-C Prevents the C preprocessor from removing comments,
other than those on preprocessing directive lines.
-c Directs the C compiler to suppress linking with ld and
to produce a .o file for each source file. You can
explicitly name a single object file by
using the -o option. When the compiler produces object
code for each or input file, it always creates an
object file in the current working directory. If you
suppress the linking step, you also suppress the remo-
val of the object files.
-Dname[=token]
Associates name with the specified token as if by a
#define preprocessing directive. If no =token is
specified, the token 1 is supplied.
Predefinitions:unix
sparc (SPARC)
i386 (x86)
sun
The above are not predefined in -Xc mode.
These predefinitions are valid in all modes:
__amd64(x86)
__x86_64(x86)
__sun
__unix
__SUNPRO_C=0x580
__`uname -s`_`uname -r`
__sparc (SPARC)
__sparcv9 (SPARC with -xarch=v9|v9a|v9b)
__i386 (x86)
__BUILTIN_VA_ARG_INCR
__SVR4
The following is predefined in -Xa and -Xt modes only:
__RESTRICT
The compiler also predefines the object-like macro
__PRAGMA_REDEFINE_EXTNAME,
to indicate the pragma will be recognized.
-d [y|n]
-dy specifies dynamic linking, which is the default, in
the link editor. -dn specifies static linking in the
link editor.
This option and its argument are passed to ld.
Note: This option causes fatal errors if you use it in
combination with dynamic libraries. Most system
libraries are only available as dynamic libraries.
-dalign
(SPARC) Obsolete. You should not use this option. Use
-xmemalign=8s instead. For a complete list of obsolete
options and flags, see the C User's Guide.
-E Runs the source file through the preprocessor only and
sends the output to stdout. The preprocessor is built
directly into the compiler, except in -Xs mode, where
/usr/ccs/lib/cpp is invoked. Includes the preprocessor
line numbering information. See also -P option.
-errfmt[=[no%]error]
Use this option if you want to prefix the string
"error:" to the beginning of error messages so they are
more easily distinguishable from warning messages. The
prefix is also attached to warnings that are converted
to errors by -errwarn.
error Add the prefix "error:" to all error messages.
no%error Do not add the prefix "error:" to any error
messages.
If you do not use this option, the compiler sets it to
-errfmt=no%error. If you use specify -errfmt, but do
not supply a value, the compiler sets it to
-errfmt=error.
-erroff[=t[,t...] ]
Suppresses compiler warning messages but has no effect
on error messages. This option applies to all warning
messages whether or not they have been designated by
-errwarn to cause a non-zero exit status.
The -erroff values are members of a comma-separated
list that consists of one or more of the following:
tag Suppresses the warning message specified by
this tag. You can display the tag for a
message by using the -errtags=yes option.
no%tag Enables the warning message specified by this
tag.
%all Suppresses all warning messages.
%none Enables all warning messages. This is the
default.
Order is important; for example, %all,no%tag suppresses
all warning messages except tag.
The default is -erroff=%none. Specifying -erroff is
equivalent to specifying -erroff=%all.
Only warning messages from the C compiler front-end
that display a tag when the -errtags option is used can
be suppressed with the -erroff option. You can achieve
finer control over error message suppression by using
#pragma error_messages.
-errshort[=i]
Use this option to control how much detail is in the
error message produced by the compiler when it discov-
ers a type mismatch. This option is particularly useful
when the compiler discovers a type mismatch that
involves a large aggregate.
i can be one of the following:
short Error messages are printed in short form with
no expansion of types. Aggregate members are
not expanded, neither are function argument
and return types.
full Error messages are printed in full verbose
form showing the full expansion of the
mismatched types.
tags Error messages are printed with tag names for
types which have tag names. If there is no tag
name, the type is shown in expanded form.
If you do not use -errshort, the compiler sets the
option to -errshort=full. If you specify -errshort, but
do not provide a value, the compiler sets the option to
-errshort=tags.
This option does not accumulate, it accepts the last
value specified on the command line.
-errtags=a
Displays the message tag for each warning message of
the C compiler front-end that can be suppressed with
the -erroff option or made a fatal error with the
-errwarn option. Messages from the C compiler driver
and other components of the C compilation system do not
have error tags, and cannot be suppressed with -erroff
and made fatal with -errwarn.
a can be either yes or no. The default is -errtags=no.
Specifying -errtags is equivalent to specifying
-errtags=yes.
-errwarn[=t[,t...] ]
Use the -errwarn option to cause the C compiler to exit
with a failure status for the given warning messages.
t is a comma-separated list that consists of one or
more of the following: tag, no%tag, %all, %none. Order
is important; for example %all,no%tag causes the C com-
piler to exit with a fatal status if any warning except
tag is issued.
The warning messages generated by the C compiler change
from release to release as the compiler error checking
improves and features are added. Code that compiles
using -errwarn=%all without error may not compile
without error in the next release of the compiler.
Only warning messages from the C compiler front-end
that display a tag when the -errtags option is used can
be specified with the -errwarn option to cause the C
compiler to exit with a failure status.
The default is -errwarn=%none. If you specify -errwarn
alone, it is equivalent to -errwarn=%all.
The following table details the -errwarn values:
tag Cause cc to exit with a fatal status if the
message specified by tag is issued as a warn-
ing message. Has no effect if tag in not
issued.
no%tag Prevent cc from exiting with a fatal status if
the message specified by tag is issued only as
a warning message. Has no effect if tag is not
issued. Use this option to revert a warning
message that was previously specified by this
option with tag or %all from causing cc to
exit with a fatal status when issued as a
warning message.
%all Cause cc to exit with a fatal status if any
warning messages are issued. %all can be fol-
lowed by no%tag to exempt specific warning
messages from this behavior.
%none Prevents any warning messages from causing cc
to exit with a fatal status should any warning
tag be issued. This is the default.
-fast
This option is a macro that you can effectively use as
a starting point for tuning an executable for maximum
run-time performance. The expansion of -fast can change
from one release of the compiler to the next and
includes options that are target platform specific. Use
the -# or the -xdryrun options to examine the expansion
of -fast, and incorporate the appropriate options of
-fast into the ongoing process of tuning the execut-
able.
The expansion of -fast now includes the new -xlibmopt
option. This option enables the compiler to use a
library of optimized math routines. For more informa-
tion, see the description of -xlibmopt in this man
page.
The -fast option impacts the value of errno. See the
NOTES section at the end of this man page for more
information.
Modules that are compiled with -fast must also be
linked with -fast. For a complete list of compiler
options that must be specified at both compile time and
at link time, see the C User's Guide.
The -fast option is unsuitable for programs that are
intended to run on a different target than the compila-
tion machine. In such cases, follow -fast with the
appropriate -xtarget option. For example:
% cc -fast -xtarget=ultra
For C modules depending on exception handling specified
by SUID, follow -fast by -xnolibmil
% cc -fast -xnolibmil
The -fast option acts like a macro expansion on the
command line. Therefore, you can override any of the
expanded options by following -fast with the desired
option.
If you combine -fast with other options, the last
specification applies.
These options are turned on for -fast:
-fns
-fsimple=2
-fsingle
-nofstore (x86)
-xalias_level=basic
-xbuiltin=%all
-xdepend
-xlibmil
-xlibmopt
-xmemalign=8s (SPARC)
-xO5
-xprefetch=auto,explicit (SPARC)
-xregs=no%frameptr (x86)
-xtarget=native
Note: Some optimizations make certain assumptions about
program behavior. If the program does not conform to
these assumptions, the application may crash or produce
incorrect results. Please refer to the description of
the individual options to determine if your program is
suitable for compilation with -fast.
Do not use this option for programs that depend on IEEE
standard exception handling; you can get different
numerical results, premature program termination, or
unexpected SIGFPE signals.
-fd Reports K&R function declarations and definitions.
-features=[[no%]extinl|%none]
The compiler's treatment of extern inline functions
conforms by default to the behavior specified by the
ISO/IEC 9899:1999 C standard. Compile new codes with
-features=no%extinl to obtain the same treatment of
extern inline functions as provided by versions 5.5, or
older, of the C and C++ compilers.
If you do not specify a setting for -features, the com-
piler sets it to -features=extinl.
Old C and C++ objects (pre C/C++ 5.6) can be linked
with new C and C++ objects with no change of behavior
for the old objects. To get standard conforming
behavior, old code must be recompiled using the current
compiler.
-features=extinl
Generates extern inline functions as global
functions. This is the default, which conforms
with the 1999 C standard.
-features=no%extinl
Generates extern inline functions as static
functions.
-features=%none
The option is disabled.
-flags
Prints a one-line summary of available options.
-flteval[={any|2}]
(x86) Use this option to control how floating point
expressions are evaluated.
2 Floating point expressions are evaluated as
long double.
any Floating point expressions are evaluated
depending on the combination of the types of
the variables and constants that make up an
expression.
If you do not specify -flteval, the compiler sets it to
-flteval=any. If you do specify -flteval, but do not
provide a value, the compiler sets it to -flteval=2.
You must not specify the following options in combina-
tion with -flteval=2:
o -fprecision
o -nofstore
o -xarch=amd64
o -xarch=sse2
For more information, see 'Precision of Floating Point
Evaluators' in appendix E of the C User's Guide.
-fnonstd
-fnonstd is a macro for -fns and -ftrap=common.
-fns[=[no|yes]]
For SPARC, selects the SPARC nonstandard floating-point
mode.
For x86, selects SSE flush-to-zero mode and, where
available, denormals-are-zero mode. This option causes
subnormal results to be flushed to zero on x86. Where
available, this option also causes subnormal operands
to be treated as zero. This option has no effect on
traditional x86 floating-point operations that do util-
ize the SSE or SSE2 instruction set.
The default, -fns=no, is standard floating-point mode.
Optional use of =yes or =no provides a way of toggling
the -fns flag following some other macro flag that
includes -fns, such as -fast.
-fns is the same as -fns=yes.
-fns=yes selects non-standard floating-point.
-fns=no selects standard floating-point.
On some SPARC systems, the nonstandard floating point
mode disables "gradual underflow", causing tiny results
to be flushed to zero rather than producing subnormal
numbers. It also causes subnormal operands to be
silently replaced by zero. On those SPARC systems that
do not support gradual underflow and subnormal numbers
in hardware, use of this option can significantly
improve the performance of some programs.
When nonstandard mode is enabled, floating point arith-
metic may produce results that do not conform to the
requirements of the IEEE 754 standard. See the Numeri-
cal Computation Guide for more information.
On SPARC systems, this option is effective only if used
when compiling the main program.
-fprecision=p
(x86) Initializes the rounding precision mode bits in
the Floating-point Control Word to p, which is one of
single (24 bits), double (53 bits), or extended (64
bits) respectively. The default floating-point
rounding-precision mode is extended.
Note that on x86, only the precision, not exponent,
range is affected by the setting of floating-point
rounding precision mode.
This option is effective only on x86 systems and only
if used when compiling the main program. On SPARC sys-
tems, the option is ignored.
-fround=r
Sets the IEEE 754 rounding mode that is established at
runtime during the program initialization.
r must be one of: nearest, tozero, negative, positive.
The default is -fround=nearest.
The meanings are the same as those for the ieee_flags
subroutine.
When r is tozero, negative, or positive, this flag
causes the rounding direction mode to be set to round-
to-zero, round-to-negative-infinity, or round-to-
positive-infinity respectively when a program begins
execution. When r is nearest or the -fround flag is
not used, the rounding direction mode is not altered
from its initial value (round-to-nearest by default).
This option is effective only if used when compiling
the main program.
-fsimple[=n]
Allows the optimizer to make simplifying assumptions
concerning floating-point arithmetic.
The compiler defaults to -fsimple=0. Specifying -fsim-
ple is equivalent to -fsimple=1.
If n is present, it must be 0, 1, or 2.
-fsimple=0
Permits no simplifying assumptions. Preserves strict
IEEE 754 conformance.
-fsimple=1
Allows conservative simplifications. The resulting code
does not strictly conform to IEEE 754, but numeric
results of most programs are unchanged.
With -fsimple=1, the optimizer can assume the follow-
ing:
o The IEEE 754 default rounding/trapping modes do not
change after process initialization.
o Computations producing no visible result other than
potential floating- point exceptions may be deleted.
o Computations with Infinity or NaNs as operands need
not propagate NaNs to their results. For example, x*0
may be replaced by 0.
o Computations do not depend on sign of zero.
With -fsimple=1, the optimizer is not allowed to optim-
ize completely without regard to roundoff or excep-
tions. In particular, a floating-point computation can-
not be replaced by one that produces different results
with rounding modes held constant at run time.
-fsimple=2
Enables use of SIMD instructions to compute reductions
when -xvector=simd is in effect.
Permits aggressive floating point optimizations that
may cause many programs to produce different numeric
results due to changes in rounding. For example, -fsim-
ple=2 permits the optimizer to attempt replace all com-
putations 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 con-
stant values during execution of the loop.
Even with -fsimple=2, the optimizer still is not per-
mitted to introduce a floating point exception in a
program that otherwise produces none.
See Also:
Techniques for Optimizing Applications: High Perfor-
mance Computing written by Rajat Garg and Ilya Sharapov
for a more detailed explanation of how optimization can
impact precision.
-fsingle
(-Xt and -Xs modes only) Causes the compiler to evalu-
ate float expressions as single precision, rather than
double precision. (This option has no effect if the
compiler is used in either -Xa or -Xc modes, as float
expressions are already evaluated as single precision.)
-fstore
(x86) Causes the compiler to convert the value of a
floating-point expression or function to the type on
the left-hand side of an assignment, when that expres-
sion or function is assigned to a variable, or when the
expression is cast to a shorter floating-point type,
rather than leaving the value in the register. Due to
roundoffs and truncation, the results may be different
from those generated from the register value. This is
the default mode. To turn off this option, use the
-nofstore option.
-ftrap[=t[,t...] ]
Sets the IEEE 745 trapping mode in effect at startup
but does not install a SIGFPE handler. You can use
ieee_handler(3M) or fex_set_handling(3M) to simultane-
ously enable traps and install a SIGFPE handler. If you
specify more than one value, the list is processed
sequentially from left to right.
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.
The default is -ftrap=%none.
Note that the [no%] form of the option is used only to
modify the meanings of the %all or common value and
must be used with one of these values, as shown in the
example. The [no%] form of the option by itself does
not explicitly cause a particular trap to be disabled.
Example: -ftrap=%all,no%inexact means set all traps,
except inexact.
If you compile one routine with -ftrap=t, compile all
routines of the program with the same -ftrap=t option;
otherwise, you can get unexpected results.
Use the -ftrap=inexact trap with caution, as it will
result in the trap being issued whenever a floating-
point value cannot be represented exactly. For example,
the following statement may generate this condition:
x = 1.0 / 3.0;
-G Produce a shared object rather than a dynamically
linked executable. This option is passed to ld and
cannot be used with the -dn option.
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.
If you are creating a shared object by specifying -G
along with other compiler options that must be speci-
fied at both compile time and link time, make sure that
those same options are also specified when you link
with the resulting shared object.
When you create a shared object, all the object files
that are compiled with -xarch=v9 must also be compiled
with an explicit -xcode value as documented under the
description of -xcode.
-g Produces additional symbol table information for dbx(1)
and the Performance Analyzer analyzer(1).
If you specify -g, and the optimization level is -x03
or lower, the compiler provides best-effort symbolic
information with almost full optimization. Tail-call
optimization and back-end inlining are disabled.
If you specify -g and the optimization level is -x04,
the compiler provides best-effort symbolic information
with full optimization.
Compile with the -g option to use the full capabilities
of the Performance Analyzer. While some performance
analysis features do not require -g, you must compile
with -g to view annotated source, some function level
information, and compiler commentary messages. See the
analyzer(1) man page and the Performance Analyzer
manual for more information.
The commentary messages that are generated with -g
describe the optimizations and transformations that the
compiler made while compiling your program. Use the
er_src(1) command to display the messages, which are
interleaved with the source code.
Note: In previous releases, this option forced the com-
piler to use the incremental linker (ild) by default
instead of the linker (ld) for link-only invocations of
the compiler. That is, with -g, the compiler's default
behavior was to automatically invoke ild in place of ld
whenever you used the compiler to link object files,
unless you specified -G or source files on the command
line. This is no longer the case. The incremental
linker is no longer available.
-H Prints, one per line, the path name of each file
included during the current compilation to standard
error.
-h name
Assigns a name to a shared dynamic library; allows you
to keep different versions of a library.
In general, the name after -h should be the same as the
file name given in the -o option. The space between -h
and name is optional.
The linker assigns the specified name to the library
and records the name in the library file as the intrin-
sic name of the library. If there is no -h name option,
then no intrinsic name is recorded in the library file.
When the runtime linker loads the library into an exe-
cutable file, it copies the intrinsic name from the
library file into the executable, into a list of needed
shared library files. Every executable has such a list.
If there is no intrinsic name of a shared library, then
the linker copies the path of the shared library file
instead.
-I[-|dir]
-Idir adds dir to the list of directories that are
searched for #include files. -I values accumulate from
left to right.
o For include statements of the form #include
<foo.h>, the preprocessor searches for the header
file in the following order:
1. The directories named with the -I option, if
any.
2. The compiler and system standard directories,
usually /usr/include.
o For include statements of the form #include
"foo.h", the compiler searches the directories in
the following order:
1. The current directory (that is, the directory
that contains the file which contains the
include statement itself.
2. The directories named with -I options, if
any.
3. The compiler and system standard directories,
usually /usr/include.
-I- changes the include-file search rules to the fol-
lowing:
o The compiler never searches the current
directory, unless the directory is listed
explicitly in a -I directive. This effect
applies even for include statements of the
form #include "foo.h".
o For include files of the form #include
"foo.h", search the directories in the fol-
lowing order:
o The directories named with -I options
(both before and after -I-).
o The compiler and system standard direc-
tories, usually /usr/include.
o For include files of the form #include
<foo.h>, search the directories in the fol-
lowing order:
o The directories named with the -I
options that appear after -I- (that is,
the compiler does not search the -I
directories that appear before -I-).
o The compiler and system standard direc-
tories, usually /usr/include.
Only the first -I- option on the command line works as
described above.
-Idir looks in dir, prior to /usr/include, for included
files whose names do not begin with slash (/). Direc-
tories for multiple -I options are searched in the
order specified.
Warnings
Never specify the compiler installation area,
/usr/include, /lib, /usr/lib, as search directories.
-i Ignores the LD_LIBRARY_PATH and LD_LIBRARY_PATH_64 set-
tings.
-KPIC
(SPARC) Obsolete. You should not use this option. Use
-xcode=pic32 instead. For a complete list of obsolete
options and flags, see the C User's Guide.
(x86) -KPIC is identical to -Kpic on x86 architectures.
-Kpic
(SPARC) Obsolete. You should not use this option. Use
-xcode=pic13 instead. For a complete list of obsolete
options and flags, see the C User's Guide.
(x86) Generate position-independent code for use in
shared libraries (small model). Permits references to,
at most, 2**11 unique external symbols
-keeptmp
Retains temporary files created during compilation,
instead of deleting them automatically.
-Ldir
Adds dir to the list of directories searched for
libraries by ld. This option and its arguments are
passed to ld.
Warnings
Never specify the compiler installation area,
/usr/include, /lib, /usr/lib, as search directories.
-lname
Links with object library libname.so or libname.a (for
ld(1)). The order of libraries in the command line is
important, as symbols are resolved from left to right.
This option must follow the sourcefile.
-mc Removes duplicate strings from the .comment section of
an object file. When you use the -mc flag, -mcs -c is
invoked.
-misalign
(SPARC) Obsolete. You should not use this option. Use
the -xmemalign=1i option instead. For a complete list
of obsolete options and flags, see the C User's Guide.
-misalign2
(SPARC) Obsolete. You should not use this option. Use
the -xmemalign=2i option instead. For a complete list
of obsolete options and flags, see the C User's Guide.
-mr[,string]
-mr removes all strings from the .comment section of an
object file. When you use the -mr flag, mcs -d is
invoked.
-mr,string removes all strings from the .comment sec-
tion and inserts string in the .comment section of the
object file. If string contains embedded blanks, it
must be enclosed in quotation marks. If string is null,
the .comment section will be empty. When you use this
flag, mcs -d -a is invoked.
-mt Passes D_REENTRANT to preprocessor. Appends -lthread
after all other user-specified libraries on the command
line. If you are doing your own multithread coding,
you must use this option in the compile and link steps.
For a complete list of compiler options that must be
specified at both compile time and at link time, see
the C User's Guide.To obtain faster execution, this
option requires a multiprocessor system. On a single-
processor system, the resulting executable usually runs
more slowly with this option.
-native
This option is a synonym for -xtarget=native.
-nofstore
(x86) Does not convert the value of a floating-point
expression or function to the type on the left-hand
side of an assignment, when that expression or function
is assigned to a variable, or is cast to a shorter
floating-point type; rather, it leaves the value in a
register.
-O Use default optimization level -xO3. This macro now
expands to -xO3 instead of -xO2.
The change in default yields higher run-time perfor-
mance. However, -x03 may be inappropriate for programs
that rely on all variables being automatically con-
sidered volatile. Typical programs that might have this
assumption are device drivers and older multi-threaded
applications that implement their own synchronization
primitives. The work around is to compile with -xO2
instead of -O.
-o filename
Names the output file filename, instead of the default
a.out. filename cannot be the same as sourcefile since
cc does not overwrite the source file. This option and
its argument are passed to ld.
-P Preprocesses only the named C files and leaves the
result in corresponding files suffixed .i. The output
will not contain any preprocessing line directives,
unlike -E.
-p Obsolete See -xpg.
-Q[y|n]
Emits or does not emit identification information to
the output file. If y is used, identification
information about each invoked compilation tool will be
added to the output files (the default behavior). This
can be useful for software administration. -Qn
suppresses this information.
-qp Same as -p.
-Rdir[:dir...]
A colon-separated list of directories used to specify
library search directories to the runtime linker. If
present and not null, it is recorded in the output
object file and passed to the runtime linker.
If both LD_RUN_PATH and the -R option are specified,
the -R option takes precedence.
-S Compiles, but does not assemble or link edit the named
C files. The assembler-language output is left in
corresponding files suffixed .s.
-s Removes all symbolic debugging information from the
output object file. This option is passed to ld(1).
This option cannot be specified with -g.
-Uname
Causes any definition of name to be undefined. This
option removes any initial definition of the preproces-
sor symbol name created by -D on the same command line
including those placed by the command-line driver.
-U has no effect on any preprocessor directives in
source files. You can supply multiple -U options on the
command line.
If the same name is specified for both -D and -U, name
is not defined, regardless of the order of the options.
-V Causes each invoked tool to print its version informa-
tion on the standard error output.
-v Causes the compiler to perform more and stricter seman-
tic checks, and to enable certain lint-like checks on
the named C files.
-Wc,arg
Passes the argument arg to c. Each argument must be
separated from the preceding by only a comma. (A comma
can be part of an argument by escaping it by an immedi-
ately preceding backslash (\) character; the backslash
is removed from the resulting argument.) All -W argu-
ments are passed after the regular command-line argu-
ments.
c can be one of the following:
a Assembler: (fbe), (gas)
c C code generator: (cg)(SPARC)
d cc driver (1)
h Intermediate code translator (ir2hf)(x86)
i Interprocedure analysis (ube_ipa)(x86)
l Link editor (ld)
m mcs
0 (Captial letter 'o') Interprocedural optim-
izer
o Postoptimizer
p Preprocessor (cpp)
u C code generator (ube), (x86)
0 (The number zero) Compiler (acomp) (ssbd
SPARC)
2 Optimizer: (iropt)
(1) Note: You cannot use -Wd to pass the cc options
listed in this man page to the C compiler.
For example, -Wa,-o,objfile passes -o and objfile to
the assembler, in that order; also -Wl,-I,name causes
the linking phase to override the default name of the
dynamic linker, /usr/lib/ld.so.1.
The order in which the argument(s) are passed to a tool
with respect to the other specified command line
options may change.
-w Suppress compiler warning messages.
The option overrides the error_messages pragma.
-X[c|a|t|s]
Specifies the degree of conformance to the ISO C stan-
dard. The value of -xc99 affects which version of the
ISO C standard the -X option applies.
c (conformance)
Strictly conformant ISO C, without K&R C compati-
bility extensions. The compiler issues errors and
warnings for programs that use non-ISO C con-
structs. The predefined macro __STDC__ has a
value of 1 with the -Xc option.
a This is the default compiler mode. ISO C plus K&R
C compatibility extensions, with semantic changes
required by ISO C. Where K&R C and ISO C specify
different semantics for the same construct, the
compiler uses the ISO C interpretation. If the -Xa
option is used in conjunction with the
-xtransition option, the compiler issues warnings
about the different semantics. The predefined
macro __STDC__ has a value of 0 with the -Xa
option.
t (transition)
This option uses ISO C plus K&R C compatibility
extensions without semantic changes required by
ISO C. Where K&R C and ISO C specify different
semantics for the same construct, the compiler
uses the K&R C interpretation. If you use the -Xt
option in conjunction with the -xtransition
option, the compiler issues warnings about the
different semantics. The predefined macro __STDC__
has a value of zero with the -Xt option.
s (K&R C)
The compiler tries to warn about all language con-
structs that have differing behavior between Sun
ISO C and the K&R C. Invokes cpp for processing.
__STDC__ is not defined in this mode.
The predefined macro __STDC__ has the value 0 for -Xt
and -Xa, and 1 for -Xc. (It is not defined for -Xs.)
All warning messages about differing behavior can be
eliminated through appropriate coding; for example, use
of casts can eliminate the integral promotion change
warnings.
-x386
(x86) Obsolete. Do not use this option. Use
-xchip=generic instead. For a complete list of obsolete
options and flags, see the C User's Guide.
-x486
(x86) Obsolete. Do not use this option. Use
-xchip=generic instead. For a complete list of obsolete
options and flags, see the C User's Guide.
-xa Obsolete. Do not use this option. Use -xprofile=tcov
instead. For a complete list of obsolete options and
flags, see the C User's Guide.
-xalias_level[=a]
where a must be one of:any, basic, weak, layout,
strict, std, strong. Use this flag to place the indi-
cated alias level into effect for the whole translation
unit. In other words, the alias level you select is
applied to all of the memory references in the transla-
tion unit. If you do not supply -xalias_level, the com-
piler assumes -xalias_level=any. If you supply
-xalias_level without a value, the compiler assumes
-xalias_level=layout.
o any
The compiler assumes that all memory references can
alias at this level. There is no type-based alias anay-
lysis.
o basic
If you use the -xalias_level=basic option, the compiler
assumes that memory references that involve different C
basic types do not alias each other. The compiler also
assumes that references to all other types can alias
each other as well as any C basic type. The compiler
assumes that references using char * can alias any
other type.
o weak
If you use the -xalias_level=weak option, the compiler
assumes that any structure pointer can point to any
structure type. Any structure or union type that con-
tains a reference to any type that is either referenced
in an expression in the source being compiled or is
referenced from outside the source being compiled, must
be declared prior to the expression in the source being
compiled.
You can satisfy this restriction by including all the
header files of a program that contain types that
reference any of the types of the objects referenced in
any expression of the source being compiled.
At the level of -xalias_level=weak, the compiler
assumes that memory references that involve different C
basic types do not alias each other. The compiler
assumes that references using char * alias memory
references that involve any other type.
o layout
The compiler assumes that memory references that
involve types with the same sequence of types in memory
can alias each other. The compiler assumes that two
references with types that do not look the same in
memory do not alias each other. The compiler assumes
that any two memory accesses through different struct
types alias if the initial members of the structures
look the same in memory. However, at this level, you
should not use a pointer to a struct to access some
field of a dissimilar struct object that is beyond any
of the common initial sequence of members that look the
same in memory between the two structs. This is because
the compiler assumes that such references do not alias
each other.
At the level of -xalias_level=layout the compiler
assumes that memory references that involve different C
basic types do not alias each other. The compiler
assumes that references using char * can alias memory
references involving any other type.
o strict
The compiler assumes that memory references, that
involve types such as structs or unions, that are the
same when tags are removed, can alias each other. Con-
versely, the compiler assumes that memory references
involving types that are not the same even after tags
are removed do not alias each other. However, any
structure or union type that contains a reference to
any type that is part of any object referenced in an
expression in the source being compiled, or is refer-
enced from outside the source being compiled, must be
declared prior to the expression in the source being
compiled.
You can satisfy this restriction by including all the
header files of a program that contain types that
reference any of the types of the objects referenced in
any expression of the source being compiled.
At the level of -xalias_level=strict the compiler
assumes that memory references that involve different C
basic types do not alias each other. The compiler
assumes that references using char * can alias any
other type.
o std
The compiler assumes that types and tags need to be the
same to alias, however, references using char * can
alias any other type. This rule is the same as the res-
trictions on the dereferencing of pointers that are
found in the 1999 ISO C standard. Programs that prop-
erly use this rule will be very portable and should see
good performance gains under optimization.
o strong
The same restrictions apply as at the std level, but
additionally, the compiler assumes that pointers of
type char * are used only to access an object of type
char. Also, the compiler assumes that there are no
interior pointers. An interior pointer is defined as a
pointer that points to a member of a struct.
See Also: -xprefetch_auto_type
-xarch=isa
Specifies the target architecture instruction set
(ISA).
This option limits the code generated by the compiler
to the instructions of the specified instruction set
architecture. This option does not guarantee use of any
target-specific instructions. However, use of this
option may affect the portability of a binary program.
See the Notes and Warnings section at the end of this
entry.
If you compile and link in separate steps, make sure
you specify the same value for -xarch in both steps.
For a complete list of compiler options that must be
specified at both compile time and at link time, see
the C User's Guide.
Values:
For SPARC platforms:
Value Meaning
generic Set the parameters for the best performance
over most 32-bit platform architectures.
This is no longer the default, see v8plus.
This option uses the best instruction set for
good performance on most processors without
major performance degradation on any of them.
With each new release, the definition of best
instruction set may be adjusted, if appropri-
ate.
generic64 Set the parameters for the best performance
over most 64-bit platform architectures.
This option uses the best instruction set for
good performance on Solaris operating systems
with 64-bit kernels, without major perfor-
mance degradation on any of them. With each
new release, the definition of best instruc-
tion set may be adjusted, if appropriate.
Currently, this is equivalent to -xarch=v9.
native Set the parameters for the best performance
on the host environment. The compiler chooses
the appropriate setting for producing 32-bit
binaries for the system on which the proces-
sor is running.
native64 Set the parameters for the best performance
on the 64-bit host environment. The compiler
chooses the appropriate setting for producing
64-bit binaries for the system on which the
processor is running.
v7 Compile for the SPARC-V7 ISA. (Obsolete)
Current Solaris operating systems no longer
support the SPARC V7 architecture, and pro-
grams compiled with this option run slower on
current platforms. The default is -
xarch=v8plus.
Examples: SPARCstation 1, SPARCstation 2
v8a Compile for the V8a version of the SPARC-V8
ISA.
By definition, V8a means the V8 ISA, but
without the fsmuld instruction. This option
enables the compiler to generate code for
good performance on the V8a ISA.
Example: Any system based on the microSPARC I
chip architecture
v8 Compile for the SPARC-V8 ISA.
Enables the compiler to generate code for
good performance on the V8 architecture.
Example: SPARCstation 10
v8plus This is the default and it means the compiler
uses the instruction set for the V8plus ver-
sion of the SPARC-V9 ISA. See the following
section 'SPARC Defaults' for more informa-
tion.
By definition, V8plus means the V9 ISA, but
limited to the 32-bit subset defined by the
V8plus ISA specification, without the Visual
Instruction Set (VIS), and without other
implementation-specific ISA extensions. This
option enables the compiler to generate code
for good performance on the V8plus ISA. The
resulting object code is in SPARC-V8+ ELF32
format and only executes in a Solaris
UltraSPARC environment -- it does not run on
a 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 Instruction Set
(VIS) version 1.0, and with UltraSPARC exten-
sions. 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 specifi-
cation. 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 exten-
sions.
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 architecture.
v9 Compile for the SPARC-V9 ISA.
Enables the compiler to generate code for
good performance on the V9 SPARC architec-
ture. The resulting .o object files are in
ELF64 format and can only be linked with
other SPARC-V9 object files in the same for-
mat. 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 compiling in
a 64-bit enabled Solaris operating environ-
ment.
v9a Compile for the SPARC-V9 ISA with UltraSPARC
extensions.
Adds to the SPARC-V9 ISA the Visual Instruc-
tion Set (VIS) and extensions specific to
UltraSPARC processors, and enables the com-
piler 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 exe-
cutable can only be run on an UltraSPARC pro-
cessor running a 64-bit enabled Solaris
operating environment with the 64-bit kernel.
-xarch=v9a is only available when compiling
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 ver-
sion 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 environment with
the 64-bit kernel.
-xarch=v9b is only available when compiling
in a 64-bit enabled Solaris operating
environment.
SPARC Defaults
The new -xarch default for SPARC yields higher run-time
performance for nearly all machines in current use.
However, applications that are intended for deployment
on pre-UltraSPARC computers no longer execute by
default on those computers. Compile with -xarch=v8 to
ensure that the applications execute on those comput-
ers.
If you want to deploy on v8 systems, you must specify
the option -xarch=v8 explicitly on every compiler com-
mand line as well as any link-time commands. The pro-
vided system libraries run on v8 architectures.
If you want to deploy on v7 systems, you must specify
the option -xarch=v7 explicitly on every compiler com-
mand line as well as any link-time commands. The pro-
vided system libraries use the v8 instruction set. For
the Sun Studio 10 release, the only supported operating
system for v7 is the Solaris 8 release. When a v8
instruction is encountered, the Solaris 8 operating
system interprets the instruction in software. The pro-
gram runs, but performance is degraded.
Notes
o SPARC instruction set architectures V7, V8, and V8a
are all upwardly 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 execute
together, but only on a SPARC V8plusb compatible
platform.
o -xarch values v9, v9a, and v9b are only available on
UltraSPARC 64-bit Solaris operating environments.
o Object binary files (.o) compiled with v9 and v9a can
be linked and can execute together, but will run only
on a SPARC V9a compatible platform.
o Object binary files (.o) compiled with 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 executable may
run much more slowly on earlier architectures. Also,
although quad-precision (REAL*16 and long double)
floating-point instructions are available in many of
these instruction set architectures, the compiler does
not use these instructions in the code it generates.
For x86 platforms:
Value Meaning
amd64 Compile for AMD 64-bit architecture and
generate a 64-bit ELF format binary file.
amd64a Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the AMD64
architecture and generates 64-bit ELF format
binary file.
generic Limits instruction set to the x86 architec-
ture and is equivalent to the -xarch=386
option. This is the default.
generic64 Product 64-bit object binaries for good per-
formance on most 64-bit platform architec-
tures.
This option uses the best instruction set for
good performance on Solaris operating
environments with 64-bit kernels, without
major performance degradation on any of them.
With each new release, the definition of
"best" instruction set may be adjusted, if
appropriate.
native Compile for good performance on this system.
This option uses the best instruction set for
good performance on most processors without
major performance degradation on any of them.
With each new release, the definition of
"best" instruction set may be adjusted, if
appropriate.
386 Limits the instruction set to the x86 386/486
architecture.
pentium_pro
Limits the instruction set to the 32-bit
pentium_pro architecture.
pentium_proa
Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the 32-bit
pentium_pro architecture.
sse Adds the SSE instruction set to the 32-bit
pentium_pro architecture.
ssea Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the 32-bit
SSE architecture.
sse2 Adds the SSE2 instruction set to the 32-bit
pentium_pro architecture.
sse2a Adds the AMD extensions (3DNow!, 3DNow!
extensions, and MMX extensions) to the 32-bit
SSE2 architecture.
Caution:
Programs that are compiled with -xarch= set
to sse (Pentium 3) or sse2 (Pentium 4) to run
on Solaris x86 SSE or SSE2 compatible plat-
forms must be run only on platforms that are
SSE or SSE2 enabled.
Programs compiled with -xarch set to
pentium_proa must be run on platforms sup-
porting AMD 3DNow! and 3DNow! extensions.
Programs compiled with -xarch set to ssea, or
sse2a must be run on platforms supporting AMD
3DNow! and 3DNow! extensions as well as SSE
or SSE2 enabled.
OS releases starting with Solaris 9 4/04 are
SSE/SSE2-enabled on Pentium 3 or 4 compatible
platforms. Earlier versions of Solaris OS are
not SSE/SSE2-enabled.
Similarly, programs compiled with
-xarch=amd64 for Solaris x86 AMD64 platforms
must be on run platforms that support the AMD
64-bit architecture. Note that AMD64 archi-
tecture supports SSE/SSE2.
Programs compiled with -xarch=amd64a must be
run on platforms supporting the AMD 64-bit
architecture as well as AMD 3DNOW! and AMD
3DNow! extensions.
Program binaries compiled and built using
these specialized -xarch hardware flags are
checked by the operating system to verify
that they are being run on appropriately
enabled hardware. This verification is
available with Sun Studio 11 running on the
Solaris 10 operating system.
On systems prior to Solaris 10, no verifica-
tion is done and it is the user's responsi-
bility to ensure objects built using these
flags are deployed on suitable hardware.
Running programs compiled with these -xarch
flags on platforms that are not enabled with
the appropriate features or instruction set
extensions can result in "Illegal Instruc-
tion" errors, segmentation faults or
incorrect results occurring without any
explicit warning messages. This warning
extends also to programs that employ .il
inline assembly language functions or __asm()
assembler code that utilize SSE, SSE2, AMD
64, and AMD 3DNow! instructions and AMD
3DNow! extensions.
If you compile and link in separate steps,
always link using the compiler and using the
same -xarch setting to ensure that the
correct startup routine is linked.
Arithmetic results on x86 may differ from
results on SPARC due to the x86 80-byte
floating-point registers. To minimize these
differences, use the -fstore option or com-
pile with -xarch=sse2 if the hardware sup-
ports SSE2.
x86 Defaults:
If you do not specify -xarch=isa, the compiler assumes
-xarch=generic.
Note: When you specify -fast on x86, the compiler sets
-xarch=native.
Interactions:
Although this option can be used alone, it is part of
the expansion of the -xtarget option and may be used to
override the -xarch value that is set by a specific
-xtarget option. For example, -xtarget=ultra2 expands
to -xarch=v8 -xchip=ultra2 -xcache=16/32/1:512/64/1. In
the following command -xarch=v8plusb overrides the
-xarch=v8 that is set by the expansion of
-xtarget=ultra2.
example% cc -xtarget=ultra2 -xarch=v8plusb ...
Warnings:
If this option is used with optimization, the appropri-
ate choice can provide good performance of the execut-
able on the specified architecture. An inappropriate
choice, however, might result in serious degradation of
performance or in a binary program that is not execut-
able on all intended target platforms.
-xautopar
Turns on automatic parallelization for multiple proces-
sors. Does dependence analysis (analyze loops for
inter- iteration data dependence) and loop restructur-
ing. If optimization is not at -xO3 or higher, optimi-
zation is raised to -xO3 and a warning is issued.
Note that -xautopar does not accept OpenMP paralleliza-
tion directives. However, the Sun-specific MP pragmas
have been deprecated and the compiler supports the APIs
specified by the OpenMP 2.5 standard instead. See the
OpenMP API User's Guide for migration information to
the directives of the standard.
Avoid -xautopar if you do your own thread management.
To get faster execution, this option requires a multi-
ple processor system. On a single-processor system, the
resulting binary usually runs slower.
To determine how many processors you have, use the
psrinfo command.
To request a number of processors, set the PARALLEL and
OMP_NUM_THREADS environment variables. See the ENVIRON-
MENT section of this man page for more information.
o Do not request more processors than are available.
o If N is the number of processors on the machine, then
for a one-user, multiprocessor system, try
PARALLEL=N-1.
If you use -xautopar and compile and link in one step,
then linking automatically includes the microtasking
library and the threads-safe C runtime library. If you
use -xautopar and compile and link in separate steps,
then you must link with cc -xautopar as well. For a
complete list of all compiler options that must be
specified at both compile time and at link time, see
the C User's Guide.
-xbinopt={prepare|off}
(SPARC) Instructs the compiler to prepare the binary
for later optimizations, transformations and analysis
(see binopt(1)). This option may be used for building
executables or shared objects. This option must be used
with optimization level -xO1 or higher to be effective.
There is a modest increase in size of the binary when
built with this option..
If you compile in separate steps, -xbinopt must appear
on both compile and link steps:
example% cc -c -xO1 -xbinopt=prepare a.c b.c
example% cc -o myprog -xbinopt=prepare a.o
If some source code is not available for compilation,
this option may still be used to compile the remainder
of the code. It should then be used in the link step
that creates the final binary. In such a situation,
only the code compiled with this option can be optim-
ized, transformed or analyzed.
Compiling with -xbinopt=prepare and -g increases the
size of the executable by including debugging informa-
tion. The default is -xbinopt=off.
-xbuiltin[=a]
Use the -xbuiltin[=(%all|%none)] command when you want
to improve the optimization of code that calls standard
library functions. Many standard library functions,
such as the ones defined in math.h and stdio.h, are
commonly used by various programs. This command lets
the compiler substitute intrinsic functions or inline
system functions where profitable for performance. See
the er_src(1) man page for an explanation of how to
read compiler commentary in object files to determine
for which functions the compiler actually makes a sub-
sitution.
However, these substitutions can cause the setting of
errno to become unreliable. If your program depends on
the value of errno, avoid this option. See the NOTES
section at the end of this man page for more informa-
tion.
a stands for (%all|%none).
Note: -xbuiltin only inlines global functions defined
in system header files, never static functions defined
by the user.
The first default of this command is -xbuiltin=%none,
which means no functions from the standard libraries
are substituted or inlined. The first default applies
when you do not specify -xbuiltin.
The second default of this command is -xbuiltin=%all,
which means the compiler substitutes intrinsics or
inlines standard library functions as it determines the
optimization benefit. The second default applies when
you specify -xbuiltin but do not provide an argument.
If you compile with -fast, then -xbuiltin is set to
%all.
-xCC When you specify -xc99=none and -xCC, the compiler
accepts the C++-style comments. In particular, the "//"
can be used to indicate the start of a comment.
-xc99[=o]
The -xc99 flag controls compiler recognition of the
implemented features from the C99 standard (ISO/IEC
9899:1999, Programming Language - C).
o can be a comma separated list comprised of the fol-
lowing:
Value Meaning
[no]_lib [Do not] Enable the 1999 C standard
library semantics of routines that
appeared in both the 1990 and 1999 C
standard.
all Turn on recognition of supported C99
language features and enable the 1999 C
standard library semantics of routines
that appear in both the 1990 and 1999 C
standard.
none Turn off recognition of C99 language
features, and do not enable the 1999 C
standard library semantics of routines
that appeared in both the 1990 and 1999
C standard.
If you do not specify -xc99, the compiler defaults to
-xc99=all,no_lib.
If you specify -xc99 without any values, the option is
set to -xc99=all.
NOTE:
Though the compiler support-level defaults to the
language features of the C99 standard, the standard
headers provided by Solaris 8 and Solaris 9 in
/usr/include do not conform with the 1999 ISO/IEC C
standard. If you encounter error messages, try using
-xc99=none to obtain the 1990 ISO/IEC C standard
behavior for these headers.
The 1999 C standard library semantics of routines that
appeared in both the 1990 and 1999 C standard are not
available and therefore cannot be enabled on Solaris 8
and Solaris 9. The compiler issues an error message
when -xc99=lib has been specified directly or
indirectly on Solaris 8 or Solaris 9.
-xcache=c
Defines the cache properties for use by the optimizer.
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
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
Although this option can be used alone, it is part of
the expansion of the -xtarget option; its primary use
is to override a value supplied by the -xtarget option.
This option specifies the cache properties that the
optimizer can use. It does not guarantee that any par-
ticular cache property is used.
The -xcache values are:
generic
This is the default. Sets the parameters for the
best performance over most architectures.
native
Sets the parameters for the best performance on
the host environment.
s1/l1/a1
Defines level 1 cache properties.
s1/l1/a1:s2/l2/a2
Defines levels 1 and 2 cache properties.
s1/l1/a1:s2/l2/a2:s3/l3/a3
Defines levels 1, 2, and 3 cache properties.
Example:-xcache=16/32/4:1024/32/1 specifies the following:
Level 1 cache has: Level 2 cache has:
16K bytes
1024K bytes
32 bytes line size
32 bytes line size
4-way associativity
Direct mapping associativity.
-xcg{89|92}
(SPARC) Obsolete. You should not use this option.
Current Solaris operating systems no longer support
SPARC V7 architecture. Compiling with this option gen-
erates code that runs slower on current SPARC plat-
forms. Use -O instead to take advantage of defaults for
-xarch, -xchip, and -xcache.
-xchar=o
The option is provided solely for the purpose of easing
the migration of code from systems where the char type
is defined as unsigned. Unless you are migrating from
such a system, do not use this option. Only code that
relies on the sign of a char type needs to be rewritten
to explicitly specify signed or unsigned. You can sub-
stitute one of the following values for o:
o signed: Treat character constants and variables
declared as char as signed. This impacts the behavior
of compiled code, it does not affect the behavior of
library routines.
o s: equivalent to signed.
o unsigned: Treat character constants and variables
declared as char as unsigned. This impacts the
behavior of compiled code, it does not affect the
behavior of library routines.
o u: equivalent to unsigned.
If you do not specify -xchar, the compiler assumes
-xchar=s. If you specify -xchar, but do not specify a
value, the compiler assumes -xchar=s.
The -xchar option changes the range of values for the
type char only for code compiled with -xchar. This
option does not change the range of values for type
char in any system routine or header file. In particu-
lar, the value of CHAR_MAX and CHAR_MIN, as defined by
limits.h, do not change when this option is specified.
Therefore, CHAR_MAX and CHAR_MIN no longer represent
the range of values encodable in a plain char.
If you use -xchar, be particularly careful when you
compare a char against a predefined system macro
because the value in the macro may be signed. This is
most common for any routine that returns an error code
which is accessed through a macro. Error codes are
typically negative values so when you compare a char
against the value from such a macro, the result is
always false. A negative number can never be equal to
any value of an unsigned type.
It is strongly recommended that you never use -xchar to
compile routines for any interface exported through a
library. The Solaris ABI specifies type char as signed,
and system libraries behave accordingly. The effect of
making char unsigned has not been extensively tested
with system libraries. Instead of using this option,
modify your code that it does not depend on whether
type char is signed or unsigned. The sign of type char
varies among compilers and operating systems.
-xchar_byte_order=o
Produce an integer constant by placing the characters
of a multi-character character-constant in the speci-
fied byte order. You can substitute one of the follow-
ing values for o:
o low: place the characters of a multi-character
character-constant in low-to-high byte order.
o high: place the characters of a multi-character
character-constant in high-to-low byte order.
o default: place the characters of a multi-character
character-constant in an order determined by the com-
pilation mode -X[a|c|s|t].
-xcheck[=n]
(SPARC) Performs a runtime check for stack overflow of
the main thread in a singly-threaded program as well as
slave-thread stacks in a multithreaded program. If a
stack overflow is detected, a SIGSEGV is generated. If
your application needs to handle a SIGSEGV caused by a
stack overflow differently than it handles other
address-space violations, see sigaltstack(2).
n must be one of the following values.
Value Meaning
%all Perform all -xcheck checks.
%none Do not perform any of the -xcheck
checks.
stkovf Enables a runtime check for stack over-
flow.
no%stkovf Turns off stack-overflow checking.
If you do not specify -xcheck, the compiler defaults to
-xcheck=%none. If you specify -xcheck without any argu-
ments, the compiler defaults to -xcheck=%all which
turns on the runtime check for stack overflow.
The -xcheck option does not accumulate on the command
line. The compiler sets the flag in accordance with the
last occurrence of the command.
-xchip=c
Specifies the target processor for use by the optim-
izer.
c must be one of the values listed below.
Although this option can be used alone, it is part of
the expansion of the -xtarget option; its primary use
is to override a value supplied by the -xtarget option.
This option specifies timing properties by specifying
the target processor.
Some effects are:
o The ordering of instructions, that is, scheduling
o The way the compiler uses branches
o The instructions to use in cases where semantically
equivalent alternatives are available
The -xchip values for SPARC platforms are:
generic
Set the parameters for the best performance over
most SPARC platform architectures. This is the
default.
native Set the parameters for the best performance on
the host environment.
old Uses the timing properties of the pre-SuperSPARC
processors.
super Optimize for the SuperSPARC processor.
super2 Optimize for the SuperSPARC II processor.
micro Optimize for the microSPARC(TM) processor.
micro2 Optimize for the microSPARC II processor.
hyper Optimize for the hyperSPARC(TM) processor.
hyper2 Optimize for the hyperSPARC II processor.
ultra Optimize for the UltraSPARC(TM) processor.
ultra2 Optimize for the UltraSPARC II processor.
ultra2e
Optimize for the UltraSPARC IIe processor.
ultra2i
Optimize for the UltraSPARC IIi processor.
ultra3 Optimize for the UltraSPARC(TM) III processor.
ultra3cu
Optimize for the UltraSPARC IIIcu processor.
ultra3i
Optimize for the UltraSPARC IIIi processor.
ultra3iplus
Optimize for the UltraSPARC IIIiplus processor.
ultra4 Optimize for the UltraSPARC IV processor.
ultra4plus
Optimize for the UltraSPARC IVplus processor.
ultraT1
Optimize for the UltraSPARC T1 processor.
The -xchip values for x86 platforms are:
386 Optimize for the 386 architecture.
486 Optimize for the 486 architecture.
pentium
Optimize for the pentium architecture.
pentium_pro
Optimize for the pentium_pro architecture.
pentium3
Optimize for Pentium 3 style processor
pentium4
Optimize for Pentium 4 style processor
For more information on how the compiler uses the new
pentium3 and pentium4 flags, see the section 'New
-xarch, -xtarget, and -xchip Flags on x86' at the
beginning of this man page.
-xcode=v
(SPARC) Specify code address space
Note: It is highly recommended that you build shared
objects by specifying -xcode=pic13 or -xcode=pic32. It
is possible to build workable shared objects with
-xarch=v9 -xcode=abs64 and with -xarch=v8 -xcode=abs32,
but these will be inefficient. Shared objects built
with -xarch=v9 -xcode=abs32 or -xarch=v9 -xcode=abs44
will not work.
The values for -xcode are:
abs32 This is the default for 32-bit systems. Gen-
erates 32-bit absolute addresses.
Code + data + bss size is limited to 2**32
bytes.
-xarch=(generic|v8|v8a|8plus|v8plusa|v8plusb)
abs44 This is the default for 64-bit systems. Gen-
erates 44-bit absolute addresses.
Code + data + bss size is limited to 2**44
bytes. Available only on 64-bit architectures:
-xarch=(v9|v9a|v9b)
abs64 Generates 64-bit absolute addresses.
Available only on 64-bit architectures:
-xarch=(v9|v9a|v9b)
pic13 Generates position-independent code for use in
shared libraries (small model).
Equivalent to -Kpic. Permits references to at
most 2**11 unique external symbols on 32-bit
architectures, 2**10 on 64-bit.
pic32 Generates position-independent code for use in
shared libraries (large model).
Equivalent to -KPIC. Permits references to at
most 2**30 unique external symbols on 32-bit
architectures, 2**29 on 64-bit.
The default on V8 is -xcode=abs32. The default for
SPARC and UltraSPARC V9 is -xcode=abs44.
When building shared dynamic libraries, the default
-xcode value of abs44 (not abs32) will not work with
-xarch=v9, v9a, or v9b. Specify -xcode=pic13 or
-xcode=pic32 instead.
To determine whether to use -xcode=pic13 or
-xcode=pic32, check the size of the Global Offset Table
(GOT) by using elfdump -c (see the elfdump(1) man page
for more information) and to look for the section
header, sh_name: .got. The sh_size value is the size of
the GOT. If the GOT is less than 8,192 bytes, specify
-xcode=pic13, otherwise specify -xcode=pic32.
In general, use the following guidelines to determine
how you should use -xcode:
o If you are building an executable you should not use
-xcode=pic13 or -xcode=pic32.
o If you are building an archive library only for
linking into executables you should not use
-xcode=pic13 or -xcode=pic32.
o If you are building a shared library, start with
-xcode=pic13 and once the GOT size exceeds 8,192 bytes,
use -xcode=pic32.
o If you are building an archive library for linking
into shared libraries you should just use -xcode=pic32.
-xcrossfile[=n]
Enable optimization and inlining across source files
If specified, n may be 0, or 1. The default is
-xcrossfile=0 which specifies that no cross file
optimizations are performed. -xcrossfile is equivalent
to -xcrossfile=1.
Normally, the scope of the compiler's analysis is lim-
ited to each separate file on the command line. For
example, -xO4's automatic inlining is limited to sub-
programs defined and referenced within the same source
file.
With -xcrossfile, the compiler analyzes all the files
named on the command line as if they had been con-
catenated into a single source file. Consider the fol-
lowing command-line example:
example% cc -xcrossfile -xO4 -c f1.c f2.c
example% cc -xcrossfile -xO4 -c f3.c f4.c
Cross-module optimizations occur between files f1.c and
f2.c, and between f3.c and f4.c. No optimizations occur
between f1.c and f3.c or f4.c.
-xcrossfile is only effective when used with -xO4 or
-xO5.
However, this option has no effect when you direct the
compiler to produce assembly source by specifying the
-S option. Assembly (.s) files do not participate in
optimizations and inlining across source files.
The files produced from this compilation are inter-
dependent (due to possible inlining) must be used as a
unit when linking into a program. If any one routine is
changed and the files recompiled, they must all be
recompiled.
As a result, use of this option will affect how
makefiles are constructed.
See also -xldscope.
-xcsi
This option allows the C compiler to accept source code
written in locales that do not conform to the ISO C
source character code requirements. These locales
include ja_JP.PCK.
Note: The compiler translation phases required to han-
dle such locales may result in significantly longer
compile times. You should only use this option when
you compile source files that contain source characters
from one of these locales.
The compiler does not recognize source code written in
locales that do not conform to the ISO C source charac-
ter code requirements unless you specify -xcsi.
-xdebugformat=[stabs|dwarf]
Specify -xdebugformat=dwarf if you maintain software
which reads debugging information in the dwarf format.
This option causes the compiler to generate debugging
information by using the dwarf standard format and is
the default
-xdebugformat=stabs generates debugging information
using the stabs standard format.
If you do not specify -xdebugformat, the compiler
assumes -xdebugformat=dwarf. This option requires an
argument.
This option affects the format of the data that is
recorded with the -g option. Some small amount of
debugging information is recorded even without -g, and
the format of that information is also controlled with
this option. So -xdebugformat has a an effect even
when -g is not used.
The dbx and Performance Analyzer software understand
both stabs and dwarf format so using this option does
not have any effect on the functionality of either
tool.
See also the dumpstabs(1) and dwarfdump(1) man pages
for more information.
-xdepend[=[yes|no] ]
Analyzes loops for inter-iteration data dependencies
and performs loop restructuring.
Loop restructuring includes loop interchange, loop
fusion, scalar replacement, and elimination of "dead"
array assignments. If optimization is not at -xO3 or
higher, the compiler raises the optimization to -xO3
and issues a warning.
If you do not specify -xdepend, the default is
-xdepend=no which means the compiler does not analyze
loops for data dependencies. If you specify -xdepend
but do not specify an argument, the compiler sets the
option to -xdepend=yes which means the compiler
analyzes loops for data dependencies.
Dependency analysis is included in -xautopar or
-xparallel.
The dependency analysis is done at compile time.
Dependency analysis may help on single-processor sys-
tems. However, if you try -xdepend on single-processor
systems, you should not use either -xautopar or -xex-
plicitpar. If either of them is on, the -xdepend optim-
ization is done for multiple-processor systems.
See Also: -xprefetch_auto_type
-xdryrun
This option is a macro for -###.
-xe Performs only syntax and semantic checking on the
source file, but does not produce any object or execut-
able file.
-xexplicitpar
(SPARC) Parallelizes the loops that are specified. You
do the dependency analysis: analyze and specify loops
for inter-iteration and data dependencies. The software
parallelizes the specified loops.
Note that -xexplicitpar does not accept OpenMP paral-
lelization directives. However, the Sun-specific MP
pragmas have been deprecated and the compiler supports
the APIs specified by the OpenMP 2.5 standard instead.
See the OpenMP API User's Guide for migration informa-
tion to the directives of the standard.
If optimization is not at -xO3 or higher, then it is
raised to -xO3 and a warning is issued.
Avoid -xexplicitpar if you do your own thread manage-
ment.
To get faster code, use this option on a multiprocessor
system. On a single-processor system, the generated
code usually runs slower.
If you identify a loop for parallelization, and the
loop has dependencies, you can get incorrect results,
possibly different ones with each run, and with no
warnings. Do not apply an explicit parallel pragma to
a reduction loop. The explicit parallelization is
done, but the reduction aspect of the loop is not done,
and the results can be incorrect.
If you use -xexplicitpar and compile and link in one
step, then linking automatically includes the
microtasking library and the threads-safe C runtime
library. If you use -xexplicitpar and compile and link
in separate steps, then you must also link with cc
-xexplicitpar. For a complete list of compiler options
that must be specified at both compile time and at link
time, see the C User's Guide.
Do not specify -xexplicitpar and -xopenmp together.
-xF The -xF option enables the optimal reordering of func-
tions and variables by the linker.
This option instructs the compiler to place functions
and/or data variables into separate section fragments,
which enables the linker, using directions in a mapfile
specified by the linker's -M option, to reorder these
sections to optimize program performance. Generally,
this optimization is only effective when page fault
time constitutes a significant fraction of program run
time.
Reordering functions and variables for optimal perfor-
mance requires the following operations:
1. Compiling and linking with -xF.
2. Following the instructions in the Performance
Analyzer manual regarding how to generate a mapfile for
functions or following the instructions in the Linker
and Libraries Guide regarding how to generate a mapfile
for data.
3. Relinking with the new mapfile by using the linker's
-M option.
4. Re-executing under the Analyzer to verify improve-
ment.
v can be one of the following values:
Value Meaning
[no%]func [Do not] fragment functions into
separate sections.
[no%]gbldata [Do not] fragment global data (variables
with external linkage) into separate
sections.
%all Fragment functions and global data.
%none Fragment nothing.
If you do not specify -xF, the default is -xF=%none. If
you specify -xF without any arguments, the default is
-xF=%none,func.
See Also:
analyzer(1), debugger(1), ld(1)
-xhelp=f
Displays on-line help information.
f must be either flags or readme.
-xhelp=flags displays a summary of the compiler
options;
-xhelp=readme displays the readme file;
-xhwcprof=[enable|disable]
(SPARC) Use the -xhwcprof option to enable compiler
support for hardware counter-based profiling.
When -xhwcprof is enabled, the compiler generates
information that helps tools match hardware counter
data reference and miss events with associated instruc-
tions. Corresponding data-types and structure-members
may also be identified in conjunction with symbolic
information (produced with -g). This information can be
useful in performance analysis and it is not easily
identified from profiles based on code addresses,
source statements, or routines.
You can compile a specified set of object files with
-xhwcprof however, -xhwcprof is most useful when
applied to all object files in the application. This
will provide coverage to identify and correlate all
memory references distributed in the application's
object files.
If you are compiling and linking in separate steps, use
-xhwcprof at link time as well. Future extensions to
-xhwcprof may require its use at link time. For a com-
plete list of compiler options that must be specified
at both compile time and at link time, see the C User's
Guide.
An instance of -xhwcprof=enable or -xhwcprof=disable
overrides all previous instances of -xhwcprof in the
same command line.
-xhwcprof is disabled by default. Specifying -xhwcprof
without any arguments is the equivalent to
-xhwcprof=enable.
-xhwcprof requires that optimization be turned on and
that the debug data format be set to dwarf
(-xdebugformat=dwarf).
The combination of -xhwcprof and -g increases compiler
temporary file storage requirements by more than the
sum of the increases due to -xhwcprof and -g specified
alone.
The following command compiles example.c and specifies
support for hardware counter profiling and symbolic
analysis of data types and structure members using
DWARF symbols:
example% cc -c -O -xhwcprof -g -xdebugformat=dwarf
example.c
For more information on hardware counter-based profil-
ing, see the Performance Analyzer manual.
-xinline[=v[,v]...]
v can be [{%auto,func_name,no%func_name}].
-xinline tries to inline only those functions specified
in the list. The list is comprised of either a comma-
separated list of function names, or a comma separated
list of no%func_name values, or the value %auto. If you
specify %nofunc_name, the compiler is not to inline the
named function. If you specify %auto, the compiler is
to attempt to automatically inline all functions in the
source files.
The list of values accumulates from left to right. So
for a specification of -xinline=%auto,no%foo the com-
piler attempts to inline all functions except foo. For
a specification of -xinline=%bar,%myfunc,no%bar the
compiler only tries to inline myfunc.
When you compile with optimization set at -xO4 or
above, the compiler normally tries to inline all refer-
ences to functions defined in the source file. You can
restrict the set of functions the compiler attempts to
inline by specifying the -xinline option. If you
specify only -xinline=, that is you do not name any
functions or auto, this indicates that none of the rou-
tines in the source files are to be inlined. If you
specify a list of func_name and no%func_name without
specifying %auto, the compiler only attempts to inline
those functions specified in the list. If %auto is
specified in the list of values with the -xinline
option at optimization level set at -xO4 or above, the
compiler attempts to inline all functions that are not
explicitly excluded by no%func_name.
A function is not inlined if any of the following apply
(no warning is issued):
o Optimization is less than -xO3
o The routine cannot be found
o Inlining the routine does not look profitable or
safe to iropt
o The source for the routine is not in the file being
compiled (however, see -xcrossfile).
If you specify multiple -xinline options on the command
line, they do not accumulate. The last -xinline on the
command line specifies what functions the compiler
attempts to inline.
See also -xldscope.
-xipo[=a]
The compiler performs partial-program optimizations by
invoking an interprocedural analysis pass. Unlike
-xcrossfile, -xipo performs optimizations across all
object files in the link step, and is not limited to
just the source files on the compile command. However,
just like -xcrossfile, whole-program optimizations per-
formed with -xipo do not include assembly (.s) source
files.
You must specify -xipo both at compile time and at link
time. For a complete list of compiler options that
must be specified at both compile time and at link
time, see the C User's Guide.
Analysis and optimization is limited to the object
files compiled with -xipo, and does not extend to
object files or libraries. -xipo is multiphased, so
you need to specify -xipo for each step if you compile
and link in separate steps.
The -xipo option generates significantly larger object
files due to the additional information needed to per-
form optimizations across files. However, this addi-
tional information does not become part of the final
executable binary file. Any increase in the size of the
executable program is due to the additional optimiza-
tions performed. The object files created in the compi-
lation steps have additional analysis information com-
piled within them to permit crossfile optimizations to
take place at the link step.
a is 0, 1, or 2. -xipo without any arguments is
equivalent to -xipo=1. -xipo=0 is the default setting
and turns off -xipo.
With -xipo=1, the compiler performs inlining across all
source files. At -xipo=2, the compiler performs inter-
procedural aliasing analysis as well as optimization of
memory allocation and layout to improve cache perfor-
mance.
Here are some important considerations for -xipo:
o It requires an optimization level of at least -xO4.
o It conflicts with -xcrossfile. If you use these
together, the result is a compilation error.
o Objects that are compiled without -xipo can be linked
freely with objects that are compiled with -xipo.
In this example, compilation and linking occur in a
single step:
cc -xipo -xO4 -o prog part1.c part2.c part3.c
In this example, compilation and linking occur in
separate steps:
cc -xipo -xO4 -c part1.c part2.c
cc -xipo -xO4 -c part3.c
cc -xipo -xO4 -o prog part1.o part2.o part3.o
The object files created in the compilation steps have
additional analysis information compiled within them to
permit crossfile optimizations to take place at the
link step.
A restriction is that libraries, even if compiled with
-xipo do not participate in crossfile interprocedural
analysis, as shown in this example:
cc -xipo -xO4 one.c two.c three.c
ar -r mylib.a one.o two.o three.o
cc -xipo -xO4 -o myprog main.c four.c mylib.a
Here interprocedural optimizations are performed
between one.c, two.c and three.c, and between main.c
and four.c, but not between main.c or four.c and the
routines on mylib.a. (The first compilation may gen-
erate warnings about undefined symbols, but the
interprocedural optimizations are performed because it
is a compile and link step.)
When Not To Use -xipo=2 Interprocedural Analysis
The compiler tries to perform whole-program analysis
and optimizations as it works with the set of object
files in the link step. The compiler makes the follow-
ing two assumptions for any function (or subroutine)
foo() defined in this set of object files:
(1) foo() is not called explicitly by another routine
that is defined outside this set of object files at
runtime.
(2) The calls to foo() from any routine in the set of
object files are not interposed upon by a different
version of foo() defined outside this set of object
files.
Do not compile with -xipo=2 if assumption (1) is not
true for the given application.
Do not compile with either -xipo=1 or -xipo=2 if
assumption (2) is not true.
As an example, consider interposing on the function
malloc() with your own version and compiling with
-xipo=2. Consequently, all the functions in any library
that reference malloc() that are linked with your code
have to be compiled with -xipo=2 also and their object
files need to participate in the link step. Since this
might not be possible for system libraries, do not com-
pile your version of malloc() with -xipo=2.
As another example, suppose that you build a shared
library with two external calls, foo() and bar() inside
two different source files. Furthermore, suppose that
bar() calls foo(). If there is a possibility that foo()
could be interposed at runtime, then do not compile the
source file for foo() or for bar() with -xipo=1 or
-xipo=2. Otherwise, foo() could be inlined into bar(),
which could cause incorrect results.
See also -xjobs and -xipo_archive
-xipo_archive[=a]
The -xipo_archive option enables the compiler to optim-
ize object files that are passed to the linker with
object files that were compiled with -xipo and that
reside in the archive library (.a) before producing an
executable. Any object files contained in the library
that were optimized during the compilation are replaced
with their optimized version.
a is one of the following:
writeback
The compiler optimizes object files passed to
the linker with object files compiled with
-xipo that reside in the archive library (.a)
before producing an executable. Any object
files contained in the library that were optim-
ized during the compilation are replaced with
an optimized version.
readonly
The compiler optimizes object files passed to
the linker with object files compiled with
-xipo that reside in the archive library (.a)
before producing an executable.
none There is no processing of archive files.
If you do not specify a setting for -xipo_archive, the
compiler sets it to -xipo_archive=none.
-xjobs=n
Compile with multiple processors.
Specify the -xjobs option to set how many processes the
compiler creates to complete its work. This option can
reduce the build time on a multi-cpu machine.
Currently, -xjobs works only with the -xipo option.
When you specify -xjobs=n, the interprocedural optim-
izer uses n as the maximum number of code generator
instances it can invoke to compile different files.
Generally, a safe value for n is 1.5 multiplied by the
number of available processors. Using a value that is
many times the number of available processors can
degrade performance because of context switching over-
heads among spawned jobs. Also, using a very high
number can exhaust the limits of system resources such
as swap space.
You must always specify -xjobs with a value. Otherwise
an error diagnostic is issued and compilation aborts.
Multiple instances of -xjobs on the command line over-
ride each other until the rightmost instance is
reached.
The following example compiles more quickly on a system
with two processors than the same command without the
-xjobs option.
example% cc -xipo -xO4 -xjobs=3 t1.c t2.c t3.c
-xldscope={v}
Changes the default linker scoping for the definition
of extern symbols. Changing the default can result in
faster and safer shared libraries because the implemen-
tation will be better hidden.
v must be one of the following:
Value Meaning
global Global linker scoping is the least res-
trictive linker scoping. All references
to the symbol bind to the definition in
the first dynamic module that defines
the symbol. This linker scoping is the
current linker scoping for extern sym-
bols.
symbolic Symbolic linker scoping and is more res-
trictive than global linker scoping. All
references to the symbol from within the
dynamic module being linked bind to the
symbol defined within the module. Out-
side of the module, the symbol appears
as though it were global. This linker
scoping corresponds to the linker option
-Bsymbolic.
hidden Hidden linker scoping is more restric-
tive than symbolic and global linker
scoping. All references within a dynamic
module bind to a definition within that
module. The symbol will not be visible
outside of the module.
If you do not specify -xldscope, the compiler assumes
-xldscope=global. It is not legal to specify -xldscope
without any arguments. The compiler issues an error if
you specify -xldscope without an argument. Multiple
instances of this option on the command line override
each other until the rightmost instance is reached.
If you intend to allow a client to override a function
in a library, you must be sure that the function is not
generated inline during the library build. The compiler
inlines a function if you specify the function name
with -xinline, if you use #pragma inline, if you com-
pile at -xO4 or higher in which case inlining can hap-
pen automatically, if you use the inline specifier, or
if you are using cross-file optimization.
For example, suppose library ABC has a default alloca-
tor function that can be used by library clients, and
is also used internally in the library:
void* ABC_allocator(size_t size) { return malloc(size);
}
If you build the library at -xO4 or higher, the com-
piler inlines calls to ABC_allocator that occur in
library components. If a library client wants to
replace ABC_allocator with a customized version, the
replacement will not occur in library components that
called ABC_allocator. The final program will include
different versions of the function.
Library functions declared with the __hidden or __sym-
bolic specifiers can be generated inline when building
the library. They are not supposed to be overridden by
clients. For more information, see chapter 2 "C-
Compiler Information Specific to Sun's Implementation"
of the C User's