svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
CC(1)
CC(1) User Commands CC(1)
NAME
CC - C++ compiler
SYNOPSIS
CC [-#] [-###] [-abiopt=[mangle5|mangle6]]
[-B{dynamic|static|symbolic}] [-c]
[-compat[={5|g}]] [+d] [-Dname[=def]] [-d{y|n}]
[-dalign] [-dryrun] [-E] [-erroff[=t[,t...]]]
[-errtags[=a]] [-errwarn[=t[,t...]]] [-fast]
[-features=a[,a...]] [-fexceptions|-fno-exceptions]
[-filt[=filter[,filter...]] [-flags]
[-fma[={none|fused}]] [-fno-strict-aliasing] [-fnonstd]
[-fns[={yes|no}]] [-fopenmp] [-fprecision=a]
[-fround=a] [-fsimple[=n]] [-fstore] [-fsrict-aliasing] [-ftrap=a[,a...]]
[-fvisibility=v[-G] [-g] [-g[n]] [-gz[=cmp-type]] [-H] [-h[ ]lname] [-help]
[-Ipathname] [-I-] [-i] [-include] [-inline]
[-instances=i] [-instlib=file] [-KPIC] [-Kpic]
[-keeptmp] [-Lpath] [-llib] [-libmieee] [-libmil]
[-library=lib[,lib...]] [-m32|-m64] [-mc] [-misalign]
[-mr[,string]] [-mt] [-native] [-noex] [-nofstore]
[-nolib] [-nolibmil] [-noqueue] [-norunpath] [-O[n]]
[-O[level]] [-o file] [+p] [-P] [-p] [-pedantic{=[yes|no]}]
[-pentium] [-pg] [-PIC] [-pic]
[-preserve_argvalues[=int|none]] [-pta]
[-ptipath] [-pto] [-ptv]
[{-Qoption|-qoption} phase [,option...]]
[{-Qproduce|-qproduce}type] [-qp] [-Rpath[:path...]]
[-S] [-s] [-shared] [-staticlib=l[,l...]] [-std=v]
[-sync_stdio=[yes|no]] [-temp=path]
[-template=a[,a...]] [-time] [-traceback[=list]]
[-Uname] [-unroll=n] [-V] [-v] [-verbose=a[,a...]]
[-Wc,arg] [+w] [+w2] [-w] [-Xlinker arg] [-Xm]
[-xaddr32[={yes|no}]] [-xalias_level[=n]]
[-xannotate[={yes|no}]] [-xar]
[-xarch=isa] [-xatomic=a] [-xautopar]
[-xbuiltin[={a}] [-xcache=c] [-xchar[=o]] [-xcheck[=n]]
[-xchip=c] [-xcode=v] [-xcompress={[no%]debug}] [-xcompress_format=cmp-type] [-xdebugformat=dwarf]
[-xdebuginfo=a[,a...]] [-xdepend[={yes|no}]]
[-xdumpmacros[=value[,value...]] [-xe] [-xF[=v]]
[-xglobalize[={yes|no}]] [-xhelp=flags]
[-xhwcprof[={enable|disable}]] [-xia]
[-xinline[=func_spec[,func_spec...]]
[-xinline_param=a[,a[,a]...]] [-xinline_report[=n]]
[-xinstrument=[no%]datarace] [-xipo[={0|1|2}]
[-xipo_archive[=a]] [-xipo_build=[yes|no]]
[-xivdep[=p]] [-xjobs=[n|auto]]
[-xkeep_unref[={[no%]funcs,[no%]vars}]]
[-xkeepframe[=p]] [-xlang=language[,language]]
[-xldscope=[v]] [-xlibmieee] [-xlibmil] [-xlibmopt]
[-xlinkopt[=level]]
[-xloopinfo] [-xM] [-xM1] [-xMD] [-xMF] [-xMMD]
[-xMerge] [-xmaxopt[=v]] [-xmemalign=ab] [-xmodel=[a]]
[-xnolib] [-xnolibmil] [-xnolibmopt] [-xOn]
[-xopenmp[=i]] [-xpagesize=n] [-xpagesize_heap=n]
[-xpagesize_stack=n]
[-xpatchpadding[={fix|patch|size}]] [-xpch=v]
[-xpchstop] [-xpec] [-xpg] [-xport64[=v]]
[-xprefetch[=a[,a]] [-xprefetch_auto_type=[a]
[-xprefetch_level[=l]] [-xprevise={yes|no}] [-xprofile=p]
[-xprofile_ircache[=path]]
[-xprofile_pathmap=collect_prefix:use_prefix]
[-xreduction] [-xregs=r[,r...]] [-xrestrict[=f]]
[-xs[={yes|no}]] [-xsafe=mem] [-xsecure_code_analysis{=[yes|no]]
[-xsegment_align=n] [-xspace]
[-xtarget=t] [-xtemp=path] [-xthreadvar[=o]]
[-xthroughput[={yes|no}]] [-xtime]
[-xtrigraphs[={yes|no}]] [-xunboundsym={yes|no}]
[-xunroll=n] [-xustr={ascii_utf16_ushort|no}]
[-xvector[=a]] [-xvis] [-xvpara] [-xwe] [-Yc,path]
[-z arg] [file] ...
DESCRIPTION
Oracle Developer Studio 12.6 C++ Compiler.
This man page details the options or flags for the Oracle Developer
Studio 12.6 C++ compiler.
Complete documentation for this release is available on the Oracle
Technical Network (OTN) Oracle Developer Studio website:
http://oracle.com/technetwork/server-storage/solarisstudio
The OTN website is a complete resource for Oracle Developer 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 Oracle Developer Studio suite, see What's New in the Oracle Devel‐
oper
Studio
12.6
Release.
A man page, by definition, is a quick reference. For more detailed in‐
formation on the C++ compiler and its options, see the Oracle
Developer Studio
12.6:
C++ User's Guide.
Compiling for 64-Bit Platforms
Use the -m32 and -m64 options to specify the data type model of the
target compilation, ILP32 or LP64 respectively.
The -xarch option no longer carries an implicit data type 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 each 32-bits wide. The LP64 model specifies that long and
pointer data types are each 64-bits wide and int is 32-bits wide. The
Oracle Solaris and Linux OS also support large files and large arrays
under the LP64 data type 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 ob‐
jects can only take place in an 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 sse2, sse2a, or sse3 and beyond
must be run only on platforms that provide these extensions and fea‐
tures.
With this release, the default instruction set and the meaning of
-xarch=generic has changed to sse2. Now, compiling without specifying a
target platform option results in an sse2 binary incompatible with
older Pentium III or earlier systems.
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 can also differ between Oracle Solaris and Linux be‐
cause 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 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 oc‐
curring without any explicit warning messages.
On Linux, however, there is no such verification check. Running binary
objects compiled by Oracle Developer Studio compilers on older hardware
platforms could result in runtime failures; on Linux it is the user's
responsibility to deploy these binaries on suitable hardware platforms.
This warning extends also to programs that employ .il inline assembly
language functions or __asm() assembler code that utilize SSE2, SSE2a,
and SSE3 (and beyond) instructions and extensions.
Overview of the C++ Compiler
CC converts C++ and assembly source files to object files, and links
object files and libraries into executable programs.
Programs that contain C++ objects must be linked with CC.
CC takes arguments ending in .c, .C, .cc, .cxx, .c++, .cpp, or .i to be
C++ source programs. Arguments ending in .s are presumed to be assembly
source files. Arguments ending in .o are presumed to be object files.
Files whose names do not end with the above suffixes are treated as ob‐
ject programs or libraries and are handed over to the link editor. Un‐
less -c, -S, -E, or -P is specified, these programs and libraries, to‐
gether with the results of any specified compilations or assemblies,
are linked in the order given to produce an output file named a.out.
You can specify a different name for the executable by using the -o op‐
tion.
If a single file is compiled and linked all at once, the intermediate
files are deleted.
Before you use the CC command, insert into your search path the name of
the directory in which you have chosen to install the C++ compilation
system. For instructions on setting your search path, see the csh(1) or
the sh(1) man page.
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 de‐
fault 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/lib/compilers/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 af‐
ter the options specified on the command line. These are the preproces‐
sor option -I, linker options -B, -L, -R, and -l, and all file argu‐
ments, such as source files, object files, archives, and shared ob‐
jects.
The following is an example of how a user-supplied default compiler op‐
tion 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.cc
The compiler command is now equivalent to:
CC -fast -xvpara -c -I/local/hdrs -L/local/libs -lliblocal \
tst.cc -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 di‐
agnose problems. Set the environment variable SPRO_DEFAULTS_PATH to an
absolute path rather than the current directory to avoid such problems.
The interface stability of the default options file is uncommitted. The
order of option processing is subject to change in a future release.
OPTIONS
Some C++ compiler options which affect binary compatibility have de‐
fault behavior that matches the platform where the compiler is running.
For the following operating systems, the default behavior for Data Type
Model, Compatibility Mode, Library Mode are listed:
Oracle Linux 6 and Oracle Linux 7:
-m64 -std=c++03 -library=stdcpp
Oracle Solaris 10 and Oracle Solaris 11
-m32 -std=sun03 -library=Cstd
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 re‐
leases. Use the indicated replacement option.
See ld(1) for linker 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.
In general, compiler options are processed from left to right (with the
exception that the -U options are processed after all -D options), al‐
lowing selective overriding of macro options (options that include
other options). This rule does not apply to linker options.
For a complete description of the C++ compiler options, including exam‐
ples, see the Oracle Developer Studio
12.6:
C++ User's Guide
CC accepts the following options.
-#
Turns on verbose mode, showing how command options expand. Shows
each component as it is invoked.
-###
Shows each component as it would be invoked, but does not actually
execute it. Also shows how command options would expand.
-abiopt=[mangle5|mangle6]
This option is allowed only in -compat=5 (or -std=sun03) mode. It
is an error in all other modes.
The mangle6 sub-option is allowed on all platforms. It selects cor‐
rect name mangling that might not be compatible with prior compiler
releases on Oracle Solaris SPARC and on Oracle Solaris x86 with the
-m32 option.
The mangle5 sub-option is allowed only on Oracle Solaris SPARC with
-m32 or -m64 and Oracle Solaris x86 only with -m32. It selects name
mangling compatible with prior compiler releases. It is the default
on Oracle Solaris SPARC and on Oracle Solaris x86 with the -m32 op‐
tion.
The name mangling performed in prior releases of Oracle Developer
Studio in -compat=5 mode had errors. Fixing the errors would have
created binary incompatibilities. The errors were found and cor‐
rected prior to Oracle Studio releases on x86/Solaris with -m64 and
on Oracle Linux, but remained on the other platforms.
-Bbinding
Specifies whether a library binding for linking is symbolic, dy‐
namic (shared), or static (nonshared).
-Bdynamic is the default. You can use the -B option several times
on a command line.
For more information on the -Bbinding option, see the ld(1) man
page and the Oracle Solaris documentation.
-Bdynamic directs the link editor to look for liblib.so files. Use
this option if you want shared library bindings for linking. If the
liblib.so files are not found, it looks for liblib.a files.
-Bstatic directs the link editor to look only for liblib.a files.
The .a suffix indicates that the file is static, that is, non‐
shared. Use this option if you want nonshared library bindings for
linking.
-Bsymbolic forces symbols to be resolved within a shared library if
possible, even when a symbol is already defined elsewhere. For an
explanation of -Bsymbolic, see the ld(1) man page.
This option and its arguments are passed to the linker, ld. If you
compile and link in separate steps and are using the -Bbinding op‐
tion, you must include the option in the link step.
Warning:
Never use -Bsymbolic with programs containing C++ code, use linker
scoping instead. See the Oracle
Developer Studio
12.6:
C++ User's Guide for more information on linker
scoping. See also the -xldscope option.
With -Bsymbolic, references in different modules can bind to dif‐
ferent copies of what is supposed to be one global object.
The exception mechanism relies on comparing addresses. If you have
two copies of something, their addresses won't compare equal, and
the exception mechanism can fail because the exception mechanism
relies on comparing what are supposed to be unique addresses.
-c
Compile and produce a .o file for each source file without linking.
You can explicitly name a single object file by using the -o op‐
tion. When the compiler produces object code for each or input
file, it always creates an object file in the current working di‐
rectory. If you suppress the linking step, you also suppress the
removal of the object files.
For example:
o CC -c x.cc generates the object file x.o.
o CC -c -o y.o x.cc generates the object file y.o.
Warnings:
When the compiler produces object code for an input file (for exam‐
ple, .cc, .c, or .i), the compiler always produces a .o file in the
working directory. If you suppress the linking step, the .o files
are not removed.
See also: -o filename
-compat={5|g}
Sets the compatibility mode of the compiler. The -compat option
must specify the mode, either 5 or g. The new -std option is pre‐
ferred and provides more choices.
The -compat=5 mode implements the language described by the
ANSI/ISO 1998 C++ standard as corrected in 2003. ("Compatibility
Mode", -compat=4, was removed in Oracle Solaris Studio 12.3.)
The -compat=g mode follows the same standard and provides compati‐
bility with the gcc/g++ compiler on all Oracle Solaris and Linux
platforms.
-compat=5
Selects the C++03 dialect, using the Sun ABI, compatible with
C++ 5.0 through 5.15. Sets the __SUNPRO_CC_COMPAT preprocessor
macro to 5). It is equivalent to -std=sun03.
-compat=g
Enables recognition of some g++ language extensions and causes
the compiler to generate code that is binary-compatible with
g++ on Oracle Solaris and Linux platforms. It is equivalent to
-std=c++03.
The gcc headers and libraries used are those provided with the
compiler, rather than the version of gcc installed on the sys‐
tem.
The binary compatibility extends only to shared (dynamic or
.so) libraries, not to individual .o files or archive (.a) li‐
braries.
Sets the __SUNPRO_CC_COMPAT preprocessor macro to 'G'.
Example 1, linking g++ shared library to Oracle Developer Stu‐
dio C++ main program
% g++ -shared -o libfoo.so -fpic a.cc b.cc c.cc
% CC -compat=g main.cc -L. -lfoo
Example 2, linking Oracle Developer Studio C++ shared library
to g++ main program
% CC -compat=g -G -o libfoo.so -Kpic a.cc b.cc c.cc
% g++ main.cc -L. -lfoo
Defaults:
The -compat and -std options have default values that depend on the
platform. They are intended to match C++ libraries bundled with the
operating system. See the defaults list at the beginning of the OP‐
TIONS section.
Interactions:
The -compat and -std options cannot appear on the same command
line.
See -features=a, -std=v, and -xnolib for additional information.
+d
Prevents the compiler from expanding C++ inline functions.
Under the C++ language rules, a C++ inline function is a function
for which one of the following statements is true.
o The function is defined using the inline keyword.
o The function is defined (not just declared) inside a
class definition.
o The function is a compiler-generated class member func‐
tion.
Under the C++ language rules, the compiler can choose whether actu‐
ally to inline a call to an inline function. The C++ compiler in‐
lines calls to an inline function unless:
o The function is too complex.
o The +d option is selected.
o The -g option is selected with no optimization option.
Interactions:
This option is automatically turned on when you specify -g, the de‐
bugging option, unless a -O or -xO optimization level is also spec‐
ified.
The -g0 debugging option does not turn on +d.
The +d option has no effect on the automatic inlining that is per‐
formed when you use -xO4 or -xO5.
-Dname[=def]
Defines a macro symbol name to the preprocessor. Doing so is equiv‐
alent to including a #define directive at the beginning of the
source. You can use multiple -D options.
The following values are predefined.
SPARC and x86 platforms:
__ARRAYNEW
__BUILTIN_VA_ARG_INCR
__DATE__
__FILE__
__LINE__
__STDC__ = 0
__SUNPRO_CC = 0x5150
__SUNPRO_CC_COMPAT = 5 or G
__TIME__
__cplusplus
__has_attribute
__sun
__unix
_BOOL if type bool is enabled (see "-features=[no%]bool")
_WCHAR_T
sun
unix
__SVR4 (Oracle Solaris)
__SVR4__ (Oracle Solaris)
__svr4__ (Oracle Solaris)
__SunOS_RELEASE (Oracle Solaris)
__SunOS_5_10 (Oracle Solaris)
__SunOS_5_11 (Oracle Solaris)
_LP64 (-m64)
__LP64__ (-m64)
Note: __has_attribute is a function-like macro.
A hex value 0xRRrrmm representing the Oracle Solaris release, where
RR.rr is the output of the sysinfo (SI_RELEASE) system call, or of
the uname -r command, with leading zeros added when
needed. The mm digits are reserved for possible future "micro" re‐
leases. All the digits are decimal. Example for Oracle Solaris 11,
which is SunOS 5.11: __SunOS_RELEASE, has the value, 0x051100 . The
value of __SunOS_RELEASE for an older Oracle Solaris release is al‐
ways less than the value for a later release. Example of use:
#if __SunOS_RELEASE >= 0x051100 // Solaris 11 or later.
SPARC only:
sparc
sparcv8
__SUN_PREFETCH = 1
__sparc
SPARC V9 only:
__sparcv9 (with -m64)
x86 only:
linux
__amd64 (with -m64)
__gnu__linux__
__linux
__linux__
__x86_64 (with -m64)
__i386__ (with -m32)
Note that __sun is only defined on Oracle Solaris platforms. Use
__SUNPRO_CC to determine if the compiler is the Oracle Developer
Studio CC compiler.
Defaults:
If you do not use [=def], name is defined as 1.
Interactions:
If +p is used, sun, unix, sparc and i386 are not defined.
-d{y|n}
Allows or disallows dynamic libraries for the entire executable.
-dy specifies dynamic linking, which is the default, in the link
editor.
-dn specifies static linking in the link editor.
This option and its arguments are passed to ld.
Interactions:
This option causes fatal errors if you use it in combination with
dynamic libraries. Most system libraries are only available as dy‐
namic libraries.
-dalign
(SPARC) (Obsolete) You should not use this option. Use -xmema‐
lign=8s instead. For a complete list of obsolete options, see the
Oracle Developer Studio
12.6:
C++ User's Guide.
This option is silently ignored on x86/x64 platforms.
-dryrun
Directs the CC driver to show, but not execute, the commands con‐
structed by the compilation driver.
-E
Directs the CC driver to only preprocess the C++ source files, and
to send the result to stdout (standard output). No compilation is
done; no .o files are generated.
This option causes preprocessor-type line number information to be
included in the output.
To compile the output of the -E option when the source code in‐
volves templates, you might need to use the -template=no%extdef op‐
tion with the -E option. If application code uses the "definitions
separate" template source code model, the output of the -E option
might still not compile. Refer to the C++ Users Guide chapters on
templates for more information.
-erroff[=t[,t...] ]
Suppresses compiler warning messages but has no effect on error
messages. This option applies to all warning messages whether or
not they have been designated by -errwarn to cause a non-zero exit
status.
Values:
The -erroff values are members of a comma-separated list that con‐
sists of one or more of the following:
tag Suppresses the warning message specified by this tag.
You can display the tag for a message by using the
-errtags=yes option.
no%tag Enables the warning message specified by this tag.
%all Suppresses all warning messages.
%none Enables all warning messages. This is the default.
Order is important; for example, %all,no%tag suppresses all warning
messages except tag.
Defaults:
The default is -erroff=%none. Specifying -erroff is equivalent to
specifying -erroff=%all.
Warnings:
Only warning messages from the C++ compiler that display a tag when
the -errtags option is used can be suppressed with the -erroff op‐
tion.
-errtags [ = a]
Displays the message tag for each warning message of the C++ com‐
piler that can be suppressed with the -erroff option or made a fa‐
tal 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 fa‐
tal with -errwarn.
Values and Defaults:
a can be either yes or no. The default is -errtags=no. Specifying
-errtags is equivalent to specifying -errtags=yes.
In previous C++ compilers, the -errtags option caused a tag to be
printed as part of the message for both warnings and errors. The
C++ compiler behavior is now the same as the C compiler, emitting
tags only for warning messages.
-errwarn [ = t[,t...]]
Use the -errwarn option to cause the C++ compiler to exit with a
failure status for the given warning messages.
Values:
t is a comma-separated list that consists of one or more of the
following: tag, no%tag, %all, %none. Order is important; for exam‐
ple %all,no%tag causes the C++ compiler to exit with a fatal status
if any warning except tag is issued.
The following table details the -errwarn values:
tag
Cause CC to exit with a fatal status if the message specified
by tag is issued as a warning message. Has no effect if tag in
not issued.
no%tag
Prevent CC from exiting with a fatal status if the message
specified by tag is issued only as a warning message. Has no
effect if tag is not issued. Use this option to revert a warn‐
ing 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 de‐
fault.
Defaults:
The default is -errwarn=%none. If you specify -errwarn alone, it is
equivalent to -errwarn=%all.
Warnings:
The warning messages generated by the C++ compiler change from re‐
lease to release as the compiler error checking improves and fea‐
tures are added. Code that compiles using -errwarn=%all without er‐
ror may not compile without error in the next release of the com‐
piler.
Only warning messages from the C++ compiler that display a tag when
the -errtags option is used can be specified with the -errwarn op‐
tion to cause the C++ compiler to exit with a failure status.
See Also: -erroff, -errtags
-fast
This option is a macro that you can effectively use as a starting
point for tuning an executable for maximum runtime performance. The
expansion of -fast can change from one release of the compiler to
the next and includes options that are target platform specific.
Use the -dryrun option to examine the expansion of -fast, and in‐
corporate the appropriate options of -fast into the ongoing process
of tuning the executable.
Modules that are compiled with -fast must also be linked with
-fast. For a complete list of compiler options that must be speci‐
fied at both compile time and at link time, see the Oracle Devel‐
oper Studio
12.6:
C++ User's Guide.
The expansion of -fast includes the -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.
This option provides near maximum performance for most applications
by expanding the following compilation options:
-fma=fused (SPARC, x86)
-fns (SPARC, x86)
-fsimple=2 (SPARC, x86)
-nofstore (x86)
-xbuiltin=%all (SPARC, x86)
-xdepend (SPARC, x86)
-xlibmil (SPARC, x86)
-xlibmopt (SPARC, x86)
-xmemalign (SPARC)
-xO5 (SPARC, x86)
-xregs=frameptr (x86)
-xtarget=native (SPARC, x86)
Note that this selection of component option flags is subject to
change with each release of the compiler. You can view an expansion
of the -fast options by running the command
CC -fast -xdryrun |& grep ###
For details on the options set by -fast, see the Oracle Developer
Studio
12.6:
C++ User's Guide.
Interactions:
You can override the values set by -fast by specifying different
values to the right of -fast on the command line. For example, al‐
though the optimization level set by -fast is -xO5, if you specify
-fast, -xO3, the optimization level becomes -xO3.
The -fast macro expands into compilation options that may affect
other specified options. For example, in the following command, the
expansion of the -fast macro includes -xtarget=native which reverts
-xarch to one of the 32-bit architecture options.
Incorrect:
example% CC -xarch=sparcvis3 -fast test.cc
Correct:
example% CC -fast -xarch=sparcvis3 test.cc
See the description for each option to determine possible interac‐
tions.
Warnings:
Code compiled with the -fast option is not portable. For example,
compiling code using the following command on an UltraSPARC(TM) III
system will generate a binary that will not execute on an Ultra‐
SPARC II system.
example% CC -fast test.cc
Do not use this option for programs that depend on IEEE standard
floating-point exception handling; different numerical results,
premature program termination, or unexpected SIGFPE signals might
occur.
The -fast option includes -fns -ftrap=%none; that is, this option
turns off all trapping.
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.
The expansion of the -fast option includes -D_MATHERR_ERRNO_DONT‐
CARE.
See also:
Numerical Computation Guide, ieee_sun(3M)
-features=a
Enables/disables various C++ language features.
The following table lists the -features sub-option keywords and
their meanings. The prefix no% applied to a sub-option disables
that sub-option.
%all
Deprecated. Do not use %all. See warning below.
%none
Deprecated. Do not use %none. See warning below.
[no%]altspell
Recognize alternative token spellings (for example, and for
&&). The default is altspell.
[no%]anachronisms
Allow anachronistic constructs. When disabled (that is -fea‐
ture=no%anachronisms), no anachronistic constructs are allowed.
The default is anachronisms.
[no%]bool
Allow the bool type and literals. When enabled, the macro _BOOL
= 1. When disabled, the macro is not de‐
fined. The default is bool.
[no%]conststrings
Put literal strings in read-only memory. The default is const‐
strings.
cplusplus_redef
Allow the normally pre-defined macro __cplusplus to be rede‐
fined by a -D option on the command line. Attempting to rede‐
fine __cplusplus with a #define directive in source code is not
allowed.
Example:
CC -features=cplusplus_redef -D__cplusplus=1 ...
The g++ compiler typically predefines the __cplusplus macro to
1, and source code might depend on this non-standard value.
(The standard value is 199711L for compilers implementing the
1998 C++ standard or the 2003 update. Future standards will re‐
quire a larger value for the macro.)
Do not use this option unless you need to redefine __cplusplus
to 1 in order to compile code intended for g++.
[no%]except
Allow C++ exceptions. When C++ exceptions are disabled (that
is, -features=no%except), a throw-specification on a function
is accepted but ignored; the compiler does not generate excep‐
tion code. Note that the keywords try, throw, and catch are al‐
ways reserved. The default is except.
explicit
Recognizes the keyword explicit. no%explicit is not allowed.
[no%]export
Recognize the keyword export. The default is export.
[no%]extensions
Allow non-standard code that is commonly accepted by other C++
compilers. See chapter 4 of the Oracle Developer
Studio
12.6:
C++ User's Guide for an explanation of
the invalid code that is accepted by the compiler when you use
the -features=extensions option. The default is -fea‐
tures=no%extensions.
[no%]iddollar
Allow $ as a non-initial identifier character. The default is
no%iddollar.
[no%]localfor
Use standard-conforming local-scope rules for the for state‐
ment. The default is localfor.
[no%]mergestrings
(SPARC) Causes the compiler to put string literals and other
suitable const or read-only data into a special section of the
binary where the linker removes duplicate strings.
The default is -features=no%mergestrings, and duplicate strings
are not removed.
-features=mergestrings is only effective when -features=const‐
strings is also in effect.
[no%]mutable
Recognize the keyword mutable. The default is mutable.
namespace
Recognize the keyword namespace. no%namespace is not allowed.
[no%]nestedaccess
Allow nested classes to access private members of the enclosing
class. The default is -features=nestedacces.
[no%]rvalueref
Allow binding a non-const reference to an rvalue or temporary.
The default is -features=no%rvalueref. The C++ compiler has
traditionally been lax in enforcing the rule that a non-const
reference cannot be bound to a temporary or rvalue. The C++
compiler accepts the invalid code by default. To restore the
old compiler behavior, use the option -features=rvalueref.
[no%]rtti
Issue runtime type identification (RTTI) data in the compiled
program. The default is -features=rtti. Specifying -fea‐
tures=no%rtti disables generation of RTTI data. RTTI data can
be large, so if you don't need RTTI, the program uses less data
space. Some C++ language features depend on RTTI and will not
work if no%rtti is in effect. The compiler issues error mes‐
sages if you use a feature that is disabled by no%rtti.
[no%]split_init
Put initializers for nonlocal static objects into individual
functions. When you use -features=no%split_init, the compiler
puts all the initializers in one function. Using -fea‐
tures=no%split_init minimizes code size at the possible expense
of compile time. The default is split_init.
[no%]strictdestorder
Follow the requirements specified by the C++ standard regarding
the order of the destruction of objects with static storage du‐
ration. The default is strictdestrorder.
[no%]tmplife
Clean up the temporary objects that are created by an expres‐
sion at the end of the full expression, as defined in the
ANSI/ISO C++ Standard. (When -features=no%tmplife is in effect,
most temporary objects are cleaned up at the end of their
block.) The default is tmplife.
[no%]tmplrefstatic
Allow function templates to refer to dependent static functions
or static function templates. The default is the standard con‐
formant no%tmplrefstatic.
[no%]transitions
Allow ARM language constructs that are problematic in standard
C++ and that may cause the program to behave differently than
expected or that may be rejected by future compilers. When you
use -features=no%transitions, the compiler issues warnings
about these constructs instead of error messages.
[no%]zla
Allow an array to be declared with a size of 0, which is other‐
wise not allowed in C++. For example,
struct S {
int a[0]; // allowed only with -features=zla
};
int b[0]; // allowed only with -features=zla
Interactions:
This option accumulates instead of overrides.
Use of the following is not compatible with the standard libraries
and headers:
o no%bool
o no%except
o no%mutable
no%bool is not compatible with any gcc compatibility compiler
modes: -compat=g or -std=[c++03|c++11|c++14].
Warnings:
Do not use -features=%all or -features=%none. These sub-options are
deprecated and might be removed in a future release. Results can be
unpredictable.
The behavior of a program might change when you use -features=tm‐
plife. Testing whether the program works both with and without the
-features=tmplife option is one way to test the program's portabil‐
ity.
-fexceptions|-fno-exceptions
-fexceptions is equivalent to -features=except.
-fno-exceptions is equivalent to -features=no%except (and thus to
-noex).
-filt[=filter[,filter...]]
Suppress the filtering that CC normally applies to linker error
messages.
The prefix no% applied to a sub-option disables that sub-option.
filter must be one of the following values:
[no%]errors
Show the C++ explanations of the linker error messages. The
suppression of the explanations is useful when the linker diag‐
nostics are provided directly to another tool.
[no%]names
Demangle the C++ mangled linker names.
[no%]returns
Demangle the return types of functions. Suppression of this de‐
mangling helps you to identify function names more quickly, but
note that in the case of co-variant returns, some functions
differ only in the return type.
[no%]stdlib
Simplify names from the standard library in both the linker and
compiler error messages. This makes it easier for you to recog‐
nize the name of standard-library functions.
%all
Equivalent to -filt=errors,names,returns,stdlib. This is the
default behavior.
%none
Equivalent to -filt=no%errors,no%names,no%returns,no%stdlib.
Defaults:
If you do not specify the -filt option, or if you specify -filt
without any values, then the compiler assumes -filt=er‐
rors,names,returns,stdlib.
Interactions:
[no%]returns has no effect when used with no%names. That is, the
following options are equivalent:
-filt=no%names
-filt=no%names,no%returns
-filt=no%names,returns
See also: c++filt(1).
-flags
Same as -xhelp=flags.
-fma[={none|fused}]
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 architecture requirement is -xarch=sparcfmaf on SPARC
and -xarch=avx2 on x86 to generate fused multiply-add instructions.
The compiler marks the binary program if fused multiply-add in‐
structions are generated in order to prevent the program from exe‐
cuting on platforms that do not support fused multiply-add instruc‐
tions. When the minimum architecture is not used, then -fma=fused
has no effect.
Fused multiply-add instructions eliminate the intermediate rounding
step between the multiply and add. Consequently, programs may pro‐
duce different results when compiled with -fma=fused although pre‐
cision will tend to increase rather than decrease.
-fno-strict-aliasing
-fno-strict-aliasing isequivalent to -xalias_level=any
-fnonstd
This is a macro that expands to -ftrap=common on x86, and -fns
-ftrap=common on SPARC.
See -fns and -ftrap=common as well as the Numerical Computation
Guide for more information.
-fns[={no|yes}]
For SPARC, this option causes the nonstandard floating-point mode
to be enabled when a program begins execution.
For x86, this option selects SSE flush-to-zero mode and, where
available, denormals-are-zero mode. This option causes subnormal
results to be flushed to zero on x86. Where available, this option
also causes subnormal operands to be treated as zero. This option
has no effect on traditional x86 floating-point operations that do
not utilize the SSE or SSE2 instruction set.
On some SPARC platforms, the nonstandard floating-point mode dis‐
ables "gradual underflow," causing tiny results to be flushed to
zero rather than to produce subnormal numbers. It also causes sub‐
normal operands to be silently replaced by zero.
On those SPARC platforms that do not support gradual underflow and
subnormal numbers in hardware, use of this option can significantly
improve the performance of some programs.
Optional use of =yes or =no provides a way of 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 float‐
ing point. -fns=no selects standard floating point.
Defaults:
If -fns is not specified, the nonstandard floating-point mode is
not enabled automatically. Standard IEEE 754 floating-point compu‐
tation takes place, that is, underflows are gradual.
If only -fns is specified -fns=yes is assumed.
Warnings:
When nonstandard mode is enabled, floating-point arithmetic may
produce results that do not conform to the requirements of the IEEE
754 standard.
On SPARC systems, this option is effective only if used when com‐
piling the main program.
If you compile one routine with -fns, then compile all routines of
the program with the -fns option; otherwise you can get unexpected
results.
-fopenmp
Same as -xopenmp=parallel.
-fprecision=a
(x86) Sets floating-point rounding precision mode. a must be one
of: single, double, extended.
The -fprecision flag sets the rounding precision mode bits in the
Floating Point Control Word. These bits control the precision to
which the results of basic arithmetic operations (add, subtract,
multiply, divide, and square root) are rounded.
The following table shows the meanings of the values of a.
single
Rounds to an IEEE single-precision value
double
Rounds to an IEEE double-precision value
extended
Rounds to the maximum precision available
When a is single or double, this flag causes the rounding precision
mode to be set to single or double precision, respectively, when a
program begins execution. When p is extended or the -fprecision
flag is not used, the rounding precision mode remains as the ex‐
tended precision.
The single precision rounding mode causes results to be rounded to
24 significant bits, and double precision rounding mode causes re‐
sults to be rounded to 53 significant bits. In the default extended
precision mode, results are rounded to 64 significant bits. This
mode controls only the precision to which results in registers are
rounded, and it does not affect the range. All results in register
are rounded using the full range of the extended double format. Re‐
sults that are stored in memory are rounded to both the range and
precision of the destination format.
The nominal precision of the float type is single. The nominal pre‐
cision of the long double type is extended.
Defaults:
When the -fprecision flag is not specified, the rounding precision
mode defaults to extended.
Warnings:
This option is effective only on x86 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). -fpre‐
cision is ignored on SPARC platforms.
-fround=a
Sets the IEEE rounding mode in effect at startup.
a must be one of: nearest, tozero, negative, posi‐
tive.
nearest
Rounds towards the nearest number and breaking ties to even
numbers.
tozero
Round-to-zero.
negative
Round-to-negative-infinity.
positive
Round-to-positive-infinity.
This option sets the IEEE 754 rounding mode that:
o Can be used by the compiler in evaluating constant ex‐
pressions.
o Is established at runtime during the program initializa‐
tion.
The meanings are the same as those for the ieee_flags function,
which may be used to change the mode at runtime.
Defaults:
When the -fround option is not specified, the rounding mode de‐
faults to -fround=nearest.
Warnings:
If you compile one routine with -fround=a, compile all routines of
the program with the same -fround=a option; otherwise, you can get
unexpected results. This option is effective only if used when com‐
piling 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]
Selects floating-point optimization preferences.
If n is present, it must be 0, 1 or 2.
The following table shows the -fsimple values.
0
Permits no simplifying assumptions. Preserves strict IEEE 754
conformance.
1
Allows conservative simplification. The resulting code does not
strictly conform to IEEE 754.
With -fsimple=1, the optimizer is not allowed to optimize com‐
pletely without regard to roundoff or exceptions. In particu‐
lar, a floating point computation cannot be replaced by one
that produces different results with rounding modes held con‐
stant at runtime.
With -fsimple=1, the optimizer can assume the following:
o IEEE 754 default rounding/trapping modes do not
change after process initialization.
o Computation producing no visible result other than
potential floating-point exceptions may be deleted.
o Computation with Infinity or NaNs as operands need
not propagate NaNs to their results. For example,
x*0 may be replaced by 0.
o Computations do not depend on sign of zero.
2
Includes all the functionality of -fsimple=1, and also enables
the use of SIMD instructions to compute reductions when -xvec‐
tor=simd is in effect.
Also permits aggressive floating point optimization that may
cause many programs to produce different numeric results due to
changes in rounding. For example, permits the optimizer to re‐
place 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=1y , and the values of y and z are known to have constant
values during execution of the loop.
-fsimple=2 allows fp-transformations which may introduce fp ex‐
ceptions.
Defaults:
If -fsimple is not designated, the compiler uses -fsimple=0.
If -fsimple is designated but no value is given for n, the compiler
uses -fsimple=1.
Warnings:
This option can break IEEE 754 conformance.
See Also:
Techniques for Optimizing Applications: High Performance
Computing written by Rajat Garg and Ilya Sharapov for
a more detailed explanation of how optimization can impact preci‐
sion. See also articles on performance and precision on the OTN Or‐
acle Developer Studio website: oracle.com/technetwork/server-stor‐
age/solarisstudio/
-fstore
(x86) Forces precision of floating-point expressions.
This option causes the compiler to convert the value of a floating-
point expression or function to the type on the left side of an as‐
signment - when that expression or function is assigned to a vari‐
able, or when that expression is cast to a shorter floating-point
type rather than leaving the value in a register.
To turn off this option, use the -nofstore option.
Warnings:
Due to roundoffs and truncation, the results may be different from
those that are generated from the register values.
-ftrap=a[,a...]
Sets the IEEE trapping mode in effect at startup but does not in‐
stall 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.
a must be one of the following values.
[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.
Note that the [no%] prefix 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%] prefix by itself does not ex‐
plicitly cause a particular trap to be disabled.
Defaults:
If you do not specify -ftrap, the compiler assumes -ftrap=%none.
Example: -ftrap=%all,no%inexact means to set all traps except inex‐
act.
Warnings:
If you compile one routine with -ftrap, compile all routines of the
program with the same -ftrap option; otherwise, you can get unex‐
pected results.
Use the -ftrap=inexact trap with caution, as it will result in the
trap being issued whenever a floating-point value cannot be repre‐
sented exactly. For example, the following statement may generate
this condition:
x = 1.0 / 3.0;
-fstrict-aliasing
-fstrict-aliasing is equivalent to -xalias_level=compatible
-fvisibility=v
The -fvisibility=v option is equivalent to the -xldscope option as
follows:
-fvisibility=default -fvisibility=default is equivalent to
-xldscope=global
-fvisibility=internal -fvisibility=internal is equivalent to
-xldsdope=hidden
-fvisibility=protected -fvisibility=protected is equivalent to
-xldscope=symbolic
-fvisibility=hidden -fvisibility=hidden is equivalent to
-xldscope=hidden
-G
Build a dynamic shared library instead of an executable file; see
the ld(1) man page and the Oracle Developer Studio
12.6:
C++ User's Guide All source files specified in the
command line are compiled with the -pic by default.
When building a shared library from files that involve templates
and were compiled with the -instances=extern option, any template
instances referenced by the .o files will be included from the tem‐
plate cache automatically.
If you are creating a shared object by specifying -G along with
other compiler options that must be specified at both compile time
and link time, make sure that those same options are also specified
at both compile time and link time when you link with the resulting
shared object.
When you create a shared object, all the object files that are com‐
piled for 64-bit SPARC architectures must also be compiled with an
explicit -xcode value as documented under the description of
-xcode.
The following options are passed to ld if -c is not specified: -dy,
-G, and -R.
Do not use ld -G to build shared libraries; use CC
-G. The CC driver automatically passes several options to ld that
are needed for C++.
When you use the -G option, the compiler does not pass any default
-l options to ld. If you want the shared library to have a depen‐
dency on another shared library, you must pass the necessary -l or
-library option on the command line. For example, if you want the
shared library to be dependent upon libCrun, you must pass -lCrun
or -library=Crun on the command line.
For more information, see the -shared option.
-g
See -g[n].
-g[n]
Instructs both the compiler and the linker to prepare the file or
program for debugging with dbx(1) or the performance analyzer(1).
The tasks include:
o Producing more detailed information in the symbol table
of the object files and the executable, depending on n.
o Producing some "helper functions," which the Debugger
can call to implement some of its features.
o Disabling the inline generation of functions, if no op‐
timization level is specified; that is, using this op‐
tion implies the +d option if no optimization level is
also specified. -g with any -O or -xO level does not
disable inlining.
o Disabling certain levels of optimization
If you use this option with -xO[level] (or its equivalent options,
such as -O), you will get inlining and limited debugging informa‐
tion. For more information, see the entry for -xO.
If you specify -gO and the optimization level is -xO3 or lower, the
compiler provides best-effort symbolic information with almost full
optimization. Tail-call optimization is disabled.
If you use this option and the optimization level is -xO4 or
higher, the compiler provides best effort symbolic information with
full optimization.
When you specify this option, the +d option is specified automati‐
cally unless -O or -xO are also specified.
To use the full capabilities of the Performance Analyzer, compile
with the -g option. While some performance analysis features do not
require -g, you must compile with -g to view annotated source, some
function level information, and compiler commentary messages. See
the analyzer(1) man page and the Performance
Analyzer manual for more information.
The commentary messages that are generated with -g describe the op‐
timizations and transformations that the compiler made while com‐
piling your program. Use the er_src(1) command to display the mes‐
sages which are interleaved with the source code.
If you compile and link your program in separate steps, then in‐
cluding the -g option in one step and excluding it from the other
step will not affect the correctness of the program, but it will
affect the ability to debug the program. Any module that is not
compiled with -g (or -g0), but is linked with -g (or -g0) will not
be prepared properly for debugging. Note that compiling the module
that contains the function main with the -g option (or the -g0 op‐
tion) is usually necessary for debugging.
-g is implemented as a macro which expands to various other, more
primitive, options. See -xdebuginfo for the details of the expan‐
sions.
Values:
-g
Produce standard debugging information.
-gnone
Do not produce any debugging information. This is the default.
-g1
Produce file and line number as well as simple parameter infor‐
mation that is considered crucial during post-mortem debugging.
-g2
Same as -g.
-g3
Produce additional debugging information, which currently con‐
sists only of macro definition information. This added informa‐
tion can result in an increase in the size of the debug infor‐
mation in the resulting .o and executable when compared to us‐
ing only -g.
-g0
Instructs the compiler to prepare the file or program for de‐
bugging, but not to disable inlining. This option is the same
as -g, except that +d is disabled and dbx cannot step into in‐
lined functions.
See also:
For more information, see the explanations for -xs and +d, as well
as the ld(1) manual page.
-gz[=cmp-type]
Equivalent of specifying -xcompress=debug -xcom‐
press_format=cmp-type.
-gz with no sub-option is equivalent to -gz=zlib.
-H
On the standard error output (stderr), prints, one per line, the
path name of each #include file contained in the current compila‐
tion.
-h[ ]lname
Assigns the name lname to the generated shared dynamic library.
This is a loader option that is passed to ld. In general, the name
after -h should be exactly the same as the one after -o. A space
between the -h and lname is optional.
The compile-time loader assigns the specified name to the shared
dynamic library you are creating. It records the name in the li‐
brary file as the intrinsic name of the library. If there is no
-hlname option, then no intrinsic name is recorded in the library
file.
Every executable file has a list of needed shared library files.
When the runtime linker links the library into an executable file,
the linker copies the intrinsic name from the library into that
list of needed shared library files. If there is no intrinsic name
of a shared library, then the linker copies the path of the shared
library file instead. This command line is an example:
% CC -G -o libx.so.1 -h libx.so.1 a.o b.o c.o
Interactions:
This option accumulates instead of overrides.
-help
This option is deprecated and will be removed in a future release.
Use -xhelp=flags instead.
-Ipathname
Adds pathname to the list of directories that are searched for
files with relative file names (those that do not begin with a
slash.)
The compiler searches for quote-included files (of the form #in‐
clude "foo.h") in this order:
1. In the directory containing the source
2. In the directories named with -I options, if any
3. In the include directories for compiler-provided C++
header files, ANSI C header files, and special-purpose
files
4. In usrinclude
The compiler searches for bracket-included files (of the form #in‐
clude <foo.h>) in this order:
1. In the directories named with -I options, if any
2. In the include directories for compiler-provided C++
header files, ANSI C header files, and special-purpose
files
3. In usrinclude
Note: If the spelling matches the name of a standard header file,
also refer to "Standard Header Implementation" in the Oracle Devel‐
oper Studio
12.6:
C++ User's Guide.
Interactions:
This option accumulates instead of overrides.
The -I- option allows you to override the default search rules.
If -library=no%Cstd is specified, then the compiler-provided Cstd
header files are not searched.
Note: If -ptipath is not used, the compiler looks for template
files in -Ipathname. It is recommended that you use -Ipathname in‐
stead of -ptipath.
Warnings:
Never specify the compiler installation area, /usr/include, /lib,
/usr/lib, as search directories.
-I-
Change the include-file search rules to the following:
o For include files of the form #include "foo.h", search
the directories in the following order:
1. The directories named with -I options (both before
and after -I-)
2. The directories for compiler-provided C++ header
files, ANSI C header files, and special-purpose
files.
3. The /usr/include directory.
o For include files of the form #include <foo.h>, search
the directories in the following order:
1. The directories named with the -I options that ap‐
pear after -I-.
2. The directories for compiler-provided C++ header
files, ANSI C header files, and special-purpose
files.
3. The /usr/include directory.
Warnings:
Never specify the compiler installation area, /usr/include, /lib,
/usr/lib, as search directories.
Only the first -I- in a command line causes the described behavior.
-i
Tells the linker, ld(1), to ignore any LD_LIBRARY_PATH or LD_LI‐
BRARY_PATH_64 setting.
-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 preproces‐
sor directive.
The first directory the compiler searches for filename is the cur‐
rent 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.
-inline
This option is deprecated and will be removed in a future release.
Use -xinline instead.
-instances=a
Controls the placement and linkage of template instances. The fol‐
lowing table shows the meanings of the values of a.
extern
Places all needed instances into the template repository within
comdat sections and gives them global linkage. (If an instance
in the repository is out of date, it is reinstantiated.)
Note: If you are compiling and linking in separate steps and
you specify -instance=extern for the compilation step, you must
also specify it for the link step.
explicit
Places explicitly instantiated instances into the current ob‐
ject file within comdat sections and gives them global linkage.
Does not generate any other needed instances.
global
Places all needed instances into the current object file within
comdat sections and gives them global linkage.
semiexplicit
Places explicitly instantiated instances and all instances
needed by the explicit instances into the current object file
within comdat sections and gives them global linkage.
static
-instances=static is deprecated. There is no longer any reason
to use -instances=static, because -instances=global now gives
you all the advantages of static without the disadvantages.
This option was provided in earlier compilers to overcome prob‐
lems that do not exist in this version of the compiler. Places
all needed instances into the current object file and gives
them static linkage.
Defaults:
If instances is not specified, -instances=global is assumed.
Warnings:
static and semiexplicit values may produce invalid results. See Or‐
acle Developer
Studio
12.6:
C++ User's Guide for more information.
-instlib=file
Use this option to inhibit the generation of a template instances
that are duplicated in a library, either static or shared, and the
current object. In general, if your program shares large numbers of
instances with libraries, try -instlib=file and see whether compi‐
lation time improves.
Values:
Use the file argument to specify the library that contains template
instances that could be generated by the current compilation. The
filename argument must contain a forward slash '/' character. For
paths relative to the current directory, use dot-slash './'.
Defaults:
The -instlib=file option has no default and is only used if you
specify it. This option can be specified multiple times and accumu‐
lates.
Example:
Assume that the libfoo.a and libbar.so libraries instantiate many
template instances that are shared with your source file a.cc.
Adding -instlib=file and specifying the libraries helps reduce com‐
pile time by avoiding the redundancy.
example% CC -c -instlib=./libfoo.a -instlib=./libbar.so a.cc
Interactions:
When you compile with -g, if the library specified with -in‐
stlib=file is not compiled with -g, those template instances will
not be debuggable. The workaround is to avoid -instlib=file when
you use -g.
The -L path is not searched to find file.
Warnings:
If you specify a library with -instlib, you must link with that li‐
brary.
See Also:
-template, -instances, -pti
-KPIC
(SPARC) (Obsolete) Use -xcode=pic32 instead.
(x86) Same as -Kpic on x86 architectures.
-Kpic
(SPARC) (Obsolete) Use -xcode=pic13 instead.
(x86) Produces position-independent code. Use this option to com‐
pile source files when building a shared library. Each reference to
a global datum is generated as a dereference of a pointer in the
global offset table. Each function call is generated in pc-relative
addressing mode through a procedure linkage table.
-keeptmp
Retains the temporary files that are created during compilation.
Along with -verbose=diags, this option is useful for debugging.
-Lpath
Adds path to the library search paths.
This option is passed to ld. The linker searches the directory
specified by path before it searches the compiler-provided directo‐
ries.
Interactions:
This option accumulates instead of overrides.
Warnings:
Never specify the /usr/include, lib, /usr/lib, or the compiler in‐
stallation area as search directories.
-llib
Add library liblib.a or liblib.so to linker's list of search li‐
braries.
This option is passed to ld. Normal libraries have names such as
liblib.a or liblib.so where the lib and .a or .so parts are re‐
quired. You can specify the lib part with this option. Put as many
libraries as you want on a single command line; they are searched
in the order specified with -Lpath.
Use this option after your object file names.
Interactions:
This option accumulates instead of overrides.
Warnings:
If you are building a multithreaded application, you must compile
and link your program with the -mt option. See -mt.
-libmieee
This option is deprecated and will be removed in a future release.
Use -xlibmieee instead.
-libmil
This option is deprecated and will be removed in a future release.
Use -xlibmil instead.
-library=lib[,lib...]
Incorporates specified CC-provided libraries into compilation and
linking.
When the -library option is used to specify a CC-provided library,
the proper -I paths are set during compilation and the proper -L,
-Y, -P, and -R paths and -l options are set during linking.
Values:
The prefix no% applied to a sub-option disables that sub-option.
The following table shows the meanings of the values for lib.
[no%]f77
Deprecated. Do not use. Use -xlang=f95.
[no%]f90
Deprecated. Do not use. Use -xlang=f90.
[no%]f95
Deprecated. Do not use. Use -xlang=f95.
[no%]interval
Deprecated. Do not use. Use -xia.
[no%]iostream
Use libiostream, the classic iostreams library.
[no%]Cstd
Use libCstd, a C++ runtime library compatible with all C++5.x
releases. Available only in -compat=5 mode.
[no%]stlport4
Use the STLport implementation of the standard library instead
of the default library. Code compiled with -library=stlport4
cannot be used in the same program as code compiled with -li‐
brary=Cstd or -library=stdcxx4. Available only in -compat=5
mode.
[no%]stlport4_dbg
Use STLport's debug-enabled library. Available only in -com‐
pat=5 mode.
[no%]stdcxx4
Use the Apache stdcxx version 4 library installed as part of
Oracle Solaris. This option also sets the -mt option implic‐
itly. The stdcxx library requires multi-threading mode. Code
compiled with -library=stdcxx4 cannot be used in the same pro‐
gram as code compiled with -library=Cstd or -library=stlport4.
Available only in -compat=5 mode.
[no%]stdcpp
Use libstdc++, the C++ runtime library for modes -compat=g,
-std=c++03, -std=c++11, and -std=c++14. Not available with
-compat=5 mode.
[no%]Crun
Use libCrun, the C++ compiler support library only for -com‐
pat=5 mode.
[no%]CrunG3
Use libCrunG3, the C++ compiler support library for modes -com‐
pat=g, -std=c++03, -std=c++11, and -std=c++14. Not available
with -compat=5 mode.
[no%]gc
Use libgc, garbage collection.
[no%]sunperf
Use the Sun Performance Library.
%none
In -compat=5 or -std=sun03 mode, use no libraries except
libCrun. In gcc compatibility modes (any of -compat=g or
-std=[c++03|c++11|c++14]) use no libraries other than
libCrunG3. libCrunG3 has a dependency on the g++ runtime li‐
braries libgcc_s and libstdc++. The option -library=%none in
gcc compatibility modes will not work unless you add no%CrunG3.
The libCrunG3 library provides support for operator new, dy‐
namic_cast, RTTI, exceptions, and initializing arrays of ob‐
jects. Most programs require this library.
Note that -library=libC is not allowed.
Defaults:
The -library option has default values that depend on the plat‐
form. They are intended to match C++ libraries bundled with the op‐
erating system. See the defaults list at the beginning of the OP‐
TIONS section.
Also, the libm and libc libraries are always included, even if you
specify -library=%none. libCrun is always included.
Example:
To link without any C++ libraries (except libCrun), use:
example% CC -library=%none
If you include both libCstd and libiostream, you must be careful
not to use the old and new forms of iostreams (for example, cout
and std::cout) within a program to access the same file. Mixing
standard iostreams and classic iostreams in the same program is
likely to cause problems if the same file is accessed from both
classic and standard iostream code.
Interactions:
If -xnolib is specified, -library is ignored.
If a library is specified with -library, the proper -I paths are
set during compilation. The proper -L, -Y, -P, -R,
paths and -l options are set during linking.
This option accumulates instead of overrides.
You can specify at most one of either -library=stlport4, -li‐
brary=stdcxx4, or -library=Cstd on the same command line.
When you use the interval arithmetic libraries, you must include
one of the following libraries: libCstd or libiostream.
The specified libraries are linked before the system support li‐
braries are linked.
Warnings:
The so-called "Classic" iostreams is the original 1986 version of
iostreams, which was replaced in the 1998 C++ standard. It is se‐
lected through the -library=iostream option. No two implementations
of "classic" iostreams are the same, so apart from being obsolete,
code using it is not portable. Note that this library might be dis‐
continued in future Oracle Developer Studio releases.
Do not redefine or modify any of the configuration macros for STL‐
port or Oracle Developer Studio C++ libraries. The libraries are
configured and built in a way that works with the C++ compiler.
Modifying the configuration macros results in programs that will
not compile, will not link, or do not run properly.
If you compile and link in separate steps, the set of -library op‐
tions that appear in the compile command must appear in the link
command. See the defaults list at the beginning of the OPTIONS sec‐
tion.
The set of libraries is not stable and might change from release to
release.
See also:
-I,-l,-R, -staticlib, -xia, -xlang, -xnolib, C++ Interval Arith‐
metic Programming
Reference, C++ Standard Reference
Library
-m32|-m64
Specifies the data type 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.
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 Oracle De‐
veloper Studio
12.6:
C++ User's Guide.
Note that in previous compiler releases, the data type 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 command
line is sufficient to create 64-bit objects.
The default behavior depends on the platform. See the defaults list
at the beginning of the OPTIONS section.
See also -xarch.
-mc
Removes duplicate strings from the .comment section of the object
file. When you use the -mc option, the mcs -c command is invoked.
(See the mcs(1) man page.)
-misalign
(SPARC) (Obsolete) You should not usethis option. Use the -xmema‐
lign=2i option instead.
-mr[,string]
Removes all strings from the .comment section of the object file
and, if string is supplied, places string in that section. If the
string contains blanks, the string must be enclosed in quotation
marks. When you use this option, the command mcs -d [-a string] is
invoked.
Interactions:
This option is not valid when -S is specified.
-mt[={yes|no}]
Use this option to compile and link multithreaded code.
This option passes -D_REENTRANT to the preprocessor.
-mt=yes is the default behavior of the compiler. -mt is equivalent
to -mt=yes. If this behavior is not desired use the option -mt=no.
The -xopenmp option (for using the OpenMP shared-memory paral‐
lelization API) includes -mt=yes automatically.
Use this option consistently. If you compile and link one transla‐
tion unit with -mt, you must compile and link all units of the pro‐
gram with -mt.
To determine which system support libraries will be linked by de‐
fault, compile with the -dryrun option.
See also: -xnolib
-native
Use -xtarget=native.
-noex
Use -features=no%except.
-nofstore
(x86) Cancel -fstore on command line.
Cancels forcing expressions to have the precision of the destina‐
tion variable invoked by -fstore.
-nofstore is invoked by -fast. -fstore is the usual default.
-nolib
This option is deprecated and will be removed in a future release.
Use -xnolib instead.
-nolibmil
This option is deprecated and will be removed in a future release.
Use -xnolibmil instead.
-noqueue
(Obsolete) This option silently does nothing.
-norunpath
Does not build the path for shared libraries into the executable.
If an executable file uses shared libraries, then the compiler nor‐
mally builds in a path that points the runtime linker to those
shared libraries. To do so, the compiler passes the -R option to
ld. The path depends on the directory where you have installed the
compiler.
This option is recommended for building executables that will be
shipped to customers who may have a different path for the shared
libraries that are used by the program.
Interactions:
If you use any shared libraries under the compiler installed area
(default location <installpath>/lib ) and you also use -norunpath,
then you should either use the -R option at link time or set the
environment variable LD_LIBRARY_PATH at run time to specify the lo‐
cation of the shared libraries. This will allow the runtime linker
to find the shared libraries.
-O
The -O macro expands to -xO3. Compiling with this option yields
higher runtime performance. However, optimization level -xO3 may be
inappropriate for programs that rely on all variables being auto‐
matically considered volatile. Typical programs that might have
this assumption are device drivers and older multi-threaded appli‐
cations that implement their own synchronization primitives. The
work around is to compile with -xO2 instead of -O.
-O[level]
Use -xOlevel.
-o filename
Names the output file filename, instead of the default a.out. file‐
name cannot be the same as sourcefile since cc does not overwrite
the source file.
filename must have an appropriate suffix. When used with -c, file‐
name specifies the target .o object file; with -G or -shared op‐
tions it specifies the target .so library file. This option and its
argument are passed to ld.
+p
Ignore non-standard preprocessor asserts.
Defaults:
If +p is not present, the compiler recognizes nonstandard pre‐
processor asserts.
Interactions:
If +p is used, the sun, unix, sparc, and i386 macros are not de‐
fined.
-P
Only preprocesses source: does not compile. (Outputs a file with a
.i suffix.)
This option does not include preprocessor-type line number informa‐
tion in the output.
-p
(Obsolete) See -xpg.
-pedantic{=[yes|no]}
When enabled, emits warnings or errors for code that is accepted by
default, but which does not conform to the C++ Standard. The Stan‐
dard that is in effect is determined by the -compat and -std op‐
tions:
C++ 2003 -compat=[5|g] or -std=[c++03|sun03]
C++ 2011 -std=c++11
C++ 2014 -std=c++14
The option -pedantic is equivalent to -pedantic=yes.
-pedantic=no is the default when no -pedantic option is specified.
The option does not interact with the +w or -w options.
If -pedantic appears more than once, the right-most option takes
precedence.
-pentium
(x86) Use -xtarget=pentium.
-pg
This option is deprecated and will be removed in a future release.
Use -xpg instead.
-PIC
(SPARC) Same as -xcode=pic32.
(x86) Same as -KPIC.
-pic
(SPARC) Same as -xcode=pic13.
(x86) Same as -Kpic.
-preserve_argvalues[=simple|none]
(x86) Saves copies of register-based function arguments in the
stack.
When none is specified or if the -preserve_argvalues option is not
specified on the command line, the compiler behaves as usual.
When simple is specified, up to six integer arguments are saved.
The values are not updated during the function lifetime on assign‐
ments to formal parameters.
-pta
Use -template=wholeclass.
-ptipath
Specifies an additional search directory for template source.
This option is an alternative to the normal search path set by
-Ipathname. If the -ptipath flag is used, the compiler looks for
template definition files on this path and ignores the -Ipathname
flag.
Using the -Ipathname flag instead of -ptipath produces less confu‐
sion.
Interactions:
This option accumulates instead of overrides.
-pto
Use -instances=static.
-ptv
Use -verbose=template.
-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 al‐
ready recognizes. For example, the C++ compiler recognizes the -z
option for the linker (ld). If you issue a command like this
CC -G -zallextract mylib.a -zdefaultextract ... // correct
the -z options are passed in order to the linker. But if you spec‐
ify the command like this
CC -G -Qoption ld -zallextract mylib.a \
-Qoption ld -zdefaultextract ... // error
the -z options can be reordered, giving incorrect results.
The following table shows the possible values for phase.
SPARC x86
ccfe ccfe
previse previse
iropt iropt
cg ube
CClink CClink
ld ld
Examples:
When the CC driver invokes ld in the following command, -Qoption
passes the -i option to ld:
example% CC -Qoption ld -i test.cc
Warnings:
Be careful to avoid unintended effects. For example,
-Qoption ccfe -features=bool,iddollar
is interpreted as
-Qoption ccfe -features=bool -Qoption ccfe iddollar
The correct usage is
-Qoption ccfe -features=bool,-features=iddollar
Note that these features do not require -Qoption and are used only
as an example.
-qoption phase option
Use -Qoption.
-qp
Same as -p.
-Qproduce sourcetype
Causes the CC driver to produce source code of the type sourcetype.
Source code types are shown in the following table.
.i Preprocessed C++ source from ccfe
.o Object file from the code generator
.s Assembler source from the code generator
-qproduce sourcetype
Use -Qproduce.
-Rpath[:path...]
Builds dynamic library search paths into the executable file.
This option is passed to ld.
Defaults:
If the -R option is not present, the default library search path is
recorded in the output object and passed to the runtime linker. The
default library search order can be seen by using the -dryrun op‐
tion and examining the -Y option of the ld invocation.
Interactions:
This option accumulates instead of overrides.
If both the LD_RUN_PATH environment variable and the -R option are
specified, then the path from -R is scanned, and the path from
LD_RUN_PATH is ignored.
See also: -norunpath
-S
Compiles and generates only assembly code. This option causes the
CC driver to compile the program and output an assembly source
file, but not assemble the program. The assembly source file is
named with a .s suffix.
-s
Strip the symbol table from the executable file. This option re‐
moves all symbol information from output executable files. This op‐
tion is passed to ld.
-shared
Builds a dynamic shared library instead of an executable file. All
source files specified in the command line are compiled with the
-pic option by default. For more information, ld(1) man page and
the Oracle Developer Studio 12.6: C++ User's
Guide.
When building a shared library from files that involve templates
and are compiled with the -instances=extern option, any template
instances referenced by the .o files will be included from the tem‐
plate cache automatically.
If you are creating a shared object by specifying the -G option
along with other compiler options that must be specified at both
compile time and link time, make sure that those same options are
also specified at both compile time and link time when you link
with the resulting shared object.
When you create a shared object, all the object files that are com‐
piled for 64-bit SPARC architectures must also be compiled with an
explicit -xcode value as documented under the description of
-xcode.
The following options are passed to ld if the -c option is not
specified: -dy, -G, and -R.
When you use the -shared option, the compiler passes default -l op‐
tions to ld, which are the same options that are passed by default
when creating an executable.
For more information, see the -G option.
-staticlib=l[,l...]
Indicates which C++ libraries specified by the -library option (in‐
cluding its defaults), and by the -xlang option are to be linked
statically.
Values:
l must be one of the following values.
[no%]library
Link library statically. The valid values for library are all
valid values for -library (except %all and %none
) all the valid values for -xlang, and interval (to be used in
conjunction with -xia). Use the prefix no% to disable linking
library.
%all
Link statically all the libraries specified by the -library op‐
tion, all the library specified in the -xlang option, and, if
-xia is specified, the interval libraries.
%none
Link no libraries specified in the -library option and the
-xlang option statically. If -xia is specified in the command
line, link no interval libraries statically.
Defaults:
If -staticlib is not specified, -staticlib=%none is assumed.
Interactions:
This option accumulates instead of overrides.
The -staticlib option only works for the C++ libraries that are se‐
lected explicitly with the -xia, the -xlang option, and the -li‐
brary option, in addition to the C++ libraries that are selected
implicitly by default. Cstd and Crun are selected by default.
Examples:
The following command links libCrun statically because Crun is a
default value for -library.
(correct) example% CC -staticlib=Crun test.cc
However, the following command does not link libgc because libgc is
not linked unless explicitly specified with the -library option.
(incorrect) example% CC -staticlib=gc test.cc
(correct) example% CC -library=gc -staticlib=gc test.cc
Warnings:
The set of allowable values for libraries is not stable and might
change from release to release.
On Oracle Solaris platforms, system libraries are not available as
static libraries.
You should link the support libraries dynamically unless you have a
specific need to link them statically. In some cases, static link‐
ing can prevent a program from working correctly.
Exception: The library, libCrunG3, when needed, is linked stati‐
cally by default on Linux. Linking statically avoids having to pro‐
vide this library to end users. On Oracle Solaris, libCrunG3.so.1
is part of the OS, so dynamic linking is appropriate.
-std=v
v is required and is one of the following:
c++03 (zero-3, not oh-3)
Select C++ 03 dialect and g++ binary compatibility. It is
equivalent to the -compat=g option.
c++11
Select C++ 11 dialect and g++ binary compatibility.
c++14
Select C++ 14 dialect and g++ binary compatibility.
c++0x (zero-x, not oh-x)
Equivalent to c++11.
sun03
Equivalent to -compat=5.
If more than one -std option appears, only the last one (right-
most) has an effect.
Defaults:
The -compat and -std options have default values that depend on the
platform. They are intended to match C++ libraries bundled with the
operating system. See the table at the top of this section.
Interactions:
The -compat and -std options cannot appear on the same command
line.
Except when -std=sun03 is specified, none of the following -library
sub-options can be used when -std is specified: Cstd, Crun,
iostream, stlport4, and stdcxx4.
Notes:
The C++11 and C++14 dialects are not available with -compat=5 bi‐
nary compatibility.
See also: -xnolib.
-sync_stdio=[yes|no]
Use this option when your runtime performance is degraded due to
the synchronization between C++ iostreams and C stdio. Synchroniza‐
tion is needed only when you use iostreams to write to cout and
stdio to write to stdout in the same program. The C++ standard re‐
quires synchronization so the C++ compiler turns it on by default.
However, application performance is often much better without syn‐
chronization. If your program does not write to both cout and std‐
out, you can use the option -sync_stdio=no to turn off synchroniza‐
tion.
Defaults:
If you do not specify -sync_stdio, the compiler sets it to
-sync_stdio=yes.
Examples:
Consider the following example:
#include <stdio.h>
#include <iostream>
int main()
{
std::cout << "\nHello ";
printf("beautiful ");
std::cout << "world!";
printf("\n");
}
With synchronization, the program prints on a line by itself
Hello beautiful world!
Without synchronization, the output gets scrambled.
Warnings:
This option is only effective for linking of executables, not for
libraries.
-temp=path
Defines the directory for temporary files.
This option sets path as the directory for the temporary files
which are generated during the compilation process. The compiler
gives precedence to the value set by -temp over the value of TM‐
PDIR.
See also: -keeptmp
-template=a[,a...]
Enables/disables various template options.
a must be one of the following values. The prefix no% applied to a
sub-option disables that sub-option.
[no%]extdef
Search for template definitions in separate source files.
[no%]geninlinefuncs
Instantiate inline member functions of the explicitly instanti‐
ated class template which were not generated previously.
[no%]wholeclass
Instantiate a whole template class, rather than only those
functions that are used. You must reference at least one member
of the class; otherwise, the compiler does not instantiate any
members for the class.
When -template=no%extdef is specified, the compiler predefines the
macro _TEMPLATE_NO_EXTDEF.
Defaults:
-template=no%wholeclass,no%extdef,no%geninlinefuncs
-time
This option is deprecated and will be removed in a future release.
Use -xtime instead.
-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 generated 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 command
line when linking. The option is also accepted at compile-time but
is ignored unless an executable binary is generated. Using -trace‐
back with -G or -shared options to create a shared library is an
error.
%none
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, and sigxfsz.
Any of these can be preceeded with no% to disable catching 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 coredump‐
size limit to zero using:
% limit coredumpsize 0
The -traceback option has no effect on runtime performance.
-Uname
Deletes initial definition of the preprocessor symbol name. This
option removes any initial definition of the macro symbol name that
was created by -D on the same command line, including those implic‐
itly placed there by the command-line driver.
This option has no effect on any other predefined macros nor on
macro definitions in source files.
To see the -D options that are placed on the command line by the
command-line driver, add the -dryrun option to your command line.
You can specify multiple -U options on the command line.
Examples:
The following command undefines the predefined symbol __sun. Pre‐
processor statements in test.cc such as #ifdef(__sun) will sense
that the symbol is undefined.
example% CC -U__sun test.cc
Interactions:
This option accumulates instead of overrides.
All -U options are processed after any -D options that are present.
-unroll=n
This option is deprecated and will be removed in a future release.
Use -xunroll=n instead.
-V
Same as -verbose=version.
-v
Same as -verbose=diags.
-verbose=a[,a...]
Controls compiler verbosity.
a must be one of the following values. The prefix no% applied to a
sub-option disables that sub-option when used with %all.
[no%]template
Turn on the template instantiation verbose mode, sometimes
called the verify mode. The verbose mode displays each phase of
instantiation as it occurs during compilation.
[no%]diags
Print the command line for each compilation pass.
[no%]version
Direct the CC driver to print the names and version numbers of
the programs it invokes.
%all
Invokes all the above.
%none
Invokes none of the above.
Defaults:
If -verbose is not specified, the compiler assumes -verbose=%none.
Interactions:
This option accumulates instead of overrides.
-Wc,arg
Passes the argument arg to component c. Each argument must be sepa‐
rated 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
l Link editor (ld)
m mcs
O (Capital letter 'O') Interprocedural optimizer
o Postoptimizer
p Preprocessor (cpp)
0 (The number zero) Compiler (ccfe)
2 Optimizer: (iropt)
3 Static error checking: (previse)
Note: You cannot use -Wd to pass the CC options listed in this man
page to the C++ compiler.
-Wa,-o,objfile passes -o and objfile to the assembler, in that or‐
der; also -Wl,-I,name causes the linking phase to override the de‐
fault name of the dynamic linker, /usr/lib/ld.so.1.
The order in which the argument(s) are passed to a tool with re‐
spect to the other specified command line options may change.
+w
Identifies code that might have unintended consequences.
(The +w option no longer generates a warning if a function is too
large to inline or if a declared program element is unused. These
warnings do not identify real problems in the source, and were thus
inappropriate to some development environments. Removing these
warnings from +w enables more aggressive use of +w in those envi‐
ronments. These warnings are still available with the +w2 option.)
Generates additional warnings about questionable constructs that
are:
o Nonportable
o Likely to be mistakes
o Inefficient
Defaults:
If +w is not specified, the compiler warns about constructs that
are almost certainly problems.
Interactions:
Some C++ standard headers result in warnings when compiled with +w.
+w2
Emits the same warnings as +w as well as warnings about technical
violations that are probably harmless, but that might reduce the
maximum portability of your program.
The +w2 option no longer warns about the use of implementation-de‐
pendent constructs in the system header files. Because the system
header files are the implementation, the warning was inappropriate.
Removing these warnings from +w2 enables more aggressive use of the
option.
Warnings:
Some Oracle Solaris software and C++ standard header files result
in warnings when compiled with +w2.
-w
Suppresses warning messages.
This option causes the compiler not to print warning messages. Some
warnings, particularly warnings regarding serious anachronisms,
cannot be suppressed.
-Xlinker arg
Passes arg to linker ld(1).
-Xm
Use -features=iddollar.
-xaddr32[={yes|no}]
(x86/x64) 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 cre‐
ation 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 Or‐
acle Solaris platforms supporting SF1_SUNW_ADDR32 software capabil‐
ity.
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 capabil‐
ities definition, described in the Linker and Libraries Guide.
-xalias_level[= n]
Allows the compiler to perform type-based alias-analysis.
Defaults:
n must be any, simple, or compatible.
-xalias_level
If you do not specify -xalias_level, the compiler sets it to
-xalias_level=any. If you specify -xalias_level without any
values, the compiler sets it to -xalias_level=compatible.
-xalias_level=any
At this level of analysis, the compiler assumes that any type
may alias any other type. However, despite this assumption,
some optimization is possible.
-xalias_level=simple
The compiler assumes that fundamental types are not aliased.
Specifically, a storage object with a dynamic type that is one
of the following fundamental types
o char, signed char, and unsigned char
o wchar_t
o short int, unsigned short int
o int, unsigned int
o long int, unsigned long int
o long long int, unsigned long long
int
o float, double, long double
o enumeration types
o data pointer types
o function pointer types
o data member pointer types
o function member pointer types
will only be accessed through lvalues of the following types:
o the dynamic type of the object
o a constant or volatile qualified version of the dy‐
namic type of the object
o a type that is the signed or unsigned type corre‐
sponding to the dynamic type of the object
o a type that is the signed or unsigned type corre‐
sponding to a constant or volatile qualified version
of the dynamic type of the object
o an aggregate or union type that includes one of the
aforementioned types among its members (including,
recursively, a member of a subaggregate or contained
union)
o a char or unsigned char type
-xalias_level=compatible
The compiler assumes that layout-incompatible types are not
aliased. A storage object is only accessed through lvalues of
the following types:
o the dynamic type of the object
o a constant or volatile qualified version of the dy‐
namic type of the object
o a type that is the signed or unsigned type which
corresponds to the dynamic type of the object
o a type that is the signed or unsigned type which
corresponds to the constant or volatile qualified
version of the dynamic type of the object
o an aggregate or union type that includes one of the
aforementioned types among its members (including,
recursively, a member of a subaggregate or contained
union)
o a type that is (possibly constant or volatile quali‐
fied) base class type of the dynamic type of the ob‐
ject
o a char or unsigned char type
The compiler assumes that the types of all references are lay‐
out compatible with the dynamic type of the corresponding stor‐
age object. Two types are layout-compatible under the following
conditions:
o If two types are the same type, then they are lay‐
out-compatible types.
o If two types differ only in constant or volatile
qualification, then they are layout-compatible
types.
o For each of the signed integer types, there exists a
corresponding (but different) unsigned integer type.
These corresponding types are layout compatible.
o Two enumeration types are layout-compatible if they
have the same underlying type.
o Two Plain Old Data (POD) struct types are layout
compatible if they have the same number of members,
and corresponding members (in order) have layout
compatible types.
o Two POD union types are layout compatible if they
have the same number of members, and corresponding
members (in any order) have layout compatible types.
References may be non-layout-compatible with the dynamic type
of the storage object under limited circumstances:
o If a POD union contains two or more POD structs that
share a common initial sequence, and if the POD
union object currently contains one of those POD
structs, it is permitted to inspect the common ini‐
tial part of any of them. Two POD structs share a
common initial sequence if corresponding members
have layout compatible types and, as applicable to
bit fields, the same widths, for a sequence of one
or more initial members.
o A pointer to a POD struct object, suitably converted
using a reinterpret_cast, points to its initial mem‐
ber, or if that member is a bit field, to the unit
in which it resides.
Interactions:
The compiler does not perform type-based alias analysis at opti‐
mization level -xO2 and below.
-xannotate[={yes|no}]
Instructs the compiler to create binaries that can later be used by
the optimization and observability tools binopt(1), code-ana‐
lyzer(1), discover(1), collect(1), and uncover(1).
The default on Oracle Solaris is -xannotate=yes. The default on
Linux is -xannotate=yes. Specifying -xannotate without a value is
equivalent to -xannotate=yes.
For optimal use of the optimization and observability tools, -xan‐
notate=yes must be in effect at both compile and link time.
Compile and link with -xannotate=no to produce slightly smaller bi‐
naries and libraries when optimization and observability tools will
not be used.
-xar
Creates archive libraries.
When building a C++ archive that uses templates, it is necessary in
most cases to include in the archive those template functions that
are instantiated in the template repository. The template reposi‐
tory is used only when at least one object file was compiled with
the -instances=extern option. Using with -xar automatically adds
those templates to the archive as needed.
However, since the compiler default is not to use a template cache,
the -xar option is often not needed. You can use the standard sys‐
tem ar(1) command to create .a archive files of C++ code, unless
some code was compiled with -instances. In that case use the -xar
compiler option instead.
Values:
Specify -xar to invokes ar -c-r and create an archive from scratch.
Examples:
The following command archives the template functions contained in
the repository and the object files.
example% CC -xar -o libmain.a a.o b.o c.o
Warnings:
Do not add .o files from the template repository on the command
line.
Do not use the ar command directly for building archives. Use CC
-xar to ensure that template instantiations are automatically in‐
cluded in the archive.
See Also: ar(1)
-xarch=isa
Specifies the target architecture instruction set (ISA).
This option limits the code generated by the compiler to the in‐
structions of the specified instruction set architecture by allow‐
ing 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: 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.
Note: Use the -m64 or -m32 option to specify the intended data type
model, LP64 (64-bits) or ILP32 (32-bits) respectively. The -xarch
flag no longer indicates the data type model, except for compati‐
bility with previous releases, as indicated below.
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 (all platforms):
generic
This option uses the instruction set common to most processors.
This is the default and is equivalent to -xarch=sse2 on x86
platforms and -xarch=sparcvis2 on SPARC platforms.
native
Compile for good performance on this system.
The compiler chooses the appropriate setting for the current
system processor it is running on.
Values on SPARC platforms:
sparc
Compile for the SPARC-V9 ISA.
Compile for the V9 ISA, but without the Visual Instruction Set
(VIS), and without other implementation-specific ISA exten‐
sions. This option enables the compiler to generate code for
good performance on the V9 ISA.
sparc4
Compile for the SPARC4 version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 in‐
struction set, plus the UltraSPARC extensions, 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.
sparc4b
Compile for the SPARC4B version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 in‐
struction set, plus the UltraSPARC extensions, which includes
VIS 1.0, the UltraSPARC-III extensions, which includes VIS2.0,
the SPARC64 VI extensions for floating-point multiply-add, the
SPARC64 VII extensions for integer multiply-add, and the PAUSE
and CBCOND instructions from the SPARC T4 extensions.
sparc4c
Compile for the SPARC4C version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 in‐
struction set, plus the UltraSPARC extensions, which includes
VIS 1.0, the UltraSPARC-III extensions, which includes VIS2.0,
the SPARC64 VI extensions for floating-point multiply-add, the
SPARC64 VII extensions for integer multiply-add, the VIS3B sub‐
set of the VIS 3.0 instructions a subset of the SPARC T3 exten‐
sions, called the VIS3B subset of VIS 3.0, and the PAUSE and
CBCOND instructions from the SPARC T4 extensions.
sparc5
Compile for the SPARC5 version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 in‐
struction set, plus the extensions, which includes VIS 1.0, the
Ultra SPARC-III extensions, which includes VIS2.0, the fused
floating-point multiply-add instructions, VIS 3.0, SPARC4, and
SPARC5 instructions.
sparcace
Compile for the sparcace version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 in‐
struction set, plus the UltraSPARC extensions, including the
Visual Instruction Set (VIS) version 1.0, the UltraSPARC-III
extensions, including the Visual Instruction Set (VIS) version
2.0, the SPARC64 VI extensions for floating-point multiply-add,
the SPARC64 VII extensions for integer multiply-add, and the
SPARC64 X extensions for SPARCACE floating-point.
sparcaceplus
Compile for the sparcaceplus version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 in‐
struction set, plus the UltraSPARC extensions, including the
Visual Instruction Set (VIS) version 1.0, the UltraSPARC-III
extensions, including the Visual Instruction Set (VIS) version
2.0, the SPARC64 VI extensions for floating-point multiply-add,
the SPARC64 VII extensions for integer multiply-add, the
SPARC64 X extensions for SPARCACE floating-point, and the
SPARC64 X+ extensions for SPARCACE floating-point.
sparcace2
Compile for the sparcace2 version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 in‐
struction set, plus the UltraSPARC extensions, including the
Visual Instruction Set (VIS) version 1.0, the UltraSPARC-III
extensions, including the Visual Instruction Set (VIS) version
2.0, the SPARC64 VI extensions for floating-point multiply-add,
the SPARC64 VII extensions for integer multiply-add, the
SPARC64 X extensions for SPARCACE floating-point, the SPARC64
X+ extensions for SPARCACE floating-point, and the SPARC64 XII
extensions for SPARCACE floating-point.
sparcvis
Compile for the SPARC-V9 ISA plus VIS.
Compile for SPARC-V9 plus the Visual Instruction Set (VIS) ver‐
sion 1.0, and with UltraSPARC extensions. This option enables
the compiler to generate code for good performance on the Ul‐
traSPARC architecture.
sparcvis2
Compile for the SPARC-V9 ISA with UltraSPARC III extensions.
Enables the compiler to generate object code for the UltraSPARC
architecture, plus the Visual Instruction Set (VIS) version
2.0, and with UltraSPARC III extensions.
sparcvis3
Compile for the SPARC-V9 ISA with UltraSPARC III and VIS 3 ex‐
tensions.
Enables the compiler to use instructions from the SPARC-V9 in‐
struction set, plus the UltraSPARC extensions, including the
Visual Instruction Set (VIS) version 1.0, the UltraSPARC-III
extensions, including the Visual Instruction Set (VIS) version
2.0, the fused multiply-add instructions, and the Visual In‐
struction 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 in‐
struction set, plus the UltraSPARC extensions, including the
Visual Instruction Set (VIS) version 1.0, the UltraSPARC-III
extensions, including the Visual Instruction Set (VIS) version
2.0, and the SPARC64 VI extensions for floating-point multiply-
add.
Note that you must use -xarch=sparcfmaf in conjunction with
-fma=fused and some optimization level to get the compiler to
attempt to find opportunities to use the multiply-add instruc‐
tions automatically.
sparcima
Compile for the sparcima version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 in‐
struction set, plus the UltraSPARC extensions, including the
Visual Instruction Set (VIS) version 1.0, the UltraSPARC-III
extensions, including the Visual Instruction Set (VIS) version
2.0, 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 data type model
need only use -m64.
v9a
Is equivalent to -m64 -xarch=sparcvis and is provided for com‐
patibility with earlier releases.
v9b
Is equivalent to -m64 -xarch=sparcvis2 and is provided for com‐
patibility with earlier releases.
Notes:
Object binary files (.o) compiled with sparc and sparcvis can be
linked and can execute together, but only on a sparcvis compatible
platform.
Object binary files (.o) compiled with sparc, sparcvis, and spar‐
cvis2 can be linked and can execute together, but only on a spar‐
cvis2 compatible platform.
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 instruc‐
tion set architectures, the compiler does not use these instruc‐
tions in the code it generates.
Values specific for x86 platforms:
avx512 Might use 386, MMX, Pentium_pro, SSE, SSE2, SSE3,
SSSE3, SSE4.1, SSE4.2, AES, PCLMULQDQ, AVX, FSGS‐
BASE, RDRND, F16C, AVX2, BMI1, BMI2, LZCNT, INVP‐
CID, FMA, ADX, RDSEED, PREFETCHW, PREFETCHWT1,
AVX512F, AVX512CDI, AVX512VLI, AVX512BW, and
AVX512DQ instructions.
avx2_i May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3,
SSSE3, SSE4.1, SSE4.2, AES, PCLMULQDQ, AVX, FSGS‐
BASE, RDRND, F16C, AVX2, BMI1, BMI2, LZCNT, INVP‐
CID, FMA, ADX, RDSEED, PREFETCHW and PREFETCHWT1
instructions.
avx2 May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3,
SSSE3, SSE4.1, SSE4.2, AES, PCLMULQDQ, AVX, FSGS‐
BASE, RDRND, F16C, AVX2, BMI1, BMI2, LZCNT, INVP‐
CID, and FMA instructions.
avx_i May use 386, pentium_pro, MMX, SSE, SSE2, SSE3,
SSSE3, SSE4.1, SSE4.2, AES, PCLMULQDQ, FSGSBASE,
RDRND, and F16C instructions.
avx May use 386, pentium_pro, MMX, SSE, SSE2, SSE3,
SSSE3, SSE4.1, SSE4.2, AES, and PCLMULQDQ instruc‐
tions.
aes May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3,
SSSE3, SSE4.1, SSE4.2, AES, and PCLMULQDQ instruc‐
tions.
sse4_2 May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3,
SSSE3, SSE4.1, and SSE4.2 instructions.
sse4_1 May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3,
SSSE3, and SSE4.1 instructions.
ssse3 May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, and
SSSE3 instructions.
sse3 May use 386, MMX, Pentium_pro, SSE, SSE2, and SSE3
instructions.
amdsse4a Uses the AMD SSE4a Instruction set.
sse2 May use 386, MMX, Pentium_pro, SSE, and SSE2 in‐
structions.
sse2a May use 386, MMX, Pentium_pro, SSE, SSE2 and AMD
extension: 3DNow!, 3DNow! extension instructions
for AMD processors.
sse Obsolete. Use -xarch=generic instead.
ssea May use 386, MMX, Pentium_pro, SEE and AMD exten‐
sion: 3DNow!, 3DNow! extension instructions for AMD
processors.
pentium_pro Obsolete. Use -xarch=generic instead.
pentium_proa May use 386, MMX, Pentium_pro and AMD extension:
3DNow!, 3DNow! extensions instructions for AMD
processors.
generic Uses the instruction set common to most processor.
native Uses the instructions available on the current sys‐
tem processor the compiler is running on.
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 and -xarch=generic on x86 platforms.
Interactions:
Although this option can be used alone, it is part of the expansion
of the -xtarget option and can be used to override the -xarch value
that is set by a specific -xtarget option.
For example, -xtarget=T3 expands to -xarch=sparcvis3 -xchip=T3
-xcache=8/16/4:6144/64/24. In the following command -xarch=sparc4
overrides the -xarch=sparcvis3 that is set by the expansion of
-xtarget=T3.
example% CC -xtarget=T3 -xarch=sparc4 foo.cc
Warnings:
If this option is used with optimization, the appropriate choice
can provide good performance of the executable on the specified ar‐
chitecture. An inappropriate choice, however, might result in seri‐
ous degradation of performance or in in a binary program that is
not executable on all intended target platforms.
-xatomic=a
Specify which atomics support runtime library is linked.
a must be one of the following:
studio Link with the libstatomic library bundled with Oracle De‐
veloper Studio.
gcc Link with the libatomic library in /usr/lib.
none Do not link with any atomics support library.
The option -xatomic=studio is the default when neither -latomic nor
-xatomic is specified, and the compiler is compiling in
-std={c++03|c++11|c++14} mode.
-latomic will be automatically translated to -xatomic=studio.
An explicit -xatomic option should override the presence of
-latomic regardless of the order on the command line. A warning
message will be emitted if the setting of -xatomic is conflict with
-latomic.
When the Oracle Solaris operating system includes a compatible
standard interface and the Linux bundled library conforms to a
standard interface, the need for the -xatomic option will be redun‐
dant.
-xautopar
Turns on automatic loop parallelization. Analyzes loops for inter-
iteration data dependence and does loop restructuring. If optimiza‐
tion is not at -xO3 or higher, optimization is raised to -xO3 and a
warning is issued.
Note that -xautopar does not enable the recognition of OpenMP prag‐
mas. To enable the recognition of OpenMP pragmas, use the -xopenmp
compiler option.
Use the OMP_NUM_THREADS environment variable to specify the number
of threads to use when running a program automatically parallelized
by the -xautopar compiler option. If OMP_NUM_THREADS is not set,
the default number of threads used is a multiple of the number of
cores per socket (that is, cores per processor chip), which is less
than or equal to the total number of cores or 32, whichever is
less. You can specify a different number of threads by setting the
OMP_NUM_THREADS environment variable. For best performance, the
number of threads used should not exceed the number of hardware
threads (or virtual processors) available on the machine. On Oracle
Solaris systems, this number can be determined by using the
psrinfo(1M) command. See the Oracle Developer Studio
12.6:
OpenMP API User's Guide for more information.
If you compile and link in separate steps, specify -xautopar in
both the compilation step and the link step. When used with the
link step, the -xautopar option will link with the OpenMP runtime
support library, libmtsk.so.
-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 functions where
profitable for performance. See the er_src(1) man page to learn how
to read compiler commentary output to determine 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 er‐
rno, 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 argu‐
ment, the default is -xbuiltin=%all and the compiler substitutes
intrinsics or inlines standard library functions much more aggres‐
sively.
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.
-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 property is
used.
Although this option can be used alone, it is part of the expansion
of the -xtarget option; its primary use is to override a value sup‐
plied by the -xtarget option.
The -xcache values are:
generic
Define the cache properties for good performance on most plat‐
forms. 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 migra‐
tion of code from systems where the char type is defined as un‐
signed. Unless you are migrating from such a system, do not use
this option. Only code that relies on the sign of a char type needs
to be rewritten to explicitly specify signed or unsigned.
Values:
You can substitute one of the following values for o:
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 rou‐
tines.
s Equivalent to signed.
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 rou‐
tines.
u Equivalent to unsigned.
Defaults:
If you do not specify -xchar, the compiler assumes -xchar=s. If you
specify -xchar, but do not specify a value, the compiler assumes
-xchar=s.
Interactions:
The -xchar option changes the range of values for the type char
only for code compiled with -xchar. This option does not change the
range of values for type char in any system routine or header file.
In particular, the value of CHAR_MAX and CHAR_MIN, as defined by
limits.h, do not change when this option is specified. Therefore,
CHAR_MAX and CHAR_MIN no longer represent the range of values en‐
codable in a plain char.
Warnings:
If you use -xchar, be particularly careful when you compare a char
against a predefined system macro because the value in the macro
may be signed. This is most common for any routine that returns an
error code which is accessed through a macro. Error codes are typi‐
cally 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 Oracle
Solaris ABI specifies type char as signed, and system libraries be‐
have accordingly. The effect of making char unsigned has not been
extensively tested with system libraries. Instead of using this op‐
tion, modify your code so that it does not depend on whether type
char is signed or unsigned. The sign of type char varies among com‐
pilers and operating systems.
-xcheck[=n]
Enables a runtime check for stack overflow.
Values:
n must be one of the following values.
%all
Perform all checks.
%none
Does not perform any checks.
stkovf[action]
Generate code to detect stack overflow errors at runtime, op‐
tionally specifying an action to be taken when a stack overflow
error is detected.
A stack overflow error occurs when a thread's stack pointer is
set beyond the thread's allocated stack bounds. The error may
not be detected if the new top of stack address is writable.
A stack overflow error is detected if a memory access violation
occurs as a direct result of the error, raising an associated
signal (usually SIGSEGV). The signal thus raised is said to be
associated with the error.
An undetected stack overflow error may result in silent data
corruption. Preventing undetected stack overflow errors re‐
quires compiler and runtime support.
If -xcheck=stkovf[action] is specified, the compiler generates
code to detect stack overflow errors in cases involving stack
frames larger than the system page size. The code includes a
library call to force a memory access violation instead of set‐
ting the stack pointer to an invalid but potentially mapped ad‐
dress (see _stack_grow(3C)).
The optional action, if specified, must be one of the follow‐
ing:
:detect
If action is :detect, a detected stack overflow error is
handled by executing the signal handler normally associated
with the error.
On SPARC Solaris, -xcheck=stkovf:detect is enabled by de‐
fault. This prevents silent corruption of the stack due to
stack overflow. It can be disabled by specifying
-xcheck=no%stkovf.
:diagnose
If action is :diagnose, a detected stack overflow error is
handled by catching the associated signal and calling
stack_violation(3C) to diagnose the error. This is the de‐
fault behavior if no action is specified.
If a memory access violation is diagnosed as a stack over‐
flow error, the following message is printed to stderr:
ERROR: stack overflow detected: pc=<inst_addr>,
sp=<sp_addr>
where <inst_addr> is the address of the instruction where
the error was detected, and <sp_addr> is the value of the
stack pointer at the time that the error was detected. Af‐
ter checking for stack overflow and printing the above mes‐
sage if appropriate, control passes to the signal handler
normally associated with the error.
-xcheck=stkovf:detect adds a stack bounds check on entry to
routines with stack frames larger than system page size (see
_stack_grow(3C)). The relative cost of the additional bounds
check should be negligible in most applications.
-xcheck=stkovf:diagnose adds a system call to thread creation
(see sigaltstack(2)). The relative cost of the additional sys‐
tem call depends on how frequently the application creates and
destroys new threads.
-xcheck=stkovf is supported only on Oracle Solaris. The C run‐
time library on Linux does not support stack overflow
detection.
no%stkovf
Turns off stack-overflow checking.
init_local
Initialize local variables. See the Oracle Developer Studio
12.6:
C User's Guide description of this option
for a list of the predefined values used by the compiler to
initialize variables.
Exercise caution when using -xcheck with a large amount of lo‐
cal data, such as arrays with more than 10,000 elements. This
can cause the compiler's internal representation of the program
to become very large when that local date is initialized, which
can result in significantly longer compilation times, espe‐
cially when combined with optimization levels greater than -02.
no%init_local
Do not initialize local variables.
noreturn
Inform the compiler to add code to cause a runtime error if a
routine which has been described as "do not return" returns.
A routine can be described as "do not return" by any of the
following:
o __attribute__ ((noreturn))
o #pragma does_not_return
o using the C11 qualifier _Noreturn
Undefined behaviour will result if a routine returns after be‐
ing described as not returning. The -xcheck=noreturn flag tells
the compiler to add an illegal instruction after every call to
a function marked as does not return to force the target appli‐
cation to abort if that function returns.
If you do not specify -xcheck, the compiler defaults to
-xcheck=%none and if you specify -xcheck without any arguments, the
compiler defaults to -xcheck=%all, unless you are on an Oracle So‐
laris system for SPARC, in which case, the compiler will default to
-xcheck=stkovf:detect for both cases.
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.
Although this option can be used alone, it is part of the expansion
of the -xtarget option; its primary use is to override a value sup‐
plied by the -xtarget option.
This option specifies timing properties by specifying the target
processor.
This option affects:
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
Uses timing properties for good performance on most SPARC
processors.
This is the default value that directs the compiler to use the
best timing properties for good performance on most SPARC
processors, without major performance degradation on any of
them.
native
Set the parameters for the best performance on the host envi‐
ronment.
sparc64vi (Obsolete)
Optimize for the SPARC64 VI processor.
sparc64vii (Obsolete)
Optimize for the SPARC64 VII processor.
sparc64viiplus
Optimize for the SPARC64 VII plus processor.
sparc64x
Optimize for the SPARC64 X processor.
sparc64xplus
Optimize for the SPARC64 X+ processor.
sparc64xii
Optimize for the SPARC64 XII processor.
ultraT1 (Obsolete)
Optimize for the UltraSPARC T1 processor.
ultraT2 (Obsolete)
Optimize for the UltraSPARC T2 processor.
ultraT2plus (Obsolete)
Optimize for the UltraSPARC T2+ processor.
T3 (Obsolete)
Optimize for the SPARC T3 processor.
T4
Optimize for the SPARC T4 processor.
T5
Optimize for the SPARC T5 processor.
T7
Optimize for the SPARC T7 processor.
T8
Optimize for the SPARC T8 processor.
M5
Optimize for the SPARC M5 processor.
M6
Optimize for the SPARC M6 processor.
M7
Optimize for the SPARC M7 processor.
M8
Optimize for the SPARC M8 processor.
The -xchip values for x86 platforms are:
generic
Optimize for good performance on most x86 processors.
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
Obsolete. Use -xchip=generic instead.
pentium_pro
Obsolete. Use -xchip=generic instead.
pentium3
Obsolete. Use -xchip=generic instead.
pentium4
Optimize for the Intel Pentium 4 processor.
sandybridge
Optimize for the Intel Sandy Bridge processor.
skylake
Optimize for the Skylake processor.
ivybridge
Optimize for the Intel Ivy Bridge processor.
haswell
Optimize for the Intel Haswell processor.
westmere
Optimize for the Intel Westmere processor.
amdfam10
Obsolete. Use -xchip=generic instead.
broadwell
Optimize for the Intel Broadwell processor.
-xcode=a
(SPARC) Specifies code address space.
Note: It is highly recommended that you build shared objects by
specifying -xcode=pic13 or -xcode=pic32. It is possible to build
workable shared objects with -m64 -xcode=abs64, but these will be
inefficient. Shared objects built with -m64
-xcode=abs32 or -m64 -xcode=abs44 will not work.
The following table shows the -xcode values.
abs32
Generate 32-bit absolute addresses, which are fast, but have
limited range. Code + data + bss size is limited to 2**32
bytes. This is the default on 32-bit architectures.
abs44
(SPARC) Generate 44-bit absolute addresses, which have moderate
speed and moderate range. Code + data + bss size is limited to
2**44 bytes. This is the default on 64-bit architectures. Do
not use this value with dynamic (shared) libraries.
abs64
(SPARC) Generate 64-bit absolute addresses, which are slow, but
have full range. Available only on 64-bit architectures.
pic13
Generates position-independent code (small model), which is
fast, but has limited range. Equivalent to -Kpic. Permits ref‐
erences to at most 2**11 unique external symbols on 32-bit ar‐
chitectures, 2**10 on 64-bit architectures.
pic32
Generates position-independent code (large model), which is
slow, but has full range. Equivalent to -KPIC. Permits refer‐
ences to at most 2**30 unique external symbols on 32-bit archi‐
tectures, 2**29 on 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 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 exceed 8,192 bytes,
use -xcode=pic32.
o If you are building an archive library for linking into
shared libraries you should just use -xcode=pic32.
Defaults:
The default is -xcode=abs32 for 32-bit architectures.
The default is -xcode=abs44 for 64-bit processors.
Warnings:
When you compile and link in separate steps, you must use the same
-xarch option in the compile step and the link step.
-xcompress={[no%]debug}
Compresses debug sections using the format specified by the -xcom‐
press_format option if supported by the underlying Operating Sys‐
tem. A sub-option is required. The option is ignored with a warning
when Operating System support is unavailable.
-xcompress_format=cmp-type
When -xcompress=debug is in effect, this options specifies how the
debug section is to be compressed.
The following values for cmp-type are recognized:
none No compression of the debug section is done.
zlib Compresses the debug section using ZLIB compression.
zlib-gnu Compresses the section using ZLIB compression, using
the GNU section compression format.
On Oracle Solaris, when compilation involves linking, the debug
sections are compressed using the ld option -z compress-sec‐
tions=cmp-type. For more information, see the ld(1) man page.
On Oracle Solaris, when compiling to an object file (.o), the debug
sections are compressed using elfcompress -t cmp-type. For more in‐
formation, see the elfcompress(1) man page.
On Linux, the objcopy command is used to compress debug sections of
each .o file using the objcopy --compress-debug-sec‐
tions. For more information, see the objcopy(1g) man page.
The option is ignored with a warning when Operating System support
is unavailable.
-xdebugformat=dwarf
-xdebugformat=dwarf generates debugging information using the dwarf
standard format. This is the default. The option is obsolete.
Notes:
The detailed format of individual fields in dwarf format may evolve
over time.
See also the man page for dwarfdump(1).
-xdebuginfo=a[,a...]
Control how much debugging and observability information is emit‐
ted.
The term tagtype refers to tagged types: structs, unions, enums,
and classes.
The following list contains the possible values for sub-options a.
The prefix no% applied to a sub-option disables that sub-option.
The default is -xdebuginfo=%none. Specifying -xdebuginfo without a
sub-option is forbidden.
%none
No debugging information is generated. This is the default.
[no%]line
Emit line number and file information.
[no%]param
Emit location list info for parameters. Emit full type informa‐
tion for scalar values (for example, int, char *) and type
names but not full definitions of tagtypes.
[no%]variable
Emit location list information for lexically global and local
variables, including file and function statics but excluding
class statics and externs. Emit full type information for
scalar values such as int and char * and type names but not
full definitions of tagtypes.
[no%]decl
Emit information for function and variable declarations, member
functions, and static data members in class declarations.
[no%]tagtype
Emit full type definitions of tagtypes referenced from param
and variable datasets, as well as template definitions.
[no%]macro
Emit macro information.
[no%]codetag
Emit DWARF codetags (also known as Stabs N_PATCH). This is in‐
formation regarding bitfields, structure copy, and spills used
by RTC and discover.
[no%]hwcprof
Generate information critical to hardware counter profiling.
This information includes ldst_map, a mapping from ld/st in‐
structions to the symbol table entry being referenced, and
branch_target table of branch-target addresses used to verify
that backtracking did not cross a branch-target. See -xhwcprof
for more information.
Note: ldst_map requires the presence of tagtype information.
The driver will issue an error if this requirement is not met.
These are macros which expand to combinations of -xdebuginfo and
other options as follows:
-g = -g2
-gnone =
-xdebuginfo=%none
-xglobalize=no
-xpatchpadding=fix
-xkeep_unref=no%funcs,no%vars
-g0 =
-xdebuginfo=line,param,decl,variable,tagtype
-xglobalize=yes
-xpatchpadding=fix
-xkeep_unref=funcs,vars
-g1 =
-xdebuginfo=line,param,codetag
-xglobalize=no
-xpatchpadding=fix
-xkeep_unref=no%funcs,no%vars
-g2 =
-xdebuginfo=line,param,decl,variable,tagtype,codetag
-xglobalize=yes
-xpatchpadding=fix
+d # only if no "-O" flags are present; see +d
-xkeep_unref=funcs,vars
-g3 =
-xdebuginfo=line,param,decl,variable,tagtype,codetag,macro
-xglobalize=yes
-xpatchpadding=fix
+d # only if no "-O" flags are present; see +d
-xkeep_unref=funcs,vars
-xdepend[=[yes|no] ]
Analyzes loops for inter-iteration data dependencies and performs
loop restructuring. Loop restructuring includes loop interchange,
loop fusion, scalar replacement, and elimination of "dead" array
assignments.
On SPARC, -xdepend is turned on for all optimization levels -xO3
and above, and is off for lower opt levels. Also, an explicit set‐
ting 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 compiler
sets the option to -xdepend=yes which means the compiler analyzes
loops for data dependencies.
Dependency analysis is included in -xautopar. The dependency analy‐
sis is done at compile time.
Dependency analysis may help on single-processor systems. However,
if you try -xdepend on single-processor systems, you should not use
-xautopar. If you do so, the -xdepend optimization is done for mul‐
tiple-processor systems.
See Also: -xprefetch_auto_type
-xdumpmacros[=value[,value...]]
Use this option when you want to see how macros are behaving in
your program. This option provides information such as macro de‐
fines, undefines, and instances of usage. It prints output to the
standard error (stderr), based on the order macros are processed.
The -xdumpmacros option is in effect until the end of the file or
until it is overridden by the dumpmacros or end_dumpmacros
pragma.
Values:
The prefix no% applied to a sub-option disables that sub-option.
[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 -xdumpmacros=defs,un‐
defs,use,loc,conds,sys. A good way to use this
argument is in conjunction with the [no%] form
of the other arguments. For example, -xdump‐
macros=%all,no%sys would exclude system header
macros from the output but still provide infor‐
mation for all other macros.
%none Do not print any macro information.
The option values accumulate so specifying -xdumpmacros=sys
-xdumpmacros=undefs has the same effect as -xdumpmacros=undefs,sys.
Note: The sub-options loc, conds, and sys are qualifiers for defs,
undefs and use options. By themselves, loc, conds, and sys have no
effect. For example, -xdumpmacros=loc,conds,sys has no effect.
Defaults:
If you specify -xdumpmacros without any arguments, it means -xdump‐
macros=defs,undefs,sys. If you do not specify -xdumpmacros, it de‐
faults to -xdumpmacros=%none.
-xe
Check only for syntax and semantic errors. When you specify -xe the
compiler does not produce any object code. The output for -xe is
directed to stderr.
Use the -xe option if you do not need the object files produced by
compilation. For example, if you are trying to isolate the cause of
an error message by deleting sections of code, you can speed the
edit and compile cycle by using -xe.
-xF[=v]
The -xF option enables the optimal reordering of functions and
variables by the linker.
This option instructs the compiler to place functions and/or data
variables into separate section fragments, which enables the
linker, using directions in a mapfile specified by the linker's -M
option, to reorder these sections to optimize program performance.
Generally, this optimization is only effective when page fault time
constitutes a significant fraction of program run time.
Reordering functions and variables for optimal performance requires
the following operations:
1. Compiling and linking with -xF.
2. Following the instructions in the Performance
Analyzer manual regarding how to gen‐
erate a mapfile for functions or following the instruc‐
tions in the Linker and Libraries
Guide regarding how to generate a map‐
file for data.
3. Relinking with the new mapfile by using the linker's -M
option.
4. Re-executing under the Analyzer to verify improvement.
Values:
The prefix no% applied to a sub-option disables that sub-option.
v can be one of the following values:
[no%]func
Fragment functions into separate sections.
[no%]gbldata
Fragment global data (variables with external linkage) into
separate sections.
[no%]lcldata
Fragment local data (variables with internal linkage) into sep‐
arate sections.
%all
Fragment functions, global data, and local data.
%none
Fragment nothing.
Defaults:
If you do not specify -xF, the default is -xF=%none. If you specify
-xF without any arguments, the default is -xF=%none,func.
Interactions:
Using -xF=lcldata inhibits some address calculation optimizations,
so you should only use this flag when it is experimentally justi‐
fied.
See Also:
analyzer(1), ld(1)
-xglobalize[={yes|no}]
Control globalization of function-level or file-level static vari‐
ables.
Globalization is a technique needed by fix and continue functional‐
ity in the debugger whereby function-level or file-level static
symbols are promoted to globals while a prefix is added to the name
to keep identically named symbols distinct.
The default is -xglobalize=no. Specifying -xglobalize is equivalent
to specifying -xglobalize=yes.
Interactions:
See -xpatchpadding.
-xhelp=flags
Displays a brief description of each compiler flag.
-xhelp=gccflags
Displays a summary of addtional gcc flags accepted by Studio that
is not shown by the -xhelp=flags.
-xhwcprof[={enable|disable}]
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 in‐
formation produced with -g) to which they refer. It associates pro‐
file data with the data space of the target, rather than the in‐
struction space, and provides insight into behavior that is not
easily obtained from only instruction profiling.
You can compile a specified set of object files with -xhwcprof how‐
ever, -xhwcprof is most useful when applied to all object files in
the application. This will provide coverage to identify and corre‐
late all memory references distributed in the application's object
files.
If you are compiling and linking in separate steps, use -xhwcprof
at link time as well. Future extensions to -xhwcprof may require
its use at link time.
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 de‐
bug data format be set to dwarf (-xdebugformat=dwarf), which is the
default with current Oracle Developer Studio compilers.
-xhwcprof uses -xdebuginfo to automatically enable the minimum
amount of debugging information it needs, so -g is not required.
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.
-xhwcprof is implemented as a macro that expands to various other,
more primitive, options as follows:
-xhwcprof
-xdebuginfo=hwcprof,tagtype,line
-xhwcprof=enable
-xdebuginfo=hwcprof,tagtype,line
-xhwcprof=disable
-xdebuginfo=no%hwcprof,no%tagtype,no%line
The following command compiles example.cc and specifies support for
hardware counter profiling and symbolic analysis of data types and
structure members using DWARF symbols:
example% CC -c -O -xhwcprof -g example.cc
For more information on hardware counter-based profiling, see the
Performance Analyzer manual.
-xia
Link the appropriate interval arithmetic libraries and set a suit‐
able floating-point environment.
Interactions:
To use the interval arithmetic libraries, include <suninterval.h>.
When you use the interval arithmetic libraries, you must include
one of the following libraries: Cstd, or iostreams. See -library
for information on including these libraries.
Warnings:
If you use intervals and you specify different values for -fsimple,
-ftrap, or -fns, then your program may have incorrect behavior.
C++ interval arithmetic is experimental and evolving. The specifics
may change from release to release.
On x86 platforms, -xarch=sse2 must be specified for 32-bit compila‐
tions. Also, -xia is not available on Linux platforms.
See also: -library, C++ Interval Arithmetic
Programming Reference
-xinline[=func_spec[,func_spec...]]
Specifies which user-written routines can be inlined by the opti‐
mizer at -xO3 or higher.
Values:
The prefix no% applied to a sub-option disables that sub-option.
func_spec can be one of the following:
%auto
Enable automatic inlining at optimization level -xO4 or higher.
This argument tells the optimizer that it can inline functions
of its choosing. Note that without the %auto specification, au‐
tomatic inlining is normally turned off when explicit inlining
is specified on the command line by
-xinline=[no%]func_name...
func_name
Strongly request that the optimizer inline the function. If the
function is not declared as extern "C", the value of func_name
must be mangled. You can use the nm command on the executable
file to find mangled function names. For functions declared as
extern "C", the names are not mangled by the compiler.
no%func_name
When you prefix the name of a routine on the list with no%, the
inlining of that routine is inhibited. The rule about mangled
names for func_name applies to no%func_name as well.
Only routines in the file being compiled are considered for inlin‐
ing unless you use -xipo[=1|2]. The optimizer decides which of
these routines are appropriate for inlining.
Defaults:
If the -xinline option is not specified, the compiler assumes -xin‐
line=%auto. If -xinline= is specified with no arguments, no func‐
tions are inlined regardless of the optimization level.
Examples:
To enable automatic inlining while disabling inlining of the func‐
tion declared int foo(), use
example% CC -xO5 -xinline=%auto,no%__1cDfoo6F_i_ -c a.cc
To strongly request the inlining of the function declared as int
foo(), and to make all other functions as the candidates for inlin‐
ing, use:
example% CC -xO5 -xinline=%auto, __1cDfoo6F_i_ -c a.cc
To strongly request the inlining of the function declared as int
foo(), and to not allow inlining of any other functions use:
example% CC -xO5 -xinline=__1cDfoo6F_i_ -c a.cc
Interactions:
The -xinline option has no effect for optimization levels below
-xO3. At -xO4 and higher, the optimizer decides which functions
should be inlined, and does so without the -xinline option being
specified. At -xO4 or higher, the compiler also attempts to deter‐
mine which functions will improve performance if inlined.
A routine is inlined if any of the following conditions apply.
o Optimization is set at -xO3 or higher
o Inlining is judged to be profitable and safe
o The function is in the file being compiled, or the func‐
tion is in a file that was compiled with -xipo[=1|2].
Warnings:
If you force the inlining of a function with -xinline, you might
actually diminish performance.
See Also: -xldscope
-xinline_param=a[,a[,a]...]
Use this option to manually change the heuristics used by the com‐
piler for deciding when to inline a function call.
This option only has an effect at -O3 or higher. The following sub-
options have an effect only at -O4 or higher when automatic inlin‐
ing is on.
In the following sub-options n must be a positive integer; a can be
one of the following:
default
Set the values of all the sub-options to their default values.
max_inst_hard[:n]
Automatic inlining only considers functions smaller than n
pseudo instructions (counted in compiler's internal representa‐
tion) as possible inline candidates.
Under no circumstances will a function larger than this be con‐
sidered for inlining.
max_inst_soft[:n]
Set inlined function's size limit to n pseudo instructions
(counted in compiler's internal representation).
Functions of greater size than this may sometimes be inlined.
When interacting with max_inst_hard, the value of max_inst_soft
should be equal to or smaller than the value of max_inst_hard,
i.e, max_inst_soft <= max_inst_hard.
In general, the compiler's automatic inliner only inlines calls
whose called function's size is smaller than the value of
max_inst_soft. In some cases a function may be inlined when its
size is larger than the value of max_inst_soft but smaller than
that of max_inst_hard. An example of this would be if the para‐
meters passed into a function were constants.
When deciding whether to change the value of max_inst_hard or
max_inst_soft for inlining one specific call site to a func‐
tion, use -xinline_report=2 to report detailed inlining message
and follow the suggestion in the inlining message.
max_function_inst[:n]
Allow functions to increase due to automatic inlining by up to
n pseudo instructions (counted in compiler's internal represen‐
tation).
max_growth[:n]
The automatic inliner is allowed to increase the size of the
program by up to n% where the size is measured in pseudo in‐
structions.
min_counter[:n]
The minimum call site frequency counter as measured by profil‐
ing feedback (-xprofile) in order to consider a function for
automatic inlining.
This option is valid only when the application is compiled with
profiling feedback (-xprofile=use).
level[:n]
Use this sub-option to control the degree of automatic inlining
that is applied. The compiler will inline more functions with
higher settings for -xinline_param=level.
n must be one of 1, 2, or 3.
The default value of n is 2 when this option is not specified,
or when the options is specified without :n.
Specify the level of automatic inline
level:1 basic inlining
level:2 medium inlining (default)
level:3 aggressive inlining
The level decides the specified values for the combination of
the following inlining parameters:
max_growth
+ max_function_inst
+ max_inst
+ max_inst_call
When level = 1, all the parameters are half the values of the
default.
When level = 2, all the parameters are the default value.
When level = 3, all the parameters are double the values of the
default.
max_recursive_depth[:n]
When a function calls itself either directly or indirectly, it
is said to be making a recursive call.
This sub-option allows a recursive call to be automatically in‐
lined up to n levels.
max_recursive_inst[:n]
Specifies the maximum number of pseudo instructions (counted in
compiler's internal representation) the caller of a recursive
function can grow to by performing automatic recursive inlin‐
ing.
When interactions between max_recursive_inst and max_recur‐
sive_depth occur, recursive function calls will be inlined un‐
til either the max_recursive_depth number of recursive calls,
or until the size of the function being inlined into exceeds
max_recursive_inst. The settings of these two parameters con‐
trol the degree of inlining of small recursive functions.
If -xinline_param=default is specified, the compiler will set all
the values of the sub-opitons to the default values.
If the option is not specified, the default is -xinline_param=de‐
fault.
The list of values and options accumulate from left to right. So
for a specification of
-xinline_param=max_inst_hard:30,..,max_inst_hard:50
the value max_inst_hard:50 will be passed to the compiler.
If multiple -xinline_param options are specified on the command
line, the list of sub-options likewise accumulate from left to
right. For example, the effect of
-xinline_param=max_inst_hard:50,min_counter:70 ...
-xinline_param=max_growth:100,max_inst_hard:100
will be the same as that of
-xinline_param=max_inst_hard:100,min_counter:70,max_growth:100
-xinline_report[=n]
This option generates a report written to standard output on the
inlining of functions by the compiler. The type of report depends
on the value of n, which must be 0, 1, or 2.
0 No report is generated.
1 A summary report of default values of inlining parame‐
ters is generated.
2 A detailed report of inlining messages is generated,
showing which callsites are inlined and which are not,
with a short reason for not inlining a callsite. In
some cases, this report will include suggested values
for -xinline_param that can be used to inline a call‐
site that is not inlined.
When -xinline_report is not specified, the default value for n is
0. When -xinline_report is specified without =n, the default value
is 1.
When -xlinkopt is present, the inlining messages about the call‐
sites that are not inlined might not be accurate.
The report is limited to inlining performed by the compiler that is
subject to the heuristics controllable by the -xinline_param op‐
tion. Callsites inlined by the compiler for other reasons may not
be reported.
-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 Analyzer to run the instrumented
program with collect -r races to create a data-race-detection ex‐
periment. You can run the instrumented code standalone but it runs
more slowly.
Values:
datarace
Prepare the code for analysis by the Thread Analyzer and define
__THA_NOTIFY.
no%datarace
This is the default. Do not prepare the code for analysis by
the Thread Analyzer and do not define __THA_NOTIFY.
Interactions:
-xinstrument cannot be used together with -xlinkopt.
If you compile and link in seperate steps, you must specify -xin‐
strument=datarace in both the compilation and linking steps.
This option defines the preprocessor token __THA_NOTIFY. You can
specify #ifdef __THA_NOTIFY to guard calls to libtha(3) routines.
This option also sets -g0.
Warnings:
It is illegal to specify -xinstrument without an argument.
-xipo[={0|1|2}]
Performs interprocedural optimizations.
The -xipo option performs partial-program optimizations by invoking
an interprocedural analysis pass. It performs optimizations across
all object files in the link step, and the optimizations are not
limited to just the source files on the compile command. However,
whole-program optimizations performed with -xipo do not include as‐
sembly (.s) source files.
The -xipo option is particularly useful when compiling and linking
large multifile applications. Object files compiled with this flag
have analysis information compiled within them that enables inter‐
procedural analysis across source and precompiled program files.
However, analysis and optimization is limited to the object files
compiled with -xipo, and does not extend to object files or li‐
braries.
Values:
0 Do not perform interprocedural optimizations.
1 Perform interprocedural optimizations.
2 Perform interprocedural aliasing analysis as well as
optimization of memory allocation and layout to im‐
prove cache performance.
Defaults:
If -xipo is not specified, -xipo=0 is assumed.
If only -xipo is specified, -xipo=1 is assumed.
Examples:
The following example compiles and links in the same step.
example% CC -xipo -xO4 -o prog part1.cc part2.cc part3.cc
The optimizer performs crossfile inlining across all three source
files. This is done in the final link step, so the compilation of
the source files need not all take place in a single compilation
and could be over a number of separate compilations, each specify‐
ing the -xipo option.
The following example compiles and links in separate steps.
example% CC -xipo -xO4 -c part1.cc part2.cc
example% CC -xipo -xO4 -c part3.cc
example% CC -xipo -xO4 -o prog part1.o part2.o part3.o
The object files created in the compile steps have additional
analysis information compiled within them to permit crossfile opti‐
mizations to take place at the link step.
Interactions:
The -xipo option requires at least optimization level -xO4.
Warnings:
When compiling and linking are performed in separate steps, -xipo
must be specified in both steps to be effective. Objects that are
compiled without -xipo can be linked freely with objects that are
compiled with -xipo. Libraries do not participate in crossfile in‐
terprocedural analysis, even when they are compiled with -xipo as
shown in this example:
example% CC -xipo -xO4 one.cc two.cc three.cc
example% CC -xar -o mylib.a one.o two.o three.o
example% CC -xipo -xO4 -o myprog main.cc four.cc mylib.a
In this example, interprocedural optimizations will be performed
between one.cc, two.cc, and three.cc, and between main.cc and
four.cc, but not between main.cc or four.cc and the routines in
mylib.a. The first compilation may generate warnings about unde‐
fined symbols, but the interprocedural optimizations will be per‐
formed because it is a compile and link step.
The -xipo option generates significantly larger object files due to
the additional information needed to perform optimizations across
the files. However, this additional information does not become
part of the final executable binary file. Any increase in the size
of the executable program will be due to the additional optimiza‐
tions performed.
If you have .o files compiled with the -xipo option from different
compiler versions, mixing these files can result in failure with an
error message about "IR version mismatch". When using the -xipo op‐
tion, all the files should be compiled with the same version of the
compiler.
When Not To Use -xipo=2 Interprocedural Analysis:
The compiler tries to perform whole-program analysis and optimiza‐
tions 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 ob‐
ject 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.
-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) be‐
fore producing an executable. Any object files contained in the li‐
brary 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 li‐
brary (.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 li‐
braries,each link should create its own copy of archive li‐
braries 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 li‐
brary (.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 op‐
timizations to object files compiled using -xipo and extracted
from an archive library at link time. To do that, both -xipo
and either -xipo_archive=readonly or -xipo_archive=writeback
must be specified at link time.
It is illegal to specify -xipo_archive without a flag.
-xipo_build=[yes|no]
Building -xipo without -xipo_build involves two passes through the
compiler -- once when producing the object files, and then again
later at link time when performing the cross file optimization.
Setting -xipo_build reduces compile time by avoiding optimizations
during the initial pass and optimizing only at link time. Optimiza‐
tion is not needed for the object files, as with -xipo it will be
performed at link time. If unoptimized object files built with
-xipo_build are linked without including -xipo to perform optimiza‐
tion, the application will fail to link with an unresolved symbol
error.
Examples:
The following example performs a fast build of .o files, followed
by crossfile optimization at link time:
% cc -O -xipo -xipo_build -o code1.o -c code1.c
% cc -O -xipo -xipo_build -o code2.o -c code2.c
% cc -O -xipo -o a.out code1.o code2.o
The -xipo_build will turn off -O when creating the .o files, to
build these quickly. Full -O optimization will be performed at link
time as part of -xipo crossfile optimization.
The following example links without using -xipo.
% cc -O -o a.out code1.o code2.o
If either code1.o or code2.o were generated with -xipo_build, the
result will be a link-time failure indicating the symbol __unopti‐
mized_object_file is unresolved.
When building .o files separately, the default behavior is
-xipo_build=no. However, when the executable or library is built in
a single pass from source files, -xipo_build will be implicitly en‐
abled. For example:
% cc -fast -xipo a.c b.c c.c
will implicitly enable -xipo_build=yes for the first passes that
generate a.o, b.o, and c.o. Include the option -xipo_build=no to
disable this behavior.
-xivdep[=p]
Disable or set interpretation of ivdep pragmas.
The ivdep pragmas tell a compiler to ignore some or all loop-car‐
ried dependences on array references that it finds in a loop for
purposes of optimization. This enables a compiler to perform vari‐
ous loop optimizations such as microvectorization, distribution,
software pipelining, etc., which would not be otherwise possible.
It is used in cases where the user knows either that the depen‐
dences 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 depen‐
dences.
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|auto}
Compile with multiple processes. If this flag is not specified, the
default behavior is -xjobs=auto.
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 in‐
voke to compile different files.
Generally, a safe value for n is 1.5 multiplied by the number of
available processors. Using a value that is many times the number
of available processors can degrade performance because of context
switching overhead among spawned jobs. Also, using a very high num‐
ber can exhaust the limits of system resources such as swap space.
When -xjobs=auto is specified, the compiler will automatically
choose the appropriate number of parallel jobs.
You must always specify -xjobs with a value. Otherwise an error di‐
agnostic is issued and compilation aborts.
If -xjobs is not specified, the default behavior is -xjobs=auto.
This can be overridden by adding -xjobs=n to the command line. Mul‐
tiple instances of -xjobs on the command line override each other
until the rightmost instance is reached.
Examples:
The following example links with up to 3 parallel processes for
-xipo:
% cc -xipo -xO4 -xjobs=3 t1.o t2.o t3.o
The following example links serially with a single process for
-xipo:
% cc -xipo -xO4 -xjobs=1 t1.o t2.o t3.o
The following example links in parallel, with the compiler choosing
the number of jobs for -xipo:
% cc -xipo -xO4 t1.o t2.o t3.o
Note that this is exactly the same behavior as when explicitly
specifying -xjobs=auto:
% cc -xipo -xO4 -xjobs=auto t1.o t2.o t3.o
-xkeep_unref[={[no%]funcs, [no%]vars}]
Keep definitions of unreferenced functions and variables. The no%
prefix allows the compiler to potentially remove the definitions.
The default is no%funcs,no%vars. Specifying -xkeep_unref is equiva‐
lent to specifying -xkeep_unref=funcs,vars, meaning that -keep_un‐
ref keeps everything.
-xkeepframe[=[%all,%none,function_name,no%function_name]]
Prohibit stack related optimizations for the named functions.
Specifying %all prohibits stack-related optimizations for all the
code. Specifying %none allows stack-related optimizations for all
the code.
If not specified on the command line, the compiler assumes -xkeep‐
frame=%none.
If specified on the command line without a value, the compiler as‐
sumes -xkeepframe=%all.
This option is accumulative and can appear on the command line mul‐
tiple times. For example,
-xkeepframe=%all -xkeepframe=no%func1
indicates that the stack frame should be kept for all functions ex‐
cept func1. Also, -xkeepframe overrides -xregs=frameptr. For exam‐
ple,
-xkeepframe=%all -xregs=frameptr
indicates that the stack should be kept for all functions, but the
optimizations for -xregs=frameptr would not be done.
-xlang=language[,language]
Includes the appropriate runtime libraries and ensures the proper
runtime environment for the specified language.
language must be either f90, f95 or c99.
The -f90 and -f95 arguments are equivalent. The c99 argument in‐
vokes ISO 9899:1999 C programming language behavior for objects
that were compiled with cc -std=c99 or cc -xc99=%all and are being
linked with CC.
Interactions:
The -xlang=f90 and -xlang=f95 options imply -library=f90. However,
the -library=f90 option is not sufficient for mixed-
language linking because only the -xlang option insures the proper
runtime environment.
To determine which driver to use for mixed-language linking, use
the following language hierarchy:
C++
Use the CC command.
Fortran 95 (or Fortran 90)
Use the f95 command. See f95(1) for details.
C
Use the cc command. See cc(1) for details.
When linking Fortran 95, Fortran 77, and C++ object files together,
use the driver of the highest language. For example, use the fol‐
lowing C++ compiler command to link C++ and Fortran 95 object
files.
example% CC -xlang=f95...
Warnings:
Do not use -xnolib with -xlang.
If you are mixing parallel Fortran objects with C++ objects, the
link line must specify the -mt flag.
See also: -library, -staticlib
-xldscope={v}
Changes the default linker scoping for the definition of extern
symbols. Changing the default can result in faster and safer shared
libraries because the implementation will be better hidden.
Values
v must be one of the following:
global
Symbol definitions have global linker scoping which is the
least restrictive linker scoping. All references to the symbol
bind to the definition in the first dynamic load module that
defines the symbol. This linker scoping is the current linker
scoping for extern symbols.
symbolic
Symbol definitions have symbolic linker scoping which is more
restrictive than global linker scoping. All references to the
symbol from within the dynamic load module being linked bind to
the symbol defined within the module. Outside of the module,
the symbol appears as though it is global. This linker scoping
corresponds to the linker option -Bsymbolic. Although you can‐
not use -Bsymbolic with C++ libraries, you can use the -xld‐
scope=symbolic option without causing problems.
hidden
Hidden linker scoping is more restrictive than symbolic and
global linker scoping. All references within a dynamic load
module will bind to a definition within that module. The symbol
will not be visible outside of the module.
Defaults:
If you do not specify -xldscope, the compiler assumes -xld‐
scope=global. If you specify -xldscope without any values, the com‐
piler issues an error. Multiple instances of this option on the
command line override each other until the rightmost instance is
reached.
Warnings:
If you intend to allow a client to override a function in a li‐
brary, you must be sure that the function is not generated inline
during the library build. The compiler inlines a function if you
specify the function name with -xinline, if you compile at -xO4 or
higher in which case inlining can happen automatically, if you use
the inline specifier, or if you are using cross-file optimization.
For example, suppose library ABC has a default allocator function
that can be used by library clients, and is also used internally in
the library:
void* ABC_allocator(size_t size) { return malloc(size); }
If you build the library at -xO4 or higher, the compiler inlines
calls to ABC_allocator that occur in library components. If a li‐
brary client wants to replace ABC_allocator with a customized ver‐
sion, the replacement will not occur in library components that
called ABC_allocator. The final program will include different ver‐
sions of the function.
Library functions declared with the __hidden or __symbolic speci‐
fiers can be generated inline when building the library. They are
not supposed to be overridden by clients. For more information, see
chapter 4 "Language Extensions" of the Oracle Developer Studio
12.6:
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
Causes libm to return IEEE 754 values for math routines in excep‐
tional cases. The default behavior of libm is XPG-compliant.
This option has an impact on the value of the errno variable set by
certain floating-point math library routines. See the NOTES section
at the end of this man page for more information.
-xlibmil
Inlines selected library routines for optimization.
There are inline templates for some of the libm library routines.
This option selects those inline templates that produce the fastest
executables for the floating-point option and platform currently
being used.
Note: This option does not affect C++ inline functions. This option
has an impact on the value of the errno variable set by certain
floating-point math library routines. See the NOTES section at the
end of this man page for more information.
-xlibmopt[={%none,archive,shared}]
Controls whether the compiler uses a library of optimized math rou‐
tines or the standard system math routines. The possible argument
values are:
%none
Do not link with the optimized math library. (This is the de‐
fault when no -xlibmopt option is specified.)
archive
Link with the optimized math library in static archive form.
(This is the default when -xlibmopt is specified with no argu‐
ment.)
shared
(Oracle Solaris) Link with the optimized math library in shared
object form.
The rightmost instance of this option on the command line overrides
all the previous instances. The order of this option relative to
other libraries specified on the command line is not significant.
The optimized math library includes selected math routines normally
found in libm. The optimized routines typically run faster than
their libm counterparts. The results may be slightly different from
those produced by the libm routines, although in most cases they
differ only in the least significant bit. When the static archive
form of the optimized library is used, the compiler selects rou‐
tines that are optimized for the instruction set indicated by the
-xarch value specified when linking. When the shared object form is
used, the most appropriate routines are selected at runtime based
on the instruction set supported by the system being used.
NOTE: The shared object form is available only on Oracle Solaris.
The routines in the optimized math library depend on the default
round-to-nearest floating point rounding mode. If you use the opti‐
mized math library, you must ensure that round-to-nearest mode is
in effect when any of these routines is called. These routines also
do not modify errno. Do not link with the optimized math library if
your program depends on math functions setting errno in response to
error conditions. See the NOTES section at the end of this man page
for more information.
Interactions:
-xlibmopt=archive is implied by the -fast option. To disable link‐
ing with the optimized math library when -fast is used, add -xlib‐
mopt=%none following -fast on the command line:
example% cc -fast -xlibmopt=%none
See also: -fast
-xlinkopt[=level]
(Oracle Solaris) Perform link-time optimizations on relocatable ob‐
ject files.
The link optimizer performs a number of advanced performance opti‐
mizations on the binary object code at link-time. The value level
sets the level of optimizations performed, and must be 0, 1, or 2.
The optimization levels are:
0 The link optimizer is disabled. (This is the default.)
1 Perform optimizations based on control flow analysis,
including instruction cache coloring and branch 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 a level parameter implies -xlinkopt=1.
These optimizations are performed at link time by analyzing the ob‐
ject binary code. The object files are not rewritten but the re‐
sulting executable code may differ from the original object codes.
This option is most effective when used to compile the whole pro‐
gram, and with profile feedback.
When compiling in separate steps, -xlinkopt must appear on both
compile and link steps:
example% CC -c -xlinkopt a.cc b.cc
example% CC -o myprog -xlinkopt=2 a.o
Note that the level parameter is only used when the compiler is
linking. In the example above, the link optimizer level is 2 even
though the object binaries were compiled with an implied level of
1.
Do not use the -zcombreloc linker option when you compile with
-xlinkopt.
You must use -xlinkopt on at least some of the compilation commands
for -xlinkopt to be useful at link time. The optimizer can still
perform some limited optimizations on object binaries not compiled
with -xlinkopt.
-xlinkopt will optimize code coming from static libraries that ap‐
pear on the compiler command line, but it will skip and not opti‐
mize code coming from shared (dynamic) libraries that appear on the
command line. You can also use -xlinkopt when building shared li‐
braries (compiling with -G or -shared).
The link optimizer is most effective when used with runtime 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 opti‐
mal 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.cc
example% progt
example% CC -o prog -xO5 -xprofile=use:profdir -xlinkopt file.cc
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 re‐
mains the same. Compiling with -xlinkopt and -g increases the size
of the executable by including debugging information.
Interactions:
-xlinkopt cannot be used together with -xinstrument.
-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 make‐
files and dependencies).
However, -xM only reports dependencies of the included headers and
not the associated template definition files. You can use the
.KEEP_STATE feature in your makefile to generate all the dependen‐
cies in the .make.state file that is created by make.
See make(1S) for details about makefiles and dependencies.
-xM1
This option is the same as -xM, except that this option does not
report dependencies for the /usr/include header files and it does
not report dependencies for compiler-supplied header files.
-xMD
Generates makefile dependencies like -xM but compilation continues.
-xMD generates an output file for the makefile-dependency informa‐
tion derived from the -o output filename, if specified, or the in‐
put source filename, replacing (or adding) the filename suffix with
.d. If you specify -xMD and -xMF, the preprocessor writes all make‐
file dependency information to the file specified with -xMF. Com‐
piling with -xMD -xMF or -xMD -o filename with more
than one source file is not allowed and generates an error. The de‐
pendency file is overwritten if it already exists.
-xMF filename
Use this option to specify a file for the makefile- dependency out‐
put. There is no way to specify individual filenames for multiple
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 overwritten if it
already exists.
This option cannot be used with -xM or -xM1.
-xMMD
Use this option to generate makefile dependencies excluding system
header files. This is the same functionality as -xM1, but compila‐
tion continues. -xMMD generates an output file for the makefile-de‐
pendency information derived from the -o output filename, if speci‐
fied, or the input source filename, replacing (or adding) the file‐
name 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 gener‐
ates an error. The dependency file is overwritten if it already ex‐
ists.
-xMerge
Merges the data segment with the text segment.
The data in the object file is read-only, and is shared between
processes, unless you link with ld -N.
-xMerge, -ztext, and -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 ini‐
tialized, position-dependent symbol relocations in writable stor‐
age.
-xmaxopt[=v]
This command limits the level of pragma opt to the level specified.
v must be one of the following: off, 1, 2, 3, 4, or 5. The default
value is -xmaxopt=off which causes pragma opt to be ignored. If you
specify -xmaxopt without supplying an argument, that is the equiva‐
lent of specifying -xmaxopt=5.
-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 con‐
trolling 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 mis‐
aligned 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 compile
time, the compiler generates the appropriate load/store instruction
sequence for that alignment of data.
For memory accesses where the alignment cannot be determined at
compile time, the compiler must assume an alignment to generate the
needed load/store sequence.
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 pro‐
gram does not catch the signal, the program aborts. Even
if the program 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 succeeded normally.
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 Equivalent to specifying i when a=1, 2, or 4, and s
when a=8 or 16.
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 speci‐
fied at both compile time and at link time, see the Oracle Devel‐
oper Studio
12.6:
C++ User's Guide.
Defaults:
The default for SPARC 64-bit programs (-m64) is -xmemalign=8s.
The default for SPARC 32-bit programs (-m32) is -xmemalign=8i.
If you do specify -xmemalign but do not provide a value, the de‐
fault 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 invalid when specified with -m32.
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 command-line.
If you do not specify -xmodel, the compiler assumes -xmodel=small.
Specifying -xmodel without an argument is an error.
It is not necessary to compile all translation units with this op‐
tion. You can compile select files as long as you ensure the object
you are accessing is within reach.
Be aware that not all Linux system support the medium model.
-xnolib
Disables linking with default system libraries.
Without this option, the C++ compiler links with several system
support libraries to support C++ programs. With this option, the
-llib options to link the default system support libraries are not
passed to ld.
Normally, the compiler links with the system support libraries as
follows:
For -compat=5 on Oracle Solaris, the libraries are:
-lxxx -lCrun -lm -lc
where -lxxx is one of the following:
-lstdcxx4 for the option -library=stdcxx4
(the default)
-lCstd for the option
-library=Cstd
-lstlport for the option
-library=stlport4
For -compat=5 on Linux, the libraries are:
-lxxx -lCrun -lm -lc
where -lxxx is one of the following:
-lCstd for the option -library=Cstd (the
default)
-lstlport for the option
-library=stlport4
For -compat=g, -std=c++03, -std=c++11, and -std=c++14 on all plat‐
forms, the libraries are:
-lstdc++ -lgcc_s -lCrunG3 -lm -lc
On Oracle Solaris, -compat=5 -library=stdcxx4 is the default.
On Linux, -std=c++03 is the default.
On Linux, libCrunG3 is linked statically by default. When you spec‐
ify system libraries, you can get the same default behaviour the
following way:
-lstdc++ -lgcc_s -Bstatic -lCrunG3 -Bdynamic -lm -lc
The order of the -l options is significant. The -lm option must ap‐
pear before -lc.
On Oracle Solaris if the -mt option is specified, the compiler
links with -lthread just before it links with -lm. On Linux if the
-mt option is specified, the compiler links with -lpthread just be‐
fore it links with -lm.
To determine which system support libraries will be linked by de‐
fault, compile with the -dryrun option. For example, the output
from the following command on Oracle Solaris:
CC foo.cc -m64 -dryrun
includes the following
-lstdcxx4 -lCrun -lm -lc
Examples:
For minimal compilation to meet the C application binary interface,
that is, a C++ program with only C support required, use:
CC -xnolib test.cc -lc
Interactions:
No static system libraries are available on Oracle Solaris plat‐
forms.
If you specify -xnolib, you must manually link all required system
support libraries in the given order. You must link the system sup‐
port libraries last.
If -xnolib is specified, -library is ignored.
Warnings:
Many C++ language features require the use of libCrun.
The set of system support libraries is not stable and might change
from release to release.
See also: -dryrun, -llib, -library=lib[,lib...]
-xnolibmil
Cancels -xlibmil on the command line.
Use this option with -fast to override linking with the optimized
math library.
-xnolibmopt
(Obsolete). Use -xlibmopt=%none instead. See -xlibmopt.
-xOn
Specifies optimization level (n). (Note the uppercase letter O,
followed by a digit 1, 2, 3, 4, or 5.)
The default is no optimization. However, this is only possible if
you do not specify an optimization level. If you specify an opti‐
mization level, there is no option for turning optimization off.
If you are trying to avoid setting an optimization level, be sure
not to specify any option that implies an optimization level. For
example, -fast is a macro option that sets optimization at -xO5.
All other options that imply an optimization level give a warning
message that optimization has been set. The only way to compile
without any optimization is to delete all options from the command
line or makefile that specify an optimization level.
Generally, the higher the level of optimization with which a pro‐
gram is compiled, the better the runtime performance. However,
higher optimization levels may result in increased compilation time
and larger executable files.
There are five levels that you can use with -xOn. The actual opti‐
mizations 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
usually gives minimum code size.
-xO3 Adds global optimizations at the function level, and
automatic inlining of functions whose body is smaller
than the overhead of calling the function. In general,
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 com‐
bined 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. Optimization at this level is more likely to im‐
prove performance if it is done with profile feedback.
See -xprofile=collect|use.
Interactions:
If you use -g or -g0 and the optimization level is -xO3 or lower,
the compiler provides best-effort symbolic information with almost
full optimization. Tail-call optimization and back-end inlining are
disabled.
If you use -g or -g0 and the optimization level is -xO4 or higher,
the compiler provides best-effort symbolic information with full
optimization.
Debugging with -g does not suppress -xOn, but -xOn limits -g in
certain ways. For example, the 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 symbolic
traceback. For more information, see Debugging a Program With dbx.
The -xinline option has no effect for optimization levels below
-xO3. At -xO4, the optimizer decides which functions should be in‐
lined, and does so regardless of whether you specify the -xinline
option. At -xO4, the compiler also attempts to determine which
functions will improve performance if they are inlined. If you
force the inlining of a function with -xinline, you might actually
diminish performance.
Warnings:
If you optimize at -xO3 or -xO4 with very large procedures, thou‐
sands of lines of code in a single procedure, the optimizer might
require an unreasonable amount of memory. In such cases, machine
performance can be degraded.
To prevent this degradation from taking place, use the limit com‐
mand to limit the amount of virtual memory available to a single
process (see the csh(1) man page). For example, to limit virtual
memory to 16 megabytes:
example% limit datasize 16M
This command causes the optimizer to try to recover if it reaches
16 megabytes of data space.
The limit cannot be greater than the total available swap space of
the machine, and should be small enough to permit normal use of the
machine while a larger compilation is in progress.
The best setting for data size depends on the degree of optimiza‐
tion requested, the amount of real memory, and virtual memory
available.
To find the actual swap space, type: swap -1.
To find the actual real memory, type: dmesg | grep mem.
See also: -xldscope, -fast, -xprofile=p, csh(1) man
page
Performance Analyzer discusses the effects of the different levels
of optimization on the Performance Analyzer's data.
-xopenmp[={parallel|noopt|none}]
Enable explicit parallelization with OpenMP directives.
The following details the -xopenmp values:
parallel
Enables recognition of OpenMP pragmas. The optimization level
under -xopenmp=parallel is -xO3. The compiler raises the opti‐
mization level to -xO3 if necessary and issues a warning.
This flag also defines the preprocessor macro _OPENMP. The
_OPENMP macro is defined to have the decimal value yyyymm where
yyyy and mm are the year and month designations of the version
of the OpenMP API that the implementation supports. Refer to
the Oracle Developer Studio
12.6:
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 -xO3. If you
explicitly set the optimization lower than -xO3, as in CC -xO2
-xopenmp=noopt, the compiler issues an error. If you do not
specify an optimization level with -xopenmp=noopt, the OpenMP
pragmas are recognized, the program is parallelized accord‐
ingly, but no optimization is done. This flag also defines the
preprocessor macro _OPENMP.
none
Does not enable the recognition of OpenMP pragmas, makes no
change to the optimization level of your program, and does not
define any preprocessor macros. This is the default when
-xopenmp is not specified.
If you specify -xopenmp, but do not specify a value, the compiler
assumes -xopenmp=parallel. If you do not specify -xopenmp at all,
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 a future release. You can
avoid warning messages by explicitly specifying an appropriate op‐
timization level.
Use the OMP_NUM_THREADS environment variable to specify the number
of threads to use when running an OpenMP program. If
OMP_NUM_THREADS is not set, the default number of threads used is a
multiple of the number of cores per socket (that is, cores per
processor chip), which is less than or equal to the total number of
cores or 32, whichever is less. You can specify a different number
of threads by setting the OMP_NUM_THREADS environment variable, or
by calling the omp_set_num_threads() OpenMP runtime routine, or by
using the num_threads clause on the parallel region directive. For
best performance, the number of threads used to execute a parallel
region should not exceed the number of hardware threads (or virtual
processors) available on the machine. On Oracle Solaris systems,
this number can be determined by using the psrinfo(1M) command. On
Linux systems, this number can be determined by inspecting the file
/proc/cpuinfo. See the Oracle Developer Studio
12.6:
OpenMP API User's Guide for more information.
Nested parallelism is disabled by default. To enable nested paral‐
lelism, you must set the OMP_NESTED environment variable to TRUE.
See the Oracle Developer Studio
12.6:
OpenMP API User's Guide for details.
If you compile and link in seperate steps, specify -xopenmp in both
the compilation step and the link step. When used with the link
step, the -xopenmp option will link with the OpenMP runtime support
library, libmtsk.so.
For up-to-date functionality and performance, make sure that the
latest patch of the OpenMP runtime library, libmtsk.so, is in‐
stalled on the system.
For more information about the OpenMP Fortran 95, C, and C++ appli‐
cation program interface (API) for building multithreaded applica‐
tions, see the Oracle Developer Studio
12.6:
OpenMP API User's Guide.
-xpagesize=n
Set the preferred page size for the stack and the heap.
The n value must be one of the following:
On SPARC: 4K, 8K, 64K, 512K, 2M, 4M, 32M, 256M, 2G, 16G, or de‐
fault.
On x86/x64: 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
runtime.
Use the pagesize(1) Oracle Solaris command to determine the number
of bytes in a page. The operating system offers no guarantee that
the page size request will be honored. However, appropriate segment
alignment can be used to increase the likelihood of obtaining the
requested page size. See the -xsegment_align option on how to set
the segment alignment. You can use pmap(1) or meminfo(2) to deter‐
mine 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
Oracle Developer Studio
12.6:
C++ User's Guide.
If you specify -xpagesize=default, the Oracle Solaris operating
system sets the page size.
This option is a macro for -xpagesize_heap and -xpagesize_stack.
These two options accept the same arguments as -xpagesize. You can
set them both with the same value by specifying -xpagesize=n or you
can specify them individually with different values.
Compiling with this option has the same effect as setting the
LD_PRELOAD environment variable to mpss.so.1 with the equivalent
options, or running the Oracle Solaris command ppgsz(1) with the
equivalent options before running the program. See the Oracle So‐
laris man pages for details.
The libhugetlbfs library is required for -xpagesize to work on
Linux. See the Linux libhugetlbfs(7) man page for more information.
-xpagesize_heap=n
Set the page size in memory for the heap.
The n value is the same as -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
runtime.
For details, see -xpagesize.
-xpagesize_stack=n
Set the page size in memory for the stack.
The n value is the same as -xpagesize.
You must specify a valid page size for the Oracle Solaris operating
system on the target platform. If you do not specify a valid page‐
size, the request is silently ignored at runtime.
For details, see -xpagesize.
-xpatchpadding[={fix|patch|size}]
Reserve an area of memory before the start of each function. If fix
is specified, the compiler will reserve the amount of space re‐
quired by fix and continue. This is the default. If either patch or
no value is specified, the compiler will reserve a platform-spe‐
cific default value. A value of -xpatchpadding=0 will reserve 0
bytes of space. The maximum value for size on x86 is 127 bytes and
on SPARC is 2048 bytes.
-xpch=v
This compiler option activates the precompiled-header feature. v
can be auto, autofirst, collect:pch_filename, or use:pch_filename.
You can take advantage of this feature through the -xpch and -xpch‐
stop options in combination with the #pragma hdrstop directive.
Use the -xpch option to create a precompiled-header file and im‐
prove your compilation time. The precompiled-header file is de‐
signed 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 us‐
ing that information when recompiling that source file, and when
compiling other source files that have the same sequence of head‐
ers.
You can let the compiler generate the precompiled-header file for
you automatically. Choose between one of the following two ways to
do this. One way is for the compiler to create the precompiled-
header file from the first include file it finds in the source
file. The other way is for the compiler to select from the set of
include files found in the source file starting with the first in‐
clude file and extending through a well-defined point that deter‐
mines which include file is the last one. Use one of the following
two flags to determine which method the compiler uses to automati‐
cally 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 expla‐
nation 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 contains only
the first header found in the source file.
If you decide to create your precompiled-header file manually, you
must start by first using -xpch and specify the collect mode. The
compilation command that specifies -xpch=collect must only specify
one source file. In the following example, the -xpch option creates
a precompiled-header file called header.Cpch based on the source
file a.cc:
CC -xpch=collect:myheader a.cc
A valid precompiled-header filename always has the suffix .Cpch.
When you specify pch_filename, you can add the suffix or let the
compiler add it for you. For example, if you specify CC -xpch=col‐
lect:foo a.cc, the precompiled-header file is called
foo.Cpch.
The compiler uses the following rules to determine how it handles
an existing precompiled-header file.
If the compiler finds an existing precompiled-header file, it only
uses the file when the following attributes of the file match the
same information derived from the current compilation:
o The viable prefix matches.
o The command line options are exactly the same.
o The current working directory is the same.
o The source-directory path-name is the same.
o The compiler and precompiled header version numbers
match.
The following must be true for a viable prefix to qualify as a
match:
o The #include filenames are all the same.
o All #define and #undef directives reference the same
symbols and the directives appear in the same order.
o The associated values for #define are identical.
o Any pragmas that are present appear in their original
order.
Note that #ident/#pragma idents are passed through "as is" in the
viable prefix and are unchecked for equality. The string argument
is typically different for each source file and, if checked, would
inhibit use of the existing precompiled-header file.
The compiler version used in the match condition is the same as
that returned by the compiler's -V option.
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.cc bar.cc foobar.cc
You should only use an existing precompiled-header file if the fol‐
lowing is true. If any of the following is not true, you should
recreate the precompiled-header file:
o The compiler that you are using to access the precom‐
piled-header file is the same as the compiler that cre‐
ated the precompiled-header file. A precompiled-header
file created by one version of the compiler may not be
usable by another version of the compiler.
o 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.
o 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.
o The contents of the included headers that you specify
with -xpch=use is identical to the contents of the in‐
cluded headers that were specified when the precompiled
header was created.
o The current directory (that is, the directory in which
the compilation is occurring and attempting to use a
given precompiled-header file) is the same as the direc‐
tory in which the precompiled-header file was created.
o The initial sequence of pre-processing directives, in‐
cluding #include directives, in the file you specified
with -xpch=collect are the same as the sequence of pre-
processing directives in the files you specify with
-xpch=use.
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 direc‐
tives 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 deter‐
mining which header files from the source are pre-compiled.
The viable prefix that the compiler finds during the current compi‐
lation must match the viable prefix that it used to create the pre‐
compiled-header file. In other words, the viable prefix must be in‐
terpreted 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:
o #include
o #if/ifdef/ifndef/else/elif/endif
o #define/undef
o #ident
o #pragma
Any of these may reference macros. The #else, #elif, and #endif di‐
rectives must match within the viable prefix. Comments are ignored.
The compiler determines the end point of the viable prefix automat‐
ically when you specify -xpch=auto or -xpch=autofirst and is de‐
fined as follows. For -xpch=collect or -xpch=use, the viable prefix
ends with a #pragma hdrstop.
o The first declaration/definition statement
o The first #line directive
o A #pragma hdrstop directive
o After the named include file if you specify -xpch=auto
and -xpchstop
o The first include file if you specify -xpch=autofirst
Note: An end point within a conditional statement generates a warn‐
ing and disables the automatic creation of a precompiled-header
file. Also, if you specify both the #pragma hdrstop and the -xpch‐
stop 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.
A header file is precompilable when it is interpreted consistently
across different source files. Specifically, when it contains only
complete declarations. That is, a declaration in any one file must
stand alone as a valid declaration. Incomplete type declarations,
such as struct S;, are valid declarations. The complete type decla‐
ration can appear in some other file. Consider these example header
files:
file a.h
struct S {
#include "x.h" /* not allowed */
};
file b.h
struct T; // ok, complete declaration
struct S {
int i;
[end of file, continued in another file] /* not allowed
*/
file c.h
namespace N {
int foo();
[end of file, continued in another file] /* not allowed
*/
file d.h
extern "C" {
int foo();
[end of file, continued in another file] /* not allowed
*/
file e.h
namespace N {
int foo();
} /* OK, a stand-alone namespace declaration */
file f.h
namespace N {
int bar();
} /* OK, namespace re-opened, but still stand-
alone */
A header file that is incorporated into a precompiled-header file
must not violate the following. The results of compiling a program
that violate any of these constraints is undefined.
o The header file must not use __DATE__ and __TIME__.
o The header file must not contain #pragma hdrstop.
When the compiler creates a precompiled-header file automatically,
the compiler writes it to the SunWS_cache directory. This directory
always resides in the location where the object file is created.
Updates to the file are performed under a lock so that it works
properly under dmake.
If you need to force the compiler to rebuild automatically-gener‐
ated precompiled-header files, you can clear the PCH cache direc‐
tory with the CCadmin tool. See the CCadmin(1) man page for more
information.
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 de‐
pendencies. Consider this sample make file:
%.o : %.cc shared.Cpch
$(CC) -xpch=use:shared -xpchstop=foo.h -c $<
default : a.out
foo.o + shared.Cpch : foo.cc
$(CC) -xpch=collect:shared -xpchstop=foo.h foo.cc -c
a.out : foo.o bar.o foobar.o
$(CC) foo.o bar.o foobar.o
clean :
rm -f *.o shared.Cpch .make.state a.out
These make rules, along with the dependencies generated by the com‐
piler, force a manually created precompiled-header file to be
recreated if any source file you used with -xpch=collect, or any of
the headers that are part of the precompiled-header file, have
changed. This prevents the use of an out of date precompiled-header
file.
For -xpch=auto or -xpch=autofirst, you do not have to create any
additional make rules in your makefiles.
Warnings:
Do not specify conflicting -xpch flags on the command line. For ex‐
ample, specifying both -xpch=collect and -xpch=auto, or specifying
both -xpch=autofirst with -xpchstop=<include> generates an error.
If you specify -xpch=autofirst or you specify -xpch=auto without
-xpchstop, any declaration, definition, or #line directive that ap‐
pears prior to the first include file, or appears prior to the in‐
clude file that is specified with -xpchstop for -xpch=auto, gener‐
ates a warning and disables the automatic generation of the precom‐
piled-header file.
A #pragma hdrstop before the first include file under -xpch=aut‐
ofirst or -xpch=auto disables the automatic generation of the pre‐
compiled-header file.
See also: -xpchstop
-xpchstop=file
file is the last include file to be considered in creating a pre‐
compiled-header file. Using -xpchstop on the command line is equiv‐
alent to placing a hdrstop pragma after the first include-directive
that references file in each of the source files that you specify
with the cc command.
Use -xpchstop=<include> with -xpch=auto to create a precompiled-
header file that is based on header files up through and including
<include>. This flag overrides the default -xpch=auto behavior of
using all header files contained in the entire viable prefix.
See Also: -xpch
-xpec[={yes|no}]
(Oracle Solaris) 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 tun‐
ing 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.
-xpg
Compiles for profiling with the gprof profiler.
The -xpg option compiles self-profiling code to collect data for
profiling with gprof. This option invokes a runtime recording mech‐
anism that produces a gmon.out file when the program normally ter‐
minates.
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 So‐
laris platforms or just gprof on 32 bit Solaris platforms include
approximate user CPU times. These times are derived from PC sample
data (see pcsample(2)) for routines in the main executable and rou‐
tines in shared libraries specified as linker arguments when the
executable is linked. Other shared libraries (libraries opened af‐
ter 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).
The Solaris 10 software does not include system libraries compiled
with -p. As a result, profiles collected on Solaris 10 platforms do
not include call counts for system library routines.
You can also perform this task with the Performance Analyzer. Refer
to the analyzer(1) man page.
Warnings:
If you specify -xpg at compile time, you must also specify it at
link time. See the Oracle Developer
Studio
12.6:
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 in‐
ternal errors.
Note: On x86 systems, -xpg is incompatible with -xregs=frameptr be‐
cause 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
-xport64[=v]
Use this option to help you port code to a 64-bit environment.
Specifically, this option warns against problems such as truncation
of types (including pointers), sign extension, and changes to bit-
packing that are common when you port code from a 32-bit architec‐
ture to a 64-bit architecture.
This option has no effect unless compiling in 64-bit mode with
-m64. (On all systems, -m64 is the default.)
Values:
v must be one of the following values.
no
Generate no warnings related to the porting of code from a 32
bit environment to a 64 bit environment.
implicit
Generate warning only for implicit conversions. Do not generate
warnings when an explicit cast is present.
full
Generate all warnings related to the porting of code from a 32
bit environment to a 64 bit environment. This includes warnings
for truncation of 64-bit values, sign-extension to 64 bits un‐
der ISO value-preserving rules, and changes to packing of bit‐
fields.
Defaults:
If you do not specify -xport64, the default is -xport64=no. If you
specify -xport64, but do not specify a flag, the default is
-xport64=full.
See Also: -xarch, -m32|-m64
-xprefetch[=a[,a]]
Enable and adjust prefetch instructions on those architectures that
support prefetch. You must compile with an optimization level 3 or
greater with this option.
a must be one of the following values.
auto
Enable automatic generation of prefetch instructions.
no%auto
Disable automatic generation.
explicit
Enable explicit prefetch macros.
Explicit prefetching should only be used under special circum‐
stances that are supported by measurements.
no%explicit
Disable explicit prefectch macros.
latx:factor
(SPARC) You can only combine this flag with -xprefetch=auto.
Adjust the compiler's assumed prefetch-to-load and prefetch-to-
store latencies by the specified factor. The factor must be a
positive floating-point or integer number.
yes
(Obsolete) Use -xprefetch=auto,explicit instead.
no
(Obsolete) Use -xprefetch=no%auto,no%explicit
instead.
With -xprefetch, and -xprefetch=auto the compiler is free to insert
prefetch instructions into the code it generates. This may result
in a performance improvement on architectures that support
prefetch.
If you are running computationally intensive codes on large multi‐
processors, you might find it advantageous to use
-xprefetch=latx:factor. This option instructs the code generator to
adjust the default latency time between a prefetch and its associ‐
ated load or store by the specified factor.
The prefetch latency is the hardware delay between the execution of
a prefetch instruction and the time the data being prefetched is
available in the cache. The compiler assumes a prefetch latency
value when determining how far apart to place a prefetch instruc‐
tion 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 applications, espe‐
cially 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 ex‐
ternal cache, you may be able to obtain better performance by de‐
creasing the prefetch latency values. To decrease the values, use a
factor that is less than 1 (one).
To use the -xprefetch=latx:factor option, start with a factor value
near 1.0 and run performance tests against the application. Then
increase or decrease the factor, as appropriate, and run the per‐
formance tests again. Continue adjusting the factor and running the
performance tests until you achieve optimum performance. When you
increase or decrease the factor in small steps, you will see no
performance difference for a few steps, then a sudden difference,
then it will level off again.
Defaults:
The default is -xprefetch=auto,explicit.
If automatic prefetching is enabled, such as with -xprefetch or
-xprefetch=auto, but a latency factor is not specified, then
latx:1.0 is assumed.
Interactions:
This option accumulates instead of overrides.
The sun_prefetch.h header file provides the macros for specifying
explicit prefetch instructions. The prefetches will be approxi‐
mately at the place in the executable that corresponds to where the
macros appear.
To use the explicit prefetch instructions, you must be on the cor‐
rect architecture, include sun_prefetch.h, and either exclude
-xprefetch from the compiler command or use -xprefetch,
-xprefetch=auto,explict, -xprefetch=explicit.
If you call the macros and include the sun_prefetch.h header file,
but pass -xprefetch=no%explicit, the explicit prefetches will not
appear in your executable.
The -xchip setting effects the determination of the assumed laten‐
cies and therefore the result of a latx:factor setting.
The latx:factor sub-option is valid only when automatic prefetching
is enabled. That is, latx:factor is ignored unless it is used in
conjunction with yes or auto.
Warnings:
Because the compiler tunes the prefetch mechanism for optimal per‐
formance across a wide range of machines and applications, you
should only use the latx:factor sub-option when the performance
tests indicate there is a clear benefit. The assumed prefetch la‐
tencies may change from release to release. Therefore, retesting
the effect of the latency factor on performance whenever switching
to a different release is highly recommended.
-xprefetch_auto_type=[a]
a is [no%]indirect_array_access.
Use this option to determine whether or not the compiler generates
indirect prefetches for the loops indicated by the option
-xprefetch_level in the same fashion the prefetches for direct mem‐
ory accesses are generated.
The prefix no% disables the option.
If you do not specify a setting for -xprefetch_auto_type, the com‐
piler sets it to -xprefetch_auto_type=no%indirect_array_access.
Options such as -xalias_level can affect the aggressiveness of com‐
puting the indirect prefetch candidates and therefore the aggres‐
siveness of the automatic indirect prefetch insertion due to better
memory alias disambiguation information.
-xprefetch_level=l
Controls the automatic insertion of prefetch instructions as deter‐
mined with -xprefetch=auto. The default is -xprefetch_level=1 when
you specify -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 in‐
structions. -xprefetch_level=2 targets additional loops, beyond
those targeted at level 1 and -xprefetch=3 targets additional loops
beyond those targeted at level 2.
You must compile with optimization level 3 or greater and generate
code for a platform that supports prefetch.
-xprevise={yes|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 -xprevise=yes and linking in a separate step,
include -xprevise=yes also on the link step.
The default is -xprevise=no.
On Linux, -xprevise=yes needs to be specified along with -xanno‐
tate.
See the Oracle Developer Studio Code Analyzer documentation for
further information.
-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 multi‐
threaded 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 Oracle Developer Studio
12.6:
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 op‐
timizer with -xprofile=use. The compiler generates code to mea‐
sure statement execution-frequency.
-xMerge, -ztext, and -xprofile=collect should not be used to‐
gether. While -xMerge forces statically initialized data into
read-only storage, -ztext prohibits position-dependent symbol
relocations in read-only storage, and -xprofile=collect gener‐
ates statically initialized, position-dependent symbol reloca‐
tions in writable storage.
The profile directory name profdir, if specified, is the path‐
name of the directory where profile data are to be stored when
a program or shared library containing the profiled 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 -xprofile=col‐
lect:prof_dir or -xprofile=tcov:prof_dir, profile data are
stored at run time in a directory named program.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 direc‐
tory, where profdir is the name of the executable or the name
specified in the -xprofile=collect:profdir flag. -xprofile does
not append .profile to profdir if profdir already ends in .pro‐
file. If you run the program several times, the execution fre‐
quency data accumulates in the profdir.profile directory; that
is, output from prior executions is not lost.
Example[1]: to collect and use profile data in the directory
myprof.profile located in the same directory where the program
is built:
CC -xprofile=collect:myprof.profile -xO5 prog.cc -o prog
./prog
CC -xprofile=use:myprof.profile -xO5 prog.cc -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.cc -o prog
...run prog from multiple locations...
CC -xprofile=use:/bench/myprof.profile -xO5 prog.cc -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. For a complete list of compiler
options that must be specified at both compile time and at link
time, see the Oracle Developer Studio
12.6:
C User's Guide.
See also the ENVIRONMENT VARIABLES section of this man page be‐
low for descriptions of environment variables that control
asynchronous profile collections.
use[:profdir]
Uses execution frequency data collected from code compiled with
-xprofile=collect[:profdir] or -xprofile=tcov[:profdir] to op‐
timize for the work performed when the profiled code was exe‐
cuted. profdir is the pathname of a directory containing pro‐
file 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 speci‐
fied 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.profile/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 -xpro‐
file=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 profile
directory name profdir must be used in the optimizing compila‐
tion: -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 compiler
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 -xprofile=use:profdir.
If the optional :profdir argument is omitted, a profile direc‐
tory will be created when the profiled program is executed. The
data stored in the profile directory can only be used by
tcov(1). The location of the profile directory can be con‐
trolled using environment variables SUN_PROFDATA and SUN_PROF‐
DATA_DIR. See ENVIRONMENT VARIABLES below.
If the location specified by :profdir is not an absolute path‐
name, it is interpreted relative to the current working direc‐
tory 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 ac‐
cessible 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 com‐
piled with -xprofile=tcov:/test/profdata, a directory named
/test/profdata.profile will be created by the compiler and used
to store data describing the profiled object files. The same
directory will also be used at execution time to store execu‐
tion data associated with the profiled object files.
Example 2: if a program named "myprog" is compiled with -xpro‐
file=tcov and executed in the directory /home/joe, the direc‐
tory /home/joe/myprog.profile will be created at run time and
used to store runtime profile data.
-xprofile_ircache[=path]
Use -xprofile_ircache[=path] with -xprofile=collect|use to improve
compilation time during the use phase by reusing compilation data
saved from the collect phase.
With large programs, compilation time in the use phase can improve
significantly because the intermediate data is saved. Note that the
saved data could increase disk space requirements considerably.
When you use -xprofile_ircache[=path], path overrides the location
where the cached files are saved. By default, these files are saved
in the same directory as the object file. Specifying a path is use‐
ful when the collect and use phases happen in two different direc‐
tories.
The following is a typical sequence of commands:
example% CC -xO5 -xprofile=collect -xprofile_ircache t1.cc t2.cc
example% a.out // run collects feedback data
example% CC -xO5 -xprofile=use -xprofile_ircache t1.cc t2.cc
-xprofile_pathmap=collect_prefix:use_prefix
Use the -xprofile_pathmap option when you are also specifying the
-xprofile=use command. Use -xprofile_pathmap when both of the fol‐
lowing 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=collect.
o Your object files share a common basename in the profile
but are distinguished from each other by their location
in different directories.
The collect-prefix is the prefix of the UNIX pathname of a direc‐
tory tree in which object files were compiled using -xprofile=col‐
lect.
The use-prefix is the prefix of the UNIX pathname of a directory
tree in which object files are to be compiled using -xprofile=use.
If you specify multiple instances of -xprofile_pathmap, the com‐
piler processes them in the order of their occurrence. Each use-
prefix specified by an instance of -xprofile_pathmap is compared
with the object file pathname until either a matching use-prefix is
identified or the last specified use-prefix is found not to match
the object file pathname.
-xreduction
Analyzes loops for reduction in automatic parallelization. This op‐
tion is valid only if -xautopar is also specified. Otherwise the
compiler issues a warning.
When a reduction recognition is enabled, the compiler parallelizes
reductions such as dot products, maximum and minimum finding. These
reductions yield different roundoffs from those obtained by unpar‐
allelized 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-op‐
tions: appl, float, frameptr.
Prefixing a suboption with no% disables that sub-option.
Example: -xregs=appl,no%float
Note that -xregs sub-options are restricted to specific hardware
platforms.
appl (SPARC)
Allow the compiler to generate code using the application reg‐
isters as scratch registers. The application registers are:
o g2, g3, g4 (on 32-bit platforms)
o g2, g3 (on 64-bit platforms)
It is strongly recommended that all system software and li‐
braries be compiled using -xregs=no%appl. System software (in‐
cluding 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 be‐
cause 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 floating-point
registers as scratch registers for integer values. Floating-
point values may use these registers regardless of this option.
To generate binary code free of all references to floating
point registers, use -xregs=no%float and make sure your source
code does not in any way use floating point types.
float (x86)
Allow the compiler to generate code by using the floating-point
registers as scratch registers. Floating-point values may use
these registers regardless of this option. To generate binary
code free of all references to floating point registers, use
-xregs=no%float and make sure your source code does not in any
way use floating point types. During code generation the com‐
pilers will attempt to diagnose code that results in the use of
floating point, simd, or x87 instructions.
frameptr (x86)
Allow the compiler to use the frame-pointer register (%ebp on
IA32, %rbp on x86 64-bit platforms) as a general-purpose regis‐
ter.
The default is -xregs=no%frameptr.
The C++ compiler ignores -xregs=frameptr unless exceptions 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, debuggers, and performance analyzers
cannot report on functions 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 indi‐
rectly 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, compiling
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,float. -xregs=frameptr is included in the expan‐
sion 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 regis‐
ter 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 com‐
piled without -xregs=no%appl is using the application registers in
order to safely link with that library.
-xrestrict[=f]
Treats pointer-valued function parameters as restricted pointers.
In addition to pointers, references can also be declared re‐
stricted, with the same meaning.
f is %all, %none, %source or a comma-separated list of one or more
function names.
This command-line option can be used on its own, but is best used
with optimization of -xO3 or greater.
Specifying -xrestrict=%source means that all functions defined in
the main source file, but not any header files or template defini‐
tion files, are restricted.
If you specify a function list with this option, each listed name
must be the mangled name (if applicable) of the function. See -xre‐
strict[=f] in
Oracle Developer Studio
12.6:
C++ User's Guide for examples. The pointer parame‐
ters in the specified functions are treated as restricted.
If you specify -xrestrict=%all, all pointer parameters in the en‐
tire C++ file are treated as restricted.
The default is %none. Specifying -xrestrict is equivalent to speci‐
fying -xrestrict=%source.
See also: -xprefetch_auto_type, 'Restricted Pointers' in the Oracle
Developer Studio
12.6:
C++ User's Guide
-xs[={yes|no}]
(Oracle Solaris) Link debug information from object files into exe‐
cutable.
-xs is the same as -xs=yes. The default for -xdebugformat=dwarf is
the same as -xs=yes.
This option controls the trade-off of executable size versus the
need to retain object files in order to debug. For dwarf, use
-xs=no to keep the executable small but depend on the object files.
This option has almost no effect on dbx performance or the runtime
performance of the program.
When the compile command forces linking (that is, -c is not speci‐
fied) there will be no object file(s) and the debug information
must be placed in the executable. In this case, -xs=no (implicit or
explicit) will be ignored.
The feature is implemented by having the compiler adjust the sec‐
tion flags and/or section names in the object file that it emits,
which then tells the linker what to do for that object file's debug
information. It is therefore a compiler option, not a linker op‐
tion. It is possible to have an executable with some object files
compiled -xs=yes and others compiled -xs=no.
Linux compilers accept but ignore -xs. Linux compilers do not ac‐
cept -xs={yes|no}.
-xsafe=mem
(SPARC) Allow the compiler to assume that no memory protection vio‐
lations occur.
This option allows the compiler to use the non-faulting load in‐
struction in the SPARC V9 architecture.
Warnings:
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 oc‐
cur. Because few programs incur memory-based traps, you can safely
use this option for most programs. Do not use this option for pro‐
grams that explicitly depend on memory-based traps to handle excep‐
tional conditions.
Interactions:
This option takes effect only when used with optimization level
-xO5 and one of the following -xarch values: sparc, sparcvis, spar‐
cvis2, or sparcvis3 for both -m32 and -m64.
-xsecure_code_analysis{=[yes|no]}
Enable or disable compiler secure code analysis to find and display
possible memory safety violations at compile time. Secure code
analysis runs in parallel with the compilation process and may re‐
sult in increased compile time.
If -xsecure_code_analysis is not specified or if it is specified
without a yes|no argument, the default is -xsecure_code_analy‐
sis=yes.
Use -xsecure_code_analysis=no to disable secure code analysis.
-xsegment_align=n
(Oracle Solaris) This option causes the driver to include a special
mapfile on the link line. The mapfile aligns the text, data, and
bss segments to the value specified by n. When using very large
pages, it is important that the heap and stack segments are aligned
on an appropriate boundary. If these segments are not aligned,
small pages will be used up to the next boundary, which could cause
a performance degradation. The mapfile ensures that the segments
are aligned on an appropriate boundary.
The n value must be one of the following:
SPARC: The following values are valid: 8K, 64K, 512K, 2M, 4M, 32M,
256M, 1G, and none.
x86: The following values are valid: 4K, 8K, 64K, 512K, 2M, 4M,
32M, 256M, 1G, and none.
The default for both SPARC and x86 is none.
Recommended usage is as follows:
SPARC 32-bit compilation: -xsegment_align=64K
SPARC 64-bit compilation: -xsegment_align=4M
x86 32-bit compilation: -xsegment_align=8K
x86 64-bit compilation: -xsegment_align=4M
The driver will include the appropriate mapfile. For example, if
the user specifies -xsegment_align=4M, the driver adds -M install-
directory/lib/compilers/mapfiles/map.4M.align to the link line,
where install-directory is the installation directory. The afore‐
mentioned segments will then be aligned on a 4M boundary.
-xspace
Does not allow optimizations that increase code size.
-xtarget=t
Specifies the target system for the instruction set and optimiza‐
tion.
t must be one of: native, generic, or system-name.
Each specific value for -xtarget expands into a specific set of
values for the -xarch, -xchip, and -xcache options. Use the
-xdryrun option to determine the expansion of -xtarget=native on a
running system.
For example, -xtarget=T3 is equivalent to -xchip=T3
-xcache=8/16/4:6144/64/24 -xarch=sparcvis3.
cc -dryrun -xtarget=T3 |& grep ###
### command line files and options (expanded):
### -dryrun -xchip=T3 -xcache=8/16/4:6144/64/24 -xarch=sparcvis3
The data type model, either 32-bit or 64-bit, is indicated by the
-m32|-m64 option. To specify the 64-bit data type model, use the
-m64 option as follows:
-xtarget=<value> ... -m64
To specify the 32-bit data type model, use the -m32 option as fol‐
lows:
-xtarget=<value> ... -m32
See also the -m32|-m64 option for a discussion of the default data
type model.
The expansion of -xtarget for a specific host system might not ex‐
pand to the same -xarch, -xchip, or -xcache settings as -xtar‐
get=native when compiling on that system.
The following values for t are valid on all systems:
native
Equivalent to
âxarch=native âxchip=native âxcache=native
to give best performance on the host system.
generic
Equivalent to
âxarch=generic âxchip=generic âxcache=generic
to give best performance on most systems. This is the default.
system-name
Get the best performance for the specified system.
Select a system name from the following lists that represents
the actual system you are targeting.
Valid SPARC system names are: sparc64vi (Obsolete), sparc64vii
(Obsolete), sparc64viiplus, sparc64x, sparc64xplus, sparc64xii,
ultraT1 (Obsolete), ultraT2 (Obsolete), ultraT2plus, T3 (Obso‐
lete), T4, T5, T7, M5, M6, and M7.
Valid x86 system names are: barcelona (Obsolete), haswell, ivy‐
bridge, nehalem, pentium (Obsolete), pentium_pro (Obsolete),
pentium3 (Obsolete), pentium4, penryn, sandybridge, westmere,
woodcrest, and broadwell and skylake.
-xtemp=path
Equivalent to -temp=path.
-xthreadvar[=o]
Works in conjunction with the __thread declaration specifier to
take advantage of the compiler's thread-local storage facility. Af‐
ter you declare the thread variables with the __thread specifier,
use -xthreadvar to enable the use of thread-local storage with po‐
sition dependent code (non-PIC code) in dynamic (shared) libraries.
For more information on how to use __thread, see the Oracle Devel‐
oper Studio
12.6:
C++ User's Guide.
Values:
o can be one of the following:
[no%]dynamic
Compile variables for dynamic loading. Prefix no% disables the
option. Access to thread variables is significantly faster when
-xthreadvar=no%dynamic but you cannot use the object file
within a dynamic library. That is, you can only use the object
file in an executable file.
Defaults:
If you do not specify -xthreadvar, the default used by the compiler
depends upon whether or not position-independent code is enabled.
If position-independent code is enabled, the option is set to
-xthreadvar=dynamic. If position- independent code is disabled, the
option is set to -xthreadvar=no%dynamic.
If you specify -xthreadvar but do not specify any arguments, the
option is set to -xthreadvar=dynamic.
Interactions:
Objects that use __thread must be compiled and linked with -mt.
Warnings:
If there is non-position-independent code within a dynamic library,
you must specify -xthreadvar.
The linker cannot support the thread-variable equivalent of non-PIC
code in dynamic libraries. Non-PIC thread variables are signifi‐
cantly faster, and hence should be the default for executables.
See also: -xcode, -KPIC, -Kpic
-xthroughput[={yes|no}]
The -xthroughput option tells the compiler that the application
will be run in situations where many processes are simultaneously
running on the system.
If -xthroughput=yes, the compiler will favor optimizations that
slightly reduce performance for a single process while improving
the amount of work achieved by all the processes on the system. As
an example, the compiler might choose to be less aggressive in
prefetching data. Such a choice would reduce the memory bandwidth
consumed by the process, and as such the process may run slower,
but it would also leave more memory bandwidth to be shared among
other processes.
The default is -xthroughput=no.
-xtime
Causes the CC driver to report execution times for the various com‐
pilation passes.
-xtrigraphs[={yes|no}]
Enables or disables recognition of trigraph sequences as defined by
the ISO/ANSI C standard.
-xtrigraphs=yes enables recognition of trigraph sequences in the
source code.
-xtrigraphs=no disables recognition of trigraph sequences in the
source code.
Defaults:
If the -xtrigraphs option is not specified, -xtrigraphs=yes is as‐
sumed.
If only -xtrigraphs is specified -xtrigraphs=yes is assumed.
-xunboundsym={yes|no}
Specify whether the program contains references to dynamically
bound symbols.
-xunboundsym=yes means the program contains references dynamically
bound symbols.
-xunboundsym=no means the program does not contain references to
dynamically bound symbols.
The default is -xunboundsym=no.
-xunroll=n
Enables unrolling of loops where possible.
This option specifies whether or not the compiler optimizes (un‐
rolls) loops.
When n is 1, it is a suggestion to the compiler not to unroll
loops.
When n is an integer greater than 1, -xunroll=n causes the compiler
to unroll loops n times.
-xustr={ascii_utf16_ushort|no}
This option enables compiler recognition of UTF-16 character
strings and literals. Since such strings and literals are not yet
part of any standard, this option enables recognition of non-stan‐
dard C++. Specify -xustr=ascii_utf16_ushort if you need to support
an internationalized application that uses ISO10646 UTF-16 charac‐
ters. In other words, use this option if your code contains string
characters that you want the compiler to convert to UTF-16 charac‐
ters in the object file. Without this option, the compiler neither
produces nor recognizes sixteen-bit characters. This option enables
recognition of the U"ASCII_string" string literals as an array of
unsigned short int. This option also enables recognition of charac‐
ter literals. For example: unsigned short character = U'Z';
You can turn off compiler recognition of U"ASCII_string" string
literals by specifying -xustr=no. The rightmost instance of this
option on the command line overrides all previous instances.
The default is -xustr=no. If you specify -xustr without an 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 meaning
for the syntax.
It is not an error to specify -xustr=ascii_ustf16_ushort without
also specifying a U"ASCII_string" string literal.
Not all files have to be compiled with this option.
The following example shows a string literal in quotes that is
prepended by U. It also shows a command line that specifies -xustr.
example% cat file.cc
const unsigned short *foo = U"foo";
const unsigned short bar[] = U"bar";
const unsigned short *fun() { return foo; }
example% CC -xustr=ascii_utf16_ushort file.cc -c
An 8-bit character literal can be prepended with U to form a 16-bit
UTF-16 character of type unsigned short. Examples:
const unsigned short x = U'x';
const unsigned short y = U'\x79';
-xvector[=a]
Enables automatic generation of calls to the vector library and/or
the generation of the SIMD (Single Instruction Multiple Data) in‐
structions on processors that support SIMD. You must use default
rounding mode by specifying -fround=nearest when you use this op‐
tion.
The -xvector option requires optimization level -O3 or greater. The
option is silently ignored if the optimization level is lower than
-xO3.
a can have the following values (prefix no% disables a sub-option):
[no%]lib
(Oracle Solaris) Enables the compiler to transform math library
calls within loops into single calls to the equivalent vector
math routines when such transformations are possible. This
could result in a performance improvement for loops with large
loop counts. Use no%lib to disable this option.
[no%]simd
(SPARC) For -xarch=sparcace, -xarch=sparcaceplus and
-xarch=sparcace2 directs the compiler to use floating point and
integral SIMD instructions to improve the performance of cer‐
tain loops. Contrary to that of the other SPARC -xarch values
under -xarch=sparcace, -xarch=sparcaceplus and -xarch=sparcace2
-xvector=simd is in effect unless -xvector=none or -xvec‐
tor=no%simd has been specified. In addition -xO4 or greater is
required for -xvector=simd, otherwise -xvector=simd is ignored.
For all other -xarch values, directs the compiler to use the
Visual Instruction Set [VIS1, VIS2, ViS3, etc.] SIMD instruc‐
tions to improve the performance of certain loops. Basically
with explicit -xvector=simd option, the compiler will perform
loop transformation enabling the generation of special vector‐
ized SIMD instructions to reduce the number of loop iterations.
In addition to the optimization level requirement noted below,
the -xvector=simd option is effective only if -xarch=sparcvis3
and above.
[no%]simd
(x86) Directs the compiler to use the native x86 SSE SIMD in‐
structions to improve performance of certain loops. Streaming
extensions are used on x86 by default at optimization 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=woodcrest,
-xarch=generic, -xarch=sse2, -xarch=sse3, or -fast on a modern
platform to use it. If the target ISA has no streaming exten‐
sions, the sub-option will have no effect.
%none
Disable this option entirely.
yes
This option is deprecated, specify -xvector=lib instead.
no
This option is deprecated, specify -xvector=%none instead.
On x86, the default is -xvector=simd. On SPARC, the default is
-xvector=simd under -xarch=sparcace, -xarch=sparcaceplus and
-xarch=sparcace2, and -xvector=%none on other SPARC -xarch values.
If you specify -xvector without a sub-option, the compiler assumes
-xvector=simd,lib on x86 Oracle Solaris, -xvector=lib on SPARC Ora‐
cle 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.
If you compile and link with separate commands, be sure to use the
same -xvector option in the linking CC command.
-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. Specify‐
ing -xvis is equivalent to specifying -xvis=yes.
The VIS instruction set is an extension to the SPARC V9 instruction
set. Even though the UltraSPARC processors are 64-bit, there are
many cases, especially in multimedia applications, when the data
are limited to eight or 16 bits in size. The VIS instructions can
process four 16-bit data with one instruction so they greatly im‐
prove the performance of applications that handle new media such as
imaging, linear algebra, signal processing, audio, video and net‐
working.
-xvpara
Issues warnings about potential parallel-programming related prob‐
lems that may cause incorrect results when using OpenMP. Use with
-xopenmp and OpenMP API directives.
The compiler issues warnings when it detects the following situa‐
tions:
o Loops are parallelized using MP directives with data de‐
pendencies between different loop iterations.
o OpenMP data-sharing attributes-clauses are problematic.
For example, declaring a variable "shared" whose ac‐
cesses in an OpenMP parallel region may create a data
race, or declaring a variable "private" whose value in a
parallel region is used after the parallel region.
No warnings appear if all parallelization directives are processed
without problems.
Example:
CC -xopenmp -xvpara any.cc
-xwe
Converts all warnings to errors by returning non-zero exit status.
-Yc,path
Specifies a new path for the location of component c.
If the location of a component is specified, then the new path name
for the component is path/component_name. This option is passed to
ld.
Values:
c must be one of the following values.
p Changes the default directory for cpp.
0 Changes the default directory for ccfe.
a Changes the default directory for fbe.
2 Changes the default directory for iropt.
c Changes the default directory for cg (SPARC).
O Changes the default directory for ipo.
k Changes the default directory for CClink.
l Changes the default directory for ld.
f Changes the default directory for c++filt.
m Changes the default directory for mcs.
u Changes the default directory for ube (x86).
A Specifies a directory to search for all compiler com‐
ponents. If a component is not found in path, the
search reverts to the directory where the compiler is
installed.
P Adds path to the default library search path. This
path will be searched before the default library
search paths.
S Changes the default directory for startup object
files.
Interactions:
You can have multiple -Y options on a command line. If more than
one -Y option is applied to any one component, then the last occur‐
rence holds.
See also: Oracle Solaris Linker and Libraries Guide
-z arg
Link editor option.
-xMerge, -ztext, and -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 ini‐
tialized, position-dependent symbol relocations in writable stor‐
age.
For more information see the ld(1) man page and the Oracle Solaris
Linker and Libraries Guide.
PRAGMAS
The following #pragmas are recognized by the compilation system:
#pragma align
#pragma does_not_read_global_data
#pragma does_not_return
#pragma does_not_write_global_data
#pragma dumpmacros
#pragma end_dumpmacros
#pragma fini
#pragma hdrstop
#pragma ident
#pragma init
#pragma must_have_frame
#pragma pack
#pragma rarely_called
#pragma returns_new_memory
#pragma unknown_control_flow
#pragma weak
#pragma does_not_read_global_data
#pragma does_not_write_global_data
#pragma no_side_effect
SPARC only:
#pragma no_side_effect
Refer to the Oracle Developer Studio
12.6:
C++ User's Guide for more information on these pragmas.
ENVIRONMENT VARIABLES
SUN_PROFDATA=profdir
If set, store profile data collected from a program compiled with
-xprofile=collect in a directory named profdir in the current work‐
ing directory at the time that the program is executed. If the op‐
tional argument :profdir was specified in -xprofile=col‐
lect[:profdir] at compilation time, SUN_PROFDATA 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.
SUN_PROFDATA_REPLACE={objfile,program,all}
SUN_PROFDATA_REPLACE indicates the scope of profile data to be re‐
set when a changed version of an object file is detected at run‐
time. Use SUN_PROFDATA_REPLACE to ensure that profile data are con‐
sistent with the profiled program within the specified unit of pro‐
gram scope.
The values of SUN_PROFDATA_REPLACE and their meanings are as fol‐
lows:
objfile
Reset profile data of changed object file.
program
Reset profile data of all object files in program containing
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_PROFDATA_RE‐
PLACE=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 pro‐
file data reset. Relevant options include -xOn and -xipo=n.
SUN_PROFDATA_ASYNC_INTERVAL=async_interval
Set this environment variable to enable asynchronous profile col‐
lection. In asynchronous profile collection, profile data are col‐
lected 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 envi‐
ronment 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(3LIB) 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 environment
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 collec‐
tor to stderr. SUN_PROFDATA_ASYNC_VERBOSE has no effect unless
asynchronous profile collection is enabled.
SUN_PROFDATA_CLEANUP_AFTER_EXIT=[0|1]
If set to 1, enables profiler to clean up its data structures be‐
tween the time that the process calls exit() and the time that
process exit is complete. If set to 0, avoids destructive interfer‐
ence with profile collection by application threads that have not
terminated before the application calls exit(). See exit(3C) for
details. The default setting is SUN_PROFDATA_CLEANUP_AFTER_EXIT=0.
Refer to the Oracle Developer Studio
12.6:
OpenMP API User's Guide for information about environment
variables that can be set for an OpenMP program or a program automati‐
cally parallelized by the -xautopar compiler option.
FILES
file.a Static library
file.C Input file
file.cc Input file
file.c++ Input file
file.cpp Input file
file.cxx Input file
file.o Object file
file.so Dynamic (shared) library
a.out Linked output
libC.so.5 legacy C++ runtime library
libCrun.so.1 C++ runtime library for -compat=5
libCrunG3.so.1 C++ runtime library for -compat=g
libCrunG3.a Static version of libCrunG3.so.1
libCstd.so.1 C++ runtime library for -compat=5
libdemangle.so.1 C++ demangler library
libiostream.so.1 C++ runtime library for i/o streams with -compat=5
libm.so system math library
libmmheap.so.1 memory allocator for Studio compilers and runtimes
libmtsk_db.so.1 debugging support library for -xautopar and
-xopenmp
libmtsk.so.1 runtime library for -xautopar and -xopenmp
libmvec.so.1 system vector math library
libstkovf.so.1 runtime library for stack overflow diagnosis
libsunmath.so.1 system math library extensions
libsunperf.so Sun Performance library
libtdf.so.1 file access library for -xprofile
libxprof_audit.so.1 linker audit library for -xprofile
libxprof.so.1 runtime library for -xprofile
llib-lm system math lint library
llib-lm.ln system math lint library
llib-lsunmath System math extensions lint library
llib-lsunmath.ln System math extensions lint library
xprof_fini.o Initialization and finalization handlers for pro‐
grams compiled with -xprofile=collect
SEE ALSO
analyzer(1), as(1), c++filt(1), cc(1), csh(1), dbx(1), gprof(1) ,
ld(1), more(1), nm(1), prof(1), tcov(1)
Oracle Developer Studio
12.6:
C++ User's Guide
C++ Migration Guide,
The C++ Programming Language, Third Edition, Bjarne Stroustrup, Addi‐
son-Wesley 1997
The C Programming Language, B. W. Kernighan and D. M. Ritchie, Pren‐
tice-Hall 1988
Oracle Solaris Linker and Libraries Guide
International Standard (ISO/IEC FDIS 14882), Programming Languages --
C++
NOTES
Certain floating-point math library routines return error status in the
errno variable (defined in errno.h). With compiler options -fast,
-xbuiltin, -xlibmieee, -xlibmil, -xlibmopt the compiler is free to re‐
place 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 re‐
lies on the value of errno or a floating-point exception being raised
after a floating point function call could produce inconsistent re‐
sults.
One way around this problem is to avoid compiling such codes with these
options, such as -fast.
However, if -fast optimization is required and the code depends on the
value of errno being set properly or an appropriate floating-point ex‐
ception being raised after floating-point library calls, you should
compile with the options
-xbuiltin=none -U__MATHERR_ERRNO_DONTCARE \
-xlibmopt=%none -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.
Studio 12.6 May 2017 CC(1)