cc [-#] [-###] [-Aname[(tokens)]] [-ansi]
[-B[static|dy- namic]] [-C] [-c] [-D] [-d[y|n]] [-dalign]
[-E] [-errfmt[=[no%]error]] [-errhdr[=h]]
[-erroff[=t[,t...]]] [-errshort[=i]] [-errtags=a]
[-errwarn[=t[,t...]]] [-fast] [-fd] [-features=[a]]
[-flags] [-flteval[={any|2}]] [-fma[={none|fused}]]
[-fnonstd] [-fns=[no|yes]] [-fopenmp] [-fprecision=p]
[-fround=r] [-fsimple[=n]] [-fsingle] [-fstore]
[-ftrap[=t[,t...]]] [-G] [-g] [-g[n]] [-H] [-hname]
[-I[-|dir]] [-i] [-include] [-KPIC] [-Kpic] [-keeptmp]
[-Ldir] [-lname] [-library=sunperf] [-m32|-m64] [-mc]
[-misalign] [-misalign2] [-mr[,string]] [-mt] [-native]
[-nofstore] [-O] [-On] [-ofilename] [-P] [-p]
[-pedantic{=[yes|no]}] [-preserve_argvalues[=int|none]]
[-Qoption phase [,option...]] [-Q[y|n]] [-qp]
[-Rdir[:dir...]] [-S] [-s] [-staticlib=[no%]sunperf]
[-std=value] [-temp=path] [-traceback[=list]] [-Uname]
[-V] [-v] [-Wc,arg] [-w] [-X[c|a|t|s]] [-Xlinker arg]
[-xaddr32[={yes|no}]] [-xalias_level[=a]]
[-xanalyze={code|no}] [-xannotate] [-xarch=a]
[-xautopar] [-xbinopt={a}] [-xbuiltin[=a]] [-xCC]
[-xc99[=o]] [-xcache=c] [-xchar[=o]]
[-xchar_byte_order[=o]] [-xcheck=n] [-xchip=c]
[-xcode=v] [-xcsi] [-xdebugfor- mat=[stabs|dwarf]]
[-xdebuginfo=a[,a...]] [-xdepend[={yes|no}]]
[-xdryrun] [-xdumpmacros[=v[,v...]]] [-xe] [-xF[=v]]
[-xglobalize[={yes|no}]] [-xhelp=f]
[-xhwcprof[={enable|disable}]] [-xinline=[v[,v...]]]
[-xinline_param=a[,a[,a]...]] [-xinline_report[=n]]
[-xinstrument=[no%]datarace] [-xipo[=n]]
[-xipo_archive[=a]] [-xipo_build=[yes|no]]
[-xivdep[=p]] [-xjobs={n|auto}]
[-xkeep_unref[={[no%]funcs,[no%]vars}]]
[-xkeepframe[=p]] [-xlang=language] [-xldscope=[v]]
[-xlibmieee] [-xlibmil] [-xlibmopt] [-xlicinfo]
[-xlinkopt[=level]] [-xloopinfo] [-xM] [-xM1] [-xMD]
[-xMF] [-xMMD] [-xMerge] [-xmaxopt[=v]] [-xmemalign=ab]
[-xmodel=[a]] [-xnolib] [-xnolibmil] [-xnolibmopt]
[-xnorunpath] [-xOn] [-xopenmp[=i]] [-xP]
[-xpagesize=n] [-xpagesize_heap=n] [-xpagesize_stack=n]
[-xpatchpadding[={fix|patch|size}]] [-xpec] [-xpch=v]
[-xpchstop] [-xpentium] [-xpg] [-xprefetch[=val[,val]]]
[-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] [-xsegment_align=n] [-xsfpconst]
[-xspace] [-xstrconst] [-xtarget=t] [-xtemp=path]
[-xthreadvar[=o] [-xthroughput[={yes|no}]] [-xtime]
[-xtransition] [-xtrigraphs[=[yes|no]]
[-xunboundsym={yes|no}] [-xunroll=n]
[-xustr={ascii_utf16_ushort|no}] [-xvector[=a]] [-xvis]
[-xvpara] [-Yc,dir] [-YA,dir] [-YI,dir] [-YP,dir]
[-YS,dir] [-Zll]
Oracle Solaris Studio 12.4 C Compiler version 5.13.
This man page details the options or flags that are available for the C compiler in the Oracle Solaris Studio 12.4 release.
Complete documentation for this release is available on the Oracle Technical Network (OTN) Solaris Studio website:
http://oracle.com/technetwork/server-storage/solarisstudio
The OTN website is a complete resource for Oracle Solaris Studio and includes many technical articles detailing best practices and deep dives into various programming technologies and other topics.
For the complete description of all new features and functionality in the Oracle Solaris Studio suite, see the What's New in this Release Guide.
A man page, by definition, is a quick reference. For more detailed information on the C compiler and its options, see the C User's Guide.
Use the -m32 and -m64 options to specify the memory model of the target compilation, ILP32 or LP64 respectively.
The -xarch option no longer carries an implicit memory model definition, and should be used only to specify the instruction set of the target processor.
The ILP32 model specifies that C-language int, long, and pointer data types are all 32-bits wide. The LP64 model specifies that long and pointer data types are all 64-bits wide. The Oracle Solaris and Linux OS also support large files and large arrays under the LP64 memory model.
When compiling with -m64, the resulting executable will work only on 64-bit SPARC or x86 processors under Oracle Solaris OS or Linux OS running a 64-bit kernel. Compilation, linking, and execution of 64-bit objects can only take place in a Oracle Solaris or Linux OS that supports 64-bit execution.
There are some important issues to be aware of when compiling for x86 Oracle Solaris platforms.
Programs compiled with -xarch set to sse, sse2, sse2a, or sse3 and beyond must be run only on platforms that provide these extensions and features.
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 compiler and with same -xarch setting to ensure that the correct startup routine is linked.
Numerical results with -xarch=pentium_pro or -xarch=sse might differ from results on SPARC due to the x86 80-bit floating-point registers. To minimize these differences, use the -fstore option or compile with the default -xarch=sse2.
Numerical results can also differ between Oracle Solaris and Linux because the intrinsic math libraries (for example, sin(x)) are not the same.
Since the release of Oracle Solaris 10, the linker will automatically check the compatibility of binary objects against the runtime hardware platform.
Program binaries compiled and built using specialized -xarch hardware flags are verified by the OS that they are being run on the appropriate platform. Running programs compiled with specialized -xarch options on platforms that are not enabled with the appropriate features or instruction set extensions could result in segmentation faults or incorrect results occurring without any explicit warning messages.
On Linux, however, there is no such verification check. Running binary objects compiled by Oracle Solaris 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 SSE, SSE2, SSE2a, and SSE3 (and beyond) instructions and extensions.
The cc (1) manual page describes the ISO C compiler options that are SVID compliant under current Oracle Solaris operating systems. Take note that the C compiler recognizes by default some of the constructs of the 2011 ISO/IEC C standard. Specifically, the supported features are detailed in the C User's Guide. Use the -std flag to limit the compiler to a specific version of the ISO/IEC C standard.
cc is the interface to the C compilation system. The compilation process incorporates a preprocessor, compiler, code generator, optimizer, assembler, and link editor. cc processes the supplied options and then executes the various components with the proper arguments. cc accepts several types of files as arguments.
Files with .c suffix are taken to be C source files and may be preprocessed, compiled, optimized, instrumented for profiling, assembled, and link edited. Although the preprocessor can be used as a macro processor, this is not recommended, as its output is geared toward that which would be acceptable as input to a valid C compiler. The compilation process may be stopped after the completion of any pass if the appropriate options are supplied.
If the compilation process runs through the assembler, then an object file is produced in the current working directory with .o suffix substituted for .c. However, the .o file is normally deleted if a single C file is compiled and then immediately link edited.
Files with .s suffix are taken to be assembly source files; they may be assembled and link edited.
Files with .S suffix are taken to be assembly source files; they may be assembled and link edited. Such files are passed to the preprocessor (/usr/ccs/lib/cpp on Oracle Solaris), and then to the assembler.
Files with an .i are taken to be preprocessed C source files, and may be compiled, optimized, instrumented for profiling, assembled, and link edited. Files whose names do not end in .c, .s, .S or .i are passed to the link editor, which produces a dynamically linked executable whose name by default is a.out.
See option -Yc, dir to change the default directories used for finding libraries. dir is a colon-separated path list.
The default library search order can be seen by using the -### or -xdryrun option and examining the -Y option of the ld invocation.
The default compiler options file enables the user to specify a set of default options that are applied to all compiles, unless otherwise overridden. For example, the file could specify that all compiles default at -xO2, or automatically include the file setup.il.
At startup, the compiler searches for a default options file listing default options it should include for all compiles. The environment variable SPRO_DEFAULTS_PATH specifies a colon-separated list of directories to search for the the defaults file.
If the environment variable is not set, a standard set of defaults is used. If the environment variable is set but is empty, no defaults are used.
The defaults file name must be of the form compiler.defaults, where compiler is one of the following: cc, c89, c99, CC, ftn, or lint. For example, the defaults for the C compiler would be cc.defaults
If a defaults file for the compiler is found in the directories listed in SPRO_DEFAULTS_PATH, the compiler will read the file and process the options prior to processing the options on the command line. The first defaults file found will be used and the search terminated.
System administrators may create system-wide default files in Studio-install-path/prod/etc/config. If the environment variable is set, the installed defaults file will not be read.
The format of a defaults file is similar to the command line. Each line of the file may contain one or more compiler options separated by white space. Shell expansions, such as wild cards and substitutions, will not be applied to the options in the defaults file.
The value of the SPRO_DEFAULTS_PATH and the fully expanded command line will be displayed in the verbose output produced by options -#, -###, and -dryrun.
Options specified by the user on the command line will usually override options read from the defaults file. For example, if the defaults file specifies compiling with -xO4 and the user specifies -xO2 on the command line, -xO2 will be used.
Some options appearing in the default options file will be appended after the options specified on the command line. These are the preprocessor option -I, linker options -B, -L, -R, and -l, and all file arguments, such as source files, object files, archives, and shared objects.
The following is an example of how a user-supplied default compiler option startup file might be used.
demo% cat /project/defaults/cc.defaults -fast -I/project/src/hdrs -L/project/libs -llibproj -xvpara demo% setenv SPRO_DEFAULTS_PATH /project/defaults demo% cc -c -I/local/hdrs -L/local/libs -lliblocal tst.c
The compiler command is now equivalent to:
cc -fast -xvpara -c -I/local/hdrs -L/local/libs -lliblocal \
tst.c -I/project/src/hdrs -L/project/libs -llibproj
While the compiler defaults file provides a convenient way to set the defaults for an entire project, it can become the cause of hard to diagnose problems. Set the environment variable SPRO_DEFAULTS_PATH to an absolute path rather than the current directory to avoid such problems.
The interface stability of the default options file is uncommitted. The order of option processing is subject to change in a future release.
All platform-specific options are silently accepted on all platforms. Any exceptions to this rule are noted under the specific option.
Options valid only on SPARC platforms are marked (SPARC). Options valid only on x86/x64 platforms are marked (x86).
Deprecated options are marked (Obsolete) and should not be used going forward. They are provided only for compatibility with earlier releases. Use the indicated replacement option.
See ld(1) for linker options.
In general, processing of the compiler options is from left to right, permitting selective overriding of macro options. This rule does not apply to linker or preprocessor options.
In the syntax of the command-line options, items shown in square brackets ( [] ) are optional. Curly brackets enclose a bar-separated list of literal items to be chosen, as in {yes | no | maybe }. The first item in a list usually indicates the default value when the flag appears without a value.
For example, -someoption[={no|yes}] implies -someoption is the same as -someoption=no.
The following options are interpreted by cc:
Turns on verbose mode, showing how command options expand. Shows each component as it is invoked.
Shows each component as it would be invoked, but does not actually execute it. Also shows how command options would expand.
Associate name as a predicate with the specified tokens as if by a #assert preprocessing directive.
Preassertions:system(unix)
machine(sparc) (SPARC)
machine(i386) (x86)
cpu(sparc) (SPARC)
cpu(i386) (x86)
The above are not predefined in -pedantic mode.
If -A is followed by a dash (-) only, it causes all predefined macros (other than those that begin with __) and predefined assertions to be forgotten.
Equivalent to -std=c89.
Specifies whether bindings of libraries for linking are static or dynamic, indicating whether libraries are non-shared or shared, respectively. -B dynamic causes the link editor to look for files named libx.so and then for files named libx.a when given the -lx option. -B static causes the link editor to look only for files named libx.a. This option may be specified multiple times on the command line as a toggle.
Note: Many system libraries, such as libc, are only available as dynamic libraries in the Oracle Solaris 64-bit compilation environment. Therefore, do not use -Bstatic as the last toggle on the command line.
This option and its argument are passed to ld.
Prevents the C preprocessor from removing comments, other than those on preprocessing directive lines.
Compile and produce a .o file for each source file without linking. You can explicitly name a single object file by using the -o option. When the compiler produces object code for each or input file, it always creates an object file in the current working directory. If you suppress the linking step, you also suppress the removal of the object files.
Define a macro with optional arguments as if the macro is defined by a #define preprocessing directive. If no =expansion is specified, the compiler assumes =1.
Predefinitions:unix
sparc (SPARC)
sun
The above are not predefined in -pedantic mode.
These predefinitions are valid in all modes:
__BUILTIN_VA_ARG_INCR __SUNPRO_C=0x5120 __SVR4 (Oracle Solaris) __SunOS_5_10 (Oracle Solaris) __SunOS_5_11 (Oracle Solaris) __amd64 (x86 -m64) __gnu__linux (linux) __i386 (x86) __linux (linux) __linux__ (linux) __sparc (SPARC) __sparcv8 (SPARC) __sparcv9 (SPARC -m64) __sun (Oracle Solaris) __unix __`uname -s`_`uname -r | tr . _` __x86_64 (x86 -m64) linux (x86, linux)
The following is predefined with any -std flag value when -pedantic is not specified to indicate the availability of the _Restrict keyword:
__RESTRICT
The compiler also predefines the following object-like macro to indicate the pragma will be recognized:
__PRAGMA_REDEFINE_EXTNAME
Allow or disallow dynamic linking.
-dy specifies dynamic linking, which is the default, in the link editor. -dn specifies static linking in the link editor.
This option and its argument are passed to ld.
Note: This option causes fatal errors if you use it in combination with dynamic libraries. Most system libraries are only available as dynamic libraries.
(SPARC) (Obsolete) You should not use this option. Use -xmemalign=8s instead. For a complete list of obsolete options and flags, see the C User's Guide. Ignored on x64/x86 platforms.
Runs the source file through the preprocessor only and sends the output to stdout. The preprocessor is built directly into the compiler, except in -Xs mode, where /usr/ccs/lib/cpp is invoked. Includes the preprocessor line numbering information. See also -P option.
Use this option if you want to prefix the string "error:" to the beginning of error messages so they are more easily distinguishable from warning messages. The prefix is also attached to warnings that are converted to errors by -errwarn.
Add the prefix "error:" to all error messages.
Do not add the prefix "error:" to any error messages.
If you do not use this option, the compiler sets it to -errfmt=no%error. If you use specify -errfmt, but do not supply a value, the compiler sets it to -errfmt=error.
Use this option to limit the warnings from header files to the group of header files indicated by the following flags:
Check all used header files.
Check none of the header files.
Default. Checks all the user header files. Does not check system include files, those in /usr/include and its subdirectories. Does not check system header files supplied by the compiler.
Suppresses compiler warning messages but has no effect on error messages. This option applies to all warning messages whether or not they have been designated by -errwarn to cause a non-zero exit status.
The -erroff values are members of a comma-separated list that consists of one or more of the following:
Suppresses the warning message specified by this tag. You can display the tag for a message by using the -errtags=yes option.
Enables the warning message specified by this tag.
Suppresses all warning messages.
Enables all warning messages. This is the default.
Order is important; for example, %all,no%tag suppresses all warning messages except tag.
The default is -erroff=%none. Specifying -erroff is equivalent to specifying -erroff=%all.
Only warning messages from the C compiler front-end that display a tag when the -errtags option is used can be suppressed with the -erroff option. You can achieve finer control over error message suppression by using #pragma error_messages.
Use this option to control how much detail is in the error message produced by the compiler when it discovers a type mismatch. This option is particularly useful when the compiler discovers a type mismatch that involves a large aggregate.
i can be one of the following:
Error messages are printed in short form with no expansion of types. Aggregate members are not expanded, neither are function argument and return types.
Error messages are printed in full verbose form showing the full expansion of the mismatched types.
Error messages are printed with tag names for types which have tag names. If there is no tag name, the type is shown in expanded form.
If you do not use -errshort, the compiler sets the option to -errshort=full. If you specify -errshort, but do not provide a value, the compiler sets the option to -errshort=tags.
This option does not accumulate, it accepts the last value specified on the command line.
Displays the message tag for each warning message of the C compiler front-end that can be suppressed with the -erroff option or made a fatal error with the -errwarn option. Messages from the C compiler driver and other components of the C compilation system do not have error tags, and cannot be suppressed with -erroff and made fatal with -errwarn.
a can be either yes or no. The default is -errtags=no. Specifying -errtags is equivalent to specifying -errtags=yes.
Use the -errwarn option to cause the C compiler to exit with a failure status for the given warning messages.
t is a comma-separated list that consists of one or more of the following: tag, no%tag, %all, %none. Order is important; for example %all,no%tag causes the C compiler to exit with a fatal status if any warning except tag is issued.
The warning messages generated by the C compiler change from release to release as the compiler error checking improves and features are added. Code that compiles using -errwarn=%all without error may not compile without error in the next release of the compiler.
Only warning messages from the C compiler front-end that display a tag when the -errtags option is used can be specified with the -errwarn option to cause the C compiler to exit with a failure status.
The default is -errwarn=%none. If you specify -errwarn alone, it is equivalent to -errwarn=%all.
The following table details the -errwarn values:
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.
Prevent cc from exiting with a fatal status if the message specified by tag is issued only as a warning message. Has no effect if tag is not issued. Use this option to revert a warning message that was previously specified by this option with tag or %all from causing cc to exit with a fatal status when issued as a warning message.
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.
Prevents any warning messages from causing cc to exit with a fatal status should any warning tag be issued. This is the default.
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 -# or the -xdryrun options to examine the expansion of -fast, and incorporate the appropriate options of -fast into the ongoing process of tuning the executable.
The expansion of -fast includes -xlibmopt option, which enables the compiler to use a library of optimized math routines. For more information, see the description of -xlibmopt in this man page.
The -fast option impacts the value of errno. See the NOTES section at the end of this man page for more information.
Modules that are compiled with -fast must also be linked with -fast. For a complete list of compiler options that must be specified at both compile time and at link time, see the C User's Guide.
The -fast option is unsuitable for programs that are intended to run on a different target than the compilation machine. In such cases, follow -fast with the appropriate -xtarget option. For example:
% cc -fast -xtarget=generic
For C modules depending on exception handling specified by SUID, follow -fast by -xnolibmil -xbuiltin=%default
% cc -fast -xnolibmil -xbuiltin=%default
The -fast option acts like a macro expansion on the command line. Therefore, you can override any of the expanded options by following -fast with the desired option.
If you combine -fast with other options, the last specification applies.
These options are turned on for -fast:
-fma=fused (SPARC, x86) -fns (SPARC, x86) -fsimple=2 (SPARC, x86) -fsingle (SPARC, x86) -nofstore (x86) -xalias_level=basic (SPARC, x86) -xbuiltin=%all (SPARC, x86) -xdepend (SPARC, x86) -xlibmil (SPARC, x86) -xlibmopt (SPARC, x86) -xmemalign=8s (SPARC) -xO5 (SPARC, x86) -xregs=frameptr (x86) -xtarget=native (SPARC, x86)
Note that this selection of component option flags is subject to change with each release of the compiler. For details on the options set by -fast, see the C User's Guide.
To determine the expansion of -fast on a running system, execute the command:
cc -fast -xdryrun |& grep ###
Note: Some optimizations make certain assumptions about program behavior. If the program does not conform to these assumptions, the application may crash or produce incorrect results. Please refer to the description of the individual options to determine if your program is suitable for compilation with -fast.
Do not use this option for programs that depend on IEEE standard exception handling; you can get different numerical results, premature program termination, or unexpected SIGFPE signals.
The -fast option on x86 includes -xregs=frameptr. Be sure to read the discussion of -xregs=frameptr especially when compiling mixed C, Fortran, and C++ source codes.
Reports K&R function declarations and definitions.
The compiler's treatment of extern inline functions conforms by default to the behavior specified by the ISO/IEC 9899:1999 C standard. Compile new codes with -features=no%extinl to obtain the same treatment of extern inline functions as provided by versions 5.5, or older, of the C and C++ compilers.
Old C and C++ objects (pre C/C++ 5.6) can be linked with new C and C++ objects with no change of behavior for the old objects. To get standard conforming behavior, old code must be recompiled using the current compiler.
The following table lists the possible values for a. Prefix no% disables a suboption.
Enables or disables the placement of string literals in read-only memory. The default is -features=conststrings which replaces the deprecated -xstrconst option. Note that your program will fail to write to a string literal under the default compilation mode just as if you had specified -xstrconst on the command line.
Allows/disallows zero-sized struct/union declarations and void function with return statements returning a value to work.
Generates extern inline functions as global functions. This is the default, which conforms with the 1999 C standard.
Generates extern inline functions as static functions.
Enables/disables recognition of the typeof operator. The typeof operator returns the type of its argument (either an expression or a type). It is specified syntactically like the sizeof operator, but it behaves semantically like a type defined with typedef. Accordingly, it can be used anywhere a typedef can be used. For example, it can be used in a declaration, a cast, or inside of a sizeof or typeof. The default is -features=typeof.
The option -features=%none is deprecated and should be replaced by -features=no% followed by the suboption.
Examples:
typeof(int) i;/* declares variable "i" to be type int*/
typeof(i+10) j;/* declares variable "j" to be type int,
the type of the expression */
i = sizeof(typeof(j)); /* sizeof returns the size of
the type associated with variable "j" */
int a[10];
typeof(a) b;/* declares variable "b" to be array of
size 10 */
The typeof operator can be especially useful in macro definitions, where arguments may be of arbitrary type. For example:
#define SWAP(a,b)
{ typeof(a) temp; temp = a; a = b; b = temp; }
Same as -xhelp=flags. Prints a one-line summary of available options.
(x86) Use this option to control how floating point expressions are evaluated.
Floating point expressions are evaluated as long double.
Floating point expressions are evaluated depending on the combination of the types of the variables and constants that make up an expression.
If you do not specify -flteval, the compiler sets it to -flteval=any. If you do specify -flteval, but do not provide a value, the compiler sets it to -flteval=2.
-flteval=2 is only usable with -xarch=sse, pentium_pro, ssea, or pentium_proa.
-flteval=2 is also not compatible in combination with options -fprecision or -nofstore.
For more information, see 'Precision of Floating Point Evaluators' in appendix E of the C User's Guide.
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 instructions are generated in order to prevent the program from executing on platforms that do not support fused multiply-add instructions. When the minimum architecture is not used, then -fma=fused has no affect.
Fused multiply-add instructions eliminate the intermediate rounding step between the multiply and add. Consequently, programs may produce different results when compiled with -fma=fused although precision will tend to increase rather than decrease.
Macro for -fns and -ftrap=common.
For SPARC, selects the SPARC nonstandard floating-point mode.
For x86, selects SSE flush-to-zero mode and, where available, denormals-are-zero mode. This option causes subnormal results to be flushed to zero on x86. Where available, this option also causes subnormal operands to be treated as zero. This option has no effect on traditional x86 floating-point operations that do not utilize the SSE or SSE2 instruction set.
The default, -fns=no, is standard floating-point mode.
Optional use of =yes or =no provides a way of toggling the -fns flag following some other macro flag that includes -fns, such as -fast.
-fns is the same as -fns=yes. -fns=yes selects non-standard floating-point. -fns=no selects standard floating-point.
On some SPARC systems, the nonstandard floating point mode disables "gradual underflow", causing tiny results to be flushed to zero rather than producing subnormal numbers. It also causes subnormal operands to be silently replaced by zero. On those SPARC systems that do not support gradual underflow and subnormal numbers in hardware, use of this option can significantly improve the performance of some programs.
When nonstandard mode is enabled, floating point arithmetic may produce results that do not conform to the requirements of the IEEE 754 standard. See the Numerical Computation Guide for more information.
On SPARC systems, this option is effective only if used when compiling the main program.
Same as -xopenmp=parallel.
(x86) Initializes the rounding precision mode bits in the Floating-point Control Word to p, which is one of single (24 bits), double (53 bits), or extended (64 bits) respectively. The default floating-point rounding-precision mode is extended.
Note that on x86, only the precision, not exponent, range is affected by the setting of floating-point rounding precision mode.
This option is effective only on x86 systems and only if used when compiling the main program, but is ignored if compiling for 64-bit platforms (-m64), or SSE2-enabled processors (-xarch=sse2). -fprecision is ignored on SPARC platforms.
Sets the IEEE 754 rounding mode that is established at runtime during the program initialization.
r must be one of: nearest, tozero, negative, positive.
The default is -fround=nearest.
The meanings are the same as those for the ieee_flags subroutine.
When r is tozero, negative, or positive, this flag causes the rounding direction mode to be set to round-to-zero, round-to-negative-infinity, or round-to-positive-infinity respectively when a program begins execution. When r is nearest or the -fround flag is not used, the rounding direction mode is not altered from its initial value (round-to-nearest by default).
This option is effective only if used when compiling the main program.
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.
Allows the optimizer to make simplifying assumptions concerning floating-point arithmetic.
The compiler defaults to -fsimple=0. Specifying -fsimple is equivalent to -fsimple=1.
If n is present, it must be 0, 1, or 2.
Permits no simplifying assumptions. Preserves strict IEEE 754 conformance.
Allows conservative simplifications. The resulting code does not strictly conform to IEEE 754.
With -fsimple=1, the optimizer can assume the following:
The IEEE 754 default rounding/trapping modes do not change after process initialization.
Computations producing no visible result other than potential floating- point exceptions may be deleted
Computations with Infinity or NaNs as operands need not propagate NaNs to their results. For example, x*0 may be replaced by 0.
Computations do not depend on sign of zero.
With -fsimple=1, the optimizer is not allowed to optimize completely without regard to roundoff or exceptions. In particular, a floating-point computation cannot be replaced by one that produces different results with rounding modes held constant at runtime.
Includes all the functionality of -fsimple=1, and also enables use of SIMD instructions to compute reductions when -xvector=simd is in effect.
Also permits aggressive floating point optimizations that may cause many programs to produce different numeric results due to changes in rounding. For example, -fsimple=2 permits the optimizer to attempt replace all computations of x/y in a given loop with x*z, where x/y is guaranteed to be evaluated at least once in the loop, z=1/y, and the values of y and z are known to have constant values during execution of the loop.
Even with -fsimple=2, the optimizer still is not permitted to introduce a floating point exception in a program that otherwise produces none.
See also: Techniques for Optimizing Applications: High Performance Computing by Rajat Garg and Ilya Sharapov for a more detailed explanation of how optimization can impact precision. See also articles on performance and precision on the OTN Oracle Solaris Studio website: oracle.com/technetwork/server-storage/solarisstudio/
(-Xt and -Xs modes only) By default -Xs and -Xt follow the K&R C rules for float expressions, by promoting them to double and evaluating them in double precision. Use the -fsingle flag when specifying -Xs or -Xt to cause the compiler to evaluate float expressions as single precision.
(x86) Causes the compiler to convert the value of a floating-point expression or function to the type on the left-hand side of an assignment, when that expression or function is assigned to a variable, or when the expression is cast to a shorter floating-point type, rather than leaving the value in the register. Due to roundoffs and truncation, the results may be different from those generated from the register value. This is the default mode. To turn off this option, use the -nofstore option.
Sets the IEEE 745 trapping mode in effect at startup but does not install a SIGFPE handler. You can use ieee_handler(3M) or fex_set_handling(3M) to simultaneously enable traps and install a SIGFPE handler. If you specify more than one value, the list is processed sequentially from left to right.
Use prefix no% to remove a suboption from %all or common.
Trap on division by zero.
Trap on inexact result.
Trap on invalid operation.
Trap on overflow.
Trap on underflow.
Trap on all the above.
Trap on none of the above.
Trap on invalid, division by zero, and overflow.
The default is -ftrap=%none.
Note that the [no%] form of the option is used only to modify the meanings of the %all or common value and must be used with one of these values, as shown in the example. The [no%] form of the option by itself does not explicitly cause a particular trap to be disabled.
Example: -ftrap=%all,no%inexact means set all traps, except inexact.
If you compile one routine with -ftrap=t, compile all routines of the program with the same -ftrap=t option; otherwise, you can get unexpected results.
Use the -ftrap=inexact trap with caution, as it will result in the trap being issued whenever a floating-point value cannot be represented exactly. For example, the following statement may generate this condition:
x = 1.0 / 3.0;
Produce a shared object rather than a dynamically linked executable. This option is passed to ld and cannot be used with the -dn option.
When you use the -G option, the compiler does not pass any default -l options to ld. If you want the shared library to have a dependency on another shared library, you must pass the necessary -l option on the command line.
If you are creating a shared object by specifying -G along with other compiler options that must be specified at both compile time and link time, make sure that those same options are also specified when you link with the resulting shared object.
When you create a shared object, all the object files that are compiled for 64-bit SPARC architectures must also be compiled with an explicit -xcode value as documented under the description of -xcode.
See -g[n].
Produce additional symbol table information for dbx(1) and the Performance Analyzer analyzer(1).
If you specify -g, and the optimization level is -xO3 or lower, the compiler provides best-effort symbolic information with almost full optimization. Tail-call optimization and back-end inlining are disabled.
If you specify -g and the optimization level is -xO4, the compiler provides best-effort symbolic information with full optimization.
Compile with the -g option to use the full capabilities of the Performance Analyzer. While some performance analysis features do not require -g, you must compile with -g to view annotated source, some function level information, and compiler commentary messages. See the analyzer(1) man page and the Performance Analyzer manual for more information.
The commentary messages that are generated with -g describe the optimizations and transformations that the compiler made while compiling your program. Use the er_src(1) command to display the messages, which are interleaved with the source code.
If you compile and link your program in separate steps, then including the -g option in one step and excluding it from the other step will not affect the correctness of the program, but it will affect the ability to debug the program. Any module that is not compiled with -g but is linked with -g will not be prepared properly for debugging. Note that compiling the module that contains the function main with the -g option is usually necessary for debugging.
-g is implemented as a macro that expands to various other, more primitive, options. See -xdebuginfo for the details of the expansions.
Values:
Produce standard debugging information.
Do not produce any debugging information. This is the default.
Produce file and line number as well as simple parameter information that is considered crucial during post-mortem debugging.
Same as -g.
Produce additional debugging information, which currently consists only of macro definition information. This added information can result in an increase in the size of the debug information in the resulting .o and executable when compared to using only -g.
Prints, one per line, the path name of each file included during the current compilation to standard error.
Assigns a name to a shared dynamic library; allows you to keep different versions of a library.
In general, the name after -h should be the same as the file name given in the -o option. The space between -h and name is optional.
The linker assigns the specified name to the library and records the name in the library file as the intrinsic name of the library. If there is no -h name option, then no intrinsic name is recorded in the library file.
When the runtime linker loads the library into an executable file, it copies the intrinsic name from the library file into the executable, into a list of needed shared library files. Every executable has such a list. If there is no intrinsic name of a shared library, then the linker copies the path of the shared library file instead.
-Idir adds dir to the list of directories that are searched for #include files. -I values accumulate from left to right.
For include statements of the form #include <foo.h>, the preprocessor searches for the header file in the following order:
The directories named with the -I option, if any.
The compiler and system standard directories, usually /usr/include.
For include statements of the form #include "foo.h", the compiler searches the directories in the following order:
The current directory (that is, the directory that contains the file which contains the include statement itself.
The directories named with -I options, if any.
The compiler and system standard directories, usually /usr/include.
-I- changes the include-file search rules to the following:
The compiler never searches the current directory, unless the directory is listed explicitly in a -I directive. This effect applies even for include statements of the form #include "foo.h".
For include files of the form #include "foo.h", search the directories in the following order:
The directories named with -I options (both before and after -I-).
The compiler and system standard directories, usually /usr/include.
For include files of the form #include <foo.h>, search the directories in the following order:
The directories named with the -I options that appear after -I- (that is, the compiler does not search the -I directories that appear before -I-).
The compiler and system standard directories, usually /usr/include.
Only the first -I- option on the command line works as described above.
-Idir looks in dir, prior to usr/include, for included files whose names do not begin with slash (/). Directories for multiple -I options are searched in the order specified.
Warnings:
Never specify the compiler installation area, /usr/include, /lib, /usr/lib, as search directories.
Ignores the LD_LIBRARY_PATH and LD_LIBRARY_PATH_64 settings.
This option causes the compiler to treat filename as if it appears in the first line of a primary source file as a #include preprocessor directive.
The first directory the compiler searches for filename is the current working directory and not the directory containing the main source file, as is the case when a file is explicitly included. If the compiler cannot find filename in the current working directory, it searches the normal directory paths. If you specify multiple -include options, the files are included in the order they appear on the command line.
(SPARC) (Obsolete) You should not use this option. Use -xcode=pic32 instead. For a complete list of obsolete options and flags, see the C User's Guide.
(x86) -KPIC is identical to -Kpic on x86 architectures.
(SPARC) (Obsolete) You should not use this option. Use -xcode=pic13 instead. For a complete list of obsolete options and flags, see the C User's Guide.
(x86) Produces position-independent code. Use this option to compile source files when building a shared library. Each 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.
Retains temporary files created during compilation, instead of deleting them automatically.
Adds dir to the list of directories searched for libraries by ld. This option and its arguments are passed to ld.
Warnings:
Never specify the compiler installation area, /usr/include, /lib, /usr/lib, as search directories.
Links with object library libname.so or libname.a (for ld(1)). The order of libraries in the command line is important, as symbols are resolved from left to right. This option must follow the sourcefile.
Link with the Oracle Solaris Studio supplied performance libraries.
Specifies the memory model for the compiled binary object.
Use -m32 to create 32-bit executables and shared libraries. Use -m64 to create 64-bit executables and shared libraries.
The ILP32 memory model (32-bit int, long, pointer data types) is the default on all Oracle Solaris platforms and on Linux platforms that are not 64-bit enabled. The LP64 memory model (64-bit long, pointer data types) is the default on Linux platforms that are 64-bit enabled. -m64 is permitted only on platforms that are enabled for the LP64 model.
Object files or libraries compiled with -m32 cannot be linked with object files or libraries compiled with -m64.
When compiling applications with large amounts of static data using -m64, -xmodel=medium may also be required. Be aware that some Linux platforms do not support the medium model.
Modules that are compiled with -m32|-m64 must also be linked with -m32|-m64. For a complete list of compiler options that must be specified at both compile time and at link time, see the C User's Guide.
Note that in previous compiler releases, the memory model, ILP32 or LP64, was implied by the choice of the instruction set with -xarch. Starting with the Sun Studio 12 compilers, this is no longer the case. On most platforms, just adding -m64 to the command line is sufficient to create 64-bit objects.
On Oracle Solaris, -m32 is the default. On Linux systems supporting 64-bit programs, -m64 -xarch=sse2 is the default.
See also: -xarch.
Removes duplicate strings from the .comment section of an object file. When you use the -mc flag, mcs -c is invoked.
(SPARC) (Obsolete) You should not use this option. Use the -xmemalign=1i option instead. For a complete list of obsolete options and flags, see the C User's Guide.
(SPARC) (Obsolete) You should not use this option. Use the -xmemalign=2i option instead. For a complete list of obsolete options and flags, see the C User's Guide.
-mr removes all strings from the .comment section of an object file. When you use the -mr flag, mcs -d is invoked.
-mr,string removes all strings from the .comment section and inserts string in the .comment section of the object file. If string contains embedded blanks, it must be enclosed in quotation marks. If string is null, the .comment section will be empty. When you use this flag, mcs -d -a is invoked.
Use this option to compile and link multithreaded code using the Oracle Solaris threads or POSIX threads API. The -mt=yes option assures that libraries are linked in the appropriate order.
This option passes -D_REENTRANT to the preprocessor.
To use Oracle Solaris threads, include the thread.h header file and compile with the -mt=yes option. To use POSIX threads on Oracle Solaris platforms, include the pthread.h header file and compile with the -mt=yes option.
On Linux platforms, only the POSIX threads API is available. (There is no libthread on Linux platforms.) Consequently, -mt=yes on Linux platforms adds -lpthread instead of -lthread. To use POSIX threads on Linux platforms, compile with -mt.
Note that when compiling with -G, neither -ltread nor -lpthread are automatically included by -mt=yes. You will need to explicitly list these libraries when building a shared library.
The -xopenmp option (for using the OpenMP shared-memory parallelization API) includes -mt=yes automatically.
If you compile with -mt=yes and link in a separate step, you must use the -mt=yes option in the link step as well as the compile step. If you compile and link one translation unit with -mt=yes, you must compile and link all units of the program with -mt=yes.
-mt=yes is the default behavior of the compiler. If this behavior is not desired use the option -mt=no.
The option -mt is equivalent to -mt=yes.
See also: -xnolib
This option is a synonym for -xtarget=native.
(x86) Cancel -fstore on command line. Cancels forcing expressions to have the precision of the destination variable as invoked by -fstore.
-nofstore is invoked by -fast. The normal default is -fstore.
Use default optimization level -xO3. However, -xO3 may be inappropriate for programs that rely on all variables being automatically considered volatile. Typical programs that might have this assumption are device drivers and older multi-threaded applications that implement their own synchronization primitives. The work around is to compile with -xO2 instead of -O.
The same as -xOn.
Names the output file filename, instead of the default a.out. filename cannot be the same as sourcefile since cc does not overwrite the source file.
filename must have an appropriate suffix. When used with -c, filename specifies the target .o object file; with -G it specifies the target .so library file. This option and its argument are passed to ld.
Preprocesses only the named C files and leaves the result in corresponding files suffixed .i. The output will not contain any preprocessing line directives, unlike -E.
(Obsolete) See -xpg.
Strict conformance with errors/warnings for non-ANSI constructs. The -std flag can be used to specify which ANSI standard is in effect. The -Xc, -Xa, -Xt, -Xs, and -xc99 flags cannot be specified with the -pedantic flag. Doing so will result in an error being issued by the compiler.
The first default, when -pedantic is not specified, is -pedantic=no.
The second default is equivalent to pedantic=yes.
(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.
When complete is specified, the values of all function arguments in the stack trace are visible to the user in the proper order.
The values are not updated during the function lifetime on assignments to formal parameters.
Passes option to the compilation phase.
To pass multiple options, specify them in order as a comma-separated list. Options that are passed to components with -Qoption can be reordered. Options that the driver recognizes are kept in the correct order. Do not use -Qoption for options that the driver already recognizes.
The following table shows the possible values for phase and the corresponding argument for -Wc,arg
Qoption phase W<c> ===== ==== fbe a Assembler: (fbe), (gas) cg c C code generator: (cg)(SPARC) driver d cc driver (1) ld l Link editor (ld) mcs m mcs ipo O (Capital letter 'O') Interprocedural optimizer postopt o Postoptimizer cpp p Preprocessor (cpp) ube u C code generator (ube), (x86) acomp 0 (The number zero) Compiler acomp iropt 2 Optimizer: (iropt)
See also: -Wc,arg
Emits or does not emit identification information to the output file. If y is used, identification information about each invoked compilation tool will be added to the output files (the default behavior). This can be useful for software administration. -Qn suppresses this information.
Same as -p.
A colon-separated list of directories used to specify library search directories to the runtime linker. If present and not null, it is recorded in the output object file and passed to the runtime linker.
If both LD_RUN_PATH and the -R option are specified, the -R option takes precedence.
Compiles, but does not assemble or link edit the named C files. The assembler-language output is left in corresponding files suffixed .s.
Removes all symbolic debugging information from the output object file. This option is passed to ld(1). This option cannot be specified with -g.
When used with -library=sunperf, -staticlib=sunperf will link statically with the Sun performance libraries. By default and when -library=no%sunperf is specified, -library=sunperf results in dynamic linking of the Sun performance libraries.
For compatibility with CC, %all and %none are also accepted values for -staticlib, where %all is equivalent to sunperf and %none is equivalent to no%sunperf.
C language standard selection flag.
value is defined as one of the following:
C source language accepted is that defined by the ISO C90 standard.
C source language accepted is that defined by the ISO C99 standard.
C source language accepted is that defined by the ISO C11 standard.
The first default is c11, implying acceptance of the C source language as defined by ANSI C11 with extensions. There is no second default. Instead, specification of -std without a value will generate an error.
When any of the flags -Xc, -Xa, -Xt, or -xtransition are specified, the -std first default is not in effect and the compiler defaults to -xc99=all,no_lib. When -Xs is specified, the first default is not in effect and the compiler defaults to -xc99=none. When -xc99 is specified, the -std first default is not in effect and the compiler is as specified by -xc99.
The -Xc, -Xa, -Xt, -Xs, and -xc99 flags cannot be used if the -std flag has been specified. Doing so will result in an error being issued by the compiler.
If you compile and link in separate steps you must use the same values for -std flag in both steps.
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 TMPDIR.
See also: -keeptmp
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 -traceback with -G to create a shared library is an error.
Disables traceback.
Specifies that a stack trace should be issued if any of a set of common signals is generated: sigill, sigfpe, sigbus, sigsegv, and sigabrt.
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, sigbus, 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.
If the core dump is not wanted, users may set the coredumpsize limit to zero using:
% limit coredumpsize 0
The -traceback option has no effect on runtime performance.
Causes any definition of name to be undefined. This option removes any initial definition of the preprocessor symbol name created by -D on the same command line including those placed by the command-line driver.
-U has no effect on any preprocessor directives in source files. You can supply multiple -U options on the command line.
If the same name is specified for both -D and -U, name is not defined, regardless of the order of the options.
Causes each invoked tool to print its version information on the standard error output.
Causes the compiler to perform more and stricter semantic checks, and to enable certain lint-like checks on the named C files.
Passes the argument arg to c. Each argument must be separated from the preceding by only a comma. (A comma can be part of an argument by escaping it by an immediately preceding backslash (\) character; the backslash is removed from the resulting argument.) All -W arguments are passed after the regular command-line arguments.
c can be one of the following:
Assembler: (fbe), (gas)
C code generator: (cg)(SPARC)
cc driver (1)
Link editor (ld)
mcs
(Capital letter 'O') Interprocedural optimizer
Postoptimizer
Preprocessor (cpp)
C code generator (ube), (x86)
(The number zero) Compiler (acomp)
Optimizer: (iropt)
(1) Note: You cannot use -Wd to pass the cc options listed in this man page to the C compiler.
For example, -Wa,-o,objfile passes -o and objfile to the assembler, in that order; also -Wl,-I,name causes the linking phase to override the default name of the dynamic linker, /usr/lib/ld.so.1.
The order in which the argument(s) are passed to a tool with respect to the other specified command line options may change.
Suppress compiler warning messages.
The option overrides the error_messages pragma.
(Obsolete) The -Xs option will be removed in a future release. It is recommended that C code that requires -Xs to build and compile correctly be migrated to conform with at least the C99 dialect of the ISO C standard, that is, compilable with -std=c99.
The -Xc, -Xa, -Xt, and -Xs flags cannot be used if the -std or -xlang flag has been specified.
When not using the -std flag, the -X options specify varying degrees of compliance to the 1990 and 1999 ISO C standard. The value of -xc99 affects which version of the ISO C standard the -X option applies.
Strictly conformant ISO C, without K&R C compatibility extensions. The compiler issues errors and warnings for programs that use non-ISO C constructs. The predefined macro __STDC__ has a value of 1 with the -Xc option.
ISO C plus K&R C compatibility extensions, with semantic changes required by ISO C. Where K&R C and ISO C specify different semantics for the same construct, the compiler uses the ISO C interpretation. If the -Xa option is used in conjunction with the -xtransition option, the compiler issues warnings about the different semantics. The predefined macro __STDC__ has a value of 0 with the -Xa option.
This option uses ISO C plus K&R C compatibility extensions without semantic changes required by ISO C. Where K&R C and ISO C specify different semantics for the same construct, the compiler uses the K&R C interpretation. If you use the -Xt option in conjunction with the -xtransition option, the compiler issues warnings about the different semantics. The predefined macro __STDC__ has a value of zero with the -Xt option.
The compiler tries to warn about all language constructs that have differing behavior between Oracle Solaris Studio ISO C and the K&R C. Invokes cpp for processing. __STDC__ is not defined in this mode.
The predefined macro __STDC__ has the value 0 for -Xt and -Xa, and 1 for -Xc. (It is not defined for -Xs.) All warning messages about differing behavior can be eliminated through appropriate coding; for example, use of casts can eliminate the integral promotion change warnings.
Passes arg to linker, ld (1) .
Equivalent to -Wl,arg.
(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 creation of a process that is restricted to a 32-bit address space.
When -xaddr32=no is specified a usual 64 bit binary is produced.
If the -xaddr32 option is not specified, -xaddr32=no is assumed.
If only -xaddr32 is specified -xaddr32=yes is assumed.
This option is only applicable to -m64 compilations and only on Oracle Solaris platforms supporting SF1_SUNW_ADDR32 software capability.
Since Linux kernel does not support addres space limitation this option is not available on Linux. The -xaddr32 option is ignored on Linux.
When linking, if a single object file was compiled with -xaddr32=yes the whole output file is assumed to be compiled with -xaddr32=yes.
A shared object that is restricted to a 32-bit address space must be loaded by a process that executes within a restricted 32-bit mode address space.
For more information refer to the SF1_SUNW_ADDR32 software capabilities definition, described in the Linker and Libraries Guide.
a must be one of:any, basic, weak, layout, strict, std, strong. Use this flag to place the indicated alias level into effect for the whole translation unit. In other words, the alias level you select is applied to all of the memory references in the translation unit. If you do not supply -xalias_level, the compiler assumes -xalias_level=any. If you supply -xalias_level without a value, the compiler assumes -xalias_level=layout.
The compiler assumes that all memory references can alias at this level. There is no type-based alias anaylysis.
If you use the -xalias_level=basic option, the compiler assumes that memory references that involve different C basic types do not alias each other. The compiler also assumes that references to all other types can alias each other as well as any C basic type. The compiler assumes that references using char * can alias any other type.
If you use the -xalias_level=weak option, the compiler assumes that any structure pointer can point to any structure type. Any structure or union type that contains a reference to any type that is either referenced in an expression in the source being compiled or is referenced from outside the source being compiled, must be declared prior to the expression in the source being compiled.
You can satisfy this restriction by including all the header files of a program that contain types that reference any of the types of the objects referenced in any expression of the source being compiled.
At the level of -xalias_level=weak, the compiler assumes that memory references that involve different C basic types do not alias each other. The compiler assumes that references using char * alias memory references that involve any other type.
The compiler assumes that memory references that involve types with the same sequence of types in memory can alias each other. The compiler assumes that two references with types that do not look the same in memory do not alias each other. The compiler assumes that any two memory accesses through different struct types alias if the initial members of the structures look the same in memory. However, at this level, you should not use a pointer to a struct to access some field of a dissimilar struct object that is beyond any of the common initial sequence of members that look the same in memory between the two structs. This is because the compiler assumes that such references do not alias each other.
At the level of -xalias_level=layout the compiler assumes that memory references that involve different C basic types do not alias each other. The compiler assumes that references using char * can alias memory references involving any other type.
The compiler assumes that memory references, that involve types such as structs or unions, that are the same when tags are removed, can alias each other. Conversely, the compiler assumes that memory references involving types that are not the same even after tags are removed do not alias each other. However, any structure or union type that contains a reference to any type that is part of any object referenced in an expression in the source being compiled, or is referenced from outside the source being compiled, must be declared prior to the expression in the source being compiled.
You can satisfy this restriction by including all the header files of a program that contain types that reference any of the types of the objects referenced in any expression of the source being compiled.
At the level of -xalias_level=strict the compiler assumes that memory references that involve different C basic types do not alias each other. The compiler assumes that references using char * can alias any other type.
The compiler assumes that types and tags need to be the same to alias, however, references using char * can alias any other type. This rule is the same as the restrictions on the dereferencing of pointers that are found in the 1999 ISO C standard. Programs that properly use this rule will be very portable and should see good performance gains under optimization.
The same restrictions apply as at the std level, but additionally, the compiler assumes that pointers of type char * are used only to access an object of type char. Also, the compiler assumes that there are no interior pointers. An interior pointer is defined as a pointer that points to a member of a struct.
See also: -xprefetch_auto_type
(Obsolete) This option will be removed in a future release. Use -xprevise instead.
Compile with this option to produce a static analysis of the source code that can be viewed using the Code Analyzer.
When compiling with -xanalyze=code and linking in a separate step, include -xanalyze=code also on the link step.
The default is -xanalyze=%none.
On Linux, -xanalyze=code needs to be specified along with -xannotate.
See the Oracle Solaris Studio Code Analyzer documentation for further information.
Instructs the compiler to create binaries that can later be used by the optimization and observability tools binopt(1), code-analyzer(1), discover(1), collect(1), and uncover(1).
The default on Oracle Solaris is -xannotate=yes. The default on Linux is -xannotate=no. Specifying -xannotate without a value is equivalent to -xannotate=yes.
For optimal use of the optimization and observability tools, -xannotate=yes must be in effect at both compile and link time.
Compile and link with -xannotate=no to produce slightly smaller binaries and libraries when optimization and observability tools will not be used.
Specifies the target architecture instruction set (ISA).
This option limits the code generated by the compiler to the instructions of the specified instruction set architecture by allowing only the specified set of instructions. This option does not guarantee use of any target-specific instructions. However, use of this option can affect the portability of a binary program. See the Notes and Warnings sections at the end of this entry.
Note: Use the -m64 or -m32 option to specify the intended memory model, LP64 (64-bits) or ILP32 (32-bits) respectively. The -xarch flag no longer indicates the memory model, except for compatibility with previous releases, as indicated below.
Note: The compiler and linker will mark .o files and executables that require a particular instruction set architecture (ISA) so that the executable will not be loaded at runtime if the running system does not support that particular ISA.
Code using _asm statements or inline templates (.il files) that use architecture-specific instructions might require compiling with the appropriate -xarch values to avoid compilation errors.
If you compile and link in separate steps, make sure you specify the same value for -xarch in both steps.
Values for all platforms:
This option uses the instruction set common to most processors. This is the default and is equivalent to -xarch=sse2.
Compile for good performance on most 64-bit platforms. (Oracle Solaris only)
This option is equivalent to
-m64 -xarch=generic
and is provided for compatibility with earlier releases. Use -m64 to specify 64-bit compilation instead of -xarch=generic64.
Compile for good performance on this system.
The compiler chooses the appropriate setting for the current system processor it is running on.
Compile for good performance on this system (Oracle Solaris only).
This option is equivalent to -m64 -xarch=native and is provided for compatibility with earlier releases.
Values specific to SPARC platforms:
Compile for the SPARC-V9 ISA.
Compile for the V9 ISA, but without the Visual Instruction Set (VIS), and without other implementation-specific ISA extensions. This option enables the compiler to generate code for good performance on the V9 ISA.
Compile for the SPARC-V9 ISA plus VIS.
Compile for SPARC-V9 plus the Visual Instruction Set (VIS) version 1.0, and with UltraSPARC extensions. This option enables the compiler to generate code for good performance on the UltraSPARC architecture.
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.
Compile for the SPARC-V9 ISA with UltraSPARC III and VIS 3 extensions.
Enables the compiler to use instructions from the SPARC-V9 instruction set, plus the UltraSPARC 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 Instruction Set (VIS) version 3.0
Compile for the sparcfmaf version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 instruction set, plus the UltraSPARC 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 instructions automatically.
Compile for the SPARC4 version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 instruction set, plus the UltraSPARC 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.
Compile for the SPARC4B version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 instruction 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.
Compile for the SPARC4C version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 instruction 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 subset of the VIS 3.0 instructions a subset of the SPARC T3 extensions, called the VIS3B subset of VIS 3.0, and the PAUSE and CBCOND instructions from the SPARC T4 extensions.
Compile for the sparcace version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 instruction 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.
Compile for the sparcaceplus version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 instruction 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.
Compile for the sparcima version of the SPARC-V9 ISA.
Enables the compiler to use instructions from the SPARC-V9 instruction set, plus the UltraSPARC 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.
Is equivalent to -m64 -xarch=sparc Legacy makefiles and scripts that use -xarch=v9 to obtain the 64-bit memory model need only use -m64.
Is equivalent to -m64 -xarch=sparcvis and is provided for compatibility with earlier releases.
Is equivalent to -m64 -xarch=sparcvis2 and is provided for compatibility with earlier releases.
Notes:
Object binary files (.o) compiled with generic, sparc, sparcvis2, sparcvis3, sparcfmaf, and sparcima can be linked and can execute together but can only run on a processor supporting all the instruction sets linked.
For any particular choice, the generated executable could run much more slowly on earlier architectures. Also, although quad-precision floating-point instructions are available in many of these instruction set architectures, the compiler does not use these instructions in the code it generates.
Values specific to x86 platforms:
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AES, PCLMULQDQ, AVX, FSGSBASE, RDRND, F16C, AVX2, BMI1, BMI2, LZCNT, INVPCID, and FMA instructions.
May use 386, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AES, PCLMULQDQ AVX, FSGSBASE, RDRND and F16C instructions.
May use 386, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AES, PCLMULQDQ smf AVX instructions.
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AES, and PCLMULQDQ instructions.
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, SSE4.1, and SSE4.2 instructions.
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3, SSSE3, and SSE4.1 instructions.
May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3 and SSSE3 instructions.
May use 386, MMX, Pentium_pro, SSE, SSE2 and SSE3 instructions.
Uses the AMD SSE4a Instruction set.
May use 386, MMX, Pentium_pro, SSE and SSE2 instructions.
May use 386, MMX, Pentium_pro, SSE, SSE2 and AMD extension: 3DNow!, 3DNow! extension instructions for AMD processors.
Legacy flag, equivalent to -m64 -xarch=sse2, which was used to obtain the 64-bit memory model code, before -m64 flag is available.
Legacy flag, equivalent to -m64 -xarch=sse2a, which was used to obtain the 64-bit memory model code, before -m64 flag is available for AMD processors.
May use 386, MMX, Pentium_pro, and SEE instructions.
May use 386, MMX, Pentium_pro, SEE and AMD extension: 3DNow!, 3DNow! extension instructions for AMD processors.
May use 386, MMX and pentium_pro instructions.
May use 386, MMX, Pentium_pro and AMD extension: 3DNow!, 3DNow! extensions instructions for AMD processors.
Uses the instruction set common to most processor.
Legacy flag, equivalent to -m64 -xarch=generic, which was used to obtain the 64-bit memory model code, before -m64 flag is available.
Uses the instructions available on the current system processor the compiler is running on.
Legacy flag, equivalent to -m64 -xarch=native, which was used to obtain the 64-bit memory model code, before -m64 flag is available.
Notes:
If any part of a program is compiled or linked on an x86 platform with -m64, then all parts of the program must be compiled with one of these options as well.
For details on the various Intel instruction set architectures (SSE, SSE2, SSE3, SSSE3, and so on) refer to the Intel-64 and IA-32 Intel Architecture Software Developer's Manual
Defaults:
If -xarch=isa is not specified, the defaults are: -xarch=generic on SPARC platforms -xarch=generic on x86/x64 platforms.
Interactions:
Although this option can be used alone, it is part of the expansion of the -xtarget option and can be used to override the -xarch value that is set by a specific -xtarget option.
For example, -xtarget=ultra4 expands to
-xarch=sparcvis2 -xcache=64/32/4:8192/128/2 -xchip=ultra4
Warnings:
If this option is used with optimization, the appropriate choice can provide good performance of the executable on the specified architecture. An inappropriate choice, however, might result in serious degradation of performance or in in a binary program that is not executable on all intended target platforms.
Turns on automatic parallelization for multiple processors. Does dependence analysis (analyze loops for inter- iteration data dependence) and loop restructuring. If optimization is not at -xO3 or higher, optimization is raised to -xO3 and a warning is issued.
Note that -xautopar does not accept OpenMP parallelization directives.
Avoid -xautopar if you do your own thread management.
To get faster execution, this option requires a multiple processor system. On a single-processor system, the resulting binary usually runs slower.
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 2. To use more threads, set OMP_NUM_THREADS to a higher value. Set OMP_NUM_THREADS to 1 to run with just one thread. In general, set OMP_NUM_THREADS to the available number of virtual processors on the running system, which can be determined by using the Oracle Solaris psrinfo(1M) command. See the OpenMP API User's Guide for more information.
If you use -xautopar and compile and link in one step, then linking automatically includes the microtasking library and the threads-safe C runtime library. If you use -xautopar and compile and link in separate steps, then you must link with cc -xautopar as well. For a complete list of all compiler options that must be specified at both compile time and at link time, see the C User's Guide.
(SPARC) (Obsolete) See -xannotate.
Instructs the compiler to prepare the binary for later optimizations, transformations and analysis (see binopt(1)). This option may be used for building executables or shared objects. This option must be used with optimization level -xO1 or higher to be effective. There is a modest increase in size of the binary when built with this option.
If you compile in separate steps, -xbinopt must appear on both compile and link steps:
example% cc -c -xO1 -xbinopt=prepare a.c b.c
example% cc -o myprog -xbinopt=prepare a.o
If some source code is not available for compilation, this option may still be used to compile the remainder of the code. It should then be used in the link step that creates the final binary. In such a situation, only the code compiled with this option can be optimized, transformed or analyzed.
Compiling with -xbinopt=prepare and -g increases the size of the executable by including debugging information. The default is -xbinopt=off.
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 errno, avoid this option.
-xbuiltin=%default only inlines functions that do not set errno. The value of errno is always correct at any optimization level, and can be checked reliably. With -xbuiltin=%default at -xO3 or lower, the compiler will determine which calls are profitable to inline, and not inline others.
The -xbuiltin=%none option turns off all substitutions of library functions.
If you do not specify -xbuiltin, the default is -xbuiltin=%default when compiling with an optimization level -xO1 and higher, and -xbuiltin=%none at -xO0. If you specify -xbuiltin without an argument, the default is -xbuiltin=%all and the compiler substitutes intrinsics or inlines standard library functions much more aggressively.
Compiling with -fast adds -xbuiltin=%all.
Note: The -xbuiltin option only inlines global functions defined in system header files, never static functions defined by the user. User code that attempts to interpose on global functions may result in undefined behavior.
When you specify -std=c89 and -xCC, the compiler accepts the C++-style comments. In particular, the "//" can be used to indicate the start of a comment.
The -xc99 flag controls compiler recognition of the implemented features from the C99 standard (ISO/IEC 9899:1999, Programming Language - C).
o can be a comma separated list comprised of the following:
Enable the 1999 C standard library semantics of routines that appeared in both the 1990 and 1999 C standard. Optional no_ disables this feature.
Turn on recognition of supported C99 language features and enable the 1999 C standard library semantics of routines that appear in both the 1990 and 1999 C standard.
Turn off recognition of C99 language features, and do not enable the 1999 C standard library semantics of routines that appeared in both the 1990 and 1999 C standard.
If you do not specify -xc99, the compiler defaults to -xc99=all,no_lib.
If you specify -xc99 without any values, the option is set to -xc99=all.
The -xc99 flag cannot be used if the -std or -xlang flag has been specified.
Define cache properties for use by optimizer.
c must be one of the following:
generic
native
s1/l1/a1[/t1]
s1/l1/a1[/t1]:s2/l2/a2[/t2]
s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
The si, li, ai, and ti, are defined as follows:
The size of the data cache at level i, in kilobytes
The line size of the data cache at level i, in bytes
The associativity of the data cache at level i
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 supplied by the -xtarget option.
The -xcache values are:
Define the cache properties for good performance on most platforms. This is the default.
Define the cache properties for good performance on this host platform.
Define level 1 cache properties.
Define levels 1 and 2 cache properties.
Define levels 1, 2, and 3 cache properties.
The option is provided solely for the purpose of easing the migration of code from systems where the char type is defined as unsigned. Unless you are migrating from such a system, do not use this option. Only code that relies on the sign of a char type needs to be rewritten to explicitly specify signed or unsigned. You can substitute one of the following values for o:
Treat character constants and variables declared as char as signed. This impacts the behavior of compiled code, it does not affect the behavior of library routines.
Equivalent to signed.
Treat character constants and variables declared as char as unsigned. This impacts the behavior of compiled code, it does not affect the behavior of library routines.
Equivalent to unsigned.
If you do not specify -xchar, the compiler assumes -xchar=s. If you specify -xchar, but do not specify a value, the compiler assumes -xchar=s.
The -xchar option changes the range of values for the type char only for code compiled with -xchar. This option does not change the range of values for type char in any system routine or header file. In particular, the value of CHAR_MAX and CHAR_MIN, as defined by limits.h, do not change when this option is specified. Therefore, CHAR_MAX and CHAR_MIN no longer represent the range of values encodable in a plain char.
If you use -xchar, be particularly careful when you compare a char against a predefined system macro because the value in the macro may be signed. This is most common for any routine that returns an error code which is accessed through a macro. Error codes are typically negative values so when you compare a char against the value from such a macro, the result is always false. A negative number can never be equal to any value of an unsigned type.
It is strongly recommended that you never use -xchar to compile routines for any interface exported through a library. The Oracle Solaris ABI specifies type char as signed, and system libraries behave accordingly. The effect of making char unsigned has not been extensively tested with system libraries. Instead of using this option, modify your code that it does not depend on whether type char is signed or unsigned. The sign of type char varies among compilers and operating systems.
Produce an integer constant by placing the characters of a multi-character character-constant in the specified byte order. You can substitute one of the following values for o:
Place the characters of a multi-character character-constant in low-to-high byte order.
Place the characters of a multi-character character-constant in high-to-low byte order.
Place the characters of a multi-character character-constant in an order determined by the compilation mode -X[a|c|s|t].
Performs a runtime check for stack overflow of the main thread in a singly-threaded program as well as slave-thread stacks in a multithreaded program. If a stack overflow is detected, a SIGSEGV is generated. If your application needs to handle a SIGSEGV caused by a stack overflow differently than it handles other address-space violations, see sigaltstack(2).
n must be one of the following values.
Perform all -xcheck checks.
Do not perform any of the -xcheck checks.
Generate code to detect stack overflow errors at runtime, optionally 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 requires 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 setting the stack pointer to an invalid but potentially mapped address (see _stack_grow(3C)).
The optional action, if specified, must be one of the following:
If action is :detect, a detected stack overflow error is handled by executing the signal handler normally associated with the error.
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 default behavior if no action is specified.
If a memory access violation is diagnosed as a stack overflow 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. After checking for stack overflow and printing the above message 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 system call depends on how frequently the application creates and destroys new threads.
-xcheck=stkovf is supported only on Oracle Solaris. The C runtime library on Linux does not support stack overflow detection.
Turns off stack-overflow checking.
Initialize local variables. See the C User's Guide description of this option for a list of the predefined values used by the compiler to initialize variables.
Do not initialize local variables.
If you do not specify -xcheck, the compiler defaults to -xcheck=%none. If you specify -xcheck without any arguments, the compiler defaults to -xcheck=%all.
The -xcheck option does not accumulate on the command line. The compiler sets the flag in accordance with the last occurrence of the command.
Specifies the target processor for use by the optimizer.
c must be one of the values listed below.
Although this option can be used alone, it is part of the expansion of the -xtarget option; its primary use is to override a value supplied by the -xtarget option.
This option specifies timing properties by specifying the target processor.
Some effects are:
The ordering of instructions, that is, scheduling
The way the compiler uses branches
The instructions to use in cases where semantically equivalent alternatives are available
The -xchip values for SPARC platforms are:
Set the parameters for the best performance over most SPARC platform architectures. This is the default.
Set the parameters for the best performance on the host environment.
Uses the timing properties of the pre-SuperSPARC processors.
Optimize for the SPARC64 VI processor.
Optimize for the SPARC64 VII processor.
Optimize for the SPARC64 X processor.
Optimize for the SPARC64 X+ processor.
Optimize for the UltraSPARC(TM) processor.
Optimize for the UltraSPARC II processor.
Optimize for the UltraSPARC IIe processor.
Optimize for the UltraSPARC IIi processor.
Optimize for the UltraSPARC III processor.
Optimize for the UltraSPARC IIIcu processor.
Optimize for the UltraSPARC IIIi processor.
Optimize for the UltraSPARC IV processor.
Optimize for the UltraSPARC IVplus processor.
Optimize for the UltraSPARC T1 processor.
Optimize for the UltraSPARC T2 processor.
Optimize for the UltraSPARC T2+ processor.
Optimize for the SPARC T3 processor.
Optimize for the SPARC T4 processor.
Optimize for the SPARC T5 processor.
Optimize for the SPARC M5 processor.
Optimize for the SPARC64 VII plus processor.
Note: The following SPARC -xchip values are obsolete and may be removed in a future release: ultra, ultra2, ultra2e, ultra2i, ultra3, ultra3cu, ultra3i, ultra4, and ultra4plus.
The -xchip values for x86 platforms are:
Optimize for most x86 platforms.
Optimize for this host processor.
Optimize for the Intel Core2 processor.
Optimize for the Intel Nehalem processor.
Optimize for the AMD Opteron processor.
Optimize for the Intel Penryn processor.
Optimize for the Intel Pentium architecture.
Optimize for the Intel Pentium Pro architecture.
Optimize for the Intel Pentium 3 style processor
Optimize for the Intel Pentium 4 style processor
Optimize for the Intel Sandy Bridge processor.
Optimize for the Intel Ivy Bridge processor.
Optimize for the Intel Haswell processor.
Optimize for the Intel Westmere processor.
Optimize for the AMD FAM10 processor.
(SPARC) Specify code address space.
Note: It is highly recommended that you build shared objects by specifying -xcode=pic13 or -xcode=pic32. It is possible to build workable shared objects with -m64 -xcode=abs64, but these will be inefficient. Shared objects built with -m64 xarch=v9 -xcode=abs32 or -m64 -xcode=abs44 will not work.
The values for -xcode are:
This is the default for 32-bit systems. Generates 32-bit absolute addresses. Code + data + bss size is limited to 2**32 bytes.
This is the default for 64-bit systems. Generates 44-bit absolute addresses. Code + data + bss size is limited to 2**44 bytes. Available only on 64-bit architectures.
Generates 64-bit absolute addresses. Available only on 64-bit architectures.
Generates position-independent code for use in shared libraries (small model). Equivalent to -Kpic. Permits references to at most 2**11 unique external symbols on 32-bit architectures, 2**10 on 64-bit.
Generates position-independent code for use in shared libraries (large model). Equivalent to -KPIC. Permits references to at most 2**30 unique external symbols on 32-bit architectures, 2**29 on 64-bit.
The default is -xcode=abs32 for 32-bit architectures. The default is -xcode=abs44 for 64-bit architectures.
When building shared dynamic libraries, the default -xcode value of abs44 (not abs32) will not work with 64-bit architectures. Specify -xcode=pic13 or -xcode=pic32 instead.
To determine whether to use -xcode=pic13 or -xcode=pic32, check the size of the Global Offset Table (GOT) by using elfdump -c (see the elfdump(1) man page for more information) and to look for the section header, sh_name: .got. The sh_size value is the size of the GOT. If the GOT is less than 8,192 bytes, specify -xcode=pic13, otherwise specify -xcode=pic32.
In general, use the following guidelines to determine how you should use -xcode:
If you are building an executable you should not use -xcode=pic13 or -xcode=pic32.
If you are building an archive library only for linking into executables you should not use -xcode=pic13 or -xcode=pic32.
If you are building a shared library, start with -xcode=pic13 and once the GOT size exceeds 8,192 bytes, use -xcode=pic32.
If you are building an archive library for linking into shared libraries you should just use -xcode=pic32.
This option allows the C compiler to accept source code written in locales that do not conform to the ISO C source character code requirements. These locales include ja_JP.PCK.
Note: The compiler translation phases required to handle such locales may result in significantly longer compile times. You should only use this option when you compile source files that contain source characters from one of these locales.
The compiler does not recognize source code written in locales that do not conform to the ISO C source character code requirements unless you specify -xcsi.
Specify -xdebugformat=dwarf if you maintain software which reads debugging information in the dwarf format. This option causes the compiler to generate debugging information by using the dwarf standard format and is the default.
-xdebugformat=stabs generates debugging information using the stabs standard format.
If you do not specify -xdebugformat, the compiler assumes -xdebugformat=dwarf. This option requires an argument.
This option affects the format of the data that is recorded with the -g option. Some small amount of debugging information is recorded even without -g, and the format of that information is also controlled with this option. So -xdebugformat has a an effect even when -g is not used.
The dbx and Performance Analyzer software understand both stabs and dwarf format so using this option does not have any effect on the functionality of either tool.
See also the dumpstabs(1) and dwarfdump(1) man pages for more information.
Control how much debugging and observability information is emitted.
The term tagtype refers to tagged types: structs, unions, enums, and classes.
The following list contains the possible values for suboptions a. The prefix no% applied to a suboption disables that suboption. The default is -xdebuginfo=%none. Specifying -xdebuginfo without a suboption is forbidden.
No debugging information is generated. This is the default.
Emit line number and file information.
Emit location list info for parameters. Emit full type information for scalar values (for example, int, char *) and type names but not full definitions of tagtypes.
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.
Emit information for function and variable declarations, member functions, and static data members in class declarations.
Emit full type definitions of tagtypes referenced from param and variable datasets, as well as template definitions.
Emit macro information.
Emit DWARF codetags (also known as Stabs N_PATCH). This is information regarding bitfields, structure copy, and spills used by RTC and discover.
Generate information critical to hardware counter profiling. This information includes ldst_map, a mapping from ld/st instructions 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
-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
-xkeep_unref=funcs,vars
-g3 =
-xdebuginfo=line,param,decl,variable,tagtype,codetag,macro
-xglobalize=yes
-xpatchpadding=fix
-xkeep_unref=funcs,vars
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 setting of -xdepend overrides any implicit setting.
On x86, if optimization is not at -xO3 or higher, the compiler raises the optimization to -xO3 and issues a warning.
If you do not specify -xdepend, the default is -xdepend=no which means the compiler does not analyze loops for data dependencies. If you specify -xdepend but do not specify an argument, the compiler sets the option to -xdepend=yes which means the compiler analyzes loops for data dependencies.
Dependency analysis is included in -xautopar. The dependency analysis is done at compile time.
Dependency analysis may help on single-processor systems. However, if you try -xdepend on single-processor systems, you should not also specify -xautopar , otherwise the -xdepend optimization is done for multiple-processor systems.
See also: -xprefetch_auto_type
This option is a macro for -###.
Use this option when you want to see how macros are behaving in your program. This option provides information such as macro defines, undefines, and instances of usage. It prints output to the standard error (stderr), based on the order macros are 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 suboption disables that suboption.
Print all macro defines.
Print all macro undefines.
Print information about macros used.
Print location (path name and line number) also for defs, undefs, and use.
Print use information for macros used in conditional directives.
Print all macros defines, undefines, and use information for macros in system header files.
Sets the option to -xdumpmacros=defs,undefs,use,loc,conds,sys. A good way to use this argument is in conjunction with the [no%] form of the other arguments. For example, -xdumpmacros=%all,no%sys would exclude system header macros from the output but still provide information for all other macros.
Do not print any macro information.
The option values accumulate so specifying -xdumpmacros=sys -xdumpmacros=undefs has the same effect as -xdumpmacros=undefs,sys.
Note: The sub-options loc, conds, and sys are qualifiers for defs, undefs and use options. By themselves, loc, conds, and sys have no effect. For example, -xdumpmacros=loc,conds,sys has no effect.
Defaults:
If you specify -xdumpmacros without any arguments, it means -xdumpmacros=defs,undefs,sys. If you do not specify -xdumpmacros, it defaults to -xdumpmacros=%none.
Performs only syntax and semantic checking on the source file, but does not produce any object or executable file.
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 runtime.
Reordering functions and variables for optimal performance requires the following operations:
Compiling and linking with -xF.
Following the instructions in the Performance Analyzer manual regarding how to generate a mapfile for functions or following the instructions in the Linker and Libraries Guide regarding how to generate a mapfile for data.
Relinking with the new mapfile by using the linker's -M option.
Re-executing under the Analyzer to verify improvement.
v can be one of the following values. Prefix no% disables the suboption.
Fragment functions into separate sections.
Fragment global data (variables with external linkage) into separate sections.
Fragment functions and global data.
Fragment nothing.
If you do not specify -xF, the default is -xF=%none. If you specify -xF without any arguments, the default is -xF=%none,func.
See also: analyzer(1), ld(1)
Control globalization of file static variables but not functions.
Globalization is a technique needed by fix and continue and interprocedural optimization whereby file static symbols are promoted to global 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.
-xipo requires globalization as well and will override -xglobalize.
Displays a summary of the compiler options.
(SPARC) Use the -xhwcprof option to enable compiler support for dataspace profiling.
When -xhwcprof is enabled, the compiler generates information that helps tools associate profiled load and store instructions with the data-types and structure members (in conjunction with symbolic information produced with -g) to which they refer. It associates profile data with the data space of the target, rather than the instruction space, and provides insight into behavior that is not easily obtained from only instruction profiling.
You can compile a specified set of object files with -xhwcprof however, -xhwcprof is most useful when applied to all object files in the application. This will provide coverage to identify and correlate all memory references distributed in the application's object files.
If you are compiling and linking in separate steps, use -xhwcprof at link time as well. Future extensions to -xhwcprof may require its use at link time. For a complete list of compiler options that must be specified at both compile time and at link time, see the C User's Guide.
An instance of -xhwcprof=enable or -xhwcprof=disable overrides all previous instances of -xhwcprof in the same command line.
-xhwcprof is disabled by default. Specifying -xhwcprof without any arguments is the equivalent to -xhwcprof=enable.
-xhwcprof requires that optimization be turned on and that the debug data format be set to dwarf (-xdebugformat=dwarf), which is the default with current Oracle Solaris Studio compilers. The occurrence of -xhwcprof and -xdebugformat=stabs on the same command line is not permitted.
-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.c and specifies support for hardware counter profiling and symbolic analysis of data types and structure members using DWARF symbols:
example% cc -c -O -xhwcprof -g -xdebugformat=dwarf example.c
For more information on hardware counter-based profiling, see the Performance Analyzer manual.
v can be [{%auto,func_name,no%func_name}].
-xinline tries to inline only those functions specified in the list. The list is comprised of either a comma-separated list of function names, or a comma separated list of no%func_name values, or the value %auto. If you specify %nofunc_name, the compiler is not to inline the named function. If you specify %auto, the compiler is to attempt to automatically inline all functions in the source files.
The list of values accumulates from left to right. So for a specification of -xinline=%auto,no%foo the compiler attempts to inline all functions except foo. For a specification of -xinline=%bar,%myfunc,no%bar the compiler only tries to inline myfunc.
When you compile with optimization set at -xO4 or above, the compiler normally tries to inline all references to functions defined in the source file. You can restrict the set of functions the compiler attempts to inline by specifying the -xinline option. If you specify only -xinline=, that is you do not name any functions or auto, this indicates that none of the routines in the source files are to be inlined. If you specify a list of func_name and no%func_name without specifying %auto, the compiler only attempts to inline those functions specified in the list. If %auto is specified in the list of values with the -xinline option at optimization level set at -xO4 or above, the compiler attempts to inline all functions that are not explicitly excluded by no%func_name.
A function is inlined if any of the following apply:
Optimization is set at -xO3 or higher.
Inlining the funciton is judged to be profitable and safe.
The source for the function is in the file being compiled or the function is in a file that was compiled with -xipo[=1|2].
If you specify multiple -xinline options on the command line, they do not accumulate. The last -xinline on the command line specifies what functions the compiler attempts to inline.
See also: -xldscope.
Use this option to manually change the heuristics used by the compiler 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 inlining is on.
In the following sub-options n must be a positive integer; a can be one of the following:
Set the values of all the sub-options to their default values.
Automatic inlining only considers functions smaller than n pseudo instructions (counted in compiler's internal representation) as possible inline candidates.
Under no circumstances will a function larger than this be considered for inlining.
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 parameters 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 function, use -xinline_report=2 to report detailed inlining message and follow the suggestion in the inlining message.
Allow functions to increase due to automatic inlining by up to n pseudo instructions (counted in compiler's internal representation).
The automatic inliner is allowed to increase the size of the program by up to n% where the size is measured in pseudo instructions.
The minimum call site frequency counter as measured by profiling 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).
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.
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 inlined up to n levels.
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 inlining.
When interactions between max_recursive_inst and max_recursive_depth occur, recursive function calls will be inlined until 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 control 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=default.
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
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.
No report is generated.
A summary report of default values of inlining parameters is generated.
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 callsite 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 callsites that are not inlined might not be accurate.
Specify this option to compile and instrument your program for analysis by the Thread Analyzer. For more information on the Thread Analyzer, see tha(1) for details.
You can then use the Performance Analzyer to run the instrumented program with collect -r races to create a data-race-detection experiment. You can run the instrumented code standalone but it runs more slowly.
You can specify -xinstrument=no%datarace to turn off preparation of source code for the thread analyzer. This is the default.
It is illegal to specify -xinstrument without an argument.
If you compile and link in seperate steps, you must specify -xinstrument=datarace in both the compilation and linking steps.
This option defines the preprocessor token __THA_NOTIFY. You can specify #ifdef __THA_NOTIFY to guard calls to libtha(3) routines.
This option also sets -g.
The compiler performs partial-program optimizations by invoking an interprocedural analysis pass. It performs optimizations across all object files in the link step, and is not limited to just the source files on the compile command. However, whole-program optimizations performed with -xipo do not include assembly (.s) source files.
You must specify -xipo both at compile time and at link time. For a complete list of compiler options that must be specified at both compile time and at link time, see the C User's Guide.
Analysis and optimization is limited to the object files compiled with -xipo, and does not extend to object files or libraries. -xipo is multiphased, so you need to specify -xipo for each step if you compile and link in separate steps.
The -xipo option generates significantly larger object files due to the additional information needed to perform optimizations across files. However, this additional information does not become part of the final executable binary file. Any increase in the size of the executable program is due to the additional optimizations performed. The object files created in the compilation steps have additional analysis information compiled within them to permit crossfile optimizations to take place at the link step.
n is 0, 1, or 2. -xipo without any arguments is equivalent to -xipo=1. -xipo=0 is the default setting and turns off -xipo.
With -xipo=1, the compiler performs inlining across all source files. At -xipo=2, the compiler performs interprocedural aliasing analysis as well as optimization of memory allocation and layout to improve cache performance.
Here are some important considerations for -xipo:
It requires an optimization level of at least -xO4.
Objects that are compiled without -xipo can be linked freely with objects that are compiled with -xipo.
In this example, compilation and linking occur in a single step:
cc -xipo -xO4 -o prog part1.c part2.c part3.c
In this example, compilation and linking occur in separate steps:
cc -xipo -xO4 -c part1.c part2.c cc -xipo -xO4 -c part3.c cc -xipo -xO4 -o prog part1.o part2.o part3.o
The object files created in the compilation steps have additional analysis information compiled within them to permit crossfile optimizations to take place at the link step.
A restriction is that libraries, even if compiled with -xipo do not participate in crossfile interprocedural analysis, as shown in this example:
cc -xipo -xO4 one.c two.c three.c ar -r mylib.a one.o two.o three.o cc -xipo -xO4 -o myprog main.c four.c mylib.a
Here interprocedural optimizations are performed between one.c, two.c and three.c, and between main.c and four.c, but not between main.c or four.c and the routines on mylib.a. (The first compilation may generate warnings about undefined symbols, but the interprocedural optimizations are performed because it is a compile and link step.)
When Not To Use -xipo=2 Interprocedural Analysis:
The compiler tries to perform whole-program analysis and optimizations 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:
foo() is not called explicitly by another routine that is defined outside this set of object files at runtime.
The calls to foo() from any routine in the set of object files are not interposed upon by a different version of foo() defined outside this set of object files.
Do not compile with -xipo=2 if assumption (1) is not true for the given application.
Do not compile with either -xipo=1 or -xipo=2 if assumption (2) is not true.
As an example, consider interposing on the function malloc() with your own version and compiling with -xipo=2. Consequently, all the functions in any library that reference malloc() that are linked with your code have to be compiled with -xipo=2 also and their object files need to participate in the link step. Since this might not be possible for system libraries, do not compile your version of malloc() with -xipo=2.
As another example, suppose that you build a shared library with two external calls, foo() and bar() inside two different source files. Furthermore, suppose that bar() calls foo(). If there is a possibility that foo() could be interposed at runtime, then do not compile the source file for foo() or for bar() with -xipo=1 or -xipo=2. Otherwise, foo() could be inlined into bar(), which could cause incorrect results.
See also: -xjobs and -xipo_archive
The -xipo_archive option enables the compiler to optimize object files that are passed to the linker with object files that were compiled with -xipo and that reside in the archive library (.a) before producing an executable. Any object files contained in the library that were optimized during the compilation are replaced with their optimized version.
a is one of the following:
The compiler optimizes object files passed to the linker with object files compiled with -xipo that reside in the archive library (.a) before producing an executable. Any object files contained in the library that were optimized during the compilation are replaced with an optimized version.
For parallel links that use a common set of archive libraries,each link should create its own copy of archive libraries to be optimized before linking.
The compiler optimizes object files passed to the linker with object files compiled with -xipo that reside in the archive library (.a) before producing an executable.
The option -xipo_archive=readonly enables cross-module inlining and interprocedural data flow analysis of object files in an archive library specified at link time. However, it does not enable cross-module optimization of the archive library's code except for code that has been inserted into other modules by cross module inlining.
To apply cross-module optimization to code within an archive library, -xipo_archive=writeback is required. Note that doing so modifies the contents of the archive library from which the code was extracted.
Default. There is no processing of archive files. The compiler does not apply cross-module inlining or other cross-module optimizations to object files compiled using -xipo and extracted from an archive library at link time. To do that, both -xipo and either -xipo_archive=readonly or -xipo_archive=writeback must be specified at link time.
It is illegal to specify -xipo_archive without a flag.
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. Optimization 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 optimization, 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 __unoptimized_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 enabled. 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.
Disable or set interpretation of ivdep pragmas.
The ivdep pragmas tell a compiler to ignore some or all loop-carried dependences on array references that it finds in a loop for purposes of optimization. This enables a compiler to perform various 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 dependences do not matter or that they never occur in practice.
The interpretation of #pragma ivdep directives depend upon the value of the -xivdep option.
The following values for p are interpreted as follows:
Ignore assumed loop-carried vector dependences.
Ignore all loop-carried vector dependences.
Ignore assumed backward loop-carried vector dependences.
Ignore all backward loop-carried vector dependences.
Do not ignore any dependences (disables ivdep pragmas).
These interpretations are provided for compatibility with other vendor's interpretations of the ivdep pragma.
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 invoke to compile different files.
Generally, a safe value for n is 1.5 multiplied by the number of available processors. Using a value that is many times the number of available processors can degrade performance because of context switching overhead among spawned jobs. Also, using a very high number 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 diagnostic 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. Multiple 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
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 equivalent to specifying -xkeep_unref=funcs,vars, meaning that -keep_unref keeps everything.
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 -xkeepframe=%none.
If specified on the command line without a value, the compiler assumes -xkeepframe=%all.
This option is accumulative and can appear on the command line multiple times. For example,
-xkeepframe=%all -xkeepframe=no%func1
indicates that the stack frame should be kept for all functions except func1. Also, -xkeepframe overrides -xregs=frameptr. For example,
-xkeepframe=%all -xregs=frameptr
indicates that the stack should be kept for all functions, but the optimizations for -xregs=frameptr would not be done.
The -xlang flag can be used to override the default libc behavior as specified by the -std flag. language must be one of the following:
Specify runtime library behavior of libc to be in conformance with the C90 standard.
Specify runtime library behavior of libc be in conformance with the C99 standard.
Equivalent to c99. The runtime library behavior of libc for c99 and c11 are identical.
When -xlang is not specified, the default value is c99 when -std=c99 has been specified and c11 when -std=c11 has been specified. Otherwise the default value is c89.
The -Xc, -Xa, -Xt, -Xs, and -xc99 flags cannot be used if -xlang has been specified. Doing so will result in an error being issued by the compiler.
If you compile and link in separate steps you must use the same values for -xlang in both steps.
To determine which driver to use for mixed-language linking, use the following language hierarchy:
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.
v must be one of the following:
Global linker scoping is the least restrictive linker scoping. All references to the symbol bind to the definition in the first dynamic module that defines the symbol. This linker scoping is the current linker scoping for extern symbols.
Symbolic linker scoping and is more restrictive than global linker scoping. All references to the symbol from within the dynamic module being linked bind to the symbol defined within the module. Outside of the module, the symbol appears as though it were global. This linker scoping corresponds to the linker option -Bsymbolic.
Hidden linker scoping is more restrictive than symbolic and global linker scoping. All references within a dynamic module bind to a definition within that module. The symbol will not be visible outside of the module.
If you do not specify -xldscope, the compiler assumes -xldscope=global. It is not legal to specify -xldscope without any arguments. The compiler issues an error if you specify -xldscope without an argument. Multiple instances of this option on the command line override each other until the rightmost instance is reached.
If you intend to allow a client to override a function in a library, you must be sure that the function is not generated inline during the library build. The compiler inlines a function if you specify the function name with -xinline, if you use #pragma inline, if you 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 library client wants to replace ABC_allocator with a customized version, the replacement will not occur in library components that called ABC_allocator. The final program will include different versions of the function.
Library functions declared with the __hidden or __symbolic specifiers can be generated inline when building the library. They are not supposed to be overridden by clients. For more information, see chapter 2 "C-Compiler Implementation Specific Information" in the C User's Guide.
Library functions declared with the __global specifier, should not be declared inline, and should be protected from inlining by use of the -xinline compiler option.
See also:
-xinline, -xO, ld(1).
Forces IEEE 754 style return values for math routines in exceptional cases. In such cases, no exception message will be printed, and errno should not be relied on.
Inlines some library routines for faster execution. This option selects the appropriate assembly language inline templates for the floating-point option and platform for your system. -xlibmil inlines a function regardless of any specification of the function as part of the -xinline flag.
However, these substitutions can cause the setting of errno to become unreliable. If your program depends on the value of errno, avoid this option. See the NOTES section at the end of this man page for more information.
Enables the compiler to use a library of optimized math routines. You must use default rounding mode by specifying -fround=nearest when you use this option.
The math routine library is optimized for performance and usually generates faster code. The results may be slightly different from those produced by the normal math library. If so, they usually differ in the last bit.
However, these substitutions can cause the setting of errno to become unreliable. If your program depends on the value of errno, avoid this option. See the NOTES section at the end of this man page for more information.
The order on the command line for this library option is not significant.
Interactions:
This option is implied by the -fast option.
See also:
-fast, -xnolibmopt
(Obsolete) Use -library=sunperf to link with the Sun Performance Library.
This option is silently ignored by the compiler.
Instructs the compiler to perform link-time optimizations on relocatable object files.
The post-optimizer performs a number of advanced performance optimizations on the binary object code at link-time. The value level sets the level of optimizations performed, and must be 0, 1, or 2.
The optimization levels are:
The post-optimizer is disabled. (This is the default.)
Perform optimizations based on control flow analysis, including instruction cache coloring and branch optimizations, at link time.
Perform additional data flow analysis, including dead-code elimination and address computation simplification, at link time.
Specifying -xlinkopt without the level parameter implies -xlinkopt=1.
These optimizations are performed at link time by analyzing the object binary code. The object files are not rewritten but the resulting executable code may differ from the original object codes.
This option is most effective when you use it to compile the whole program, and with profile feedback.
If you compile in separate steps, -xlinkopt must appear on both compile and link steps:
example% cc -c -xlinkopt a.c b.c example% cc -o myprog -xlinkopt=2 a.o
For a complete list of compiler options that must be specified at both compile time and at link time, see the C User's Guide.
Note that the level parameter is only used when the compiler is linking. In the example above, the post-optimization level used is 2 even though the object binaries were compiled with an implied level of 1.
Do not use the -zcombreloc linker option when you compile with -xlinkopt.
You must use -xlinkopt on at least some of the compilation 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 optimizes code coming from static libraries that appear on the compiler command line, but it skips and does not optimize code coming from shared (dynamic) libraries that appear on the command line. You can also use -xlinkopt when you build shared libraries (compiling with -G ).
The link-time post-optimizer is most effective when you use it with 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 optimal placement of code performed at link time can reduce instruction cache misses. Typically, this would be compiled as follows:
example% cc -o progt -xO5 -xprofile=collect:profdir file.c example% progt example% cc -o prog -xO5 -xprofile=use:profdir -xlinkopt file.c
For details on using profile feedback, see -xprofile.
Note that compiling with this option increases link time slightly. Object file sizes also increase, but the size of the executable remains the same. Compiling with -xlinkopt and -g increases the size of the excutable by including debugging information.
Shows which loops are parallelized and which are not. This option is normally for use with the -xautopar option.
Runs only the preprocessor on the named C programs, requesting that it generate makefile dependencies and send the result to the standard output (see make (1) for details about makefiles and dependencies).
Same as -xM except that -xM1 is not supported in -Xs mode nor does -xM1 report dependencies for /usr/include header files. For example:
example% more hello.c
#include <stdio.h>
main()
{
(void) printf ("hello\n");
}
example% cc -xM hello.c
hello.o: hello.c
hello.o: /usr/include/stdio.h
Compiling with -xM1 does not report header file dependencies:
example% cc -xM1 hello.c hello.o: hello.c
Generates makefile dependencies like -xM but compilation continues. -xMD generates an output file for the makefile-dependency information derived from the -o output filename, if specified, or the input source filename, replacing (or adding) the filename suffix with .d . If you specify -xMD and -xMF, the preprocessor writes all makefile dependency information to the file specified with -xMF. Compiling with -xMD -xMF or -xMD -o filename with more than one source file is not allowed and generates an error. The dependency file is overwritten if it already exists.
Use this option to specify a file for the makefile- dependency output. 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.
Use this option to generate makefile dependencies excluding system header files. This is the same functionality as -xM1, but compilation continues. -xMMD generates an output file for the makefile-dependency information derived from the -o output filename, if specified, or the input source filename, replacing (or adding) the filename suffix with .d . If you specify -xMF, the compiler uses the filename you provide instead. Compiling with -xMMD -xMF or -xMMD -o filename with more than one source file is not allowed and generates an error. The dependency file is overwritten if it already exists.
Directs cc to merge the data segment with the text segment. Data initialized in the object file produced by this compilation is read-only and (unless linked with ld -N) is shared between processes.
-xMerge, -ztext, 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 initialized, position-dependent symbol relocations in writable storage.
This command limits the level of pragma opt to the level specified. The default value is -xmaxopt=off which causes pragma opt to be ignored. If you specify -xmaxopt without supplying an argument, that is the equivalent of specifying -xmaxopt=5.
If you specify both -xO and -xmaxopt, the optimization level set with -xO must not exceed the -xmaxopt value.
(SPARC) Use the -xmemalign option to control the assumptions the compiler makes about the alignment of data. By controlling the code generated for potentially misaligned memory accesses and by controlling program behavior in the event of a misaligned access, you can more easily port your code to SPARC.
Specify the maximum assumed memory alignment and behavior of misaligned data accesses. There must be a value for both a (alignment) and b (behavior). a specifies the maximum assumed memory alignment and b specifies the behavior for misaligned memory accesses.
For memory accesses where the alignment is determinable at 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:
The OS converts the trap to a SIGBUS signal. If the program does not catch the signal, the program aborts. Even if the program catches the signal, the misaligned access attempt will not have succeeded.
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:
Assume at most 1 byte alignment.
Assume at most 2 byte alignment.
Assume at most 4 byte alignment.
Assume at most 8 byte alignment.
Assume at most 16 byte alignment.
Accepted values for b are:
Interpret access and continue execution.
Raise signal SIGBUS.
For 64-bit SPARC programs (-m64) only. Raise signal SIGBUS for alignments less than or equal to 4, otherwise interpret access and continue execution. For 32-bit programs, the f flag is equivalent to i.
You must also specify -xmemalign whenever you want to link to an object file that was compiled with the value of b set to either i or f. For a complete list of compiler options that must be specified at both compile time and at link time, see the C User's Guide.
Defaults:
The default for 64-bit SPARC programs (-m64) is -xmemalign=8s.
The default for 32-bit SPARC programs (-m32) is -xmemalign=8i.
If you do specify -xmemalign but do not provide a value, the default is -xmemalign=1i for all platforms.
(x86) The -xmodel option determines the data address model for shared objects on the Oracle Solaris x64 platforms and should only be specified for the compilation of such objects.
This option is valid only when -m64 is also specified on 64-bit enabled x64 processors.
a is one of the following:
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.
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.
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 option. You can compile select files as long as you ensure the object you are accessing is within reach.
Be aware that not all Linux system support the medium model.
Does not link any libraries by default; that is, no -l options are passed to the linker ld. Normally, the cc driver passes -lc to ld.
When you use -xnolib, you must pass all -l options explicitly yourself.
Does not inline math library routines. Use -xnolibmil after the -fast option, as follows:
cc -fast -xnolibmil ...
Do not link with the optimized math routine library by turning off any previously specified -xlibmopt options.
Use this option after the -fast option on the command line, as in:
example% cc -fast -xnolibmopt ...
Do not build a runtime search path for shared libraries into the executable.
Normally cc does not pass any -R path to the linker. There are a few options that do pass -R path to the linker such as -xliclib=sunperf and -xopenmp. The -xnorunpath option can be used to prevent this.
This option is recommended for building executables that will be shipped to customers who may have a different path for the shared libraries that are used by the program.
Specifies optimization level (n). (Note the uppercase letter O, followed by a digit 1, 2, 3, 4, or 5)
Generally, the higher the level of optimization with which a program is compiled, the better runtime performance obtained. However, higher optimization levels may result in increased compilation time and larger executable files.
There are five levels that you can use with -xOn. The actual optimizations performed by the compiler at each level may change with each compiler release. They are only summarized here.
If the optimizer runs out of memory, it attempts to proceed over again at a lower level of optimization, resuming compilation of subsequent routines at the original level.
Values:
Do only the basic local optimizations.
Do basic local and global optimization. This level usually gives minimum code size.
Adds global optimizations at the function level. In general, this level, and -xO4, usually result in the minimum code size when used with the -xspace option.
Adds automatic inlining of functions in the same file. In general, -xO4 results in larger code unless combined with -xspace.
See -inline to control which routines are inlined.
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 improve performance if it is done with profile feedback. See -xprofile=collect|use.
The default is no optimization. However, this is only possible if you do not specify an optimization level. If you specify an optimization level, there is no option for turning optimization off.
If you are trying to avoid setting an optimization level, be sure not to specify any option that implies an optimization level. For example, -fast is a macro option that sets 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 make file that specify an optimization level.
If you use -g and the optimization level is -xO3 or lower, the compiler provides best-effort symbolic information with almost full optimization. Tail-call optimization and back-end inlining are disabled.
If you use -g and the optimization level is -xO4 or higher, the compiler provides best-effort symbolic information with full optimization.
Debugging with -g does not suppress -xOn, but -xOn limits -g in certain ways. For example, the optimization options reduce the utility of debugging so that you cannot display variables from dbx, but you can still use the dbx where command to get a symbolic traceback. For more information, see Debugging a Program With dbx.
If you specify both -xO and -xmaxopt, the optimization level set with -xO must not exceed the -xmaxopt value.
See also:
-xldscope, -fast, -xprofile=p, csh(1) man page
Performance Analyzer discusses the effects of the different levels of optimization on the Analyzer's data.
Enable explicit parallelization with OpenMP directives.
The following details the -xopenmp values:
Enables recognition of OpenMP pragmas. The optimization level under -xopenmp=parallel is -xO3. The compiler raises the optimization 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 Solaris Studio OpenMP API User's Guide for the value of the _OPENMP macro for a particular release.
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 accordingly, but no optimization is done. This flag also defines the preprocessor macro _OPENMP.
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 optimization 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 to execute a parallel region is the number of cores available on the machine, capped at 32. 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 OpenMP API User's Guide for more information.
Nested parallelism is disabled by default. To enable nested parallelism, you must set the OMP_NESTED environment variable to TRUE. See the 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 installed on the system.
For more information about the OpenMP Fortran 95, C, and C++ application program interface (API) for building multithreaded applications, see the Oracle Solaris Studio OpenMP API User's Guide.
For information that is specific to the C implementation of OpenMP, see the Oracle Solaris Studio C User's Guide.
Performs only syntax and semantic checking on the source file in order to print prototypes for all K&R C functions. This option does not produce any object or executable code.
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 default.
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 determine page size of the target platform.
The -xpagesize option has no effect unless you use it at compile time and at link time. For a complete list of compiler options that must be specified at both compile time and at link time, see the C User's Guide.
If you specify -xpagesize=default, the operating system sets the page size.
Compiling with this option has the same effect as setting the LD_PRELOAD environment variable to mpss.so.1 with the equivalent options, or running the Oracle Solaris command ppgsz(1) with the equivalent options before running the program. See the Oracle Solaris man pages for details.
This option is a macro for -xpagesize_heap and -xpagesize_stack. These two options accept the same arguments as -xpagesize. You can set them both with the same value by specifying -xpagesize=n or you can specify them individually with different values.
Set the page size in memory for the heap.
The n value is the same as for -xpagesize.
You must specify a valid page size for the target platform. If you do not specify a valid pagesize, the request is silently ignored at runtime.
See -xpagesize for details.
Set the page size in memory for the stack.
The n value is the same as described for -xpagesize.
You must specify a valid page size for the Oracle Solaris operating system on the target platform. If you do not specify a valid pagesize, the request is silently ignored at runtime.
See -xpagesize for details.
Reserve an area of memory before the start of each function. If fix is specified, the compiler will reserve the amount of space required by fix and continue. This is the default. If either patch or no value is specified, the compiler will reserve a platform-specific 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.
This compiler option activates the precompiled-header feature. v can be auto, autofirst, collect:pch_filename, or use:pch_filename. You can take advantage of this feature through the -xpch and -xpchstop options in combination with the #pragma hdrstop directive.
Use the -xpch option to create a precompiled-header file and improve your compilation time. The precompiled-header file is designed to reduce compile time for applications whose source files share a common set of include files containing a large amount of source code. A precompiled header works by collecting information about a sequence of header files from one source file, and then using that information when recompiling that source file, and when compiling other source files that have the same sequence of headers.
You can let the compiler generate the precompiled-header file for you automatically. Choose between one of the following two ways to do this. One way is for the compiler to create the precompiled-header file from the first include file it finds in the source file. The other way is for the compiler to select from the set of include files found in the source file starting with the first include file and extending through a well-defined point that determines which include file is the last one. Use one of the following two flags to determine which method the compiler uses to automatically generate a precompiled header:
The contents of the precompiled-header file is based on the longest viable prefix (see the following section for an explanation of how a viable prefix is identified) that the compiler finds in the source file. This flag produces a precompiled header file that consists of the largest possible number of header files.
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 specifying the collect mode. The compilation command that specifies -xpch=collect must only specify one source file. In the following example, the -xpch option creates a precompiled-header file called header.cpch based on the source file a.c:
cc -xpch=collect:myheader a.cc
A valid precompiled-header filename always has the suffix .cpch. When you specify pch_filename, you can add the suffix or let the compiler add it for you. For example, if you specify cc -xpch=collect:foo a.c, the precompiled-header file is called foo.cpch.
If the compiler cannot use the precompiled-header file, under -xpch=auto and -xpch=autofirst, it will generate a new precompiled-header file. If the compiler cannot use the precompiled-header file under -xpch=use, a warning is issued and the compilation is done using the real headers.
You can also direct the compiler to use a specific precompiled header. Specify -xpch=use:pch_filename to do this. You can specify any number of source files with the same sequence of include files as the source file used to create the precompiled-header file. For example, your command in use mode could look like this:
cc -xpch=use:foo.cpch foo.c bar.c foobar.c
You should only use an existing precompiled-header file if the following is true. If any of the following is not true, you should recreate the precompiled-header file:
The compiler that you are using to access the precompiled-header file is the same as the compiler that created the precompiled-header file. A precompiled-header file created by one version of the compiler may not be usable by another version of the compiler.
Except for the -xpch option, the compiler options you specify with -xpch=use must match the options that were specified when the precompiled-header file was created.
The set of included headers you specify with -xpch=use is identical to the set of headers that were specified when the precompiled header was created.
The contents of the included headers that you specify with -xpch=use is identical to the contents of the included headers that were specified when the precompiled header was created.
The current directory (that is, the directory in which the compilation is occurring and attempting to use a given precompiled-header file) is the same as the directory in which the precompiled-header file was created.
The initial sequence of pre-processing directives, including #include directives, in the file you specified with -xpch=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 directives are not recognized by the compiler as tokens. This initial sequence of tokens is known as the viable prefix. In other words, the viable prefix is the top portion of the source file that is common to all source files. The compiler uses this viable prefix as the basis for creating a precompiled-header file and thereby determining which header files from the source are pre-compiled.
The viable prefix that the compiler finds during the current compilation must match the viable prefix that it used to create the precompiled-header file. In other words, the viable prefix must be interpreted consistently by the compiler across all the source files that use the same precompiled-header file.
The viable prefix consists of any of the following pre-processor directives:
#include
#if/ifdef/ifndef/else/elif/endif
#define/undef
#ident
#pragma
Any of these may reference macros. The #else, #elif, and #endif directives must match within the viable prefix. Comments are ignored.
The compiler determines the end point of the viable prefix automatically when you specify -xpch=auto or -xpch=autofirst and is defined as follows. For -xpch=collect or -xpch=use, the viable prefix ends with a #pragma hdrstop.
The first declaration/definition statement
The first #line directive
A #pragma hdrstop directive
After the named include file if you specify -xpch=auto and -xpchstop
The first include file if you specify -xpch=autofirst
Note: An end point within a conditional statement generates a warning and disables the automatic creation of a precompiled-header file. Also, if you specify both the #pragma hdrstop and the -xpchstop option, then the compiler uses the 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 precompileable 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 declaration can appear in some other file. Consider these example header files:
file a.h
struct S {
#include "x.h" /* not allowed */
};
file b.h
struct T; // ok, complete declaration
struct S {
int i;
[end of file, continued in another file] /* not allowed */
A header file that is incorporated into a precompiled-header file must not violate the following. The results of compiling a program that violate any of these constraints is undefined.
The header file must not use __DATE__ and __TIME__.
The header file must not contain #pragma hdrstop.
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-generated precompiled-header files, you can clear the precompiled-header file cache-directory 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 dependencies. Consider this sample make file:
%.o : %.cc shared.cpch $(cc) -xpch=use:shared -xpchstop=foo.h -c $< default : a.out foo.o + shared.cpch : foo.c $(cc) -xpch=collect:shared -xpchstop=foo.h foo.c -c a.out : foo.o bar.o foobar.o $(c) foo.o bar.o foobar.o clean : rm -f *.o shared.cpch .make.state a.out
These make rules, along with the dependencies generated by the compiler, force a manually created precompiled-header file to be recreated if any source file you used with -xpch=collect, or any of the headers that are part of the precompiled-header file, have changed. This prevents the use of an out of date 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 example, 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 appears prior to the first include file, or appears prior to the include file that is specified with -xpchstop for -xpch=auto, generates a warning and disables the automatic generation of the precompiled-header file.
A #pragma hdrstop before the first include file under -xpch=autofirst or -xpch=auto disables the automatic generation of the precompiled-header file.
See also: -xpchstop
file is the last include file to be considered in creating a precompiled-header file. Using -xpchstop on the command line is equivalent to placing a hdrstop pragma (See the C User's Guide) after the first include-directive that references file in each of the source files that you specify with the cc command.
Use -xpchstop=<include> with -xpch=auto to create a precompiled-header file that is based on header files up through and including <include>. This flag overrides the default -xpch=auto behavior of using all header files contained in the entire viable prefix.
See also: -xpch
(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 tuning and troubleshooting.
A binary that is built with -xpec is usually five to ten times larger than if it is built without -xpec.
If you do not specify -xpec, the compiler sets it to -xpec=no. If you specify -xpec, but do not supply a flag, the compiler sets it to -xpec=yes.
(x86) Generates code for the Pentium processor.
Prepares the object code to collect data for profiling with gprof(1). Invokes a runtime recording mechanism that produces a gmon.out file (at normal termination).
Note: There is no advantage for -xprofile if you specify -xpg. The two do not prepare or use data provided by the other.
Profiles are generated by using prof or gprof on 64-bit Oracle Solaris platforms or just gprof on 32-bit Oracle Solaris platforms include approximate user CPU times. These times are derived from PC sample data (see pcsample (2) ) for routines in the main executable and routines in shared libraries specified as linker arguments when the executable is linked. Other shared libraries (libraries opened after process startup using dlopen (3C) ) are not profiled.
On 32-bit Oracle Solaris systems, profiles generated using prof (1) are limited to routines in the executable. 32-bit shared libraries can be profiled by linking the executable with -xpg and using gprof (1) .
Current Oracle Solaris releases do not include system libraries compiled with -p. As a result, profiles collected on current Oracle Solaris platforms do not include call counts for system library routines.
Note: On x86 systems, -xpg is incompatible with -xregs=frameptr because the gprof runtime library requires a valid frame pointer to determine the return address of a profiled routine. Note also that compiling with -fast on x86 systems will invoke -xregs=frameptr. Compile with the following instead:
-fast -xregs=no%frameptr -xpg
If you specify -xpg at compile time, you must also specify it at link time. See the C User's Guide for a complete list of options that must be specified at both compile time and link time.
Note: Binaries compiled with -xpg for gprof profiling should not be used with binopt(1), as they are incompatible and can result in internal errors.
Enables prefetch instructions on those architectures that support prefetch. You must compile with optimization level 3 or greater with this option.
val must be one of the following:
Enable automatic generation of prefetch instructions.
Disable automatic generation.
Enable explicit prefetch macros.
Explicit prefetching should only be used under special circumstances that are supported by measurements.
Disable explicit prefetch macros.
(SPARC) You can only combine this option with -xprefetch=auto. Adjust the compiler's assumed prefetch-to-load and prefetch-to-store latencies by the specified factor. The factor must be a positive number of the form n.n.
The prefetch latency is the hardware delay between the execution of a prefetch instruction and the time the data being prefetched is available in the cache.
The compiler assumes a prefetch latency value when determining how far apart to place a prefetch instruction and the load or store instruction that uses the prefetched data.
Note: the assumed latency between a prefetch and a load may not be the same as the assumed latency between a prefetch and a store.
The compiler tunes the prefetch mechanism for optimal performance across a wide range of machines and applications. This tuning may not always be optimal. For memory-intensive applications, especially applications intended to run on large multiprocessors, you may be able to obtain better performance by increasing the prefetch latency values. To increase the values, use a factor that is greater than 1 (one). A value between .5 and 2.0 will most likely provide the maximum performance.
For applications with datasets that reside entirely within the external cache, you may be able to obtain better performance by decreasing the prefetch latency values. To decrease the values, use a factor that is less than one.
To use the latx:factor suboption, start with a factor value near 1.0 and run performance tests against the application. Then increase or decrease the factor, as appropriate, and run the performance tests again. Continue adjusting the factor and running the performance tests until you achieve optimum performance. When you increase or decrease the factor in small steps, you will see no performance difference for a few steps, then a sudden difference, then it will level off again.
(Obsolete) Do not use. Use -xprefetch=auto,explicit instead.
(Obsolete) Do not use. Use -xprefetch=no%auto,no%explicit instead.
Defaults:
If you do not specify -xprefetch, the default is now -xprefetch=auto,explicit, not -xprefetch=yes. If you specify -xprefetch without a value, it is also equivalent to -xprefetch=auto,explicit. This change adversely affects applications that have essentially non-linear memory access patterns. To disable the change, specify -xprefetch=no%auto,no%explicit.
The sun_prefetch.h header file provides the macros that you can use to specify explicit prefetch instruction. The prefetches will be approximately at the place in the executable that corresponds to where the macros appear.
a is [no%]indirect_array_access.
Use this option to determine whether or not the compiler generates indirect prefetches for the loops indicated by the option -xprefetch_level in the same fashion the prefetches for direct memory accesses are generated.
If you do not specify a setting for -xprefetch_auto_type, the compiler sets it to -xprefetch_auto_type=no%indirect_array_access.
Options such as -xdepend, -xrestrict, and -xalias_level can affect the aggressiveness of computing the indirect prefetch candidates and therefore the aggressiveness of the automatic indirect prefetch insertion due to better memory alias disambiguation information.
Use this option to control the aggressiveness of automatic insertion of prefetch instructions as determined with -xprefetch=auto.
l must be 1, 2, or 3.
Prefetch levels 2 and 3 may not be effective on older SPARC and x86 platforms.
-xprefetch_level=1 enables automatic generation of prefetch instructions. -xprefetch_level=2 enables additional generation beyond level 1 and -xprefetch=3 enables additional generation beyond level 2.
You must compile with optimization level 3 or greater and generate code for a platform that supports prefetch.
The default is -xprefetch_level=1 when you specify -xprefetch=auto.
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 -xannotate.
See the Oracle Solaris Studio Code Analyzer documentation for further information.
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 multithreaded applications. That is, profiling a program that does its own multitasking ( -mt ) produces accurate results. This option is only valid when you specify -xO2 or greater level of optimization.
If compilation and linking are performed in separate steps, the same -xprofile option must appear on the compile as well as the link step. See the C User's Guide for a complete list of options that must be specified at both compile time and link time.
Collects and saves execution frequency for later use by the optimizer with -xprofile=use. The compiler generates code to measure statement execution-frequency.
-xMerge, -ztext, 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 initialized, position-dependent symbol relocations in writable storage.
The profile directory name profdir, if specified, is the pathname of the directory where profile data are to be stored when a program or shared library containing the 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=collect:prof_dir or -xprofile=tcov:prof_dir, profile data are stored at runtime 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 runtime. 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 runtime. These environment variables similarly control the path and names of the profile data files written by tcov, as described in the tcov (1) man page.
If these environment variables are not set, the profile data is written to the directory profdir.profile in the current directory, where profdir is the name of the executable or the name specified in the -xprofile=collect:profdir flag. -xprofile does not append .profile to profdir if profdir already ends in .profile. If you run the program several times, the execution frequency data 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.c -o prog ./prog cc -xprofile=use:myprof.profile -xO5 prog.c -o prog
Example[2]: to collect profile data in the directory /bench/myprof.profile and later use the collected profile data in a feedback compilation at optimization level -xO5:
cc -xprofile=collect:/bench/myprof.profile -xO5 prog.c -o prog ...run prog from multiple locations... cc -xprofile=use:/bench/myprof.profile -xO5 prog.c -o prog
If you are compiling and linking in separate steps, make sure that any object files compiled with -xprofile=collect are also linked with -xprofile=collect.
See also the ENVIRONMENT VARIABLES section of this man page below for descriptions of environment variables that control asynchronous profile collections.
Uses execution frequency data collected from code compiled with -xprofile=collect[:profdir] or -xprofile=tcov[:profdir] to optimize for the work performed when the profiled code was executed. profdir is the pathname of a directory containing profile data collected by running a program that was compiled with -xprofile=collect[:profdir] or -xprofile=tcov[:profdir].
To generate data that can be used by both tcov and -xprofile=use[:profdir], the same profile directory must be specified at compilation time, using the option -xprofile=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 -xprofile=collect.
Except for the -xprofile option, the source files and other compiler options must be exactly the same as those used for the compilation that created the compiled program which in turn generated the feedback file. The same version of the compiler must be used for both the collect build and the use build as well.
If compiled with -xprofile=collect:profdir, the same profile directory name profdir must be used in the optimizing compilation: -xprofile=use:profdir.
See also -xprofile_ircache for speeding up compilation between collect and use phases.
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 directory 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 controlled using environment variables SUN_PROFDATA and SUN_PROFDATA_DIR. See ENVIRONMENT below.
If the location specified by :profdir is not absolute, it is interpreted relative to the current working directory when the program is compiled.
If :profdir is specified for any object file, the same location must be specified for all object files in the same program. The directory whose location is specified by :profdir must be accessible from all machines where the profiled program is to be executed. The profile directory should not be deleted until its contents are no longer needed, because data stored there by the compiler cannot be restored except by recompilation.
Example 1: If object files for one or more programs are compiled with -xprofile=tcov:/test/profdata, a directory named /test/profdata.profile will be created by the compiler and used to store data describing the profiled object files. The same directory will also be used at execution time to store execution data associated with the profiled object files.
Example 2: If a program named "myprog" is compiled with -xprofile=tcov and executed in the directory /home/joe, the directory /home/joe/myprog.profile will be created at runtime and used to store runtime profile data.
(SPARC) 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 useful when the collect and use phases happen in two different directories.
Here's a typical sequence of commands:
example% cc -xO5 -xprofile=collect -xprofile_ircache t1.c t2.c example% a.out // run collects feedback data example% cc -xO5 -xprofile=use -xprofile_ircache t1.c t2.c
(SPARC) Use the -xprofile_pathmap option when you are also specifying the -xprofile=use command. Use -xprofile_pathmap when both of the following are true and the compiler is unable to find profile data for an object file that is compiled with -xprofile=use.
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.
Your object files share a common basename in the profile but are distinguished from each other by their location in different directories.
The collect-prefix is the prefix of the UNIX pathname of a directory tree in which object files were compiled using -xprofile=collect.
The use-prefix is the prefix of the UNIX pathname of a directory tree in which object files are to be compiled using -xprofile=use.
If you specify multiple instances of -xprofile_pathmap, the compiler processes them in the order of their occurrence. Each use-prefix specified by an instance of -xprofile_pathmap is compared with the object file pathname until either a matching use-prefix is identified or the last specified use-prefix is found not to match the object file pathname.
Analyzes loops for reduction in automatic parallelization. This option is valid only if -xautopar is also specified. Otherwise the compiler issues a warning.
When a reduction recognition is enabled, the compiler parallelizes reductions such as dot products, maximum and minimum finding. These reductions yield different roundoffs from those obtained by unparallelized code.
Specify the usage of registers for the generated code.
r is a comma-separated list of one or more of the following suboptions: appl, float, frameptr.
Prefixing a suboption with no% disables that suboption.
Example: -xregs=appl,no%float
Note that -xregs suboptions are restricted to specific hardware platforms.
Allow the compiler to generate code using the application registers as scratch registers. The application registers are g2, g3, and g4 on 32-bit platforms) and g2 and g3 on 64-bit platforms.
It is strongly recommended that all system software and libraries be compiled using -xregs=no%appl. System software (including shared libraries) must preserve these registers' values for the application. Their use is intended to be controlled by the compilation system and must be consistent throughout the application.
In the SPARC ABI, these registers are described as application registers. Using these registers can increase performance because fewer load and store instructions are needed. However, such use can conflict with some old library programs written in assembly code.
For more information on SPARC instruction sets, see -xarch.
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.
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 compilers will attempt to diagnose code that results in the use of floating point, simd, or x87 instructions.
Allow the compiler to use the frame-pointer register (%ebp on IA32, %rbp on x86 64-bit platforms) as a general-purpose register.
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 indirectly from a C or Fortran function, can throw an exception. If compiling such mixed source code with -fast, add -xregs=no%frameptr after the -fast option on the command line.
With more available registers on 64-bit platforms, 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 expansion of -fast on x86.
It is strongly recommended that you compile code intended for shared libraries that will link with applications, with -xregs=no%appl,float. At the very least, the shared library should explicitly document how it uses the application registers so that applications linking with those libraries are aware of these register assignments.
For example, an application using the registers in some global sense (such as using a register to point to some critical data structure) would need to know exactly how a library with code compiled without -xregs=no%appl is using the application registers in order to safely link with that library.
Treats pointer-valued function parameters as restricted pointers. f is %all, %none or a comma-separated list of one or more function names. This command-line option can be used on its own, but is best used with optimization of -xO3 or greater.
If a function list is specified with this option, pointer parameters in the specified functions are treated as restricted; if -xrestrict=%all is specified, all pointer parameters in the entire C file are treated as restricted.
The default is %none. Specifying -xrestrict is equivalent to specifying -xrestrict=%all.
See also: 'Restricted Pointers' in the C User's Guide.
(Oracle Solaris) Link debug information from object files into executable.
-xs is the same as -xs=yes. The default for -xdebugformat=dwarf is the same as -xs=yes. The default for -xdebugformat=stabs is the same as -xs=no.
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. For stabs, use -xs or -xs=yes to avoid dependence on the object files at the cost of a larger executable. 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 specified) 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 section 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 option. 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 accept -xs={yes|no}.
(SPARC) Allow the compiler to assume that no memory protection violations occur.
This option allows the compiler to use the non-faulting load instruction in 64-bit SPARC architecture.
Because non-faulting loads do not cause a trap when a fault such as address misalignment or segmentation violation occurs, you should use this option only for programs in which such faults cannot occur. Because few programs incur memory-based traps, you can safely use this option for most programs. Do not use this option for programs that explicitly depend on memory-based traps to handle exceptional conditions.
This option takes effect only when used with optimization level -xO5 and one of the following -xarch values: sparc, sparcvis, sparcvis2, or sparcvis3 for both -m32 and -m64.
(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 aforementioned segments will then be aligned on a 4M boundary.
Represents unsuffixed floating-point constants as single precision, instead of the default mode of double precision. Not valid with -pedantic.
Does no optimizations that increase code size. Does not parallelize loops if it increases code size. Example: Does not unroll loops.
This option may be deprecated in a future release. Use -features=[no%]conststrings instead.
The -xstrconst option inserts string literals into the read-only data section of the text segment instead of the default data segment. Duplicate strings will be eliminated and the remaining copy shared amongst references in the code.
Specifies the target system for the instruction set and optimization.
t must be one of: native, native64, generic, generic64, or system-name.
The -xtarget option permits a quick and easy specification of the -xarch, -xchip, and -xcache combinations that occur on real systems. The only meaning of -xtarget is in its expansion. See the -xdryrun explanation for details on how to see the expansion of macro options such as -xtarget.
-xtarget=native is equivalent to -m32, -xarch=native, -xchip=native, -xcache=native.
-xtarget=native64 is equivalent to -m64, -xarch=native64, -xchip=native64, -xcache=native.
-xtarget=generic is equivalent to -m32, -xarch=generic, -xchip=generic, -xcache=generic.
-xtarget=generic64 is equivalent to -m64, -xarch=generic64, -xchip=generic64, -xcache=generic.
The -fast macro option includes -xtarger=native in its expansion.
The -xtarget command itself is a macro option which acts like a macro expansion on the command line for the -xarch -xchip and -xcache options. Therefore, you can override any of the expanded options by following -xtarget with the desired option. Use the -xdryrun option to determine the expansion of -xtarget=native on a running system.
Note: The expansion of -xtarget for a specific host platform might not expand to the same -xarch, -xchip, or -xcache settings as -xtarget=native when compiling on that platform.
On SPARC platforms:
Compiling for 64-bit Oracle Solaris software on 64-bit SPARC architectures is indicated by the -m64 option. If you specify -xtarget with a flag other than native64 or generic64, you must also specify the -m64 option as follows:
-xtarget=ultra4 ... -m64
Otherwise the compiler uses a 32-bit memory model.
Set the parameters for the best performance on the host environment (assumes a 32-bit architecture).
Set the parameters for the best performance on the host environment (assumes a 64-bit architecture).
This is the default and sets the parameters for the best performance over most 32-bit platform architectures.
Set the parameters for the best performance over most 64-bit platform architectures.
Get the best performance for the specified system.
Valid SPARC platform names are shown below.
Commonly used platform names: ultra, ultra2, ultra2i, ultra1/140, ultra1/170, ultra1/200, ultra2/1170, ultra2/1200, ultra2/1300, ultra2/2170, ultra2/2200, ultra2/2300, ultra2e, ultra2i, ultra3, ultra3cu, ultra3i, ultra4, ultra4plus, ultraT1, ultraT2, ultraT2plus, T3, T4, T5, M5, sparc64vi, sparc64vii, sparc64viiplus, sparc64x, sparc64xplus.
Note: The following SPARC platform names are obsolete and may be removed in a future release: ultra, ultra2, ultra2e, ultra2i, ultra3, ultra3cu, ultra3i, ultra4, and ultra4plus.
On x86 platforms:
Compiling for 64-bit Oracle Solaris software on 64-bit x86 platforms is indicated by the -m64 option. If you specify -xtarget with a flag other than native64 or generic64, you must also specify the -m64 option as follows:
-xtarget=opteron ... -m64
Otherwise the compiler uses a 32-bit memory model.
This is the default and yields the best performance for generic architecture, chip and cache on most 32-bit systems.
Gets the best performance for generic architecture, chip and cache on most 64-bit systems.
The compiler generates code for the best performance on the host system. This flag determines the available architecture, chip, and cache properties of the machine on which the compiler is running and assumes a 32-bit architecture.
Set the parameters for the best performance on the host system. This flag determines the available architecture, chip, and cache properties of the machine on which the compiler is running and assumes a 64-bit architecture.
Generate code for the best performance on the indicated x86 processor-name. The following processors are recognized: barcelona, haswell, ivybridge, nehalem, opteron, pentium, pentium_pro, pentium3, pentium4, penryn, sandybridge, westmere, woodcrest.
The actual expansion of an -xtarget suboption might change and improve with each compiler release. Use the -dryrun option to see the actual expansion:
cc -dryrun -xtarget=ultra4 |& grep ### ### command line files and options (expanded): ### -dryrun -xchip=ultra4 -xcache=64/32/4:8192/128/2 -xarch=sparcvis2
Equivalent to -temp=path.
Works in conjunction with the __thread declaration specifier to take advantage of the compiler's thread-local storage facility. After you declare the thread variables with the __thread specifier, use -xthreadvar to enable the use of thread-local storage with position dependent code (non-PIC code) in dynamic (shared) libraries. For more information on how to use __thread, see the C User's Guide.
o must be the following:
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.
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.
If there is non-position-independent code within a dynamic library, you must specify -xthreadvar.
The linker cannot support the thread-variable equivalent of non-PIC code in dynamic libraries. Non-PIC thread variables are significantly faster, and hence should be the default for executables.
If there is non-position-independent code within a dynamic library, you must specify -xthreadvar.
Using thread variables on different versions of Oracle Solaris software requires different options on the command line.
See also: -xcode, -KPIC, -Kpic
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.
Reports the time and resources used by each compilation.
Issues warnings for differences between K&R C and ISO C. The -xtransition option issues messages in conjunction with the -Xa and -Xt options. You can eliminate all warning messages about differing behavior through appropriate coding.
Enables or disables recognition of trigraph sequences as defined by the ISO C standard.
-xtrigraphs=yes enables recognition of trigraph sequences in the source code.
-xtrigraphs=no disables recognition of trigraph sequences in the source code.
Defaults:
If the -xtrigraphs option is not specified, -xtrigraphs=no is assumed.
If only -xtrigraphs is specified -xtrigraphs=yes is assumed.
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.
Specifies whether or not the compiler optimizes (unrolls) loops. n is a positive integer. When n is 1, it is a command and the compiler unrolls no loops. When n is greater than 1, -xunroll=n allows the compiler to unroll loops n times.
Specify -xustr=ascii_utf16_ushort if you need to support an internationalized application that uses ISO10646 UTF-16 string literals. In other words, use this option if your code contains string literals that you want the compiler to convert to UTF-16 strings in the object file. Without this option, the compiler neither produces nor recognizes sixteen-bit character string literals. This option enables recognition of the U"ASCII_string" string literals as an array of unsigned short int. Since such strings are not yet part of any standard, this option enables recognition of non-standard C.
You can turn off compiler recognition of U"ASCII_string" string literals by specifying -xustr=no. The rightmost instance of this option on the command line overrides all previous instances.
The default is -xustr=no. If you specify -xustr without an argument, the compiler won't accept it and instead issues a warning. The default can change if the C or C++ standards define a meaning for the syntax.
It is not an error to specify -xustr=ascii_ustf16_ushort without also specifying a U"ASCII_string" string literal.
Specifying the flag -xustr=ascii_utf16_ushort results in an error if -std=c11 (including the default) is in effect. One of -Xc, -Xa, -Xt, -Xs, -xc99, -std=c99, -std=c89, or -ansi must also be specified when -xustr=ascii_utf16_ushort is specified.
Not all files have to be compiled with this option.
The following example shows a string literal in quotes that is prepended by U. It also shows a command line that specifies -xustr.
example% cat file.c
const unsigned short *foo = U"foo";
const unsigned short bar[] = U"bar";
const unsigned short *fun() { return
example% cc -xustr=ascii_utf16_ushort file.c -c
Enables automatic generation of calls to the vector library or the generation of the SIMD (Single Instruction Multiple Data) instructions on x86 processors that support SIMD. You must use default rounding mode by specifying -fround=nearest when you use this option.
The -xvector option requires optimization level -xO3 or greater. Compilation will not proceed if the optimization level is unspecified or lower than -xO3, and a message is issued.
a is the equivalent of the following. Prefix no% disables a suboption.
(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.
(SPARC) For -xarch=sparcace and -xarch=sparcaceplus, directs the compiler to use floating point and integral SIMD instructions to improve the performance of certain loops. Contrary to that of the other SPARC platforms, -xvector=simd is always effective under -xarch=sparcace and -xarch=sparcaceplus with the specification of any -xvector option, except -xvector=none and -xvector=no%simd. In addition -O greater than 3 is required for -xvector=simd, otherwise it is skipped without any warning.
For all other -xarch values, directs the compiler to use the Visual Instruction Set [VIS1, VIS2, ViS3, etc.] SIMD instructions to improve the performance of certain loops. Basically with explicit -xvector=simd option, the compiler will perform loop transformation enabling the generation of special vectorized SIMD instructions to reduce the number of loop iterations. The -xvector=simd option is effective only if -O is greater than 3 and -xarch is sparcvis3 and above. Otherwise -xvector=simd is skipped without any warning.
(x86) Directs the compiler to use the native x86 SSE SIMD instructions to improve performance of certain loops. Streaming extensions are used on x86 by default at 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=generic64, -xarch=sse2, -xarch=sse3, or -fast on a modern platform to use it. If the target ISA has no streaming extensions, the suboption will have no effect.
Disables this option entirely.
This option is deprecated, specify -xvector=lib instead.
This option is deprecated, specify -xvector=%none instead.
The default is -xvector=simd on x86 and -xvector=%none on SPARC platforms. If you specify -xvector without a suboption, the compiler assumes -xvector=simd,lib on x86 Oracle Solaris, -xvector=lib on SPARC Oracle Solaris, and -xvector=simd on Linux platforms.
This option overrides previous instances so -xvector=%none undoes a previously specified -xvector=lib.
The compiler includes the libmvec libraries in the load step.
Note: -xvector=%none should be used when compiling Oracle Solaris kernel code for x86 platforms.
If you compile and link with separate commands, be sure to use the same option for both compilation and linking.
(SPARC) Compile with -xvis=yes when including the <vis.h> header to generate VIS instructions, or when using assembler inline code (.il) that uses VIS instructions. The default is -xvis=no. Specifying -xvis is equivalent to specifying -xvis=yes.
The VIS[tm] instruction set is an extension to the SPARC V9 instruction set. Even though the UltraSPARC processors are 64-bit, there are many cases, especially in multimedia applications, when the data are limited to eight or 16 bits in size. The VIS instructions can process four 16-bit data with one instruction so they greatly improve the performance of applications that handle new media such as imaging, linear algebra, signal processing, audio, video and networking.
Issues warnings about potential parallel-programming related problems that may cause incorrect results when using OpenMP. Use with -xopenmp and OpenMP API directives.
The compiler issues warnings when it detects the following situations:
Loops are parallelized using MP directives when there are data dependencies between different loop iterations
OpenMP data-sharing attributes-clauses are problematic. For example, declaring a variable "shared" whose accesses in an OpenMP parallel region may cause data race, or declaring a 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.c
Specifies a new directory dir for the location of component c. c can consist of any of the characters representing tools listed under the -W option.
If the location of a tool is being specified, then the new path name for the tool will be dir/tool. If more than one -Y option is applied to any one item, then the last occurrence holds.
Specifies a directory dir to search for all compiler components. If a component is not found in dir, the search reverts to the directory where the compiler is installed.
Changes default directory searched for include files.
Changes default directory for finding libraries files.
Changes default directory for startup object files.
Creates the program database for lock_lint, but does not generate executable code.
cc recognizes -a, -e, -r, -t, -u, and -z and passes these options and their arguments to ld. cc also passes any unrecognized options to ld with a warning.
Certain floating-point math library routines will return error status in the errno variable (defined in errno.h). With options -fast , -xbuiltin, -xlibmieee, -xlibmil, and -xlibmopt, the compiler is free to replace calls to floating point functions with equivalent optimized code that does not set the errno variable. Further, -fast also defines the macro __MATHERR_ERRNO_DONTCARE, which allows the compiler to assume that math functions need not set errno. As a result, user code that relies on the value of errno or a floating-point exception being raised after a floating point function call could produce inconsistent results.
One way around this problem is to avoid compiling such codes with -fast.
However, if -fast optimization is required and the code depends on the value of errno being set properly or an appropriate floating-point exception being raised after floating-point library calls, you should compile with the options
-xbuiltin=none -U__MATHERR_ERRNO_DONTCARE \ -xnolibmopt -xnolibmil
following -fast on the command line to inhibit the compiler from optimizing out such library calls and to to ensure that calls to math functions set errno as documented.
New Shared LibrariesFor Solaris release 10, new shared libraries libxprof.so.1, libxprof_audit.so.1, and libtdf.so.1 must be installed in order to use the -xprofile option. These libraries are pre-installed on the latest Oracle Solaris releases.
The following #pragmas are recognized by the compilation system:
#pragma align #pragma c99 #pragma does_not_read_global_data #pragma does_not_return #pragma does_not_write_global_data #pragma error_messages #pragma fini #pragma hdrstop #pragma ident #pragma init #pragma [no_]inline #pragma [no_]warn_missing_parameter #pragma int_to_unsigned #pragma opt #pragma pack #pragma rarely_called #pragma redefine_extname #pragma returns_new_memory #pragma struct_align #pragma unknown_control_flow #pragma weak #pragma does_not_read_global_data #pragma does_not_write_global_data #pragma no_side_effect
See also the OpenMP API User's Guide for a list of supported OpenMP 2.5 directives.
SPARC Only:
#pragma nomemorydepend #pragma no_side_effect #pragma pipeloop #pragma unroll
Refer to the C User's Guide for more information on these pragmas.
The following is a list of environment variables that you can set along with a brief description of their function.
A default set of options to lint. LINT_OPTIONS is interpreted by lint as though its value had been placed on the command line, immediately following the name used to invoke lint, as in:
lint $LINT_OPTIONS ... other-arguments ...
Enable or disable dynamic adjustment of the number of threads.
Enable or disable nested parallelism. See the OpenMP API User's Guide.
This variable tells the runtime system the maximum number of threads the program can create. Default is 2. See the OpenMP API User's Guide.
Set the runtime schedule type and chunk size. See the OpenMP API User's Guide.
Same as OMP_NUM_THREADS.
The executing program maintains a main memory stack for the master thread and distinct stacks for each slave thread. Stacks are temporary memory address spaces used to hold arguments and automatic variables over subprogram invocations. The default size of the main stack is about eight megabytes. Use the limit (1) command to display the current main stack size as well as set it.
Each slave thread of a multithreaded program has its own thread stack. This stack mimics the main stack of the master thread but is unique to the thread. The thread's private arrays and variables (local to the thread) are allocated on the thread stack.
All slave threads have the same stack size, which is four megabytes for 32-bit applications and eight megabytes for 64-bit applications by default. The size is set with the STACKSIZE environment variable.
Setting the thread stack size to a value larger than the default may be necessary for some parallelized code.
The syntax of the STACKSIZE environment variable accepts a keyword for denoting the slave thread stacksize: B for Bytes, K for Kilobytes, M for Megabytes, G for Gigabytes.
For example, setenv STACKSIZE 8192 sets the slave thread stack size to 8 MB. 1235B sets the slave thread stack size for 1235 Bytes. 1235G sets it for 1235 Gigabytes. The default for an integer value without a suffix letter is still Kilobytes.
Sometimes the compiler may generate a warning message that indicates a bigger stack size is needed. However, it may not be possible to know just how large to set it, except by trial and error, especially if private/local arrays are involved. If the stack size is too small for a thread to run, the program will abort with a segmentation fault.
cc normally creates temporary files in the directory tmp. You may specify another directory by setting the environment variable TMPDIR to your chosen directory. (If TMPDIR isn't a valid directory, then cc will use tmp). The -xtemp option has precedence over the TMPDIR environment variable.
(Obsolete) The source browser functionality is no longer supported.
If set, store profile data collected from a program compiled with -xprofile=collect in a directory named profdir in the current working directory at the time that the program is executed. If the optional argument :profdir was specified in -xprofile=collect[:profdir] at compilation time, SUN_PROFDATA as no effect.
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=collect[:profdir] at compilation time, SUN_PROFDATA_DIR has no effect.
Controls end-of-task status of each helper thread and can be set to spin or sleep ns. The default is sleep. See the OpenMP API User's Guide for details.
Set this environment variable to TRUE to print warning messages from the OpenMP and other parallelization runtime-systems. If you registered a function by using sunw_mp_register_warn() to handle warning messages, then SUNW_MP_WARN prints no warning messages, even if you set it to TRUE. If you did not register a function and set SUNW_MP_WARN to TRUE, SUNW_MP_WARN prints the warning messages to stderr. If you do not register a function and you do not set SUNW_MP_WARN, no warning messages are issued. For more information on sunw_mp_register_warn() see the C User's Guide.
The value of the environment variable SUN_PROFDATA_REPLACE indicates the scope of profile data to be reset when a changed version of an object file is detected at runtime. Use SUN_PROFDATA_REPLACE to ensure that profile data are consistent with the profiled program within the specified unit of program scope.
The values of SUN_PROFDATA_REPLACE and their meanings are as follows:
Reset profile data of changed object file.
Reset profile data of all object files in program containing changed object file.
Reset entire contents of profile directory if any object file has changed.
The default setting of SUN_PROFDATA_REPLACE is SUN_PROFDATA_REPLACE=objfile .
Example:
% setenv SUN_PROFDATA_REPLACE program (csh) $ export SUN_PROFDATA_REPLACE=program (ksh)
With this setting, when a program containing a changed object file is executed, all object files in the program will have their profile data reset. Relevant options include -xOn and -xipo=n.
Set this environment variable to enable asynchronous profile collection. In asynchronous profile collection, profile data are collected from a running process at regular intervals whose duration is specified in units of seconds.
SUN_PROFDATA_ASYNC_INTERVAL has no effect unless one of the environment variables LD_AUDIT, LD_AUDIT_32, or LD_AUDIT_64 is set to /usr/lib/{,64}/libxprof_audit.so.1.
Asynchronous profile collection requires an MT-safe, mmap based memory allocator, such as libumem (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]
If set nonzero, enables verbose messages from asynchronous collector to stderr. SUN_PROFDATA_ASYNC_VERBOSE has no effect unless asynchronous profile collection is enabled.
If set to 1, enables profiler to clean up its data structures between the time that the process calls exit() and the time that process exit is complete. If set to 0, avoids destructive interference 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.
executable output file
tcov support
library of object files
C source file
tcov (1) test coverage input file
C source file after preprocessing
inline (1) expansion file
lock_lint database
object file
The directory for data used by -xprofile
assembler source file
dynamic library
output from tcov (1)
compiler front end
compiler command line driver
code generator (SPARC)
runtime startup code
runtime startup code
runtime startup code
assembler
startup for profiling with gprof (1)
default profile file for -xpg
Interprocedural optimizer (SPARC)
global optimizer
bids support
start-up for profiling with prof (1) and intro (3)
misalign data support (SPARC)
default profile file for -p
postoptimizer (SPARC)
Static synchronization bug detection (Oracle Solaris Operating Environment)
stack overflow checking (SPARC)
The directory used to store data when the -xpch option is used.
optimizer, code generator (x86)
Interprocedural analyzer (x86)
-Xa support
-Xc support
xpg4 support
SUSv3 support
-Xs support
-Xt support
Initialization and finalization handlers for programs compiled with -xprofile=collect
analyzer (1) , as (1) , c89 (1) , c99 (1) , cflow (1) , cscope (1) , ctags (1) , ctrace (1) , dbx (1) , er_src (1) , indent (1) , inline (4) , ld (1) , lint (1) , lock_lint (1) , prof (1) , sunstudio (1) , tmpnam (3C) , version (1)
C User's Guide
OpenMP API User's Guide
The ISO/IEC 9899-1990 Programming Language - C standard
The ISO/IEC 9899-1999 Programming Language - C standard