cc(1)cc(1)NAMEcc - C compiler
SYNOPSIScc [-#] [-###] [-Aname[(tokens)]] [-B[static|dynamic]] [-C] [-c]
[-D] [-d[y|n]] [-dalign] [-E] [-errfmt[=[no%]error]]
[-errhdr[=h]] [-erroff[=t[,t...]]] [-errshort[=i]] [-errtags=a]
[-errwarn[=t[,t...]]] [-fast] [-fd] [-features=[a]] [-flags]
[-flteval[={any|2}]] [-fma[={none|fused}]] [-fnonstd]
[-fns=[no|yes]] [-fprecision=p] [-fround=r] [-fsimple[=n]]
[-fsingle] [-fstore] [-ftrap[=t[,t...]]] [-G] [-g] [-g3] [-H]
[-hname] [-I[-|dir]] [-i] [-include] [-KPIC] [-Kpic] [-keeptmp]
[-Ldir] [-lname] [-library=sunperf] [-m32|-m64] [-mc] [-mis‐
align] [-misalign2] [-mr[,string]] [-mt] [-native] [-nofstore]
[-O] [-On] [-ofilename] [-P] [-p] [-Qoption phase [,option...]]
[-Q[y|n]] [-qp] [-Rdir[:dir...]] [-S] [-s] [-traceback[=list]]
[-Uname] [-V] [-v] [-Wc,arg] [-w] [-X[c|a|t|s]] [-Xlinker arg
[-xaddr32[={yes|no}]] [-xalias_level[=a]] [-xanalyze={code|no}]
[-xannotate] [-xarch=a]
[-xautopar] [-xbinopt={a}] [-xbuiltin[=a]] [-xCC] [-xc99[=o]]
[-xcache=c] [-xchar[=o]] [-xchar_byte_order[=o]] [-xcheck=n]
[-xchip=c] [-xcode=v] [-xcsi] [-xdebugformat=[stabs|dwarf]]
[-xdepend[={yes|no}]] [-xdryrun] [-xdumpmacros[=v[,v...]]]
[-xe] [-xF[=v]] [-xhelp=f] [-xhwcprof[={enable|disable}]] [-xin‐
line=[v[,v...]]] [-xinstrument=[no%]datarace] [-xipo[=n]]
[-xipo_archive[=a]] [-xivdep[=p]] [-xjobs=n] [-xkeepframe[=p]]
[-xldscope=[v]] [-xlibmieee]
[-xlibmil] [-xlibmopt] [-xlicinfo] [-xlinkopt[=level]] [-xloop‐
info] [-xM] [-xM1] [-xMD] [-xMF] [-xMMD] [-xMerge] [-xmax‐
opt[=v]] [-xmemalign=ab] [-xmodel=[a]] [-xnolib] [-xnolibmil]
[-xnolibmopt] [-xnorunpath] [-xOn] [-xopenmp[=i]] [-xP] [-xpage‐
size=n] [-xpagesize_heap=n] [-xpagesize_stack=n] [-xpec]
[-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]
[-xreduction] [-xregs=r[,r...]] [-xrestrict[=f]] [-xs]
[-xsafe=mem] [-xsfpconst] [-xspace] [-xstrconst] [-xtarget=t]
[-xtemp=dir] [-xthreadvar[=o] [-xtime] [-xtransition] [-xtri‐
graphs[=[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
Oracle Solaris Studio 12.3 C Compiler version 5.12 This man page
details the options or flags that are available for the C compiler in
the Oracle Solaris Studio 12.3 release. Complete documentation for
this release is available on the Oracle Technical Network (OTN) Solaris
Studio website: http://oracle.com/technetwork/server-storage/solaris‐
studio The OTN website is a complete resource for Oracle Solaris Studio
and includes many technical articles detailing best practices and deep
dives into various programming technologies and other topics. For the
complete description of all new features and functionality in the Ora‐
cle Solaris Studio suite, see the What's New in this Release guide. A
man page, by definition, is a quick reference. For more detailed infor‐
mation on the C compiler and its options, see the C User's Guide.
COMPILING FOR 64-BIT PLATFORMS:
Use the -m32 and -m64 options to specify the memory model of the target
compilation, ILP32 or LP64 respectively.
The -xarch option no longer carries an implicit memory model defini‐
tion, and should be used only to specify the instruction set of the
target processor.
The ILP32 model specifies that C-language int, long, and pointer data
types are all 32-bits wide. The LP64 model specifies that long and
pointer data types are all 64-bits wide. The Oracle Solaris and Linux
OS also support large files and large arrays under the LP64 memory
model.
When compiling with -m64, the resulting executable will work only on
64-bit SPARC or x86 processors under Oracle Solaris OS or Linux OS run‐
ning a 64-bit kernel. Compilation, linking, and execution of 64-bit
objects can only take place in a Oracle Solaris or Linux OS that sup‐
ports 64-bit execution.
SPECIAL x86 NOTES
There are some important issues to be aware of when compiling for x86
Oracle Solaris platforms.
Programs compiled with -xarch set to sse, sse2, sse2a, or sse3 and
beyond must be run only on platforms that provide these extensions and
features.
If you compile and link in separate steps, always link using the com‐
piler and with same -xarch setting to ensure that the correct startup
routine is linked.
Numerical results on x86 might differ from results on SPARC due to the
x86 80-bit floating-point registers. To minimize these differences, use
the -fstore option or compile with -xarch=sse2 if the hardware supports
SSE2.
Numerical results can also differ between Oracle Solaris and Linux
because the intrinsic math libraries (for example, sin(x)) are not the
same.
Binary Compatibility Verification
Program binaries compiled and built using specialized -xarch hardware
flags are verified by the OS that they are being run on the appropriate
platform. Running programs compiled with specialized -xarch options on
platforms that are not enabled with the appropriate features or
instruction set extensions could result in segmentation faults or
incorrect results occurring without any explicit warning messages.
This warning extends also to programs that employ .il inline assembly
language functions or __asm() assembler code that utilize SSE, SSE2,
SSE2a, and SSE3 (and beyond) instructions and extensions.
Overview of the C Compiler
The cc (1) manual page describes the ISO C compiler options that are
SVID compliant under current Oracle Solaris operating systems. Take
note that the C compiler 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 is the inter‐
face to the C compilation system. The compilation 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
profiling, assembled, and link edited. Although the preprocessor can be
used as a macro processor, this is not recommended, as its output is
geared toward that which would be acceptable as input to a valid C com‐
piler. 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. How‐
ever, 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 .S suffix are taken to be assembly source files; they may be
assembled and link edited. Such files are passed to the preprocessor
(/usr/ccs/lib/cpp on Oracle Solaris), and then to the assembler. Files
with an .i are taken to be preprocessed C source files, and may be com‐
piled, optimized, instrumented for profiling, assembled, and link
edited. Files whose names do not end in .c, .s, .S or .i are passed to
the link editor, which produces a dynamically linked 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 can be seen by using the -### or
-xdryrun option and examining the -Y option of the ld invocation.
User-Supplied Default Compiler Options Startup File
The default compiler options file enables the user to specify a set of
default options that are applied to all compiles, unless otherwise
overridden. For example, the file could specify that all compiles
default at -xO2, or automatically include the file setup.il.
At startup, the compiler searches for a default options file listing
default options it should include for all compiles. The environment
variable SPRO_DEFAULTS_PATH specifies a colon-separated list of direc‐
tories to search for the the defaults file.
If the environment variable is not set, a standard set of defaults is
used. If the environment variable is set but is empty, no defaults are
used.
The defaults file name must be of the form compiler.defaults, where
compiler is one of the following: cc, c89, c99, CC, ftn, or lint. For
example, the defaults for the C compiler would be cc.defaults
If a defaults file for the compiler is found in the directories listed
in SPRO_DEFAULTS_PATH, the compiler will read the file and process the
options prior to processing the options on the command line. The first
defaults file found will be used and the search terminated.
System administrators may create system-wide default files in Studio-
install-path/prod/etc/config. If the environment variable is set, the
installed defaults file will not be read.
The format of a defaults file is similar to the command line. Each
line of the file may contain one or more compiler options separated by
white space. Shell expansions, such as wild cards and substitutions,
will not be applied to the options in the defaults file.
The value of the SPRO_DEFAULTS_PATH and the fully expanded command line
will be displayed in the verbose output produced by options -#, -###,
and -dryrun.
Options specified by the user on the command line will usually override
options read from the defaults file. For example, if the defaults file
specifies compiling with -xO4 and the user specifies -xO2 on the com‐
mand line, -xO2 will be used.
Some options appearing in the default options file will be appended
after the options specified on the command line. These are the pre‐
processor option -I, linker options -B, -L, -R, and -l, and all file
arguments, such as source files, object files, archives, and shared
objects.
The following is an example of how a user-supplied default compiler
option startup file might be used.
demo% cat /project/defaults/cc.defaults
-fast -I/project/src/hdrs -L/project/libs -llibproj -xvpara
demo% setenv SPRO_DEFAULTS_PATH /project/defaults
demo% cc-c -I/local/hdrs -L/local/libs -lliblocal tst.c
The compiler command is now equivalent to:
cc-fast -xvpara -c -I/local/hdrs -L/local/libs -lliblocal \
tst.c -I/project/src/hdrs -L/project/libs -llibproj
While the compiler defaults file provides a convenient way to set the
defaults for an entire project, it can become the cause of hard to
diagnose problems. Set the environment variable SPRO_DEFAULTS_PATH to
an absolute path rather than the current directory to avoid such prob‐
lems.
The interface stability of the default options file is uncommitted. The
order of option processing is subject to change in a future release.
OPTIONS
All platform-specific options are silently accepted on all platforms.
Any exceptions to this rule are noted under the specific option.
Options valid only on SPARC platforms are marked (SPARC).
Options valid only on x86/x64 platforms are marked (x86).
Deprecated options are marked (Obsolete) and should not be used going
forward. They are provided only for compatibility with earlier
releases. Use the indicated replacement option.
See ld(1) for linker options. In general, processing of the compiler
options is from left to right, permitting selective overriding of macro
options. This rule does not apply to linker or preprocessor options.
In the syntax of the command-line options, items shown in square brack‐
ets ( [] ) are optional. Curly brackets enclose a bar-separated list of
literal items to be chosen, as in {yes | no | maybe } . The first item
in a list usually indicates the default value when the flag appears
without a value.
For example, -someoption[={no|yes}] implies -someoption is the same as
-someoption=no . 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 actu‐
ally 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 mul‐
tiple times on the command line as a toggle.
Note: Many system libraries, such as libc, are only available as
dynamic libraries in the Oracle Solaris 64-bit compilation envi‐
ronment. 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 Compile and produce a .o file for each source file without link‐
ing. You can explicitly name a single object file by using the
-o option. When the compiler produces object code for each .i or
.c input file, it always creates an object file in the current
working directory. If you suppress the linking step, you also
suppress the removal of the object files.
-Dname[(arg[,arg])] [=expansion]
Define a macro with optional arguments as if the macro is
defined by a #define preprocessing directive. If no =expansion
is specified, the compiler assumes =1.
Predefinitions:unix
sparc (SPARC)
sun
The above are not predefined in -Xc mode.
These predefinitions are valid in all modes:
__BUILTIN_VA_ARG_INCR
__SUNPRO_C=0x5120
__SVR4 (Oracle Solaris)
__SunOS_5_10 (Oracle Solaris)
__SunOS_5_11 (Oracle Solaris)
__amd64 (x86 -m64)
__gnu__linux (linux)
__i386 (x86)
__linux (linux)
__linux__ (linux)
__sparc (SPARC)
__sparcv8 (SPARC)
__sparcv9 (SPARC -m64)
__sun (Oracle Solaris)
__unix
__`uname -s`_`uname -r | tr . _`
__x86_64 (x86 -m64)
linux (x86, linux)
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]
Allow or disallow dynamic linking.
-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 combina‐
tion with dynamic libraries. Most system libraries are only
available as dynamic libraries.
-dalign
(SPARC) Obsolete. You should not use this option. Use -xmema‐
lign=8s instead. For a complete list of obsolete options and
flags, see the C User's Guide. Ignored on x64/x86 platforms.
-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 distinguish‐
able 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.
-errhdr [=h]
Use this option to limit the warnings from header files to the
group of header files indicated by the following flags:
Value Meaning
%all Check all used header files.
%none Check none of the header files.
%user Default. Checks all the user header files except those
in /usr/include and its subdirectories. Also checks
all the header files supplied by the compiler.
-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 mes‐
sage produced by the compiler when it discovers 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 expan‐
sion 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 spec‐
ified on the command line.
-errtags=a
Displays the message tag for each warning message of the C com‐
piler 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. Specify‐
ing -errtags is equivalent to specifying -errtags=yes.
-errwarn[=t[,t...] ]
Use the -errwarn option to cause the C compiler to exit with a
failure status for the given warning messages.
t is a comma-separated list that consists of one or more of the
following: tag, no%tag, %all, %none. Order is important; for
example %all,no%tag causes the C compiler to exit with a fatal
status if any warning except tag is issued.
The 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 warning message. Has no
effect if tag in not issued.
no%tag Prevent cc from exiting with a fatal status if the mes‐
sage specified by tag is issued only as a warning mes‐
sage. Has no effect if tag is not issued. Use this
option to revert a warning message that was previously
specified by this option with tag or %all from causing
cc to exit with a fatal status when issued as a warning
message.
%all Cause cc to exit with a fatal status if any warning
messages are issued. %all can be followed by no%tag to
exempt specific warning messages from this behavior.
%none Prevents any warning messages from causing cc to exit
with a fatal status should any warning tag be issued.
This is the default.
-fast This option is a macro that you can effectively use as a start‐
ing point for tuning an executable for maximum run-time perfor‐
mance. The expansion of -fast can change from one release of the
compiler to the next and includes options that are target plat‐
form specific. Use the -# or the -xdryrun options to examine the
expansion of -fast, and incorporate the appropriate options of
-fast into the ongoing process of tuning the executable.
The expansion of -fast includes -xlibmopt option, which enables
the compiler to use a library of optimized math routines. For
more information, see the description of -xlibmopt in this man
page.
The -fast option impacts the value of errno. See the NOTES sec‐
tion 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 compilation machine. In such
cases, follow -fast with the appropriate -xtarget option. For
example:
% cc-fast -xtarget=generic
For C modules depending on exception handling specified by SUID,
follow -fast by -xnolibmil -xbuiltin=%default
% cc-fast -xnolibmil -xbuiltin=%default
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 (SPARC, x86)
-fsimple=2 (SPARC, x86)
-fsingle (SPARC, x86)
-nofstore (x86)
-xalias_level=basic (SPARC, x86)
-xbuiltin=%all (SPARC, x86)
-xdepend (SPARC, x86)
-xlibmil (SPARC, x86)
-xlibmopt (SPARC, x86)
-xmemalign=8s (SPARC)
-xO5 (SPARC, x86)
-xregs=frameptr (x86)
-xtarget=native (SPARC, x86)
Note that this selection of component option flags is subject to
change with each release of the compiler. For details on the
options set by -fast, see the C User's Guide.
To determine the expansion of -fast on a running system, execute
the command:
cc-fast -xdryrun |& grep ###
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.
The -fast option on x86 includes -xregs=frameptr. Be sure to
read the discussion of -xregs=frameptr especially when compiling
mixed C, Fortran, and C++ source codes.
-fd Reports K&R function declarations and definitions.
-features=[a]
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.
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.
The following table lists the possible values for a. Prefix no%
disables a suboption.
Value Meaning
[no%]conststrings
Enables or disables the placement of string literals
in read-only memory. The default is -features=const‐
strings which replaces the deprecated -xstrconst
option. Note that your program will fail to write to a
string literal under the default compilation mode just
as if you had specified -xstrconst on the command
line.
extensions
Allows zero-sized struct/union declarations and void
function with return statements returning a value to
work.
extinl Generates extern inline functions as global functions.
This is the default, which conforms with the 1999 C
standard.
[no%]extinl
Generates extern inline functions as static functions.
[no%]typeof
Enables/disables recognition of the typeof operator.
The typeof operator returns the type of its argument
(either an expression or a type). It is specified syn‐
tactically like the sizeof operator, but it behaves
semantically like a type defined with typedef. Accord‐
ingly, it can be used anywhere a typedef can be used.
For example, it can be used in a declaration, a cast,
or inside of a sizeof or typeof. The default is -fea‐
tures=typeof.
%none Deprecated. Do not use %none. Examples
typeof(int) i;/* declares variable "i" to be type
int*/
typeof(i+10) j;/* declares variable "j" to be type
int, the type of the expression */
i = sizeof(typeof(j)); /* sizeof returns the size of
the type associated with variable "j" */
int a[10];
typeof(a) b;/* declares variable "b" to be array of
size 10 */
The typeof operator can be especially useful in macro
definitions, where arguments may be of arbitrary type.
For example:
#define SWAP(a,b)
{ typeof(a) temp; temp = a; a = b; b = temp; }
-flags Same as -xhelp=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 dou‐
ble.
any Floating point expressions are evaluated depending on
the combination of the types of the variables and con‐
stants that make up an expression.
If you do not specify -flteval, the compiler sets it to -flte‐
val=any. If you do specify -flteval, but do not provide a value,
the compiler sets it to -flteval=2.
-flteval=2 is only usable with -xarch=sse, pentium_pro, ssea, or
pentium_proa.
-flteval=2 is also not compatible in combination with options
-fprecision or -nofstore.
For more information, see 'Precision of Floating Point Evalua‐
tors' in appendix E of the C User's Guide.
-fma [= { none|fused}]
(SPARC) Enables automatic generation of floating-point, fused,
multiply-add instructions. -fma=none disables generation of
these instructions. -fma=fused allows the compiler to attempt
to find opportunities to improve the performance of the code by
using floating-point, fused, multiply-add instructions.
The default is -fma=none.
The minimum requirements are -xarch=sparcfmaf and an optimiza‐
tion level of at least -xO2 for the compiler to generate fused
multiply-add instructions. The compiler marks the binary program
if fused multiply-add instructions are generated in order to
prevent the program from executing on platforms that do not sup‐
port them.
Fused multiply-adds eliminate the intermediate rounding step
between the multiply and the add. Consequently, programs may
produce different results when compiled with -fma=fused,
although precision will tend to be increased rather than
decreased.
-fnonstd
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
not utilize 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 dis‐
ables "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 subnor‐
mal numbers in hardware, use of this option can significantly
improve the performance of some programs.
When nonstandard mode is enabled, floating point arithmetic may
produce results that do not conform to the requirements of the
IEEE 754 standard. See the Numerical 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 Float‐
ing-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, but is ignored if compiling for
64-bit platforms (-m64), or SSE2-enabled processors
(-xarch=sse2). -fprecision is ignored on SPARC platforms.
-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 subrou‐
tine.
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.
Note that compiling with -xvector or -xlibmopt require default
rounding. Programs that link with libraries compiled with either
-xvector or -xlibmopt or both must ensure that default rounding
is in effect.
-fsimple[=n]
Allows the optimizer to make simplifying assumptions concerning
floating-point arithmetic.
The compiler defaults to -fsimple=0. Specifying -fsimple 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 pro‐
grams are unchanged.
With -fsimple=1, the optimizer can assume the following:
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 propa‐
gate 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 optimize com‐
pletely without regard to roundoff or exceptions. In particular,
a floating-point computation cannot be replaced by one that pro‐
duces different results with rounding modes held constant at run
time.
-fsimple=2
Includes all the functionality of -fsimple=1, and also enables
use of SIMD instructions to compute reductions when -xvec‐
tor=simd is in effect.
Also permits aggressive floating point optimizations that may
cause many programs to produce different numeric results due to
changes in rounding. For example, -fsimple=2 permits the opti‐
mizer to attempt replace all computations of x/y in a given loop
with x*z, where x/y is guaranteed to be evaluated at least once
in the loop, z=1/y, and the values of y and z are known to have
constant values during execution of the loop.
Even with -fsimple=2, the optimizer still is not permitted to
introduce a floating point exception in a program that otherwise
produces none.
See Also:
Techniques for Optimizing Applications: High Performance Comput‐
ing by Rajat Garg and Ilya Sharapov for a more detailed explana‐
tion of how optimization can impact precision. See also articles
on performance and precision on the OTN Oracle Solaris Studio
website:
oracle.com/technetwork/server-storage/solarisstudio/
-fsingle
(-Xt and -Xs modes only) Causes the compiler to evaluate 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 sin‐
gle 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 expression 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 regis‐
ter. Due to roundoffs and truncation, the results may be differ‐
ent 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 simultaneously enable traps and install
a SIGFPE handler. If you specify more than one value, the list
is processed sequentially from left to right.
Use prefix no% to remove a suboption from %all or common.
Value Meaning
[no%]division Trap on division by zero.
[no%]inexact Trap on inexact result.
[no%]invalid Trap on invalid operation.
[no%]overflow Trap on overflow.
[no%]underflow 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 exe‐
cutable. 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 neces‐
sary -l option on the command line.
If you are creating a shared object by specifying -G along with
other compiler options that must be specified at both compile
time and link time, make sure that those same options are also
specified when you link with the resulting shared object.
When you create a shared object, all the object files that are
compiled for 64-bit SPARC architectures must also be compiled
with an explicit -xcode value as documented under the descrip‐
tion 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 -xO3 or lower,
the compiler provides best-effort symbolic information with
almost full optimization. Tail-call optimization and back-end
inlining are disabled.
If you specify -g and the optimization level is -xO4, the com‐
piler provides best-effort symbolic information with full opti‐
mization.
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 Ana‐
lyzer 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: If you compile and link your program in separate steps,
then including the -g option in one step and excluding it from
the other step will not affect the correctness of the program,
but it will affect the ability to debug the program. Any module
that is not compiled with -g (or -g0), but is linked with -g (or
-g0) will not be prepared properly for debugging. Note that com‐
piling the module that contains the function main with the -g
option (or the -g0 option) is usually necessary for debugging.
-g3 Produce additional debugging information.
-g3 is the same as -g with additional debugging symbol table
information so that dbx can display how macros in the source
code have been expanded. This added symbol table information
can result in an increase in the size of the debug information
in the resulting .o and executable when compared to only using
-g.
-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 intrinsic 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 executable
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 follow‐
ing order:
1. The directories named with the -I option, if any.
2. The compiler and system standard directories, usu‐
ally /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, usu‐
ally /usr/include.
-I- changes the include-file search rules to the following:
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 .TP o For include files of
the form search the directories in the following
order:
o The directories named with -I options (both
before and after -I-).
o The compiler and system standard directo‐
ries, usually /usr/include.
o For include files of the form #include <foo.h>,
search the directories in the following order:
o The directories named with the -I options
that appear after -I- (that is, the com‐
piler does not search the -I directories
that appear before -I-).
o The compiler and system standard directo‐
ries, 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 (/). Directories for multi‐
ple -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 settings.
-include filename
This option causes the compiler to treat filename as if it
appears in the first line of a primary source file as a #include
preprocessor directive.
The first directory the compiler searches for filename is the
current working directory and not the directory containing the
main source file, as is the case when a file is explicitly
included. If the compiler cannot find filename in the current
working directory, it searches the normal directory paths. If
you specify multiple -include options, the files are included in
the order they appear on the command line.
-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) Produces position-independent code. Use this option to
compile source files when building a shared library. Each refer‐
ence to a global datum is generated as a dereference of a
pointer in the global offset table. Each function call is gener‐
ated in pc-relative addressing mode through a procedure linkage
table.
-keeptmp
Retains 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 sym‐
bols are resolved from left to right. This option must follow
the sourcefile.
-library=sunperf
Link with the Oracle Solaris Studio supplied performance
libraries.
-m32|-m64
Specifies the memory model for the compiled binary object.
Use -m32 to create 32-bit executables and shared libraries. Use
-m64 to create 64-bit executables and shared libraries.
The ILP32 memory model (32-bit int, long, pointer data types) is
the default on all Oracle Solaris platforms and on Linux plat‐
forms that are not 64-bit enabled. The LP64 memory model (64-bit
long, pointer data types) is the default on Linux platforms that
are 64-bit enabled. -m64 is permitted only on platforms that are
enabled for the LP64 model.
Object files or libraries compiled with -m32 cannot be linked
with object files or libraries compiled with -m64.
When compiling applications with large amounts of static data
using -m64, -xmodel=medium may also be required. Be aware that
some Linux platforms do not support the medium model.
Modules that are compiled with -m32|-m64 must also be linked
with -m32|-m64. For a complete list of compiler options that
must be specified at both compile time and at link time, see the
C User's Guide.
Note that in previous compiler releases, the memory model, ILP32
or LP64, was implied by the choice of the instruction set with
-xarch. Starting with the Sun Studio 12 compilers, this is no
longer the case. On most platforms, just adding -m64 to the com‐
mand line is sufficient to create 64-bit objects.
On Oracle Solaris, -m32 is the default. On Linux systems sup‐
porting 64-bit programs, -m64 -xarch=sse2 is the default.
See also -xarch.
-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 section and
inserts string in the .comment section of the object file. If
string contains embedded blanks, it must be enclosed in quota‐
tion marks. If string is null, the .comment section will be
empty. When you use this flag, mcs -d -a is invoked.
-mt[={yes|no}]
Use this option to compile and link multithreaded code using the
Oracle Solaris threads or POSIX threads API. The -mt=yes option
assures that libraries are linked in the appropriate order.
This option passes -D_REENTRANT to the preprocessor.
To use Oracle Solaris threads, include the thread.h header file
and compile with the -mt=yes option. To use POSIX threads on
Oracle Solaris platforms, include the pthread.h header file and
compile with the -mt=yes option.
On Linux platforms, only the POSIX threads API is available.
(There is no libthread on Linux platforms.) Consequently,
-mt=yes on Linux platforms adds -lpthread instead of -lthread.
To use POSIX threads on Linux platforms, compile with -mt.
Note that when compiling with -G, neither -ltread nor -lpthread
are automatically included by -mt=yes. You will need to explic‐
itly list these libraries when building a shared library.
The -xopenmp option (for using the OpenMP shared-memory paral‐
lelization API) includes -mt=yes automatically.
If you compile with -mt=yes and link in a separate step, you
must use the -mt=yes option in the link step as well as the com‐
pile step. If you compile and link one translation unit with
-mt=yes, you must compile and link all units of the program with
-mt=yes
-mt=yes is the default behavior of the compiler. If this behav‐
iour is not desired use the option -mt=no.
The option -mt is equivalent to -mt=yes.
See also: -xnolib
-native
This option is a synonym for -xtarget=native.
-nofstore
(x86) Cancel -fstore on command line. Cancels forcing expres‐
sions to have the precision of the destination variable as
invoked by -fstore.
-nofstore is invoked by -fast. The normal default is -fstore.
-O Use default optimization level -xO3. However, -xO3 may be inap‐
propriate for programs that rely on all variables being automat‐
ically considered volatile. Typical programs that might have
this assumption are device drivers and older multi-threaded
applications that implement their own synchronization primi‐
tives. The work around is to compile with -xO2 instead of -O.
-On The same as -xOn.
-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.
filename must have an appropriate suffix. When used with -c,
filename specifies the target .o object file; with -G it speci‐
fies the target .so library 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.
-Qoption phase option[,option...]
Passes option to the compilation phase.
To pass multiple options, specify them in order as a comma-sepa‐
rated list. Options that are passed to components with -Qoption
can be reordered. Options that the driver recognizes are kept in
the correct order. Do not use -Qoption for options that the
driver already recognizes.
The following table shows the possible values for phase and the
corresponding argument for -Wc,arg
Qoption
phase W<c>
===== ====
fbe a Assembler: (fbe), (gas)
cg c C code generator: (cg)(SPARC)
driver d cc driver (1)
ir2hf h Intermediate code translator (ir2hf)(x86)
ld l Link editor (ld)
mcs m mcs
ipo O (Capital letter 'O') Interprocedural optimizer
postopt o Postoptimizer
cpp p Preprocessor (cpp)
ube u C code generator (ube), (x86)
acomp 0 (The number zero) Compiler acomp
iropt 2 Optimizer: (iropt)
See also -Wc,arg
-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 administra‐
tion. -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 can‐
not be specified with -g.
-traceback[={%none|common|signals_list}]
Issue a stack trace if a severe error occurs in execution.
The -traceback option causes the executable to issue a stack
trace to stderr, dump core, and exit if certain signals are gen‐
erated by the program. If multiple threads generate a signal, a
stack trace will only be produced for the first one.
To use traceback, add the -traceback option to the compiler com‐
mand line when linking. The option is also accepted at compile-
time but is ignored unless an executable binary is generated.
Using -traceback with -G to create a shared library is an error.
%none or none
disables traceback
common specifies that a stack trace should be issued if any of a
set of common signals is generated -- sigill, sigfpe,
sigbus, sigsegv, and sigabrt.
signals_list
specifies a comma-separated list of names of signals
which should generate a stack trace, in lower case. The
following signals (those that cause the generation of a
core file) can be caught:
sigquit, sigill, sigtrap, sigabrt, sigemt, sigfpe, sig‐
bus, sigsegv, sigsys, sigxcpu, sigxfsz
Any of these can be preceeded with no% to disable catch‐
ing the signal.
For example: -traceback=sigsegv,sigfpe will produce a
stack trace and core dump if either sigsegv or sigfpe is
generated.
If the option is not specified, the default is -traceback=%none
-traceback without any = sign implies -traceback=common
Note: If the core dump is not wanted, users may set the core‐
dumpsize limit to zero using:
% limit coredumpsize 0
The -traceback option has no effect on runtime performance.
-Uname Causes any definition of name to be undefined. This option
removes any initial definition of the preprocessor 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 information on the
standard error output.
-v Causes the compiler to perform more and stricter semantic
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 immediately preceding backslash
(\) character; the backslash is removed from the resulting argu‐
ment.) All -W arguments are passed after the regular command-
line arguments.
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)
l Link editor (ld)
m mcs
O (Capital letter 'O') Interprocedural optimizer
o Postoptimizer
p Preprocessor (cpp)
u C code generator (ube), (x86)
0 (The number zero) Compiler (acomp)
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 assem‐
bler, 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 standard. 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 compatibility
extensions. The compiler issues errors and warnings for
programs that use non-ISO C constructs. 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 com‐
patibility 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 warn‐
ings 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 exten‐
sions 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 -xtransi‐
tion option, the compiler issues warnings about the dif‐
ferent 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 constructs
that have differing behavior between Oracle Solaris Stu‐
dio 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 mes‐
sages about differing behavior can be eliminated through appro‐
priate coding; for example, use of casts can eliminate the inte‐
gral promotion change warnings.
-Xlinker arg
Passes arg to linker, ld(1)
Equivalent to -Wl,arg
-xaddr32[={yes|no}]
(x86/x64 only) The -xaddr32=yes compilation flag restricts the
resulting executable or shared object to a 32-bit address space.
An executable that is compiled in this manner results in the
creation of a process that is restricted to a 32-bit address
space.
When -xaddr32=no is specified a usual 64 bit binary is produced.
If the -xaddr32 option is not specified, -xaddr32=no is assumed.
If only -xaddr32 is specified -xaddr32=yes is assumed.
This option is only applicable to -m64 compilations and only on
Oracle Solaris platforms supporting SF1_SUNW_ADDR32 software
capability.
Since Linux kernel does not support addres space limitation this
option is not available on Linux. The -xaddr32 option is
ignored on Linux.
When linking, if a single object file was compiled with
-xaddr32=yes the whole output file is assumed to be compiled
with -xaddr32=yes.
A shared object that is restricted to a 32-bit address space
must be loaded by a process that executes within a restricted
32-bit mode address space.
For more information refer to the SF1_SUNW_ADDR32 software capa‐
bilities definition, described in the Linker and Libraries
Guide.
-xalias_level[=a]
where a must be one of:any, basic, weak, layout, strict, std,
strong. Use this flag to place the indicated 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 translation unit. If you do not supply -xalias_level, the
compiler 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 anaylysis.
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 contains 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 com‐
piled, 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 mem‐
bers 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. Conversely, 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 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=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 restrictions on the derefer‐
encing of pointers that are found in the 1999 ISO C standard.
Programs that properly 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 addition‐
ally, 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
-xanalyze={code|no}
Compile with this option to produce a static analysis of the
source code that can be viewed using the Code Analyzer.
When compiling with -xanalyze=code and linking in a separate
step, include -xanalyze=code also on the link step.
The default is -xanalyze=no.
See the Oracle Solaris Studio Code Analyzer documentation for
further information.
-xannotate[={yes|no}]
(Oracle Solaris) Instructs the compiler to create binaries that
can later be used by the optimization and observability tools
binopt(1), code-analyzer(1), discover(1), collect(1), and
uncover(1).
The default is -xannotate=yes. Specifying -xannotate without a
value is equivalent to -xannotate=yes.
For optimal use of the optimization and observability tools,
-xannotate=yes must be in effect at both compile and link time.
Compile and link with -xannotate=no to produce slightly smaller
binaries and libraries when optimization and observability tools
will not be used.
This option is not available on Linux systems.
-xarch=isa
Specifies the target architecture instruction set (ISA).
This option limits the code generated by the compiler to the
instructions of the specified instruction set architecture by
allowing only the specified set of instructions. This option
does not guarantee use of any target-specific instructions.
However, use of this option can affect the portability of a
binary program. See the Notes and Warnings sections at the end
of this entry.
Note: Use the -m64 or -m32 option to specify the intended memory
model, LP64 (64-bits) or ILP32 (32-bits) respectively. The
-xarch flag no longer indicates the memory model, except for
compatibility with previous releases, as indicated below.
Note: The compiler and linker will mark .o files and executables
that require a particular instruction set architecture (ISA) so
that the executable will not be loaded at runtime if the running
system does not support that particular ISA.
Code using _asm statements or inline templates (.il files) that
use architecture-specific instructions might require compiling
with the appropriate -xarch values to avoid compilation errors.
If you compile and link in separate steps, make sure you specify
the same value for -xarch in both steps.
Values for all platforms:
Value Meaning
generic This option uses the instruction set common to most
processors.
generic64 Compile for good performance on most 64-bit platforms.
(Oracle Solaris only)
This option is equivalent to
-m64 -xarch=generic
and is provided for compatibility with earlier
releases. Use -m64 to specify 64-bit compilation
instead of -xarch=generic64
native Compile for good performance on this system
The compiler chooses the appropriate setting for the
current system processor it is running on.
native64 Compile for good performance on this system (Oracle
Solaris only)
This option is equivalent to
-m64 -xarch=native and is provided for compatibility
with earlier releases.
Values specific to SPARC platforms:
sparc Compile for the SPARC-V9 ISA.
Compile for the V9 ISA, but without the Visual
Instruction Set (VIS), and without other implementa‐
tion-specific ISA extensions. This option enables the
compiler to generate code for good performance on the
V9 ISA.
sparcvis Compile for the SPARC-V9 ISA plus VIS.
Compile for SPARC-V9 plus the Visual Instruction Set
(VIS) version 1.0, and with UltraSPARC extensions.
This option enables the compiler to generate code for
good performance on the UltraSPARC architecture.
sparcvis2 Compile for the SPARC-V9 ISA with UltraSPARC III
extensions.
Enables the compiler to generate object code for the
UltraSPARC architecture, plus the Visual Instruction
Set (VIS) version 2.0, and with UltraSPARC III exten‐
sions.
sparcvis3 Compile for the SPARC-V9 ISA with UltraSPARC III and
VIS 3 extensions.
Enables the compiler to use instructions from the
SPARC-V9 instruction set, plus the UltraSPARC exten‐
sions, including the Visual Instruction Set (VIS) ver‐
sion 1.0, the UltraSPARC-III extensions, including the
Visual Instruction Set (VIS) version 2.0, the fused
multiply-add instructions, and the Visual Instruction
Set (VIS) version 3.0
sparcfmaf Compile for the sparcfmaf version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the
SPARC-V9 instruction set, plus the UltraSPARC exten‐
sions, including the Visual Instruction Set (VIS) ver‐
sion 1.0, the UltraSPARC-III extensions, including the
Visual Instruction Set (VIS) version 2.0, and the
SPARC64 VI extensions for floating-point multiply-add.
Note that you must use -xarch=sparcfmaf in conjunction
with -fma=fused and some optimization level to get the
compiler to attempt to find opportunities to use the
multiply-add instructions automatically.
sparc4 Compile for the SPARC4 version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the
SPARC-V9 instruction set, plus the UltraSPARC exten‐
sions, which includes VIS 1.0, the UltraSPARC-III
extensions, which includes VIS2.0, the fused floating-
point multiply-add instructions, VIS 3.0, and SPARC4
instructions.
sparcima Compile for the sparcima version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the
SPARC-V9 instruction set, plus the UltraSPARC exten‐
sions, including the Visual Instruction Set (VIS) ver‐
sion 1.0, the UltraSPARC-III extensions, including the
Visual Instruction Set (VIS) version 2.0, the SPARC64
VI extensions for floating-point multiply-add, and the
SPARC64 VII extensions for integer multiply-add.
v9 Is equivalent to -m64 -xarch=sparc
Legacy makefiles and scripts that use -xarch=v9 to
obtain the 64-bit memory model need only use -m64.
v9a Is equivalent to -m64 -xarch=sparcvis and is provided
for compatibility with earlier releases.
v9b Is equivalent to -m64 -xarch=sparcvis2 and is pro‐
vided for compatibility with earlier releases.
Notes:
o Object binary files (.o) compiled with generic, sparc, spar‐
cvis2, sparcvis3, sparcfmaf, and sparcima can be linked and
can execute together but can only run on a processor support‐
ing all the instruction sets linked.
For any particular choice, the generated executable could run
much more slowly on earlier architectures. Also, although
quad-precision floating-point instructions are available in
many of these instruction set architectures, the compiler does
not use these instructions in the code it generates.
Values specific to x86 platforms:
Value Meaning
pentium_pro
Limits the instruction set to the pentium_pro archi‐
tecture.
sse Adds the SSE instruction set to the pentium_pro
instruction set.
sse2 Supplements the pentium_pro and SSE instruction sets
with the SSE2 instruction set.
sse3 Supplements the pentium_pro, SSE, and SSE2 instruction
sets with the SSE3 instruction set.
ssse3 Supplements the pentium_pro, SSE, SSE2, and SSE3
instruction sets with the SSSE3 instruction set.
sse4_1 Supplements the pentium_pro, SSE, SSE2, SSE3, and
SSSE3 instruction sets with the SSE4.1 instruction
set.
sse4_2 Supplements the pentium_pro, SSE, SSE2, SSE3, SSSE3,
and SSE4.1 instruction sets with the SSE4.2 instruc‐
tion set.
amdsse4a Uses the AMD SSE4a Instruction set.
amd64 Is equivalent to -m64 -xarch=sse2 (Oracle Solaris
only)
Legacy makefiles and scripts that use -xarch=amd64 to
obtain the 64-bit memory model need only use -m64.
avx Adds the Advanced Vector Extensions to the Intel x86
instruction set.
aes Adds the Advanced Encryption Standard instruction set.
Note that the compiler does not generate AES instruc‐
tions automatically when -xarch=aes is specified
unless the source code includes .il inline code, _asm
statements, or assembler code that use AES instruc‐
tions, or references to AES intrinsic functions.
pentium_proa
Adds the AMD extensions (3DNow!, 3DNow! extensions,
and MMX extensions) to the pentium_pro architecture.
ssea Adds the AMD extensions (3DNow!, 3DNow! extensions,
and MMX extensions) to the 32-bit SSE architecture.
sse2a Adds the AMD extensions (3DNow!, 3DNow! extensions,
and MMX extensions) to the SSE2 architecture.
amd64a Is equivalent to -m64 -xarch=sse2a (Oracle Solaris
only)
Notes: If any part of a program is compiled or linked on an
x86 platform with -m64, then all parts of the program
must be compiled with one of these options as well.
For details on the various Intel instruction set
architectures (SSE, SSE2, SSE3, SSSE3, and so on)
refer to the Intel-64 and IA-32 Intel Architecture
Software Developer's Manual
Defaults:
If -xarch=isa is not specified, the defaults are:
-xarch=generic on SPARC platforms
-xarch=generic on x86/x64 platforms
Interactions:
Although this option can be used alone, it is part of the
expansion of the -xtarget option and can be used to override
the -xarch value that is set by a specific -xtarget option.
For example, -xtarget=ultra4 expands to
-xarch=sparcvis2 -xcache=64/32/4:8192/128/2 -xchip=ultra4
Warnings:
If this option is used with optimization, the appropriate
choice can provide good performance of the executable on the
specified architecture. An inappropriate choice, however,
might result in serious degradation of performance or in in a
binary program that is not executable on all intended target
platforms.
-xautopar
Turns on automatic parallelization for multiple processors. Does
dependence analysis (analyze loops for inter- iteration data
dependence) and loop restructuring. If optimization is not at
-xO3 or higher, optimization is raised to -xO3 and a warning is
issued.
Note that -xautopar does not accept OpenMP parallelization
directives.
Avoid -xautopar if you do your own thread management.
To get faster execution, this option requires a multiple proces‐
sor system. On a single-processor system, the resulting binary
usually runs slower.
Use the OMP_NUM_THREADS environment variable to specify the num‐
ber of threads to use when running a program automatically par‐
allelized by the -xautopar compiler option. If OMP_NUM_THREADS
is not set, the default number of threads used is 2. To use
more threads, set OMP_NUM_THREADS to a higher value. Set
OMP_NUM_THREADS to 1 to run with just one thread. In general,
set OMP_NUM_THREADS to the available number of virtual proces‐
sors on the running system, which can be determined by using the
Oracle Solaris psrinfo(1) command. See the OpenMP API User's
Guide for more information.
If you use -xautopar and compile and link in one step, then
linking automatically includes the microtasking library and the
threads-safe C runtime library. If you use -xautopar and compile
and link in separate steps, then you must link with cc-xautopar
as well. 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) This option is now obsolete and will be removed in a
future release of the compilers. See -xannotate.
Instructs the compiler to prepare the binary for later optimiza‐
tions, transformations and analysis (see binopt(1)). This option
may be used for building executables or shared objects. This
option must be used with optimization level -xO1 or higher to be
effective. There is a modest increase in size of the binary when
built with this option.
If you compile in separate steps, -xbinopt must appear on both
compile and link steps:
example% cc-c -xO1 -xbinopt=prepare a.c b.c
example% cc-o myprog -xbinopt=prepare a.o
If some source code is not available for compilation, this
option may still be used to compile the remainder of the code.
It should then be used in the link step that creates the final
binary. In such a situation, only the code compiled with this
option can be optimized, transformed or analyzed.
Compiling with -xbinopt=prepare and -g increases the size of the
executable by including debugging information. The default is
-xbinopt=off.
-xbuiltin[={%all|%default|%none}]
Use the -xbuiltin option to improve the optimization of code
that calls standard library functions. This option lets the
compiler substitute intrinsic functions or inline system func‐
tions where profitable for performance. See the er_src(1) man
page to learn how to read compiler commentary output to deter‐
mine which functions were substituted by the compiler.
With -xbuiltin=%all, substitutions can cause the setting of
errno to become unreliable. If your program depends on the value
of errno, avoid this option.
-xbuiltin=%default only inlines functions that do not set errno.
The value of errno is always correct at any optimization level,
and can be checked reliably. With -xbuiltin=%default at -xO3 or
lower, the compiler will determine which calls are profitable to
inline, and not inline others.
The -xbuiltin=%none option turns off all substitutions of
library functions.
If you do not specify -xbuiltin, the default is
-xbuiltin=%default when compiling with an optimization level
-xO1 and higher, and -xbuiltin=%none at -xO0. If you specify
-xbuiltin without an argument, the default is -xbuiltin=%all and
the compiler substitutes intrinsics or inlines standard library
functions much more aggressively.
Compiling with -fast adds -xbuiltin=%all.
Note: The -xbuiltin option only inlines global functions defined
in system header files, never static functions defined by the
user. User code that attempts to interpose on global functions
may result in undefined behavior.
-xCC When you specify -xc99=none and -xCC, the compiler accepts the
C++-style comments. In particular, the "//" can be used to indi‐
cate 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 following:
Value Meaning
[no_]lib Enable the 1999 C standard library semantics of
routines that appeared in both the 1990 and 1999
C standard. Optional no_ disables this feature.
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.
-xcache=c
Define cache properties for use by optimizer.
c must be one of the following:
o generic
o native
o s1/l1/a1[/t1]
o s1/l1/a1[/t1]:s2/l2/a2[/t2]
o s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
The si, li, ai, and ti, 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
ti The number of hardware threads sharing the cache at level i
The ti parameters are optional. A value of 1 is used if not
present.
This option specifies the cache properties that the optimizer
can use. It does not guarantee that any particular cache prop‐
erty is used.
Although this option can be used alone, it is part of the expan‐
sion of the -xtarget option; its primary use is to override a
value supplied by the -xtarget option.
The -xcache values are:
generic
Define the cache properties for good performance on most
platforms. This is the default.
native
Define the cache properties for good performance on this
host platform.
s1/l1/a1[/t1]
Define level 1 cache properties.
s1/l1/a1[/t1]:s2/l2/a2[/t2]
Define levels 1 and 2 cache properties.
s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
Define levels 1, 2, and 3 cache properties.
-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 substitute one of the following values for o:
o signed: Treat character constants and variables declared as
char as signed. This impacts the behavior of compiled code, it
does not affect the behavior of library routines.
o s: equivalent to signed.
o unsigned: Treat character constants and variables declared as
char as unsigned. This impacts the behavior of compiled code,
it does not affect the
behavior of library routines.
o u: equivalent to unsigned.
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 particular, the value of CHAR_MAX and CHAR_MIN,
as defined by limits.h, do not change when this option is speci‐
fied. Therefore, CHAR_MAX and CHAR_MIN no longer represent the
range of values encodable in a plain char.
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 Ora‐
cle 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 specified byte order.
You can substitute one of the following values for o:
o low: place the characters of a multi-character character-con‐
stant in low-to-high byte order.
o high: place the characters of a multi-character character-con‐
stant in high-to-low byte order.
o default: place the characters of a multi-character character-
constant in an order determined by the compilation mode
-X[a|c|s|t].
-xcheck[=n]
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 overflow.
no%stkovf Turns off stack-overflow checking.
init_local Initialize local variables. See the C User's
Guide description of this option for a list of
the predefined values used by the compiler to
initialize variables.
no%init_local Do not initialize local variables.
If you do not specify -xcheck, the compiler defaults to
-xcheck=%none. If you specify -xcheck without any arguments, the
compiler defaults to -xcheck=%all.
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 optimizer.
c must be one of the values listed below.
Although this option can be used alone, it is part of the expan‐
sion of the -xtarget option; its primary use is to override a
value supplied by the -xtarget option.
This option specifies timing properties by specifying the target
processor.
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 proces‐
sors.
sparc64vi
Optimize for the SPARC64 VI processor.
sparc64vii
Optimize for the SPARC64 VII processor.
ultra Optimize for the UltraSPARC(TM) processor.
ultra2 Optimize for the UltraSPARC II processor.
ultra2e
Optimize for the UltraSPARC IIe processor.
ultra2i
Optimize for the UltraSPARC IIi processor.
ultra3 Optimize for the UltraSPARC III processor.
ultra3cu
Optimize for the UltraSPARC IIIcu processor.
ultra3i
Optimize for the UltraSPARC IIIi processor.
ultra4 Optimize for the UltraSPARC IV processor.
ultra4plus
Optimize for the UltraSPARC IVplus processor.
ultraT1
Optimize for the UltraSPARC T1 processor.
ultraT2
Optimize for the UltraSPARC T2 processor.
ultraT2plus
Optimize for the UltraSPARC T2+ processor.
T3 Optimize for the SPARC T3 processor.
T4 Optimize for the SPARC T4 processor.
sparc64viiplus
Optimize for the SPARC64 VII plus processor.
The -xchip values for x86 platforms are:
generic
Optimize for most x86 platforms.
native Optimize for this host processor.
core2 Optimize for the Intel Core2 processor.
nehalem
Optimize for the Intel Nehalem processor.
opteron
Optimize for the AMD Opteron processor.
penryn Optimize for the Intel Penryn processor.
pentium
Optimize for the Intel Pentium architecture.
pentium_pro
Optimize for the Intel Pentium Pro architecture.
pentium3
Optimize for the Intel Pentium 3 style processor
pentium4
Optimize for the Intel Pentium 4 style processor
sandybridge
Optimize for the Intel Sandy Bridge processor.
westmere
Optimize for the Intel Westmere processor.
amdfam10
Optimize for the AMD FAM10 processor
-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 -m64 -xcode=abs64, but these will
be inefficient. Shared objects built with -m64 xarch=v9
-xcode=abs32 or -m64 -xcode=abs44 will not work.
The values for -xcode are:
abs32 This is the default for 32-bit systems. Generates 32-bit
absolute addresses.
Code + data + bss size is limited to 2**32 bytes.
abs44 This is the default for 64-bit systems. Generates 44-bit
absolute addresses.
Code + data + bss size is limited to 2**44 bytes.
Available only on 64-bit architectures.
abs64 Generates 64-bit absolute addresses.
Available only on 64-bit architectures.
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 is -xcode=abs32 for 32-bit architectures. The
default is -xcode=abs44 for 64-bit architectures.
When building shared dynamic libraries, the default -xcode value
of abs44 (not abs32) will not work with 64-bit architectures.
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.
-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 handle 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 character code require‐
ments 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 -xde‐
bugformat=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 per‐
forms loop restructuring. Loop restructuring includes loop
interchange, loop fusion, scalar replacement, and elimination of
"dead" array assignments.
On SPARC, -xdepend is turned on for all optimization levels -xO3
and above, and is off for lower opt levels. Also, an explicit
setting of -xdepend overrides any implicit setting.
On x86, if optimization is not at -xO3 or higher, the compiler
raises the optimization to -xO3 and issues a warning.
If you do not specify -xdepend, the default is -xdepend=no which
means the compiler does not analyze loops for data dependencies.
If you specify -xdepend but do not specify an argument, the com‐
piler sets the option to -xdepend=yes which means the compiler
analyzes loops for data dependencies.
Dependency analysis is included in -xautopar. The dependency
analysis is done at compile time.
Dependency analysis may help on single-processor systems. How‐
ever, if you try -xdepend on single-processor systems, you
should not also specify -xautopar , otherwise the -xdepend opti‐
mization is done for multiple-processor systems.
See Also: -xprefetch_auto_type
-xdryrun
This option is a macro for -###.
-xdumpmacros[=value[,value...]]
Use this option when you want to see how macros are behaving in
your program. This option provides information such as macro
defines, undefines, and instances of usage. It prints output to
the standard error (stderr), based on the order macros are pro‐
cessed. The -xdumpmacros option is in effect until the end of
the file or until it is overridden by the dumpmacros or
end_dumpmacros pragma.
Values:
The prefix no% applied to a suboption disables that suboption.
Value Meaning
[no%]defs
Print all macro defines
[no%]undefs
Print all macro undefines
[no%]use
Print information about macros used
[no%]loc
Print location (path name and line number) also
for defs, undefs, and use
[no%]conds
Print use information for macros used in condi‐
tional directives
[no%]sys
Print all macros defines, undefines, and use
information for macros in system header files
%all Sets the option to -xdump‐
macros=defs,undefs,use,loc,conds,sys. A good way
to use this argument is in conjunction with the
[no%] form of the other arguments. For example,
-xdumpmacros=%all,no%sys would exclude system
header macros from the output but still provide
information for all other macros.
%none Do not print any macro information
The option values accumulate so specifying -xdumpmacros=sys
-xdumpmacros=undefs has the same effect as -xdump‐
macros=undefs,sys.
Note: The sub-options loc, conds, and sys are qualifiers for
defs, undefs and use options. By themselves, loc, conds, and sys
have no effect. For example, -xdumpmacros=loc,conds,sys has no
effect.
Defaults:
If you specify -xdumpmacros without any arguments, it means
-xdumpmacros=defs,undefs,sys. If you do not specify -xdump‐
macros, it defaults to -xdumpmacros=%none.
-xe Performs only syntax and semantic checking on the source file,
but does not produce any object or executable file.
-xF[=v]
The -xF option enables the optimal reordering of functions and
variables by the linker.
This option instructs the compiler to place functions and/or
data variables into separate section fragments, which enables
the linker, using directions in a mapfile specified by the
linker's -M option, to reorder these sections to optimize pro‐
gram performance. Generally, this optimization is only effective
when page fault time constitutes a significant fraction of pro‐
gram run time.
Reordering functions and variables for optimal performance
requires the following operations:
1. Compiling and linking with -xF.
2. Following the instructions in the Performance Analyzer manual
regarding how to generate a mapfile for functions or following
the instructions in the Linker and Libraries Guide regarding how
to generate a mapfile for data.
3. Relinking with the new mapfile by using the linker's -M
option.
4. Re-executing under the Analyzer to verify improvement.
v can be one of the following values. Prefix no% disables the
suboption.
Value Meaning
[no%]func Fragment functions into separate sections.
[no%]gbldata 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), ld(1)
-xhelp=flags
displays a summary of the compiler options.
-xhwcprof[={enable|disable}]
(SPARC) Use the -xhwcprof option to enable compiler support for
dataspace profiling.
When -xhwcprof is enabled, the compiler generates information
that helps tools associate profiled load and store instructions
with the data-types and structure members (in conjunction with
symbolic information produced with -g) to which they refer. It
associates profile data with the data space of the target,
rather than the instruction space, and provides insight into
behavior that is not easily obtained from only instruction pro‐
filing.
You can compile a specified set of object files with -xhwcprof
however, -xhwcprof is most useful when applied to all object
files in the application. This will provide coverage to identify
and correlate all memory references distributed in the applica‐
tion's object files.
If you are compiling and linking in separate steps, use
-xhwcprof at link time as well. Future extensions to -xhwcprof
may require its use at link time. For a complete list of com‐
piler options that must be specified at both compile time and at
link time, see the C User's Guide.
An instance of -xhwcprof=enable or -xhwcprof=disable overrides
all previous instances of -xhwcprof in the same command line.
-xhwcprof is disabled by default. Specifying -xhwcprof without
any arguments is the equivalent to -xhwcprof=enable.
-xhwcprof requires that optimization be turned on and that the
debug data format be set to dwarf (-xdebugformat=dwarf).
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 profiling, 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 val‐
ues, or the value %auto. If you specify %nofunc_name, the com‐
piler 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 compiler attempts to
inline all functions except foo. For a specification of -xin‐
line=%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 references to functions
defined in the source file. You can restrict the set of func‐
tions 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 routines
in the source files are to be inlined. If you specify a list of
func_name and no%func_name without specifying %auto, the com‐
piler only attempts to inline those functions specified in the
list. If %auto is specified in the list of values with the -xin‐
line option at optimization level set at -xO4 or above, the com‐
piler attempts to inline all functions that are not explicitly
excluded by no%func_name.
A function is inlined if any of the following apply:
o Optimization is set at -xO3 or higher
o Inlining the funciton is judged to be profitable and safe
o The source for the function is in the file being compiled or
the function is in a file that was compiled with -xipo[=1|2].
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.
-xinstrument=[no%]datarace]
Specify this option to compile and instrument your program for
analysis by the Thread Analyzer. For more information on the
Thread Analyzer, see tha(1) for details.
You can then use the Performance Analzyer to run the instru‐
mented program with collect -r races to create a data-race-
detection experiment. You can run the instrumented code stand‐
alone but it runs more slowly.
You can specify -xinstrument=no%datarace to turn off preparation
of source code for the thread analyzer. This is the default.
It is illegal to specify -xinstrument without an argument.
If you compile and link in seperate steps, you must specify
-xinstrument=datarace in both the compilation and linking steps.
This option defines the preprocessor token __THA_NOTIFY. You can
specify #ifdef __THA_NOTIFY to guard calls to libtha(3) rou‐
tines.
This option also sets -g.
-xipo[=n]
The compiler performs partial-program optimizations by invoking
an interprocedural analysis pass. It performs optimizations
across all object files in the link step, and is not limited to
just the source files on the compile command. However, whole-
program optimizations performed with -xipo do not include assem‐
bly (.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 com‐
piled 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 perform optimizations
across files. However, this additional 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
optimizations performed. The object files created in the compi‐
lation steps have additional analysis information compiled
within them to permit crossfile optimizations to take place at
the link step.
n 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 interprocedural alias‐
ing analysis as well as optimization of memory allocation and
layout to improve cache performance.
Here are some important considerations for -xipo:
o It requires an optimization level of at least -xO4.
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 addi‐
tional 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 generate 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 opti‐
mizations as it works with the set of object files in the link
step. The compiler makes the following two assumptions for any
function (or subroutine) foo() defined in this set of object
files:
(1) foo() is not called explicitly by another routine that is
defined outside this set of object files at runtime.
(2) The calls to foo() from any routine in the set of object
files are not interposed upon by a different version of foo()
defined outside this set of object files.
Do not compile with -xipo=2 if assumption (1) is not true for
the given application.
Do not compile with either -xipo=1 or -xipo=2 if assumption (2)
is not true.
As an example, consider interposing on the function malloc()
with your own version and compiling with -xipo=2. Consequently,
all the functions in any library that reference malloc() that
are linked with your code have to be compiled with -xipo=2 also
and their object files need to participate in the link step.
Since this might not be possible for system libraries, do not
compile your version of malloc() with -xipo=2.
As another example, suppose that you build a shared library with
two external calls, foo() and bar() inside two different source
files. Furthermore, suppose that bar() calls foo(). If there is
a possibility that foo() could be interposed at runtime, then do
not compile the source file for foo() or for bar() with -xipo=1
or -xipo=2. Otherwise, foo() could be inlined into bar(), which
could cause incorrect results.
See also -xjobs and -xipo_archive
-xipo_archive[=a]
The -xipo_archive option enables the compiler to optimize object
files that are passed to the linker with object files that were
compiled with -xipo and that reside in the archive library (.a)
before producing an executable. Any object files contained in
the library that were optimized during the compilation are
replaced with their optimized version.
a is one of the following:
writeback
The compiler optimizes object files passed to the linker with
object files compiled with -xipo that reside in the archive
library (.a) before producing an executable. Any object files
contained in the library that were optimized during the compi‐
lation are replaced with an optimized version.
For parallel links that use a common set of archive
libraries,each link should create its own copy of archive
libraries to be optimized before linking.
readonly
The compiler optimizes object files passed to the linker with
object files compiled with -xipo that reside in the archive
library (.a) before producing an executable.
The option -xipo_archive=readonly enables cross-module inlining
and interprocedural data flow analysis of object files in an
archive library specified at link time. However, it does not
enable cross-module optimization of the archive library's code
except for code that has been inserted into other modules by
cross module inlining.
To apply cross-module optimization to code within an archive
library, -xipo_archive=writeback is required. Note that doing
so modifies the contents of the archive library from which the
code was extracted.
none
Default. There is no processing of archive files. The compiler
does not apply cross-module inlining or other cross-module
optimizations to object files compiled using -xipo and
extracted from an archive library at link time. To do that,
both -xipo and either -xipo_archive=readonly or -xipo_ar‐
chive=writeback must be specified at link time.
It is illegal to specify -xipo_archive without a flag.
-xivdep[=p]
Disable or set interpretation of ivdep pragmas
The ivdep pragmas tell a compiler to ignore some or all loop-
carried dependences on array references that it finds in a loop
for purposes of optimization. This enables a compiler to per‐
form various loop optimizations such as microvectorization, dis‐
tribution, software pipelining, etc., which would not be other‐
wise possible. It is used in cases where the user knows either
that the dependences do not matter or that they never occur in
practice.
The interpretation of #pragma ivdep directives depend upon the
value of the -xivdep option.
The following values for p are interpreted as follows:
loop - ignore assumed loop-carried vector dependences
loop_any - ignore all loop-carried vector dependences
back - ignore assumed backward loop-carried vector dependences
back_any - ignore all backward loop-carried vector dependences
none - do not ignore any dependences (disables ivdep pragmas)
These interpretations are provided for compatibility with other
vendor's interpretations of the ivdep pragma.
-xjobs=n
Compile with multiple processors.
Specify the -xjobs option to set how many processes the compiler
creates to complete its work. This option can reduce the build
time on a multi-cpu machine. Currently, -xjobs works only with
the -xipo option. When you specify -xjobs=n, the interprocedural
optimizer uses n as the maximum number of code generator
instances it can invoke to compile different files.
Generally, a safe value for n is 1.5 multiplied by the number of
available processors. Using a value that is many times the num‐
ber of available processors can degrade performance because of
context switching overheads among spawned jobs. Also, using a
very high number can exhaust the limits of system resources such
as swap space.
You must always specify -xjobs with a value. Otherwise an error
diagnostic is issued and compilation aborts.
Multiple instances of -xjobs on the command line override each
other until the rightmost instance is reached.
The following example compiles more quickly on a system with two
processors than the same command without the -xjobs option.
example% cc-xipo -xO4 -xjobs=3 t1.c t2.c t3.c
-xkeepframe[=[%all,%none,function_name,no%function_name]]
Prohibit stack related optimizations for the named functions.
%all - prohibit stack related optimizations for all the code
%none - allow stack related optimizations for all the code
If not specified on the command line, the compiler assumes
-xkeepframe=%none
If specified on the command line without a value, the compiler
assumes -xkeepframe=%all
This option is accumulative and can appear on the command line
multiple times. For example, -xkeepframe=%all -xkeep‐
frame=no%func1 indicates that the stack frame should be kept for
all functions except func1. Also, -xkeepframe overrides
-xregs=frameptr. For example, -xkeepframe=%all -xregs=frameptr
indicates that the stack should be kept for all functions, but
the optimizations for -xregs=frameptr would not be done.
-xldscope={v}
Changes the default linker scoping for the definition of extern
symbols. Changing the default can result in faster and safer
shared libraries because the implementation will be better hid‐
den.
v must be one of the following:
Value Meaning
global Global linker scoping is the least restrictive
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 symbols.
symbolic Symbolic linker scoping and is more restrictive
than global linker scoping. All references to the
symbol from within the dynamic module being
linked bind to the symbol defined within the mod‐
ule. Outside of the module, the symbol appears as
though it were global. This linker scoping cor‐
responds to the linker option -Bsymbolic.
hidden Hidden linker scoping is more restrictive than
symbolic and global linker scoping. All refer‐
ences within a dynamic module bind to a defini‐
tion within that module. The symbol will not be
visible outside of the module.
If you do not specify -xldscope, the compiler assumes -xld‐
scope=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 compile at -xO4 or higher in which case
inlining can happen automatically, if you use the inline speci‐
fier, or if you are using cross-file optimization.
For example, suppose library ABC has a default allocator func‐
tion that can be used by library clients, and is also used
internally in the library:
void* ABC_allocator(size_t size) { return malloc(size); }
If you build the library at -xO4 or higher, the compiler inlines
calls to ABC_allocator that occur in library components. If a
library client wants to replace ABC_allocator with a customized
version, the replacement will not occur in library components
that called ABC_allocator. The final program will include dif‐
ferent versions of the function.
Library functions declared with the __hidden or __symbolic spec‐
ifiers can be generated inline when building the library. They
are not supposed to be overridden by clients. For more informa‐
tion, see chapter 2 "C-Compiler Implementation Specific Informa‐
tion" in the C User's Guide.
Library functions declared with the __global specifier, should
not be declared inline, and should be protected from inlining by
use of the -xinline compiler option.
See Also
-xinline, -xO, ld(1).
-xlibmieee
Forces IEEE 754 style return values for math routines in excep‐
tional cases. In such cases, no exception message will be
printed, and errno should not be relied on.
-xlibmil
Inlines some library routines for faster execution. This option
selects the appropriate assembly language inline templates for
the floating-point option and platform for your system. -xlibmil
inlines a function regardless of any specification of the func‐
tion as part of the -xinline flag.
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 information.
-xlibmopt
Enables the compiler to use a library of optimized math rou‐
tines. You must use default rounding mode by specifying
-fround=nearest when you use this option.
The math routine library is optimized for performance and usu‐
ally generates faster code. The results may be slightly differ‐
ent from those produced by the normal math library. If so, they
usually differ in the last bit.
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 information.
The order on the command line for this library option is not
significant.
Interactions:
This option is implied by the -fast option.
See also:
-fast
-xnolibmopt
-xlic_lib=sunperf
(Obsolete) Use -library=sunperf to link with the Sun Performance
Library.
-xlicinfo
This option is silently ignored by the compiler.
-xlinkopt[=level]
(SPARC) Instructs the compiler to perform link-time optimiza‐
tions on relocatable object files.
The post-optimizer performs a number of advanced performance
optimizations on the binary object code at link-time. The value
level sets the level of optimizations performed, and must be 0,
1, or 2.
The optimization levels are:
0 The post-optimizer is disabled. (This is the default.)
1 Perform optimizations based on control flow analysis,
including instruction cache coloring and branch opti‐
mizations, at link time.
2 Perform additional data flow analysis, including dead-
code elimination and address computation simplifica‐
tion, at link time.
Specifying -xlinkopt without the level parameter implies
-xlinkopt=1.
These optimizations are performed at link time by analyzing the
object binary code. The object files are not rewritten but the
resulting executable code may differ from the original object
codes.
This option is most effective when you use it to compile the
whole program, and with profile feedback.
If you compile in separate steps, -xlinkopt must appear on both
compile and link steps:
example% cc-c -xlinkopt a.c b.c
example% cc-o myprog -xlinkopt=2 a.o b.o
For a complete list of compiler options that must be specified
at both compile time and at link time, see the C User's Guide.
Note that the level parameter is only used when the compiler is
linking. In the example above, the post-optimization level used
is 2 even though the object binaries were compiled with an
implied level of 1.
Do not use the -zcombreloc linker option when you compile with
-xlinkopt.
You must use -xlinkopt on at least some of the compilation com‐
mands for -xlinkopt to be useful at link time. The optimizer can
still perform some limited optimizations on object binaries not
compiled with -xlinkopt.
-xlinkopt optimizes code coming from static libraries that
appear on the compiler command line, but it skips and does not
optimize code coming from shared (dynamic) libraries that appear
on the command line. You can also use -xlinkopt when you build
shared libraries (compiling with -G ).
The link-time post-optimizer is most effective when you use it
with run-time profile feedback. Profiling reveals the most and
least used parts of the code and directs the optimizer to focus
its effort accordingly. This is particularly important with
large applications where optimal placement of code performed at
link time can reduce instruction cache misses. Typically, this
would be compiled as follows:
example% cc-o progt -xO5 -xprofile=collect:profdir file.c
example% progt
example% cc-o prog -xO5 -xprofile=use:profdir -xlinkopt file.c
For details on using profile feedback, see -xprofile.
Note that compiling with this option increases link time
slightly. Object file sizes also increase, but the size of the
executable remains the same. Compiling with -xlinkopt and -g
increases the size of the excutable by including debugging
information.
-xloopinfo
Shows which loops are parallelized and which are not. This
option is normally for use with the -xautopar option.
-xM Runs only the preprocessor on the named C programs, requesting
that it generate makefile dependencies and send the result to
the standard output (see make (1) for details about makefiles
and dependencies).
-xM1 Same as -xM except that -xM1 is not supported in -Xs mode nor
does -xM1 report dependencies for /usr/include header files. For
example:
example% more hello.c
#include <stdio.h>
main()
{
(void) printf ("hello\n");
}
example% cc-xM hello.c
hello.o: hello.c
hello.o: /usr/include/stdio.h
Compiling with -xM1 does not report header file dependencies:
example% cc-xM1 hello.c
hello.o: hello.c
-xMD Generates makefile dependencies like -xM but compilation contin‐
ues. -xMD generates an output file for the makefile-dependency
information derived from the -o output filename, if specified,
or the input source filename, replacing (or adding) the filename
suffix with .d . If you specify -xMD and -xMF, the preprocessor
writes all makefile dependency information to the file specified
with -xMF. Compiling with -xMD -xMF or -xMD -o filename with
more than one source file is not allowed and generates an error.
The dependency file is overwritten if it already exists.
-xMF filename
Use this option to specify a file for the makefile- dependency
output. There is no way to specify individual filenames for mul‐
tiple input files with -xMF on one command line. Compiling with
-xMD -xMF or -xMMD -xMF with more than one source file is not
allowed and generates an error. The dependency file is over‐
written if it already exists.
-xMMD Use this option to generate makefile dependencies excluding sys‐
tem header files. This is the same functionality as -xM1, but
compilation continues. -xMMD generates an output file for the
makefile-dependency information derived from the -o output file‐
name, if specified, or the input source filename, replacing (or
adding) the filename suffix with .d . If you specify -xMF, the
compiler uses the filename you provide instead. Compiling with
-xMMD -xMF or -xMMD -o filename with more than one source file
is not allowed and generates an error. The dependency file is
overwritten if it already exists.
-xMerge
Directs cc to merge the data segment with the text segment.
Data initialized in the object file produced by this compilation
is read-only and (unless linked with ld -N) is shared between
processes.
-xMerge -ztext -xprofile=collect should not be used together.
While -xMerge forces statically initialized data into read-only
storage, -ztext prohibits position-dependent symbol relocations
in read-only storage, and -xprofile=collect generates statically
initialized, position-dependent symbol relocations in writable
storage.
-xmaxopt[=v]
This command limits the level of pragma opt to the level speci‐
fied. The default value is -xmaxopt=off which causes pragma opt
to be ignored. If you specify -xmaxopt without supplying an
argument, that is the equivalent of specifying -xmaxopt=5.
If you specify both -xO and -xmaxopt, the optimization level set
with -xO must not exceed the -xmaxopt value.
-xmemalign=ab
(SPARC) Use the -xmemalign option to control the assumptions the
compiler makes about the alignment of data. By controlling the
code generated for potentially misaligned memory accesses and by
controlling program behavior in the event of a misaligned
access, you can more easily port your code to SPARC.
Specify the maximum assumed memory alignment and behavior of
misaligned data accesses. There must be a value for both a
(alignment) and b (behavior). a specifies the maximum assumed
memory alignment and b specifies the behavior for misaligned
memory accesses.
For memory accesses where the alignment is determinable at com‐
pile time, the compiler generates the appropriate load/store
instruction sequence for that alignment of data.
For memory accesses where the alignment cannot be determined at
compile time, the compiler must assume an alignment to generate
the needed load/store sequence.
For memory accesses where the alignment is determinable at com‐
pile time, the compiler generates the appropriate load/store
instruction sequence for that alignment of data.
For memory accesses where the alignment cannot be determined at
compile time, the compiler must assume an alignment to generate
the needed load/store sequence.
If actual data alignment at runtime is less than the specified
alignment, the misaligned access attempt (a memory read or
write) generates a trap. The two possible responses to the trap
are as follows:
o The OS converts the trap to a SIGBUS signal. If the program
does not catch the signal, the program aborts. Even if the pro‐
gram catches the signal, the misaligned access attempt will not
have succeeded.
o The OS handles the trap by interpreting the misaligned access
and returning control to the program as if the access had suc‐
ceeded normally.
Values
Accepted values for a are:
1 Assume at most 1 byte alignment.
2 Assume at most 2 byte alignment.
4 Assume at most 4 byte alignment.
8 Assume at most 8 byte alignment.
16 Assume at most 16 byte alignment.
Accepted values for b are:
i Interpret access and continue execution.
s Raise signal SIGBUS.
f For 64-bit SPARC programs (-m64) only. Raise sig‐
nal SIGBUS for alignments less than or equal to 4,
otherwise interpret access and continue execution.
For 32-bit programs, the f flag is equivalent to
i.
You must also specify -xmemalign whenever you want to link to an
object file that was compiled with the value of b set to either
i or f. For a complete list of compiler options that must be
specified at both compile time and at link time, see the C
User's Guide.
Defaults
The default for 64-bit SPARC programs (-m64) is -xmemalign=8s.
The default for 32-bit SPARC programs (-m32) is -xmemalign=8i.
If you do specify -xmemalign but do not provide a value, the
default is -xmemalign=1i for all platforms.
-xmodel=[a]
(x86) The -xmodel option determines the data address model for
shared objects on the Oracle Solaris x64 platforms and should
only be specified for the compilation of such objects.
This option is valid only when -m64 is also specified on 64-bit
enabled x64 processors.
a is one of the following:
small
This option generates code for the small model in which the
virtual address of code executed is known at link time and
all symbols are known to be located in the virtual
addresses in the range from 0 to 2^31 - 2^24 - 1.
kernel
Generates code for the kernel model in which all symbols
are defined to be in the range from 2^64 - 2^31 to 2^64 -
2^24.
medium
Generates code for the medium model in which no assumptions
are made about the range of symbolic references to data
sections. Size and address of the text section have the
same limits as the small code model. Applications with
large amounts of static data might require -xmodel=medium
when compiling with -m64.
This option is not cumulative so the compiler sets the model
value according to the rightmost instance of -xmodel on the com‐
mand-line.
If you do not specify -xmodel, the compiler assumes
-xmodel=small. Specifying -xmodel without an argument is an
error.
It is not necessary to compile all translation units with this
option. You can compile select files as long as you ensure the
object you are accessing is within reach.
Be aware that not all Linux system support the medium model.
-xnolib
Does not link any libraries by default; that is, no -l options
are passed to the linker ld. Normally, the cc driver passes -lc
to ld.
When you use -xnolib, you must pass all -l options explicitly
yourself.
-xnolibmil
Does not inline math library routines. Use -xnolibmil after the
-fast option:
cc-fast -xnolibmil ...
-xnolibmopt
Do not link with the optimized math routine library by turning
off any previously specified -xlibmopt options.
Use this option after the -fast option on the command line, as
in:
example% cc-fast -xnolibmopt ...
-xnorunpath
Do not build a runtime search path for shared libraries into the
executable.
Normally cc does not pass any -R path to the linker. There are a
few options that do pass -R path to the linker such as -xli‐
clib=sunperf and -xopenmp. The -xnorunpath option can be used
to prevent this.
This option is recommended for building executables that will be
shipped to customers who may have a different path for the
shared libraries that are used by the program.
-xOn Specifies optimization level (n). (Note the uppercase letter O,
followed by a digit 1, 2, 3, 4, or 5)
Generally, the higher the level of optimization with which a
program is compiled, the better runtime performance obtained.
However, higher optimization levels may result in increased com‐
pilation time and larger executable files.
There are five levels that you can use with -xOn. The actual
optimizations performed by the compiler at each level may change
with each compiler release. They are only summarized here.
If the optimizer runs out of memory, it attempts to proceed over
again at a lower level of optimization, resuming compilation of
subsequent routines at the original level.
Values:
-xO1 Do only the basic local optimizations.
-xO2 Do basic local and global optimization. This level usu‐
ally gives minimum code size.
-xO3 Adds global optimizations at the function level. In gen‐
eral, this level, and -xO4, usually result in the minimum
code size when used with the -xspace option.
-xO4 Adds automatic inlining of functions in the same file. In
general, -xO4 results in larger code unless combined with
-xspace.
See -inline to control which routines are inlined.
-xO5 Does the highest level of optimization, suitable only for
the small fraction of a program that uses the largest
fraction of computer time. Uses optimization algorithms
that take more compilation time or that do not have as
high a certainty of improving execution time. Optimiza‐
tion at this level is more likely to improve performance
if it is done with profile feedback. See -xprofile=col‐
lect|use.
The default is no optimization. However, this is only possible
if you do not specify an optimization level. If you specify an
optimization level, there is no option for turning optimization
off.
If you are trying to avoid setting an optimization level, be
sure not to specify any option that implies an optimization
level. For example, -fast is a macro option that sets optimiza‐
tion at -xO5. All other options that imply an optimization level
give a warning message that optimization has been set. The only
way to compile without any optimization is to delete all options
from the command line or make file that specify an optimization
level.
If you use -g and the optimization level is -xO3 or lower, the
compiler provides best-effort symbolic information with almost
full optimization. Tail-call optimization and back-end inlining
are disabled.
If you use -g and the optimization level is -xO4 or higher, the
compiler provides best-effort symbolic information with full
optimization.
Debugging with -g does not suppress -xOn, but -xOn limits -g in
certain ways. For example, the optimization options reduce the
utility of debugging so that you cannot display variables from
dbx, but you can still use the dbx where command to get a sym‐
bolic traceback. For more information, see Debugging a Program
With dbx.
If you specify both -xO and -xmaxopt, the optimization level set
with -xO must not exceed the -xmaxopt value.
See also:
-xldscope, -fast, -xprofile=p, csh(1) man page
Performance Analyzer discusses the effects of the different lev‐
els of optimization on the Analyzer's data.
-xopenmp[=i]
Use the -xopenmp option to enable explicit parallelization with
OpenMP directives.
Use the OMP_NUM_THREADS environment variable to specify the num‐
ber of threads to use when running an OpenMP. If
OMP_NUM_THREADS is not set, the default number of threads used
is 2. To use more threads, set OMP_NUM_THREADS to a higher
value. Set OMP_NUM_THREADS to 1 to run with just one thread.
In general, set OMP_NUM_THREADS to the available number of vir‐
tual processors on the running system, which can be determined
by using the Oracle Solaris psrinfo(1) command. See the OpenMP
API User's Guide for more information.
To enable nested parallelism, you must set the OMP_NESTED envi‐
ronment variable to TRUE. Nested parallelism is disabled by
default. See the Oracle Solaris Studio OpenMP API User's Guide
for details.
The following table details the -xopenmp values:
Value Meaning
parallel Enables recognition of OpenMP pragmas. The optimization
level under -xopenmp=parallel is -xO3. The compiler
changes the optimization level to -xO3 if necessary and
issues a warning. This flag also defines the preproces‐
sor token _OPENMP.
The _OPENMP token is defined to have the decimal value
yyyymm where yyyy and mm are the year and month desig‐
nations of the version of the OpenMP API that the
implementation supports. Refer to the Oracle Solaris
Studio OpenMP API User's Guide for the value of the
_OPENMP macro for a particular release.
noopt Enables recognition of OpenMP pragmas. The compiler
does not raise the optimization level if it is lower
than -O3. If you explicitly set the optimization lower
than -O3, as in cc-O2 -xopenmp=noopt, the compiler
issues an error. If you do not specify an optimization
level with -xopenmp=noopt, the OpenMP pragmas are rec‐
ognized, the program is parallelized accordingly, but
no optimization is done. This flag also defines the
preprocessor token _OPENMP.
none This flag is the default and does not enable recogni‐
tion of OpenMP pragmas, makes no change to the opti‐
mization level of your program, and does not predefine
any preprocessor tokens.
If you specify -xopenmp, but do not include an argument, the
compiler assumes -xopenmp=parallel. This default could change in
future releases. If you do not specify -xopenmp, the compiler
assumes -xopenmp=none.
If you are debugging an OpenMP program with dbx, compile with -g
-xopenmp=noopt so you can breakpoint within parallel regions and
display the contents of variables.
The default for -xopenmp might change in future releases. You
can avoid warning messages by explicitly specifying an appropri‐
ate optimization.
If you compile and link in seperate steps, specify -xopenmp in
both the compilation step and the link step. This is important
if you are building a shared object. The compiler which was used
to compile the executable must not be any older than the com‐
piler that built the .so with -xopenmp. This is especially
important when you compile libraries that contain OpenMP direc‐
tives.
Make sure that the latest patch of the OpenMP runtime library,
libmtsk.so, is installed on the system for best performance.
For information that is specific to the C implementation of
OpenMP, see the C User's Guide.
For a complete summary of the OpenMP Fortran 95, C, and C++
application program interface (API) for building multiprocessing
applications, see the OpenMP API User's Guide.
-xP Performs only syntax and semantic checking on the source file in
order to print prototypes for all K&R C functions. This option
does not produce any object or executable code.
-xpagesize=n
Set the preferred page size for the stack and the heap.
The n value must be one of the following:
On SPARC: /br
4k 8K 64K 512K 2M 4M 32M 256M 2G 16G or default.
On x86/x64 platforms:
4K 2M 4M 1G or default.
You must specify a valid page size for the target platform. If
you do not specify a valid pagesize, the request is silently
ignored at run-time.
Use the pagesize(1) Oracle Solaris command to determine the num‐
ber of bytes in a page. The Oracle Solaris operating system
offers no guarantee that the page size request will be honored.
You can use pmap(1) or meminfo(2) to determine page size of the
target platform.
The -xpagesize option has no effect unless you use it at compile
time and at link time. For a complete list of compiler options
that must be specified at both compile time and at link time,
see the C User's Guide.
If you specify -xpagesize=default, the operating system sets the
page size.
Compiling with this option has the same effect as setting the
LD_PRELOAD environment variable to mpss.so.1 with the equivalent
options, or running the Oracle Solaris command ppgsz(1) with the
equivalent options before running the program. See the Oracle
Solaris man pages for details.
This option is a macro for -xpagesize_heap and -xpagesize_stack.
These two options accept the same arguments as -xpagesize. You
can set them both with the same value by specifying -xpagesize=n
or you can specify them individually with different values.
-xpagesize_heap=n
Set the page size in memory for the heap.
The n value is the same as for -xpagesize.
You must specify a valid page size for the target platform. If
you do not specify a valid pagesize, the request is silently
ignored at run-time.
See -xpagesize for details.
-xpagesize_stack=n
Set the page size in memory for the stack.
The n value is the same as described for -xpagesize.
You must specify a valid page size for the Oracle Solaris oper‐
ating system on the target platform. If you do not specify a
valid pagesize, the request is silently ignored at run-time.
See -xpagesize for details.
-xpch=v
This compiler option activates the precompiled-header feature. v
can be auto, autofirst, collect:pch_filename, or use:pch_file‐
name. You can take advantage of this feature through the -xpch
and -xpchstop options in combination with the #pragma hdrstop
directive.
Use the -xpch option to create a precompiled-header file and
improve your compilation time. The precompiled-header file is
designed to reduce compile time for applications whose source
files share a common set of include files containing a large
amount of source code. A precompiled header works by collecting
information about a sequence of header files from one source
file, and then using that information when recompiling that
source file, and when compiling other source files that have the
same sequence of headers.
Creating a Precompiled-Header File Automatically
You can let the compiler generate the precompiled-header file
for you automatically. Choose between one of the following two
ways to do this. One way is for the compiler to create the pre‐
compiled-header file from the first include file it finds in the
source file. The other way is for the compiler to select from
the set of include files found in the source file starting with
the first include file and extending through a well-defined
point that determines which include file is the last one. Use
one of the following two flags to determine which method the
compiler uses to automatically generate a precompiled header:
-xpch=auto
The contents of the precompiled-header file is based on
the longest viable prefix (see the following section for
an explanation of how a viable prefix is identified) that
the compiler finds in the source file. This flag produces
a precompiled header file that consists of the largest
possible number of header files.
-xpch=autofirst
This flag produces a precompiled-header file that con‐
tains only the first header found in the source file.
Creating the Precompiled-Header File Manually
If you decide to create your precompiled-header file manually,
you must start by first using -xpch and specifying the collect
mode. The compilation command that specifies -xpch=collect must
only specify one source file. In the following example, the
-xpch option creates a precompiled-header file called
header.cpch based on the source file a.c:
cc -xpch=collect:myheader a.c
A valid precompiled-header filename always has the suffix .cpch.
When you specify pch_filename, you can add the suffix or let the
compiler add it for you. For example, if you specify cc
-xpch=collect:foo a.c, the precompiled-header file is called
foo.cpch.
How the Compiler Handles an Existing Precompiled-Header File
If the compiler cannot use the precompiled-header file, under
-xpch=auto and -xpch=autofirst, it will generate a new precom‐
piled-header file. If the compiler cannot use the precompiled-
header file under -xpch=use, a warning is issued and the compi‐
lation is done using the real headers.
Directing the Compiler to Use a Specific Precompiled-Header File
You can also direct the compiler to use a specific precompiled
header. Specify -xpch=use:pch_filename to do this. You can
specify any number of source files with the same sequence of
include files as the source file used to create the precompiled-
header file. For example, your command in use mode could look
like this:
cc -xpch=use:foo.cpch foo.c bar.c foobar.c
You should only use an existing precompiled-header file if the
following is true. If any of the following is not true, you
should recreate the precompiled-header file:
- The compiler that you are using to access the precompiled-
header file is the same as the compiler that created the precom‐
piled-header file. A precompiled-header file created by one ver‐
sion of the compiler may not be usable by another version of the
compiler.
- Except for the -xpch option, the compiler options you specify
with -xpch=use must match the options that were specified when
the precompiled-header file was created.
- The set of included headers you specify with -xpch=use is
identical to the set of headers that were specified when the
precompiled header was created.
- The contents of the included headers that you specify with
-xpch=use is identical to the contents of the included headers
that were specified when the precompiled header was created.
- The current directory (that is, the directory in which the
compilation is occurring and attempting to use a given precom‐
piled-header file) is the same as the directory in which the
precompiled-header file was created.
- The initial sequence of pre-processing directives, including
#include directives, in the file you specified with -xpch=col‐
lect are the same as the sequence of pre-processing directives
in the files you specify with -xpch=use.
The Viable Prefix
In order to share a precompiled-header file across multiple
source files, those source files must share a common set of
include files as their initial sequence of tokens. A token is a
keyword, name or punctuation mark. Comments and code that is
excluded by #if directives are not recognized by the compiler as
tokens. This initial sequence of tokens is known as the viable
prefix. In other words, the viable prefix is the top portion of
the source file that is common to all source files. The compiler
uses this viable prefix as the basis for creating a precompiled-
header file and thereby determining which header files from the
source are pre-compiled.
The viable prefix that the compiler finds during the current
compilation must match the viable prefix that it used to create
the precompiled-header file. In other words, the viable prefix
must be interpreted consistently by the compiler across all the
source files that use the same precompiled-header file.
The viable prefix consists of any of the following pre-processor
directives:
#include
#if/ifdef/ifndef/else/elif/endif
#define/undef
#ident
#pragma
Any of these may reference macros. The #else, #elif, and #endif
directives must match within the viable prefix. Comments are
ignored.
The compiler determines the end point of the viable prefix auto‐
matically when you specify -xpch=auto or -xpch=autofirst and is
defined as follows. For -xpch=collect or -xpch=use, the viable
prefix ends with a #pragma hdrstop.
- The first declaration/definition statement
- The first #line directive
- A #pragma hdrstop directive
- After the named include file if you specify -xpch=auto and
-xpchstop
- The first include file if you specify -xpch=autofirst
Note: An end point within a conditional statement generates a
warning and disables the automatic creation of a precompiled-
header file. Also, if you specify both the #pragma hdrstop and
the -xpchstop option, then the compiler uses the earlier of the
two stop points to terminate the viable prefix.
Within the viable prefix of each file that shares a precompiled-
header file, each corresponding #define and #undef directive
must reference the same symbol (in the case of #define, each one
must reference the same value). Their order of appearance within
each viable prefix must be the same as well. Each corresponding
pragma must also be the same and appear in the same order across
all the files sharing a precompiled header.
Screening Header Files for Problems
What makes a header file precompileable? A header file is pre‐
compileable when it is interpreted consistently across different
source files. Specifically, when it contains only complete dec‐
larations. That is, a declaration in any one file must stand
alone as a valid declaration. Incomplete type declarations, such
as struct S;, are valid declarations. The complete type declara‐
tion can appear in some other file. Consider these example
header files:
file a.h
struct S {
#include "x.h" /* not allowed */
};
file b.h
struct T; // ok, complete declaration
struct S {
int i;
[end of file, continued in another file] /* not allowed */
A header file that is incorporated into a precompiled-header
file must not violate the following. The results of compiling a
program that violate any of these constraints is undefined.
- The header file must not use __DATE__ and __TIME__.
- The header file must not contain #pragma hdrstop.
The Precompiled-Header File Cache
When the compiler creates a precompiled-header file automati‐
cally, the compiler writes it to the SunWS_cache directory. This
directory always resides in the location where the object file
is created. Updates to the file are preformed under a lock so
that it works properly under dmake.
If you need to force the compiler to rebuild automatically-gen‐
erated precompiled-header files, you can clear the precompiled-
header file cache-directory with the CCadmin tool. See the CCad‐
min(1) man page for more information.
Warnings
o Do not specify conflicting -xpch flags on the command line.
For example, specifying both -xpch=collect and -xpch=auto, or
specifying both -xpch=autofirst with -xpchstop=<include> gener‐
ates an error.
o If you specify -xpch=autofirst or you specify -xpch=auto with‐
out -xpchstop, any declaration, definition, or #line directive
that appears prior to the first include file, or appears prior
to the include file that is specified with -xpchstop for
-xpch=auto, generates a warning and disables the automatic gen‐
eration of the precompiled-header file.
o A #pragma hdrstop before the first include file under
-xpch=autofirst or -xpch=auto disables the automatic generation
of the precompiled-header file.
Precompiled-Header File Dependencies and make Files
The compiler generates dependency information for precompiled-
header files when you specify -xpch=collect. You need to create
the appropriate rules in your make files to take advantage of
these dependencies. Consider this sample make file:
.KEEP_STATE:
%.o : %.c shared.cpch
$(cc) -xpch=use:shared -xpchstop=foo.h -c $<
default : a.out
foo.o + shared.cpch : foo.c
$(cc) -xpch=collect:shared -xpchstop=foo.h foo.c -c
a.out : foo.o bar.o foobar.o
$(c) foo.o bar.o foobar.o
clean :
rm -f *.o shared.cpch .make.state a.out
These make rules, along with the dependencies generated by the
compiler, force a manually created precompiled-header file to be
recreated if any source file you used with -xpch=collect, or any
of the headers that are part of the precompiled-header file,
have changed. This prevents the use of an out of date precom‐
piled-header file.
For -xpch=auto or -xpch=autofirst, you do not have to create any
additional make rules in your makefiles.
See Also: -xpchstop
-xpchstop=[file|<include>]
where file is the last include file to be considered in creating
a precompiled-header file. Using -xpchstop on the command line
is equivalent to placing a hdrstop pragma (See the C User's
Guide) after the first include-directive that references file in
each of the source files that you specify with the cc command.
Use -xpchstop=<include> with -xpch=auto to create a precompiled-
header file that is based on header files up through and includ‐
ing <include>. This flag overrides the default -xpch=auto behav‐
ior of using all header files contained in the entire viable
prefix.
See Also: -xpch
-xpec[={yes|no}]
(Oracle Solaris) Generates a Portable Executable Code (PEC)
binary.
Generates a Portable Executable Code (PEC) binary. This option
puts the program intermediate representations in the object file
and the binary. This binary may be used later for tuning and
troubleshooting.
A binary that is built with -xpec is usually five to ten times
larger than if it is built without -xpec.
If you do not specify -xpec, the compiler sets it to -xpec=no.
If you specify -xpec, but do not supply a flag, the compiler
sets it to -xpec=yes.
-xpentium
(x86) Generates code for the Pentium processor.
-xpg Prepares the object code to collect data for profiling with
gprof(1). Invokes a runtime recording mechanism that produces a
gmon.out file (at normal termination).
Note: There is no advantage for -xprofile if you specify -xpg.
The two do not prepare or use data provided by the other.
Profiles are generated by using prof or gprof on 64 bit Oracle
Solaris platforms or just gprof on 32 bit Oracle Solaris plat‐
forms include approximate user CPU times. These times are
derived from PC sample data (see pcsample(2)) for routines in
the main executable and routines in shared libraries specified
as linker arguments when the executable is linked. Other shared
libraries (libraries opened after process startup using
dlopen(3DL)) are not profiled.
On 32 bit Oracle Solaris systems, profiles generated using
prof(1) are limited to routines in the executable. 32 bit shared
libraries can be profiled by linking the executable with -xpg
and using gprof(1).
Current Oracle Solaris releases do not include system libraries
compiled with -p. As a result, profiles collected on current
Oracle Solaris platforms do not include call counts for system
library routines.
Note: On x86 systems, -xpg is incompatible with -xregs=frameptr
because the gprof runtime library requires a valid frame pointer
to determine the return address of a profiled routine. Note
also that compiling with -fast on x86 systems will invoke
-xregs=frameptr. Compile with the following instead:
-fast -xregs=no%frameptr -xpg
If you specify -xpg at compile time, you must also specify it at
link time. See the C User's Guide for a complete list of options
that must be specified at both compile time and link time.
Note: Binaries compiled with -xpg for gprof profiling should not
be used with binopt(1), as they are incompatible and can result
in internal errors.
-xprefetch[=val[,val]]
Enables prefetch instructions on those architectures that sup‐
port prefetch. You must compile withoptimization level 3
orgreater with this option.
val must be one of the following:
auto Enable automatic generation of prefetch instruc‐
tions.
no%auto Disable automatic generation
explicit Enable explicit prefetch macros
Explicit prefetching should only be used under
special circumstances that are supported by mea‐
surements.
no%explicit Disable explicit prefetch macros
latx:factor (SPARC) You can only combine this option with
-xprefetch=auto. Adjust the compiler's assumed
prefetch-to-load and prefetch-to-store latencies
by the specified factor. The factor must be a
positive number of the form n.n .
The prefetch latency is the hardware delay
between the execution of a prefetch instruction
and the time the data being prefetched is avail‐
able in the cache.
The compiler assumes a prefetch latency value
when determining how far apart to place a
prefetch instruction and the load or store
instruction that uses the prefetched data.
Note — the assumed latency between a prefetch and
a load may not be the same as the assumed latency
between a prefetch and a store.
The compiler tunes the prefetch mechanism for
optimal performance across a wide range of
machines and applications. This tuning may not
always be optimal. For memory-intensive applica‐
tions, especially applications intended to run on
large multiprocessors, you may be able to obtain
better performance by increasing the prefetch
latency values. To increase the values, use a
factor that is greater than 1 (one). A value
between .5 and 2.0 will most likely provide the
maximum performance.
For applications with datasets that reside
entirely within the external cache, you may be
able to obtain better performance by decreasing
the prefetch latency values. To decrease the
values, use a factor that is less than one.
To use the latx:factor suboption, start with a
factor value near 1.0 and run performance tests
against the application. Then increase or
decrease the factor, as appropriate, and run the
performance tests again. Continue adjusting the
factor and running the performance tests until
you achieve optimum performance. When you
increase or decrease the factor in small steps,
you will see no performance difference for a few
steps, then a sudden difference, then it will
level off again.
yes Obsolete - do not use. Use
-xprefetch=auto,explicit instead.
no Obsolete - do not use. Use
-xprefetch=no%auto,no%explicit instead.
Defaults
If you do not specify -xprefetch, the default is now
-xprefetch=auto,explicit, not -xprefetch=yes. If you specify
-xprefetch without a value, it is also equivalent to
-xprefetch=auto,explicit. This change adversely affects applica‐
tions that have essentially non-linear memory access patterns.
To disable the change, specify -xprefetch=no%auto,no%explicit.
The sun_prefetch.h header file provides the macros that you can
use to specify explicit prefetch instruction. The prefetches
will be approximately at the place in the executable that corre‐
sponds to where the macros appear.
-xprefetch_auto_type=[a]
Where a is [no%]indirect_array_access.
Use this option to determine whether or not the compiler gener‐
ates indirect prefetches for the loops indicated by the option
-xprefetch_level in the same fashion the prefetches for direct
memory accesses are generated.
If you do not specify a setting for -xprefetch_auto_type, the
compiler sets it to -xprefetch_auto_type=no%indi‐
rect_array_access.
Options such as -xdepend, -xrestrict, and -xalias_level can
affect the aggressiveness of computing the indirect prefetch
candidates and therefore the aggressiveness of the automatic
indirect prefetch insertion due to better memory alias disam‐
biguation information.
-xprefetch_level=l
Use this option to control the aggressiveness of automatic
insertion of prefetch instructions as determined with
-xprefetch=auto.
l must be 1, 2, or 3.
Prefetch levels 2 and 3 may not be effective on older SPARC and
x86 platforms.
-xprefetch_level=1 enables automatic generation of prefetch
instructions. -xprefetch_level=2 enables additional generation
beyond level 1 and -xprefetch=3 enables additional generation
beyond level 2.
You must compile with optimization level 3 or greater and gener‐
ate code for a platform that supports prefetch.
The default is -xprefetch_level=1 when you specify
-xprefetch=auto.
-xprofile=p
Collects data for a profile or use a profile to optimize.
p must be collect[:profdir], use[:profdir], or tcov[:profdir]
This option causes execution frequency data to be collected and
saved during execution, then the data can be used in subsequent
runs to improve performance. Profile collection is safe for mul‐
tithreaded applications. That is, profiling a program that does
its own multitasking ( -mt ) produces accurate results. This
option is only valid when you specify -xO2 or greater level of
optimization.
If compilation and linking are performed in separate steps, the
same -xprofile option must appear on the compile as well as the
link step. See the C User's Guide for a complete list of
options that must be specified at both compile time and link
time.
collect[:profdir]
Collects and saves execution frequency for later use by the
optimizer with -xprofile=use. The compiler generates code
to measure statement execution-frequency.
-xMerge -ztext -xprofile=collect should not be used
together. While -xMerge forces statically initialized
data into read-only storage, -ztext prohibits position-
dependent symbol relocations in read-only storage, and
-xprofile=collect generates statically initialized, posi‐
tion-dependent symbol relocations in writable storage.
The profile directory name profdir, if specified, is the
pathname of the directory where profile data are to be
stored when a program or shared library containing the pro‐
filed object code is executed. If the pathname is not
absolute, it is interpreted relative to the current working
directory when the program is compiled with the option
-xprofile=use:profdir.
If no profile directory name is specified with -xpro‐
file=collect:prof_dir or -xprofile=tcov:prof_dir, profile
data are stored at run time in a directory named pro‐
gram.profile where program is the basename of the profiled
process's main program. In this case, the environment
variables SUN_PROFDATA and SUN_PROFDATA_DIR can be used to
control where the profile data are stored at run time. If
set, the profile data are written to the directory given by
$SUN_PROFDATA_DIR/$SUN_PROFDATA.
If a profile directory name is specified at compilation
time, SUN_PROFDATA_DIR and SUN_PROFDATA have no effect at
run time. These environment variables similarly control
the path and names of the profile data files written by
tcov, as described in the tcov(1) man page.
If these environment variables are not set, the profile
data is written to the directory profdir.profile in the
current directory, where profdir is the name of the exe‐
cutable or the name specified in the -xprofile=col‐
lect:profdir flag. -xprofile does not append .profile to
profdir if profdir already ends in .profile. If you run the
program several times, the execution frequency data accumu‐
lates in the profdir.profile directory; that is, output
from prior executions is not lost.
Example[1]: to collect and use profile data in the direc‐
tory myprof.profile located in the same directory where the
program is built:
cc -xprofile=collect:myprof.profile -xO5 prog.c -o prog
./prog
cc -xprofile=use:myprof.profile -xO5 prog.c -o prog
Example[2]: to collect profile data in the directory
/bench/myprof.profile and later use the collected profile
data in a feedback compilation at optimization level -xO5:
cc -xprofile=collect:/bench/myprof.profile -xO5 prog.c -o prog
...run prog from multiple locations...
cc -xprofile=use:/bench/myprof.profile -xO5 prog.c -o prog
If you are compiling and linking in separate steps, make
sure that any object files compiled with -xprofile=collect
are also linked with -xprofile=collect.
See also the ENVIRONMENT section of this man page below for
descriptions of environment variables that control asyn‐
chronous profile collections.
use[:profdir]
Uses execution frequency data collected from code compiled
with -xprofile=collect[:profdir] or -xpro‐
file=tcov[:profdir] to optimize for the work performed when
the profiled code was executed. profdir is the pathname of
a directory containing profile data collected by running a
program that was compiled with -xprofile=collect[:profdir]
or -xprofile=tcov[:profdir].
To generate data that can be used by both tcov and -xpro‐
file=use[:profdir], the same profile directory must be
specified at compilation time, using the option -xpro‐
file=tcov[:profdir]. To minimize confusion, specify
profdir as an absolute pathname.
The profdir is optional. If profdir is not specified, the
name of the executible binary is used. a.out is used if -o
is not specified. The compiler looks for profdir.pro‐
file/feedback, or a.out.profile/feedback without profdir
specified. For example:
cc -xprofile=collect -o myexe prog.c
cc -xprofile=use:myexe -xO5 -o myexe prog.c
The program is optimized by using the execution frequency
data previously generated and saved in the feedback files
written by a previous execution of the program compiled
with -xprofile=collect.
Except for the -xprofile option, the source files and other
compiler options must be exactly the same as those used for
the compilation that created the compiled program which in
turn generated the feedback file. The same version of the
compiler must be used for both the collect build and the
use build as well.
If compiled with -xprofile=collect:profdir, the same pro‐
file directory name profdir must be used in the optimizing
compilation: -xprofile=use:profdir.
See also -xprofile_ircache for speeding up compilation
between collect and use phases.
tcov[:profdir]
Instrument object files for basic block coverage analysis
using tcov(1).
If the optional :profdir argument is specified, the com‐
piler will create a profile directory at the specified
location. The data stored in the profile directory can be
used either by tcov(1) or by the compiler with -xpro‐
file=use:profdir .
If the optional :profdir argument is omitted, a profile
directory will be created when the profiled program is exe‐
cuted. The data stored in the profile directory can only
be used by tcov(1). The location of the profile directory
can be controlled using environment variables SUN_PROFDATA
and SUN_PROFDATA_DIR. See ENVIRONMENT below.
If the location specified by :profdir is not absolute, it
is interpreted relative to the current working directory
when the program is compiled.
If :profdir is specified for any object file, the same
location must be specified for all object files in the same
program. The directory whose location is specified by
:profdir must be accessible from all machines where the
profiled program is to be executed. The profile directory
should not be deleted until its contents are no longer
needed, because data stored there by the compiler cannot be
restored except by recompilation.
Example 1: if object files for one or more programs are
compiled with -xprofile=tcov:/test/profdata, a directory
named /test/profdata.profile will be created by the com‐
piler and used to store data describing the profiled object
files. The same directory will also be used at execution
time to store execution data associated with the profiled
object files.
Example 2: if a program named "myprog" is compiled with
-xprofile=tcov and executed in the directory /home/joe, the
directory /home/joe/myprog.profile will be created at run
time and used to store runtime profile data.
-xprofile_ircache[=path]
(SPARC) Use -xprofile_ircache[=path] with -xprofile=collect|use
to improve compilation time during the use phase by reusing com‐
pilation data saved from the collect phase.
With large programs, compilation time in the use phase can
improve significantly because the intermediate data is saved.
Note that the saved data could increase disk space requirements
considerably.
When you use -xprofile_ircache[=path], path overrides the loca‐
tion where the cached files are saved. By default, these files
are saved in the same directory as the object file. Specifying a
path is useful when the collect and use phases happen in two
different directories.
Here's a typical sequence of commands:
example% cc-xO5 -xprofile=collect -xprofile_ircache t1.c t2.c
example% a.out // run collects feedback data
example% cc-xO5 -xprofile=use -xprofile_ircache t1.c t2.c
-xprofile_pathmap=collect_prefix:use_prefix
(SPARC) Use the -xprofile_pathmap option when you are also spec‐
ifying the -xprofile=use command. Use -xprofile_pathmap when
both of the following are true and the compiler is unable to
find profile data for an object file that is compiled with
-xprofile=use.
o You are compiling the object file with -xprofile=use
in a directory that is different from the directory in which
the object file was previously compiled with -xprofile=col‐
lect.
o Your object files share a common basename in the profile
but are distinguished from each other by their location in
different directories.
The collect-prefix is the prefix of the UNIX pathname of a
directory tree in which object files were compiled using -xpro‐
file=collect.
The use-prefix is the prefix of the UNIX pathname of a directory
tree in which object files are to be compiled using -xpro‐
file=use.
If you specify multiple instances of -xprofile_pathmap, the com‐
piler processes them in the order of their occurrence. Each
use-prefix specified by an instance of -xprofile_pathmap is com‐
pared with the object file pathname until either a matching use-
prefix is identified or the last specified use-prefix is found
not to match the object file pathname.
-xreduction
Analyzes loops for reduction in automatic parallelization. This
option is valid only if -xautopar is also specified. Otherwise
the compiler issues a warning.
When a reduction recognition is enabled, the compiler paral‐
lelizes reductions such as dot products, maximum and minimum
finding. These reductions yield different roundoffs from those
obtained by unparallelized code.
-xregs=r[,r...]
Specify the usage of registers for the generated code.
r is a comma-separated list of one or more of the following sub‐
options: appl, float, frameptr.
Prefixing a suboption with no% disables that suboption.
Example: -xregs=appl,no%float
Note that -xregs suboptions are restricted to specific hardware
platforms.
appl (SPARC)
Allow the compiler to generate code using the applica‐
tion registers as scratch registers. The application
registers are:
g2, g3, g4 (on 32-bit platforms)
g2, g3 (on 64-bit platforms)
It is strongly recommended that all system software and
libraries be compiled using -xregs=no%appl. System
software (including shared libraries) must preserve
these registers' values for the application. Their use
is intended to be controlled by the compilation system
and must be consistent throughout the application.
In the SPARC ABI, these registers are described as
application registers. Using these registers can
increase performance because fewer load and store
instructions are needed. However, such use can conflict
with some old library programs written in assembly
code.
For more information on SPARC instruction sets, see
-xarch.
float (SPARC)
Allow the compiler to generate code by using the float‐
ing-point registers as scratch registers for integer
values. Use of floating-point values may use these reg‐
isters regardless of this option. To generate binary
code free of all references to floating point regis‐
ters, use -xregs=no%float and make sure your source
code does not in any way use floating point types.
frameptr (x86)
Allow the compiler to use the frame-pointer register
(%ebp on IA32, %rbp on x86 64-bit platforms) as a gen‐
eral-purpose register.
The default is -xregs=no%frameptr.
The C++ compiler ignores -xregs=frameptr unless excep‐
tions are also disabled with -features=no%except.
Note also that -xregs=frameptr is part of -fast, but is
ignored by the C++ compiler unless -features=no%except
is also specified.
With -xregs=frameptr the compiler is free to use the
frame-pointer register to improve program performance.
However, some features of the debugger and performance
measurement tools may be limited. Stack tracing, debug‐
gers, and performance analyzers cannot report on func‐
tions compiled with -xregs=frameptr.
Also, C++ calls to Posix pthread_cancel() will fail
trying to find cleanup handlers.
Mixed C, Fortran, and C++ code should not be compiled
with -xregs=frameptr if a C++ function, called directly
or indirectly from a C or Fortran function, can throw
an exception. If compiling such mixed source code with
-fast, add -xregs=no%frameptr after the -fast option on
the command line.
With more available registers on 64-bit platforms, com‐
piling with -xregs=frameptr has a better chance of
improving 32-bit code performance than 64-bit code.
Note: -xregs=frameptr is ignored and a warning is
issued by the compiler if you also specify -xpg.
Also, -xkeepframe overrides -xregs=frameptr.
The SPARC default is -xregs=appl,float.
The x86 default is -xregs=no%frameptr.
-xregs=frameptr is included in the expansion of -fast on x86.
It is strongly recommended that you compile code intended for
shared libraries that will link with applications, with
-xregs=no%appl,float. At the very least, the shared library
should explicitly document how it uses the application registers
so that applications linking with those libraries are aware of
these register assignments.
For example, an application using the registers in some global
sense (such as using a register to point to some critical data
structure) would need to know exactly how a library with code
compiled without -xregs=no%appl is using the application regis‐
ters in order to safely link with that library.
-xrestrict[=f]
Treats pointer-valued function parameters as restricted point‐
ers. f is %all, %none or a comma-separated list of one or more
function names. This command-line option can be used on its own,
but is best used with optimization of -xO3 or greater.
If a function list is specified with this option, pointer param‐
eters in the specified functions are treated as restricted; if
-xrestrict=%all is specified, all pointer parameters in the
entire C file are treated as restricted.
The default is %none. Specifying -xrestrict is equivalent to
specifying -xrestrict=%all.
See Also: 'Restricted Pointers' in the C User's Guide
-xs Allows debugging by dbx without object files.
This option causes all the debug information to be copied into
the executable. This has little impact on dbx performance or
the run-time performance of the program, but it does take more
disk space.
-xsafe=mem
(SPARC) Allow the compiler to assume that no memory protection
violations occur.
This option allows the compiler to use the non-faulting load
instruction in 64-bit SPARC architecture.
Because non-faulting loads do not cause a trap when a fault such
as address misalignment or segmentation violation occurs, you
should use this option only for programs in which such faults
cannot occur. Because few programs incur memory-based traps, you
can safely use this option for most programs. Do not use this
option for programs that explicitly depend on memory-based traps
to handle exceptional conditions.
This option takes effect only when used with optimization level
-xO5 and one of the following -xarch values: sparc, sparcvis,
sparcvis2, or sparcvis3 for both -m32 and -m64.
-xsfpconst
Represents unsuffixed floating-point constants as single preci‐
sion, instead of the default mode of double precision. Not valid
with -Xc.
-xspace
Does no optimizations that increase code size. Does not paral‐
lelize loops if it increases code size. Example: Does not
unroll loops.
-xstrconst
This option may be deprecated in a future release, use -fea‐
tures=[no%]conststrings instead.
The -xstrconst option inserts string literals into the read-only
data section of the text segment instead of the default data
segment. Duplicate strings will be eliminated and the remaining
copy shared amongst references in the code.
-xtarget=t
Specifies the target system for the instruction set and opti‐
mization.
t must be one of: native, native64, generic, generic64, or sys‐
tem-name. The -xtarget option permits a quick and easy specifi‐
cation of the -xarch, -xchip, and -xcache combinations that
occur on real systems. The only meaning of -xtarget is in its
expansion. See the -xdryrun explanation for details on how to
see the expansion of macro options such as -xtarget. -xtar‐
get=native is equivalent to -m32, -xarch=native, -xchip=native,
-xcache=native. -xtarget=native64 is equivalent to -m64,
-xarch=native64, -xchip=native64, -xcache=native. -xtar‐
get=generic is equivalent to -m32, -xarch=generic,
-xchip=generic, -xcache=generic. -xtarget=generic64 is equiva‐
lent to -m64, -xarch=generic64, -xchip=generic64,
-xcache=generic. The -fast macro option includes
-xtarger=native in its expansion. The -xtarget command itself
is a macro option which acts like a macro expansion on the com‐
mand line for the -xarch -xchip and -xcache options. Therefore,
you can override any of the expanded options by following -xtar‐
get with the desired option. Use the -xdryrun option to deter‐
mine the expansion of -xtarget=native on a running system.
Note: The expansion of -xtarget for a specific host platform
might not expand to the same -xarch, -xchip, or -xcache settings
as -xtarget=native when compiling on that platform. On SPARC
platforms: Compiling for 64-bit Oracle Solaris software on
64-bit SPARC architectures is indicated by the -m64 option. If
you specify -xtarget with a flag other than native64 or
generic64, you must also specify the -m64 option as follows:
-xtarget=ultra4 ... -m64
otherwise the compiler uses a 32-bit memory model.
Value Meaning
native Set the parameters for the best performance on the
host environment (assumes a 32-bit architecture).
native64 Set the parameters for the best performance on the
host environment (assumes a 64-bit architecture).
generic This is the default and sets the parameters for the
best performance over most 32-bit platform architec‐
tures.
generic64 Set the parameters for the best performance over most
64-bit platform architectures.
system-name
Get the best performance for the specified system.
Valid SPARC platform names are shown below.
Commonly used platform names:
ultra, ultra2, ultra2i, ultra1/140, ultra1/170,
ultra1/200, ultra2/1170, ultra2/1200, ultra2/1300,
ultra2/2170, ultra2/2200, ultra2/2300, ultra2e,
ultra2i, ultra3, ultra3cu, ultra3i, ultra4,
ultra4plus, ultraT1, ultraT2, ultraT2plus, T3, T4,
sparc64vi, sparc64vii, sparc64viiplus.
On x86 platforms
Compiling for 64-bit Oracle Solaris software on 64-bit
x86 platforms is indicated by the -m64 option. If you
specify -xtarget with a flag other than native64 or
generic64, you must also specify the -m64 option as
follows:
-xtarget=opteron ... -m64
otherwise the compiler uses a 32-bit memory model.
Value Meaning
o generic This is the default and yields the best performance
for generic architecture, chip and cache on most
32-bit systems.
o generic64
Gets the best performance for generic architecture,
chip and cache on most 64-bit systems.
o native The compiler generates code for the best performance
on the host system. This flag determines the avail‐
able architecture, chip, and cache properties of the
machine on which the compiler is running and assumes a
32-bit architecture.
o native64
Set the parameters for the best performance on the
host system. This flag determines the available
architecture, chip, and cache properties of the
machine on which the compiler is running and assumes a
64-bit architecture.
o processor-name
Generate code for the best performance on the indi‐
cated x86 processor-name. The following processors
are recognized:
barcelona, nehalem, opteron, pentium, pentium_pro,
pentium3, pentium4, penryn,
sandybridge, westmere, woodcrest The actual expansion
of an -xtarget suboption might change and improve with
each compiler release. Use the -dryrun option to see
the actual expansion:
cc-dryrun -xtarget=ultra4 |& grep ###
### command line files and options (expanded):
### -dryrun -xchip=ultra4 -xcache=64/32/4:8192/128/2 -xarch=sparcvis2
-xtemp= dir
Sets the directory the compiler uses for temporary files to dir.
No space is allowed within this option string. Without this
option, temporary files go into /tmp. -xtemp has precedence over
the TMPDIR environment variable.
-xthreadvar[=o]
Works in conjunction with the __thread declaration specifier to
take advantage of the compiler's thread-local storage facility.
After you declare the thread variables with the __thread speci‐
fier, use -xthreadvar to enable the use of thread-local storage
with position dependent code (non-PIC code) in dynamic (shared)
libraries. For more information on how to use __thread, see the
C User's Guide.
o must be the following:
Value Meaning
[no%]dynamic Compile variables for dynamic loading. Prefix no%
disables the option. Access to thread variables
is significantly faster when -xthread‐
var=no%dynamic but you cannot use the object file
within a dynamic library. That is, you can only
use the object file in an executable file.
If you do not specify -xthreadvar, the default used by the com‐
piler depends upon whether or not position-independent code is
enabled. If position-independent code is enabled, the option is
set to -xthreadvar=dynamic. If position- independent code is
disabled, the option is set to -xthreadvar=no%dynamic.
If you specify -xthreadvar but do not specify any arguments, the
option is set to -xthreadvar=dynamic.
If there is non-position-independent code within a dynamic
library, you must specify -xthreadvar.
The linker cannot support the thread-variable equivalent of non-
PIC code in dynamic libraries. Non-PIC thread variables are sig‐
nificantly faster, and hence should be the default for executa‐
bles.
If there is non-position-independent code within a dynamic
library, you must specify -xthreadvar.
Using thread variables on different versions of Oracle Solaris
software requires different options on the command line.
See Also: -xcode, -KPIC, -Kpic
-xtime Reports the time and resources used by each compilation.
-xtransition
Issues warnings for differences between K&R C and ISO C. The
-xtransition option issues messages in conjunction with the -Xa
and -Xt options. You can eliminate all warning messages about
differing behavior through appropriate coding.
-xtrigraphs[=[yes|no]]
Enables or disables recognition of trigraph sequences as defined
by the ISO C standard.
-xtrigraphs=yes enables recognition of trigraph sequences in the
source code.
-xtrigraphs=no disables recognition of trigraph sequences in the
source code.
Defaults:
If the -xtrigraphs option is not specified, -xtrigraphs=no is
assumed.
If only -xtrigraphs is specified -xtrigraphs=yes is assumed.
-xunroll=n
Specifies whether or not the compiler optimizes (unrolls) loops.
n is a positive integer. When n is 1, it is a command and the
compiler unrolls no loops. When n is greater than 1, -xunroll=n
allows the compiler to unroll loops n times.
-xustr={ascii_utf16_ushort|no}
Specify -xustr=ascii_utf16_ushort if you need to support an
internationalized application that uses ISO10646 UTF-16 string
literals. In other words, use this option if your code contains
string literals that you want the compiler to convert to UTF-16
strings in the object file. Without this option, the compiler
neither produces nor recognizes sixteen-bit character string
literals. This option enables recognition of the U"ASCII_string"
string literals as an array of unsigned short int. Since such
strings are not yet part of any standard, this option enables
recognition of non-standard C.
You can turn off compiler recognition of U"ASCII_string" string
literals by specifying -xustr=no. The rightmost instance of this
option on the command line overrides all previous instances.
The default is -xustr=no. If you specify -xustr without an argu‐
ment, the compiler won't accept it and instead issues a warning.
The default can change if the C or C++ standards define a mean‐
ing for the syntax.
It is not an error to specify -xustr=ascii_ustf16_ushort without
also specifying a U"ASCII_string" string literal.
Not all files have to be compiled with this option.
The following example shows a string literal in quotes that is
prepended by U. It also shows a command line that specifies
-xustr.
example% cat file.c
const unsigned short *foo = U"foo";
const unsigned short bar[] = U"bar";
const unsigned short *fun() { return U"fun"; }
example% cc -xustr=ascii_utf16_ushort file.c -c
-xvector[=a]
Enables automatic generation of calls to the vector library or
the generation of the SIMD (Single Instruction Multiple Data)
instructions on x86 processors that support SIMD. You must use
default rounding mode by specifying -fround=nearest when you use
this option.
The -xvector option requires optimization level -xO3 or greater.
Compilation will not proceed if the optimization level is
unspecified or lower than -xO3, and a message is issued.
a is the equivalent of the following. Prefix no% disables a sub‐
option.
[no%]lib
(SOLARIS Only) Enables the compiler to transform math
library calls within loops into single calls to the equiva‐
lent vector math routines when such transformations are
possible. This could result in a performance improvement
for loops with large loop counts. Use no%lib to disable
this option.
[no%]simd
(x86 only) Directs the compiler to use the native x86 SSE
SIMD instructions to improve performance of certain loops.
Streaming extensions are used on x86 by default at opti‐
mization level 3 and above where beneficial. Use no%simd
to disable this option.
The compiler will use SIMD only if streaming extensions
exist in the target architecture; that is, if target ISA is
at least SSE2. For example, you can specify -xtarget=wood‐
crest, -xarch=generic64, -xarch=sse2, -xarch=sse3, or -fast
on a modern platform to use it. If the target ISA has no
streaming extensions, the suboption will have no effect.
%none
Disables this option entirely.
yes This option is deprecated, specify -xvector=lib instead.
no This option is deprecated, specify -xvector=%none instead.
The default is -xvector=simd on x86 and -xvector=%none on SPARC
platforms. If you specify -xvector without a suboption, the
compiler assumes -xvector=simd,lib on x86 Oracle Solaris, -xvec‐
tor=lib on SPARC Oracle Solaris, and -xvector=simd on Linux
platforms.
This option overrides previous instances so -xvector=%none
undoes a previously specified -xvector=lib.
The compiler includes the libmvec libraries in the load step.
NOTE: -xvector=%none should be used when compiling Oracle
Solaris kernel code for x86 platforms.
If you compile and link with separate commands, be sure to use
the same option for both compilation and linking.
-xvis[={yes|no}]
(SPARC) Compile with -xvis=yes when including the <vis.h> header
to generate VIS instructions, or when using assembler inline
code (.il) that uses VIS instructions. The default is -xvis=no.
Specifying -xvis is equivalent to specifying -xvis=yes.
The VIS[tm] instruction set is an extension to the SPARC V9
instruction set. Even though the UltraSPARC processors are
64-bit, there are many cases, especially in multimedia applica‐
tions, when the data are limited to eight or 16 bits in size.
The VIS instructions can process four 16-bit data with one
instruction so they greatly improve the performance of applica‐
tions that handle new media such as imaging, linear algebra,
signal processing, audio, video and networking.
-xvpara
Issues warnings about potential parallel-programming related
problems that may cause incorrect results when using OpenMP. Use
with -xopenmp and OpenMP API directives.
The compiler issues warnings when it detects the following situ‐
ations:
o Loops are parallelized using MP directives when there are data
dependencies between different loop iterations
o OpenMP data-sharing attributes-clauses are problematic. For
example, declaring a variable "shared" whose accesses in an
OpenMP parallel region may cause data race, or declaring a vari‐
able "private" whose value in a parallel region is used after
the parallel region.
No warnings appear if all parallelization directives are pro‐
cessed without problems.
Example:
cc-xopenmp -xvpara any.c
Note: Oracle Solaris Studio compilers support OpenMP 3.1 API
parallelization. Consequently, the MP pragmas are deprecated.
See the OpenMP API User's Guide for information on migrating to
the OpenMP API.
-Yc, dir
Specifies a new directory dir for the location of component c.
c can consist of any of the characters representing tools listed
under the -W option.
If the location of a tool is being specified, then the new path
name for the tool will be dir/tool. If more than one -Y
option is applied to any one item, then the last occurrence
holds.
-YA, dir
Specifies a directory dir to search for all compiler components.
If a component is not found in dir, the search reverts to the
directory where the compiler is installed.
-YI, dir
Changes default directory searched for include files.
-YP, dir
Changes default directory for finding libraries files.
-YS, dir
Changes default directory for startup object files.
-Zll Creates the program database for lock_lint, but does not gener‐
ate executable code.
cc recognizes -a, -e, -r, -t, -u, and -z and passes these
options and their arguments to ld. cc also passes any unrecog‐
nized options to ld with a warning.
NOTES
errno
Certain floating-point math library routines will return error status
in the errno variable (defined in errno.h). With options -fast,
-xbuiltin, -xlibmieee, -xlibmil, -xlibmopt the compiler is free to
replace calls to floating point functions with equivalent optimized
code that does not set the errno variable. Further, -fast also defines
the macro __MATHERR_ERRNO_DONTCARE, which allows the compiler to
assume that math functions need not set errno. As a result, user code
that relies on the value of errno or a floating-point exception being
raised after a floating point function call could produce inconsistent
results.
One way around this problem is to avoid compiling such codes with
-fast.
However, if -fast optimization is required and the code depends on the
value of errno being set properly or an appropriate floating-point
exception being raised after floating-point library calls, you should
compile with the options
-xbuiltin=none -U__MATHERR_ERRNO_DONTCARE \
-xnolibmopt-xnolibmil
following -fast on the command line to inhibit the compiler from opti‐
mizing out such library calls and to to ensure that calls to math func‐
tions set errno as documented. New Shared Libraries
For Solaris release 10, new shared libraries libxprof.so.1, libx‐
prof_audit.so.1, and libtdf.so.1 must be installed in order to use the
-xprofile option. These libraries are pre-installed on the latest Ora‐
cle Solaris releases.
PRAGMAS
The following .nf #pragma does_not_read_global_data #pragma
does_not_write_global_data #pragma no_side_effect
See also the OpenMP API User's Guide for a list of supported OpenMP 2.5
directives.
SPARC Only:
Refer to the C User's Guide for more information on these pragmas.
ENVIRONMENT
The following is a list of environment variables that you can set along
with a brief description of their function.
LINT_OPTIONS
A default set of options to lint. LINT_OPTIONS is inter‐
preted by lint as though its value had been placed on the
command line, immediately following the name used to invoke
lint, as in:
lint $LINT_OPTIONS ... other-arguments ...
OMP_DYNAMIC
Enable or disable dynamic adjustment of the number of
threads.
OMP_NESTED
Enable or disable nested parallelism. See the OpenMP API
User's Guide.
OMP_NUM_THREADS
This variable tells the runtime system the maximum number of
threads the program can create. Default is 2. See the OpenMP
API User's Guide.
OMP_SCHEDULE
Set the run-time schedule type and chunk size. See the OpenMP
API User's Guide.
PARALLEL Same as OMP_NUM_THREADS.
STACKSIZE The executing program maintains a main memory stack for the
master thread and distinct stacks for each slave thread.
Stacks are temporary memory address spaces used to hold argu‐
ments and automatic variables over subprogram invocations.
The default size of the main stack is about eight megabytes.
Use the limit(1) command to display the current main stack
size as well as set it.
Each slave thread of a multithreaded program has its own
thread stack. This stack mimics the main stack of the master
thread but is unique to the thread. The thread's private
arrays and variables (local to the thread) are allocated on
the thread stack.
All slave threads have the same stack size, which is four
megabytes for 32-bit applications and eight megabytes for
64-bit applications by default. The size is set with the
STACKSIZE environment variable.
Setting the thread stack size to a value larger than the
default may be necessary for some parallelized code.
The syntax of the STACKSIZE environment variable accepts a
keyword for denoting the slave thread stacksize: B for Bytes,
K for Kilobytes, 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.
Sometimes the compiler may generate a warning message that
indicates a bigger stack size is needed. However, it may not
be possible to know just how large to set it, except by trial
and error, especially if private/local arrays are involved.
If the stack size is too small for a thread to run, the pro‐
gram will abort with a segmentation fault.
TMPDIR cc normally creates temporary files in the directory tmp.
You may specify another directory by setting the environment
variable TMPDIR to your chosen directory. (If TMPDIR isn't a
valid directory, then cc will use tmp). The -xtemp option
has precedence over the TMPDIR environment variable.
SUNPRO_SB_INIT_FILE_NAME
Obsolete - the source browser functionality is no longer sup‐
ported.
SUN_PROFDATA=profdir
If set, store profile data collected from a program compiled
with -xprofile=collect in a directory named profdir in the
current working directory at the time that the program is
executed. If the optional argument :profdir was specified in
-xprofile=collect[:profdir] at compilation time, SUN_PROF‐
DATA as no effect.
SUN_PROFDATA_DIR=dirname If set, store profile data collected
from a program compiled with -xprofile=collect in a directory
whose UNIX dirname is dirname. If dirname is not absolute,
it is interpreted relative to the current working directory
at the time that the program is executed. If the optional
argument :profdir was specified in -xprofile=col‐
lect[:profdir] at compilation time, SUN_PROFDATA_DIR has no
effect.
SUNW_MP_THR_IDLE
Controls end-of-task status of each helper thread and can be
set to spin or sleep ns. The default is sleep. See the OpenMP
API User's Guide for details.
SUNW_MP_WARN
Set this environment variable to TRUE to print warning mes‐
sages from the OpenMP and other parallelization runtime-sys‐
tems. If you registered a function by using sunw_mp_regis‐
ter_warn() to handle warning messages, then SUNW_MP_WARN
prints no warning messages, even if you set it to TRUE. If
you did not register a function and set SUNW_MP_WARN to TRUE,
SUNW_MP_WARN prints the warning messages to stderr. If you do
not register a function and you do not set SUNW_MP_WARN, no
warning messages are issued. For more information on
sunw_mp_register_warn() see the C User's Guide.
SUN_PROFDATA_REPLACE={objfile,program,all}
The value of the environment variable SUN_PROFDATA_REPLACE
indicates the scope of profile data to be reset when a
changed version of an object file is detected at runtime.
Use SUN_PROFDATA_REPLACE to ensure that profile data are con‐
sistent with the profiled program within the specified unit
of program scope.
The values of SUN_PROFDATA_REPLACE and their meanings are as
follows:
objfile
reset profile data of changed object file
program
reset profile data of all object files in program con‐
taining changed object file
all reset entire contents of profile directory if any object
file has changed
The default setting of SUN_PROFDATA_REPLACE is SUN_PROF‐
DATA_REPLACE=objfile .
Example:
% setenv SUN_PROFDATA_REPLACE program (csh)
$ export SUN_PROFDATA_REPLACE=program (ksh)
With this setting, when a program containing a changed object
file is executed, all object files in the program will have
their profile data reset. Relevant options include -xOn and
-xipo=n.
SUN_PROFDATA_ASYNC_INTERVAL=async_interval
Set this environment variable to enable asynchronous profile
collection. In asynchronous profile collection, profile data
are collected from a running process at regular intervals
whose duration is specified in units of seconds.
SUN_PROFDATA_ASYNC_INTERVAL has no effect unless one of the
environment variables LD_AUDIT, LD_AUDIT_32, or LD_AUDIT_64
is set to /usr/lib/{,64}/libxprof_audit.so.1.
Asynchronous profile collection requires an MT-safe, mmap
based memory allocator, such as libumem(3) with mmap-based
allocation specified by setting UMEM_OPTIONS to backend=mmap.
Example: to enable asynchronous profile collection from a 64
bit process at 1 minute intervals,specify the following envi‐
ronment variables:
$ env LD_AUDIT_64=/usr/lib/64/libxprof_audit.so.1 \
SUN_PROFDATA_ASYNC_INTERVAL=60 UMEM_OPTIONS=backend=mmap \
64-bit-program [program-args]
SUN_PROFDATA_ASYNC_VERBOSE=verbose
If set nonzero, enables verbose messages from asynchronous
collector to stderr. SUN_PROFDATA_ASYNC_VERBOSE has no
effect unless asynchronous profile collection is enabled.
FILES
a.out executable output file
bb_link.o tcov support
file.a library of object files
file.c C source file
file.d tcov(1) test coverage input file
file.i C source file after preprocessing
file.il inline(1) expansion file
file.ll lock_lint database
file.o object file
file.profile The directory for data used by -xprofile
file.s assembler source file
file.so dynamic library
file.tcov output from tcov(1)
acomp compiler front end
cc compiler command line driver
cg code generator (SPARC)
crt1.o runtime startup code
crti.o runtime startup code
crtn.o runtime startup code
fbe assembler
gcrt1.o startup for profiling with gprof(1)
gmon.out default profile file for -xpg
ipo Interprocedural optimizer (SPARC)
ir2hf intermediate code translator (x86)
iropt global optimizer
libredblack.so bids support
mcrt1.o start-up for profiling with prof(1) and intro(3)
misalign.o misalign data support (SPARC)
mon.out default profile file for -p
postopt postoptimizer (SPARC)
ssbd Static synchronization bug detection (Oracle Solaris
Operating Environment)
stack_grow.o stack overflow checking (SPARC)
SunWS_cache The directory used to store data when the -xpch option
is used.
ube optimizer, code generator (x86)
ube_ipa Interprocedural analyzer (x86)
values-xa.o -Xa support
values-xc.o -Xc support
values-xpg4.o xpg4 support
values-xpg6.o SUSv3 support
values-xs.o -Xs support
values-xt.o -Xt support
xprof_fini.o Initialization and finalization handlers for programs
compiled with -xprofile=collect
SEE ALSOanalyzer(1), as(1), c89(1), c99(1), cflow(1), cscope(1), ctags(1),
ctrace(1), dbx(1), er_src(1), indent(1), inline(4), ld(1), lint(1),
lock_lint(1), prof(1), sunstudio(1), tmpnam(3S), version(1).
C User's Guide
OpenMP API User's Guide
The ISO/IEC 9899-1990 Programming Language - C standard,
The ISO/IEC 9899-1999 Programming Language - C standard,
4th Berkeley Distribution December 2011 0a
