The following section alphabetically lists all the C++ compiler options and indicates any platform restrictions.
x86: Same as –xtarget=386. This option is provided for backward compatibility only.
x86: Same as –xtarget=486. This option is provided for backward compatibility only.
Specifies whether a library binding for linking is symbolic, dynamic (shared), or static (nonshared).
You can use the –B option several times on a command line. This option is passed to the linker, ld.
Many system libraries are only available as dynamic libraries in the Solaris 64-bit compilation environment. Therefore, do not use -Bstatic as the last toggle on the command line.
binding must be one of the following:
Value |
Meaning |
---|---|
dynamic |
Directs the link editor to look for liblib.so (shared) files, and if they are not found, to look for liblib.a (static, nonshared) files. Use this option if you want shared library bindings for linking. |
static |
Directs the link editor to look only for liblib.a (static, nonshared) files. Use this option if you want nonshared library bindings for linking. |
symbolic |
Forces symbols to be resolved within a shared library if possible, even when a symbol is already defined elsewhere. See the ld(1) man page. |
(No space is allowed between –B and the binding value.)
If -B is not specified, –Bdynamic is assumed.
To link the C++ default libraries statically, use the –staticlib option.
The -Bstatic and -Bdynamic options affect the linking of the libraries that are provided by default. To ensure that the default libraries are linked dynamically, the last use of –B should be –Bdynamic.
In a 64-bit environment, many system libraries are available only as shared dynamic libraries. These include libm.so and libc.so (libm.a and libc.a are not provided). As a result, -Bstatic and -dn may cause linking errors in 64-bit Solaris operating systems. Applications must link with the dynamic libraries in these cases.
The following compiler command links libfoo.a even if libfoo.so exists; all other libraries are linked dynamically:
example% CC a.o –Bstatic –lfoo –Bdynamic |
Never use -Bsymbolic with programs containing C++ code, use linker map files instead.
With -Bsymbolic, references in different modules can bind to different copies of what is supposed to be one global object.
The exception mechanism relies on comparing addresses. If you have two copies of something, their addresses won’t compare equal, and the exception mechanism can fail because the exception mechanism relies on comparing what are supposed to be unique addresses.
If you compile and link in separate steps and are using the -Bbinding option, you must include the option in the link step.
–nolib, –staticlib, ld(1), 12.5 Statically Linking Standard Libraries, Linker and Libraries Guide
Compile only; produce object .o files, but suppress linking.
This option directs the CC driver to suppress linking with ld and produce a .o file for each source file. If you specify only one source file on the command line, then you can explicitly name the object file with the -o option.
If you enter CC -c x.cc, the x.o object file is generated.
If you enter CC -c x.cc -o y.o, the y.o object file is generated.
When the compiler produces object code for an input file (.c, .i), the compiler always produces a .o file in the working directory. If you suppress the linking step, the .o files are not removed.
–o filename, –xe
Sets the major release compatibility mode of the compiler. This option controls the __SUNPRO_CC_COMPAT and __cplusplus macros.
The C++ compiler has two principal modes. The compatibility mode accepts ARM semantics and language defined by the 4.2 compiler. The standard mode accepts constructs according to the ANSI/ISO standard. These two modes are incompatible with each other because the ANSI/ISO standard forces significant, incompatible changes in name mangling, vtable layout, and other ABI details. These two modes are differentiated by the –compat option as shown in the following values.
The -compat option can have the following values.
Value |
Meaning |
---|---|
–compat=4 |
(Compatibility mode) Set language and binary compatibility to that of the 4.0.1, 4.1, and 4.2 compilers. Set the __cplusplus preprocessor macro to 1 and the __SUNPRO_CC_COMPAT preprocessor macro to 4. |
–compat=5 |
(Standard mode) Set language and binary compatibility to ANSI/ISO standard mode. Set the __cplusplus preprocessor macro to 199711L and the __SUNPRO_CC_COMPAT preprocessor macro to 5. |
If the –compat option is not specified, –compat=5 is assumed.
If only –compat is specified, –compat=4 is assumed.
You cannot use the standard libraries in compatibility mode (-compat[=4]).
Use of –compat[=4] with any of the following options is not supported.
-Bsymbolic
-features=[no%]strictdestrorder
-features=[no%]tmplife
-library=[no%]iostream
-library=[no%]Cstd
-library=[no%]Crun
-library=[no%]rwtools7_std
-xarch=native64, -xarch=generic64, -xarch=v9, -xarch=v9a, or -xarch=v9b
Use of –compat=5 with any of the following options is not supported.
-Bsymbolic
+e
features=[no%]arraynew
features=[no%]explicit
features=[no%]namespace
features=[no%]rtti
library=[no%]complex
library=[no%]libC
-vdelx
When building a shared library do not use -Bsymbolic.
C++ Migration Guide
Does not expand C++ inline functions.
Under the C++ language rules, a C++ inline function is a function for which one of the following statements is true.
The function is defined using the inline keyword,
The function is defined (not just declared) inside a class definition
The function is a compiler-generated class member function
Under the C++ language rules, the compiler can choose whether actually to inline a call to an inline function. The C++ compiler inlines calls to an inline function unless:
The function is too complex,
The +d option is selected, or
The -g option is selected
By default, the compiler may inline the functions f() and memf2() in the following code example. In addition, the class has a default compiler-generated constructor and destructor that the compiler may inline. When you use +d, the compiler will not inline f()and C::mf2(), the constructor, and the destructor.
inline int f() {return 0;} // may be inlined class C { int mf1(); // not inlined unless inline definition comes later int mf2() {return 0;} // may be inlined }; |
This option is automatically turned on when you specify –g, the debugging option.
The –g0 debugging option does not turn on +d.
The +d option has no effect on the automatic inlining that is performed when you use -xO4 or -xO5.
–g0, –g
Defines the macro symbol name to the preprocessor.
Using this option is equivalent to including a #define directive at the beginning of the source. You can use multiple -D options.
The following table shows the predefined macros. You can use these values in such preprocessor conditionals as #ifdef.
Table A–2 Predefined Macros
If you do not use =def, name is defined as 1.
If +p is used, sun, unix, sparc, and i386 are not defined.
–U
Allows or disallows dynamic libraries for the entire executable.
This option is passed to ld.
This option can appear only once on the command line.
Value |
Meaning |
---|---|
-dy |
Specifies dynamic linking in the link editor. |
–dn |
Specifies static linking in the link editor. |
If no -d option is specified, –dy is assumed.
In a 64-bit environment, many system libraries are available only as shared dynamic libraries. These include libm.so and libc.so (libm.a and libc.a are not provided). As a result, -Bstatic and -dn may cause linking errors in 64-bit Solaris operating systems. Applications must link with the dynamic libraries in these cases.
This option causes fatal errors if you use it in combination with dynamic libraries. Most system libraries are only available as dynamic libraries.
ld(1), Linker and Libraries Guide
-dalign is equivalent to -xmemalign=8s. See A.2.147 -xmemalign=ab for more information.
If you compile one program unit with –dalign, compile all units of a program with -dalign, or you might get unexpected results.
Shows the subcommands built by driver, but does not compile.
This option directs the CC driver to show, but not execute, the subcommands constructed by the compilation driver.
Runs the preprocessor on source files; does not compile.
Directs the CC driver to run only the preprocessor on C++ source files, and to send the result to stdout (standard output). No compilation is done; no .o files are generated.
This option causes preprocessor-type line number information to be included in the output.
This option is useful for determining the changes made by the preprocessor. For example, the following program, foo.cc, generates the output shown in A.2.13.1 Examples
#if __cplusplus < 199711L int power(int, int); #else template <> int power(int, int); #endif int main () { int x; x=power(2, 10); } . |
example% CC -E foo.cc #4 "foo.cc" template < > int power (int, int); int main () { int x; x = power (2, 10); } |
Output from this option is not supported as input to the C++ compiler when templates are used.
–P
Controls virtual table generation in compatibility mode (-compat[=4]). Invalid and ignored when in standard mode (the default mode).
The +e option can have the following values.
Value |
Meaning |
---|---|
0 |
Suppresses the generation of virtual tables and creates external references to those that are needed. |
1 |
Creates virtual tables for all defined classes with virtual functions. |
When you compile with this option, also use the –features=no%except option. Otherwise, the compiler generates virtual tables for internal types used in exception handling.
If template classes have virtual functions, ensuring that the compiler generates all needed virtual tables, but does not duplicate these tables, might not be possible.
C++ Migration Guide
This command suppresses C++ compiler warning messages and 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.
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 suppresses all warning messages except tag. The following table lists the -erroff values:
Table A–3 The -erroff Values
Value |
Meaning |
---|---|
tag |
Suppresses the warning message specified by this tag. You can display the tag for a message by using the -errtags=yes option. |
no%tag |
Enables the warning message specified by this tag. |
%all |
Suppresses all warning messages. |
%none |
Enables all warning messages (default). |
The default is -erroff=%none. Specifying -erroff is equivalent to specifying -erroff=%all.
For example, -erroff=tag suppresses the warning message specified by this tag. On the other hand, -erroff=%all,no%tag suppresses all warning messages except the messages identified by tag.
You can display the tag for a warning message by using the -errtags=yes option.
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.
-errtags, -errwarn
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 warning with the -errwarn option.
a can be either yes or no. The default is -errtags=no. Specifying -errtags is equivalent to specifying -errtags=yes.
Messages from the C++ compiler driver and other components of the compilation system do not have error tags, and cannot be suppressed with -erroff or made fatal with -errwarn.
-erroff, -errwarn
Use -errwarn 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 cc to exit with a fatal status if any warning except tag is issued.
The following table details the -errwarn values:
Table A–4 The -errwarn Values
Value |
Meaning |
---|---|
tag |
Cause CC to exit with a fatal status if the message specified by this tag is issued as a warning message. Has no effect if tag is not issued. |
no%tag |
Prevent CC from exiting with a fatal status if the message specified by tag is issued only as a warning message. Has no effect if the message specified by tag is not issued. Use this option to revert a warning message that was previously specified by this option with tag or %all from causing cc to exit with a fatal status when issued as a warning message. |
%all |
Cause CC to exit with a fatal status if any warning messages are issued. %all can be followed by no%tag to exempt specific warning messages from this behavior. |
%none |
Prevents any warning message from causing CC to exit with a fatal status should any warning message be issued. |
The default is -errwarn=%none. If you specify -errwarn alone, it is equivalent to -errwarn=%all.
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 compiler to exit with a failure status.
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.
-erroff, -errtags
This option is a macro that can be effectively used as a starting point for tuning an executable for maximum runtime performance. -fast is a macro that can change from one release of the compiler to the next and expands to options that are target platform specific. Use the -# option or -xdryrun to examine the expansion of -fast, and incorporate the appropriate options of -fast into the ongoing process of tuning the executable.
This option is a macro that selects a combination of compilation options for optimum execution speed on the machine upon which the code is compiled.
This option provides near maximum performance for many applications by expanding to the following compilation options.
Table A–5 The -fast Expansion
Option |
SPARC |
x86 |
---|---|---|
–fns |
X |
X |
–fsimple=2 |
X |
X |
–nofstore |
- |
X |
-xarch |
X |
X |
-xbuiltin=%all |
X |
X |
-xdepend |
X |
X |
–xlibmil |
X |
X |
–xlibmopt |
X |
X |
–xmemalign |
X |
- |
–xO5 |
X |
X |
-xregs=frameptr |
- |
X |
–xtarget=native |
X |
X |
The -fast macro expands into compilation options that may affect other specified options. For example, in the following command, the expansion of the -fast macro includes -xtarget=native which reverts -xarch to one of the 32-bit architecture options.
Incorrect:
example% CC -xarch=v9 -fast test.cc |
Correct:
example% CC -fast -xarch=v9 test.cc |
See the description for each option to determine possible interactions.
The code generation option, the optimization level, the optimization of built-in functions, and the use of inline template files can be overridden by subsequent options (see examples). The optimization level that you specify overrides a previously set optimization level.
The –fast option includes –fns –ftrap=%none; that is, this option turns off all trapping.
The following compiler command results in an optimization level of –xO3.
example% CC –fast –xO3 |
The following compiler command results in an optimization level of –xO5.
example% CC -xO3 –fast |
If you compile and link in separate steps, the -fast option must appear in both the compile command and the link command.
Code that is compiled with the -fast option is not portable. For example, using the following command on an UltraSPARC III system generates a binary that will not execute on an UltraSPARC II system.
example% CC -fast test.cc |
Do not use this option for programs that depend on IEEE standard floating-point arithmetic; different numerical results, premature program termination, or unexpected SIGFPE signals can occur.
In previous SPARC releases, the -fast macro expanded to -fsimple=1. Now it expands to -fsimple=2.
In previous releases, the -fast macro expanded to -xO4. Now it expands to -xO5.
In previous SPARC releases, the –fast macro option included –fnonstd; now it does not. Nonstandard floating-point mode is not initialized by –fast. See the Numerical Computation Guide, ieee_sun(3M).
-fns, -fsimple, -ftrap=%none, -xlibmil, -nofstore, -xO5, -xlibmopt, -xtarget=native
Enables/disables various C++ language features named in a comma-separated list.
In both compatibility mode (-compat[=4]) and standard mode (the default mode), a can have the following values.
Table A–6 The -features Values for Compatibility Mode and Standard Mode
Value |
Meaning |
---|---|
%all |
All the -features options that are valid for the specified mode (compatibility mode or standard mode). |
[no%]altspell |
[Do not] Recognize alternative token spellings (for example, “and” for “&&”). The default is no%altspell in compatibility mode and altspell in standard mode. |
[Do not] Allow anachronistic constructs. When disabled (that is, -features=no%anachronisms), no anachronistic constructs are allowed. The default is anachronisms. |
|
[Do not] Allow the bool type and literals. When enabled, the macro _BOOL=1. When not enabled, the macro is not defined. The default is no%bool in compatibility mode and bool in standard mode. |
|
[Do not] Put literal strings in read-only memory. The default is no%conststrings in compatibility mode and conststrings in standard mode. |
|
[Do not] Allow C++ exceptions. When C++ exceptions are disabled (that is, -features=no%except), a throw-specification on a function is accepted but ignored; the compiler does not generate exception code. Note that the keywords try, throw, and catch are always reserved. See 8.3 Disabling Exceptions. The default is except. |
|
[Do not] Recognize the keyword export. The default is no%export in compatibility mode and export in standard mode. |
|
[Do not] allow nonstandard code that is commonly accepted by other C++ compilers. See Table 3–18 for an explanation of the invalid code that is accepted by the compiler when you use the -features=extensions option. The default is no%extensions. |
|
[Do not] Allow a $ symbol as a noninitial identifier character. The default is no%iddollar. |
|
[Do not] Use new local-scope rules for the for statement. The default is no%localfor in compatibility mode and localfor in standard mode. |
|
[no%]mutable |
[Do not] Recognize the keyword mutable. The default is no%mutable in compatibility mode and mutable in standard mode. |
[Do not] Put initializers for nonlocal static objects into individual functions. When you use -features=no%split_init, the compiler puts all the initializers in one function. Using -features=no%split_init minimizes code size at the possible expense of compile time. The default is split_init. |
|
[Do not] allow ARM language constructs that are problematic in standard C++ and that may cause the program to behave differently than expected or that may be rejected by future compilers. When you use -features=no%transitions, the compiler treats these as errors. When you use -features=transitions in standard mode, the compiler issues warnings about these constructs instead of error messages. When you use -features=transitions in compatibility mode (-compat[=4]), the compiler displays the warnings about these constructs only if +w or +w2 is specified. The following constructs are considered to be transition errors: redefining a template after it was used, omitting the typename directive when it is needed in a template definition, and implicitly declaring type int. The set of transition errors may change in a future release. The default is transitions. |
|
%none |
Turn off all the features that can be turned off for the specified mode. |
In standard mode (the default mode), a can have the following additional values.
Table A–7 The -features Values for Standard Mode Only
Value |
Meaning |
---|---|
[Do not] Follow the requirements specified by the C++ standard regarding the order of the destruction of objects with static storage duration. The default is strictdestrorder. |
|
[no%]tmplrefstatic |
[Do not] allow function templates to refer to dependent static functions or static function templates. The default is the standard conformant no%tmplrefstatic. |
[Do not] Clean up the temporary objects that are created by an expression at the end of the full expression, as defined in the ANSI/ISO C++ Standard. (When -features=no%tmplife is in effect, most temporary objects are cleaned up at the end of their block.) The default is no%tmplife. |
In compatibility mode (-compat[=4]), a can have the following additional values.
Table A–8 The -features Values for Compatibility Mode Only
Value |
Meaning |
---|---|
[Do not] Recognize array forms of operator new and operator delete (for example, operator new [ ] (void*)). When enabled, the macro __ARRAYNEW=1. When not enabled, the macro is not defined. The default is no%arraynew. |
|
[Do not] Recognize the keyword explicit. The default is no%explicit. |
|
[Do not] Recognize the keywords namespace and using. The default is no%namespace. The purpose of -features=namespace is to aid in converting code to standard mode. By enabling this option, you get error messages if you use these keywords as identifiers. The keyword recognition options allow you to find uses of the added keywords without having to compile in standard mode. |
|
[Do not] Allow runtime type information (RTTI). RTTI must be enabled to use the dynamic_cast<> and typeid operators. For -compat=4 mode, the default is no%rtti. Otherwise, the default is -features=rtti, and the option -features=no%rtti is not allowed. |
The [no%]castop setting is allowed for compatibility with makefiles written for the C++ 4.2 compiler, but has no affect on compiler versions 5.0, 5.1, 5.2 and 5.3. The new style casts ( const_cast, dynamic_cast, reinterpret_cast, and static_cast) are always recognized and cannot be disabled.
If –features is not specified, the following is assumed:
Compatibility mode (-compat[=4])
–features=%none,anachronisms,except,split_init,transitions |
Standard mode (the default mode)
–features=%all,no%iddollar,no%extensions,no%tmplife |
This option accumulates instead of overrides.
Use of the following in standard mode (the default) is not compatible with the standard libraries and headers:
no%bool
no%except
no%mutable
no%explicit
In compatibility mode (-compat[=4]), the -features=transitions option has no effect unless you specify the +w option or the +w2 option.
Be careful when you specify -features=%all or -features=%none. The set of features can change with each compiler release and with each patch. Consequently, you can get unintended behavior.
The behavior of a program might change when you use the -features=tmplife option. Testing whether the program works both with and without the -features=tmplife option is one way to test the program’s portability.
The compiler assumes -features=split_init by default in compat mode (-compt=4). If you use the -features=%none option to turn off other features, you may find it desirable to turn the splitting of initializers into separate functions back on by using -features=%none,split_init instead.
Table 3–18 and the C++ Migration Guide
Controls the filtering that the compiler normally applies to linker and compiler error messages.
filter must be one of the following values.
Table A–9 The -filt Values
Value |
Meaning |
---|---|
[no%]errors |
[Do not] Show the C++ explanations of the linker error messages. The suppression of the explanations is useful when the linker diagnostics are provided directly to another tool. |
[no%]names |
[Do not] Demangle the C++ mangled linker names. |
[no%]returns |
[Do not] Demangle the return types of functions. Suppression of this type of demangling helps you to identify function names more quickly, but note that in the case of co-variant returns some functions differ only in the return type. |
[no%]stdlib |
[Do not] Simplify names from the standard library in both the linker and compiler error messages. This makes it easier for you to recognize the names of standard library template types. |
%all |
Equivalent to -filt=errors,names,returns,stdlib. This is the default behavior. |
%none |
Equivalent to -filt=no%errors,no%names,no%returns,no%stdlib. |
If you do not specify the -filt option, or if you specify -filt without any values, then the compiler assumes -filt=%all.
The following examples show the effects of compiling this code with the -filt option.
// filt_demo.cc class type { public: virtual ~type(); // no definition provided }; int main() { type t; } |
When you compile the code without the -filt option, the compiler assumes -filt=errors,names,returns,stdlib and displays the standard output.
example% CC filt_demo.cc Undefined first referenced symbol in file type::~type() filt_demo.o type::__vtbl filt_demo.o [Hint: try checking whether the first non-inlined, non-pure virtual function of class type is defined] ld: fatal: Symbol referencing errors. No output written to a.out |
The following command suppresses the demangling of the of the C++ mangled linker names and suppresses the C++ explanations of linker errors.
example% CC -filt=no%names,no%errors filt_demo.cc Undefined first referenced symbol in file __1cEtype2T6M_v_ filt_demo.o __1cEtypeG__vtbl_ filt_demo.o ld: fatal: Symbol referencing errors. No output written to a.out |
Now consider this code:
#include <string> #include <list> int main() { std::list<int> l; std::string s(l); // error here } |
Here’s the output when you specify -filt=no%stdlib:
Error: Cannot use std::list<int, std::allocator<int>> to initialize std::basic_string<char, std::char_traits<char>, std::allocator<char>>. |
Here’s the output when you specify -filt=stdlib:
Error: Cannot use std::list<int> to initialize std::string . |
When you specify no%names, neither returns nor no%returns has an effect. That is, the following options are equivalent:
-filt=no%names
-filt=no%names,no%returns
-filt=no%names,returns
(SPARC) Enables automatic generation of floating-point, fused, multiply-add instructions. -fma=none disables generation of these instructions. -fma=fused allows the compiler to attempt to find opportunities to improve the performance of the code by using floating-point, fused, multiply-add instructions.
The default is -fma=none.
The minimum requirements are -xarch=sparcfmaf and an optimization level of at least -xO2 for the compiler to generate fused multiply-add instructions. The compiler marks the binary program if fused multiply-add instructions are generated in order to prevent the program from executing on platforms that do not support them.
Causes hardware traps to be enabled for floating-point overflow, division by zero, and invalid operations exceptions. These results are converted into SIGFPE signals; if the program has no SIGFPE handler, it terminates with a memory dump (unless you limit the core dump size to 0).
SPARC: In addition, -fnonstd selects SPARC nonstandard floating point.
If –fnonstd is not specified, IEEE 754 floating-point arithmetic exceptions do not abort the program, and underflows are gradual.
x86: -fnonstd expands to -ftrap=common.
SPARC: -fnonstd expands to -fns -ftrap=common.
–fns, –ftrap=common, Numerical Computation Guide.
SPARC: Enables/disables the SPARC nonstandard floating-point mode.
-fns=yes (or -fns) causes the nonstandard floating point mode to be enabled when a program begins execution.
This option provides a way of toggling the use of nonstandard or standard floating-point mode following some other macro option that includes –fns, such as –fast.
On some SPARC devices, the nonstandard floating-point mode disables “gradual underflow,” causing tiny results to be flushed to zero rather than to produce subnormal numbers. It also causes subnormal operands to be silently replaced by zero.
On those SPARC devices that do not support gradual underflow and subnormal numbers in hardware, -fns=yes (or -fns) can significantly improve the performance of some programs.
(x86) Selects SSE flush-to-zero mode and, where available, denormals-are-zero mode.
This option causes subnormal results to be flushed to zero. 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 -fns option can have the following values.
Table A–10 The -fns Values
Value |
Meaning |
---|---|
yes |
Selects nonstandard floating-point mode |
no |
Selects standard floating-point mode |
If -fns is not specified, the nonstandard floating point mode is not enabled automatically. Standard IEEE 754 floating-point computation takes place, that is, underflows are gradual.
If only –fns is specified, –fns=yes is assumed.
In the following example, -fast expands to several options, one of which is -fns=yes which selects nonstandard floating-point mode. The subsequent -fns=no option overrides the initial setting and selects floating-point mode.
example% CC foo.cc -fast -fns=no |
When nonstandard mode is enabled, floating-point arithmetic can produce results that do not conform to the requirements of the IEEE 754 standard.
If you compile one routine with the -fns option, then compile all routines of the program with the –fns option; otherwise, you might get unexpected results.
This option is effective only on SPARC devices, and only if used when compiling the main program. On x86 devices, the option is ignored.
Use of the –fns=yes (or -fns) option might generate the following message if your program experiences a floating-point error normally managed by the IEEE floating-point trap handlers:
Numerical Computation Guide, ieee_sun(3M)
x86: Sets the non-default floating-point precision mode.
The –fprecision option sets the rounding precision mode bits in the Floating Point Control Word. These bits control the precision to which the results of basic arithmetic operations (add, subtract, multiply, divide, and square root) are rounded.
p must be one of the following values.
Table A–11 The -fprecision Values
Value |
Meaning |
---|---|
single |
Rounds to an IEEE single-precision value. |
double |
Rounds to an IEEE double-precision value. |
extended |
Rounds to the maximum precision available. |
If p is single or double, this option causes the rounding precision mode to be set to single or double precision, respectively, when a program begins execution. If p is extended or the –fprecision option is not used, the rounding precision mode remains at the extended precision.
The single precision rounding mode causes results to be rounded to 24 significant bits, and double precision rounding mode causes results to be rounded to 53 significant bits. In the default extended precision mode, results are rounded to 64 significant bits. This mode controls only the precision to which results in registers are rounded, and it does not affect the range. All results in register are rounded using the full range of the extended double format. Results that are stored in memory are rounded to both the range and precision of the destination format, however.
The nominal precision of the float type is single. The nominal precision of the long double type is extended.
When the –fprecision option is not specified, the rounding precision mode defaults to extended.
This option is effective only on x86 devices and only if used when compiling the main program. On SPARC devices, this option is ignored.
Sets the IEEE rounding mode in effect at startup.
This option sets the IEEE 754 rounding mode that:
Can be used by the compiler in evaluating constant expressions
Is established at runtime during the program initialization
The meanings are the same as those for the ieee_flags subroutine, which can be used to change the mode at runtime.
r must be one of the following values.
Table A–12 The -fround Values
Value |
Meaning |
---|---|
nearest |
Rounds towards the nearest number and breaks ties to even numbers. |
tozero |
Rounds to zero. |
negative |
Rounds to negative infinity. |
positive |
Rounds to positive infinity. |
When the –fround option is not specified, the rounding mode defaults to -fround=nearest.
If you compile one routine with –fround=r, compile all routines of the program with the same –fround=r option; otherwise, you might get unexpected results.
This option is effective only if used when compiling the main program.
Selects floating-point optimization preferences.
This option allows the optimizer to make simplifying assumptions concerning floating-point arithmetic.
If n is present, it must be 0, 1, or 2.
Table A–13 The -fsimple Values
If –fsimple is not designated, the compiler uses -fsimple=0.
If -fsimple is designated but no value is given for n, the compiler uses -fsimple=1.
-fast implies– fsimple=2.
This option can break IEEE 754 conformance.
-fast
Techniques for Optimizing Applications: High Performance Computing written by Rajat Garg and Ilya Sharapov for a more detailed explanation of how optimization can impact precision.
Forces precision of floating–point expressions.
This option causes the compiler to convert the value of a floating-point expression or function to the type on the left side of an assignment rather than leave the value in a register when the following is true:
The expression or function is assigned to a variable.
The expression is cast to a shorter floating-point type.
To turn off this option, use the –nofstore option.
Due to roundoffs and truncation, the results can be different from those that are generated from the register values.
–nofstore
Sets the IEEE 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.
t can be one of the following values.
Table A–14 The -ftrap Values
Value |
Meaning |
---|---|
[no%]division |
[Do not] Trap on division by zero. |
[no%]inexact |
[Do not] Trap on inexact result. |
[no%]invalid |
[Do not] Trap on invalid operation. |
[no%]overflow |
[Do not] Trap on overflow. |
[no%]underflow |
[Do not] Trap on underflow. |
%all |
Trap on all of the above. |
%none |
Trap on none of the above. |
common |
Trap on invalid, division by zero, and overflow. |
Note that the [no%] form of the option is used only to modify the meaning of the %all and common values, and must be used with one of these values, as shown in the example. The [no%] form of the option by itself does not explicitly cause a particular trap to be disabled.
If you do not specify –ftrap, the compiler assumes –ftrap=%none.
–ftrap=%all,no%inexact means to 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 might get unexpected results.
Use the -ftrap=inexact trap with caution. Use of– ftrap=inexact results in the trap being issued whenever a floating-point value cannot be represented exactly. For example, the following statement generates this condition:
x = 1.0 / 3.0; |
This option is effective only if used when compiling the main program. Be cautious when using this option. If you wish to enable the IEEE traps, use –ftrap=common.
ieee_handler(3M), fex_set_handling(3M) man pages.
Build a dynamic shared library instead of an executable file.
All source files specified in the command line are compiled with -xcode=pic13 by default.
When building a shared library that uses templates, it is necessary in most cases to include in the shared library those template functions that are instantiated in the template data base. Using this option automatically adds those templates to the shared library as needed.
If you are creating a shared object by specifying -G along with other compiler options that must be specified at both compile time and link time, make sure that those same options are also specified at both compile time and link time when you link with the resulting shared object.
When you create a shared object, all the object files compiled with -xarch=v9, must also be compiled with an explicit -xcode value as recommended in A.2.116 –xcode=a.
The following options are passed to the linker if– c (the compile-only option) is not specified:
–dy
–G
–R
Do not use ld -G to build shared libraries; use CC -G. The CC driver automatically passes several options to ld that are needed for C++.
When you use the -G option, the compiler does not pass any default -l options to ld. If you want the shared library to have a dependency on another shared library, you must pass the necessary -l option on the command line. For example, if you want the shared library to be dependent upon libCrun, you must pass -lCrun on the command line.
-dy, -Kpic, -xcode=pic13, –ztext, ld(1) man page, 16.3 Building Dynamic (Shared) Libraries.
Produces additional symbol table information for debugging with dbx(1) or the Debugger and for analysis with the Performance Analyzer analyzer(1).
Instructs both the compiler and the linker to prepare the file or program for debugging and for performance analysis.
The tasks include:
Producing detailed information, known as stabs, in the symbol table of the object files and the executable
Producing some “helper functions,” which the debugger can call to implement some of its features
Disabling the inline generation of functions
Disabling certain levels of optimization
If you use this option with –xOlevel (or its equivalent options, such as -O), you will get limited debugging information. For more information, see A.2.153 -xOlevel.
If you use this option and the optimization level is -xO4 or higher, the compiler provides best-effort symbolic information with full optimization.
When you specify this option, the +d option is specified automatically.
In previous releases, this option forced the compiler to use the incremental linker ( ild) by default instead of the linker ( ld) for link-only invocations of the compiler. That is, with -g, the compiler’s default behavior was to automatically invoke ild in place of ld whenever you used the compiler to link object files, unless you specified -G or source files on the command line. This is no longer the case. The incremental linker is no longer available.
To use the full capabilities of the Performance Analyzer, compile with the -g option. While some performance analysis features do not require -g, you must compile with -g to view annotated source, some function level information, and compiler commentary messages. See the analyzer(1) man page and “Compiling Your Program for Data Collection and Analysis” in Program Performance Analysis Tools 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 (or -g0), but is linked with -g (or -g0) will not be prepared properly for debugging. Note that compiling the module that contains the function main with the -g option (or the -g0 option) is usually necessary for debugging.
+d,– g0,– xs, analyzer(1) man page, er_src(1) man page, ld(1) man page, Debugging a Program With dbx (for details about stabs), Program Performance Analysis Tools.
Compiles and links for debugging, but does not disable inlining.
This option is the same as –g, except that +d is disabled and dbx cannot step into inlined functions.
If you specify -g0 and the optimization level is -xO3 or lower, the compiler provides best-effort symbolic information with almost full optimization. Tail-call optimization and back-end inlining are disabled.
+d,– g, Debugging a Program With dbx
Prints path names of included files.
On the standard error output (stderr), this option prints, one per line, the path name of each #include file contained in the current compilation.
Assigns the name name to the generated dynamic shared library.
This is a loader option, passed to ld. In general, the name after -h should be exactly the same as the one after –o. A space between the –h and name is optional.
The compile-time loader assigns the specified name to the shared dynamic library you are creating. It records the name in the library file as the intrinsic name of the library. If there is no –hname option, then no intrinsic name is recorded in the library file.
Every executable file has a list of shared library files that are needed. When the runtime linker links the library into an executable file, the linker copies the intrinsic name from the library into that list of needed shared library files. If there is no intrinsic name of a shared library, then the linker copies the path of the shared library file instead.
example% CC -G -o libx.so.1 -h libx.so.1 a.o b.o c.o |
Add pathname to the #include file search path.
This option adds pathname to the list of directories that are searched for #include files with relative file names (those that do not begin with a slash).
The compiler searches for quote-included files (of the form #include "foo.h") in this order.
In the directory containing the source
In the directories named with -I options, if any
In the include directories for compiler-provided C++ header files, ANSI C header files, and special-purpose files
In the /usr/include directory
The compiler searches for bracket-included files (of the form #include <foo.h>) in this order.
In the directories named with -I options, if any
In the include directories for compiler-provided C++ header files, ANSI C header files, and special-purpose files
In the /usr/include directory
If the spelling matches the name of a standard header file, also refer to 12.7.5 Standard Header Implementation .
The -I- option allows you to override the default search rules.
If you specify -library=no%Cstd, then the compiler does not include in its search path the compiler-provided header files that are associated with the C++ standard libraries. See 12.7 Replacing the C++ Standard Library.
If –ptipath is not used, the compiler looks for template files in –Ipathname.
Use –Ipathname instead of –ptipath.
This option accumulates instead of overrides.
Never specify the compiler installation area, /usr/include, /lib, or /usr/lib, as search directories.
-I-
Change the include-file search rules to the following:
For include files of the form #include "foo.h", search the directories in the following order.
For include files of the form #include "foo.h", search the directories in the following order:
1. The directories named with -I options (both before and after -I-).
2. The directories for compiler-provided C++ header files, ANSI C header files, and special-purpose files.
3. The /usr/include directory.
For include files of the form #include <foo.h>, search the directories in the following order:
1. The directories named in the -I options that appear after -I-.
2. The directories for compiler-provided C++ header files, ANSI C header files, and special-purpose files.
3. The /usr/include directory.
If the name of the include file matches the name of a standard header, also refer to 12.7.5 Standard Header Implementation .
The following example shows the results of using -I- when compiling prog.cc.
prog.cc #include "a.h" #include <b.h> #include "c.h" c.h #ifndef _C_H_1 #define _C_H_1 int c1; #endif inc/a.h #ifndef _A_H #define _A_H #include "c.h" int a; #endif inc/b.h #ifndef _B_H #define _B_H #include <c.h> int b; #endif inc/c.h #ifndef _C_H_2 #define _C_H_2 int c2; #endif |
The following command shows the default behavior of searching the current directory (the directory of the including file) for include statements of the form #include "foo.h". When processing the #include "c.h" statement in inc/a.h, the compiler includes the c.h header file from the inc subdirectory. When processing the #include "c.h" statement in prog.cc, the compiler includes the c.h file from the directory containing prog.cc. Note that the -H option instructs the compiler to print the paths of the included files.
example% CC -c -Iinc -H prog.cc inc/a.h inc/c.h inc/b.h inc/c.h c.h |
The next command shows the effect of the -I- option. The compiler does not look in the including directory first when it processes statements of the form #include "foo.h". Instead, it searches the directories named by the -I options in the order that they appear in the command line. When processing the #include "c.h" statement in inc/a.h, the compiler includes the ./c.h header file instead of the inc/c.h header file.
example% CC -c -I. -I- -Iinc -H prog.cc inc/a.h ./c.h inc/b.h inc/c.h ./c.h |
When -I- appears in the command line, 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".
Only the first -I- in a command line causes the described behavior.
Never specify the compiler installation area, /usr/include, /lib, or /usr/lib, as search directories.
Tells the linker, ld, to ignore any LD_LIBRARY_PATH setting.
Controls the placement and linkage of template instances.
a must be one of the following values.
Table A–15 The -instances Values
Value |
Meaning |
---|---|
extern |
Places all needed instances into the template repository within comdat sections and gives them global linkage. (If an instance in the repository is out of date, it is reinstantiated.) Note: If you are compiling and linking in separate steps and you specify -instance=extern for the compilation step, you must also specify it for the link step. |
explicit |
Places explicitly instantiated instances into the current object file and gives them global linkage. Does not generate any other needed instances. |
global |
Places all needed instances into the current object file and gives them global linkage. |
semiexplicit |
Places explicitly instantiated instances into the current object file and gives them global linkage. Places all instances needed by the explicit instances into the current object file and gives them global linkage. Does not generate any other needed instances. |
static |
Note: -instances=static is deprecated. There is no longer any reason to use -instances=static, because -instances=global now gives you all the advantages of static without the disadvantages. This option was provided in earlier compilers to overcome problems that do not exist in this version of the compiler. Places all needed instances into the current object file and gives them static linkage. |
If –instances is not specified, –instances=global is assumed.
7.2.4 Template Instance Placement and Linkage.
Use this option to inhibit the generation of template instances that are duplicated in a library, either shared or static, and the current object. In general, if your program shares large numbers of instances with libraries, try -instlib=filename and see whether compilation time improves.
Use the filename argument to specify the library that you know contains the existing template instances. The filename argument must contain a forward slash ’/’ character. For paths relative to the current directory, use dot-slash ’./’.
The -instlib=filename option has no default and is only used if you specify it. This option can be specified multiple times and accumulates.
Assume that the libfoo.a and libbar.so libraries instantiate many template instances that are shared with your source file a.cc. Adding -instlib=filename and specifying the libraries helps reduce compile time by avoiding the redundancy.
example% CC -c -instlib=./libfoo.a -instlib=./libbar.so a.cc
When you compile with -g, if the library specified with -instlib=file is not compiled with -g, those template instances will not be debuggable. The workaround is to avoid -instlib=file when you use -g.
If you specify a library with -instlib, you must link with that library.
-template, -instances, -pti
x86: Same as –Kpic.
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.
x86: Compiles with 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.
Along with –verbose=diags, this option is useful for debugging.
–v, –verbose
Adds path to list of directories to search for libraries.
This option is passed to ld. The directory that is named by path is searched before compiler-provided directories.
This option accumulates instead of overrides.
Never specify the compiler installation area, /usr/include, /lib, or /usr/lib, as search directories.
Adds library liblib.a or liblib.so to the linker’s list of search libraries.
This option is passed to ld. Normal libraries have names such as liblib.a or liblib.so, where the lib and .a or .so parts are required. You should specify the lib part with this option. Put as many libraries as you want on a single command line; they are searched in the order specified with –Ldir.
Use this option after your object file name.
This option accumulates instead of overrides.
It is always safer to put –lx after the list of sources and objects to insure that libraries are searched in the correct order.
To ensure proper library linking order, you must use -mt, rather than -lthread, to link with libthread.
–Ldir, -mt, 11.4.8 An Example Application, and Tools.h++ Class Library Reference
Incorporates specified CC-provided libraries into compilation and linking.
For compatibility mode (–compat[-4]]), l must be one of the following values.
Table A–16 The -library Values for Compatibility Mode
Value |
Meaning |
---|---|
[no%]f77 |
Deprecated. Use -xlang=f77 instead. |
[no%]f90 |
Deprecated. Use -xlang=f90 instead. |
[no%]f95 |
Deprecated. Use -xlang=f95 instead. |
[no%]rwtools7 |
[Do not] Use classic-iostreams Tools.h++ version 7. |
[no%]rwtools7_dbg |
[Do not] Use debug-enabled Tools.h++ version 7. |
[no%]complex |
[Do not] Use libcomplex for complex arithmetic. |
[no%]interval |
Deprecated. Do not use. Use -xia. |
[no%]libC |
[Do not] Use libC, the C++ support library. |
[no%]gc |
[Do not] Use libgc, garbage collection. |
[Do not] Use the Sun Performance LibraryTM |
|
%none |
Use no C++ libraries except for libC. |
For standard mode (the default mode), l must be one of the following:
Table A–17 The -library Values for Standard Mode
Value |
Meaning |
---|---|
[no%]f77 |
Deprecated. Use -xlang=f77 instead. |
[no%]f90 |
Deprecated. Use -xlang=f90 instead. |
[no%]f95 |
Deprecated. Use -xlang=f95 instead. |
[no%]rwtools7 |
[Do not] Use classic-iostreams Tools.h++ version 7. |
[no%]rwtools7_dbg |
[Do not] Use debug-enabled Tools.h++ version 7. |
[no%]rwtools7_std |
[Do not] Use standard-iostreams Tools.h++ version 7. |
[no%]rwtools7_std_dbg |
[Do not] Use debug-enabled standard-iostreams Tools.h++ version 7. |
[no%]interval |
Deprecated. Do not use. Use -xia. |
[no%]iostream |
[Do not] Use libiostream, the classic iostreams library. |
[no%]Cstd |
[Do not] Use libCstd, the C++ standard library. [Do not] Include the compiler-provided C++ standard library header files. |
[no%]Crun |
[Do not] Use libCrun, the C++ runtime library. |
[no%]gc |
[Do not] Use libgc, garbage collection. |
[no%]stlport4 |
[Do not] Use STLport’s Standard Library implementation version 4.5.3 instead of the default libCstd. For more information about using STLport’s implementation, see 13.3 STLport. |
[no%]stlport4_dbg |
[Do not] Use STLport’s debug-enabled library. |
[no%]sunperf |
[Do not] Use the Sun Performance Library. |
%none |
Use no C++ libraries, except for libCrun. |
Compatibility mode (–compat[=4])
If –library is not specified, -library=libC is assumed.
The libC library is always included unless it is specifically excluded using -library=no%libC.
Standard mode (the default mode)
The libCstd library is always included unless it is specifically excluded using -library=%none or -library=no%Cstd or -library=stlport4.
The libCrun library always is included.
Regardless of standard or compat mode, the libm and libc libraries are always included, even if you specify -library=%none.
To link in standard mode without any C++ libraries (except libCrun), use:
example% CC -library=%none |
To include the classic-iostreams Rogue Wave tools.h++ library in standard mode:
example% CC –library=rwtools7,iostream |
To include the standard-iostreams Rogue Wave tools.h++ library in standard mode:
example% CC -library=rwtools7_std |
To include the classic-iostreams Rogue Wave tools.h++ library in compatibility mode:
example% CC -compat -library=rwtools7 |
If a library is specified with -library, the proper –I paths are set during compilation. The proper –L, –Y P, –R paths and –l options are set during linking.
This option accumulates instead of overrides.
When you use the interval arithmetic libraries, you must include one of the following libraries: libC, libCstd, or libiostream.
Use of the -library option ensures that the -l options for the specified libraries are emitted in the right order. For example, the -l options are passed to ld in the order -lrwtool -liostream for both -library=rwtools7,iostream and -library=iostream,rwtools7.
The specified libraries are linked before the system support libraries are linked.
You cannot use -library=sunperf and -xlic_lib=sunperf on the same command line.
You cannot use -library=stlport4 and -library=Cstd on the same command line.
Only one Rogue Wave tools library can be used at a time and you cannot use any Rogue Wave tools library with -library=stlport4.
When you include the classic-iostreams Rogue Wave tools library in standard mode (the default mode), you must also include libiostream (see the C++ Migration Guide for additional information). You can use the standard-iostreams Rogue Wave tools library in standard mode only. The following command examples show both valid and invalid use of the Rogue Wave tools.h++ library options.
% CC -compat -library=rwtools7 foo.cc <-- valid % CC -compat -library=rwtools7_std foo.cc <-- invalid % CC -library=rwtools7,iostream foo.cc <-- valid, classic iostreams % CC -library=rwtools7 foo.cc <-- invalid % CC -library=rwtools7_std foo.cc <-- valid, standard iostreams % CC -library=rwtools7_std,iostream foo.cc <-- invalid |
If you include both libCstd and libiostream, you must be careful to not use the old and new forms of iostreams (for example, cout and std::cout) within a program to access the same file. Mixing standard iostreams and classic iostreams in the same program is likely to cause problems if the same file is accessed from both classic and standard iostream code.
Programs linking neither libC nor libCrun might not use all features of the C++ language.
If -xnolib is specified, -library is ignored.
If you compile and link in separate steps, the set of -library options that appear in the compile command must appear in the link command.
The stlport4, Cstd and iostream libraries provide their own implementation of I/O streams. Specifying more than one of these with the -library option can result in undefined program behavior. For more information about using STLport’s implementation, see 13.3 STLport.
The set of libraries is not stable and might change from release to release.
–I, –l, –R, –staticlib, -xia, -xlang, –xnolib, 11.4.8 An Example Application, Caveats:, 13.3.1 Redistribution and Supported STLport Libraries, 2.7.3.3 Using make With Standard Library Header Files, Tools.h++ User’s Guide, Tools.h++ Class Library Reference, Standard C++ Class Library Reference, C++ Interval Arithmetic Programming Reference.
For information on using the -library=no%cstd option to enable use of your own C++ standard library, see 12.7 Replacing the C++ Standard Library.
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 Solaris platforms and on Linux platforms that are not 64-bit enabled. The LP64 memory model (64-bit long, pointer data types) is thedefault 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.
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 3.3.3 Compile-Time and Link-Time Options.
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.
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 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 the object file. If the string contains blanks, the string must be enclosed in quotation marks. When you use the -mc option, the mcs -c command is invoked.
Explains where to get information about migrating source code that was built for earlier versions of the compiler.
This option might cease to exist in the next release.
SPARC: Permits misaligned data, which would otherwise generate an error, in memory. This is shown in the following code:
char b[100]; int f(int * ar) { return *(int *) (b +2) + *ar; } |
This option informs the compiler that some data in your program is not properly aligned. Thus, very conservative loads and stores must be used for any data that might be misaligned, that is, one byte at a time. Using this option may cause significant degradation in runtime performance. The amount of degradation is application dependent.
When using #pragma pack on a SPARC platform to pack denser than the type’s default alignment, the -misalign option must be specified for both the compilation and the linking of the application.
Misaligned data is handled by a trap mechanism that is provided by ld at runtime. If an optimization flag (-xO{1|2|3|4|5} or an equivalent flag) is used with the -misalign option, the additional instructions required for alignment of misaligned data are inserted into the resulting object file and will not generate runtime misalignment traps.
If possible, do not link aligned and misaligned parts of the program.
If compilation and linking are performed in separate steps, the –misalign option must appear in both the compile and link commands.
Removes all strings from the .comment section of the object file and, if string is supplied, places string in that section. If the string contains blanks, the string must be enclosed in quotation marks. When you use this option, the command mcs -d [-a string] is invoked.
This option is not valid when either -S, -xsbfast, or -sbfast is specified.
Compile and link for multithreaded code.
This option passes -D_REENTRANT to the preprocessor and passes -lthread in the correct order to ld.
The -mt option is required if the application or libraries are multithreaded.
To ensure proper library linking order, you must use this option, rather than -lthread, to link with libthread.
If you are using POSIX threads, you must link with the options -mt -lpthread. The -mt option is necessary because libC (compatibility mode) and libCrun (standard mode) need libthread for a multithreaded application.
Modules that are compiled with -mt must also be linked with -mt. For a complete list of compiler options that must be specified at both compile time and at link time, see 3.3.3 Compile-Time and Link-Time Options.
If you compile one translation unit with -mt, compile all units of the program with -mt.
If you are mixing parallel Fortran objects with C++ objects, the link line must specify the -mt option.
To ensure proper library linking order, you must use this option, rather than -lthread, to link with libthread.
If you are using POSIX threads, you must link with the -mt and -lpthread options. The -mt option is necessary because libCrun (standard mode) and libC (compatibility mode) need libthread for a multithreaded application.
If you compile and link in separate steps and you compile with -mt, be sure to link with -mt, as shown in the following example, or you might get unexpected results.
example% CC -c -mt myprog.cc example% CC -mt myprog.o |
If you are mixing parallel Fortran objects with C++ objects, the link line must specify the -mt option.
C99 support is not available in compat mode (-compat=4).
–xnolib, 10.5 Cache Member Variables, Multithreaded Programming Guide, Linker and Libraries Guide
Same as –xtarget=native.
x86: Disables forced precision of an expression.
This option does not force the value of a floating-point expression or function to the type on the left side of an assignment, but leaves the value in a register when either of the following are true:
The expression or function is assigned to a variable
or
The expression or function is cast to a shorter floating-point type
–fstore
If no license is available, this option returns without queuing your request and without compiling. A nonzero status is returned for testing makefiles.
Does not build a runtime search path for shared libraries into the executable.
If an executable file uses shared libraries, then the compiler normally builds in a path that points the runtime linker to those shared libraries. To do so, the compiler passes the –R option to ld. The path depends on the directory where you have installed the compiler.
This option is recommended for building executables that will be shipped to customers who may have a different path for the shared libraries that are used by the program.
If you use any shared libraries under the compiler installed area (the default location is /opt/SUNWspro/lib) and you also use –norunpath, then you should either use the –R option at link time or set the environment variable LD_LIBRARY_PATH at runtime to specify the location of the shared libraries. Doing so allows the runtime linker to find the shared libraries.
The -O macro now expands to -xO3 instead of -xO2.
The change in default yields higher run-time performance. However, -x03 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.
Sets the name of the output file or the executable file to filename.
When the compiler must store template instances, it stores them in the template repository in the output file’s directory. For example, the following command writes the object file to ./sub/a.o and writes template instances into the repository contained within ./sub/SunWS_cache.
example% CC -o sub/a.o a.cc |
The compiler reads from the template repositories corresponding to the object files that it reads. For example, the following command reads from ./sub1/SunWS_Cache and ./sub2/SunWS_cache, and, if necessary, writes to ./SunWS_cache.
example% CC sub1/a.o sub2/b.o |
For more information, see 7.4 The Template Repository.
The filename must have the appropriate suffix for the type of file to be produced by the compilation. It cannot be the same file as the source file, since the CC driver does not overwrite the source file.
Ignore nonstandard preprocessor asserts.
If +p is not present, the compiler recognizes nonstandard preprocessor asserts.
If +p is used, the following macros are not defined:
sun
unix
sparc
i386
Only preprocesses source; does not compile. (Outputs a file with a .i suffix.)
This option does not include preprocessor-type line number information in the output.
–E
Obsolete, see A.2.160 –xpg.
x86: Replace with –xtarget=pentium.
x86: Same as –Kpic.
SPARC: Same as –xcode=pic13.
x86: Same as -Kpic.
Same as –template=wholeclass.
Specifies an additional search directory for template source.
This option is an alternative to the normal search path set by –Ipathname. If the -ptipath option is used, the compiler looks for template definition files on this path and ignores the –Ipathname option.
Using the –Ipathname option instead of –ptipath produces less confusion.
This option accumulates instead of overrides.
–Ipathname
Same as –instances=static.
This option is obsolete and is ignored by the compiler.
Even though the -ptr option is ignored, you should remove -ptr from all compilation commands because, in a later release, it may be reused with a different behavior.
For information about repository directories, see 7.4 The Template Repository.
Same as –verbose=template.
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 -Q can be reordered. Options that the driver recognizes are kept in the correct order. Do not use -Q for options that the driver already recognizes. For example, the C++ compiler recognizes the -z option for the linker (ld). If you issue a command like this
CC -G -zallextract mylib.a -zdefaultextract ... // correct
the -z options are passed in order to the linker. But if you specify the command like this
CC -G -Qoption ld -zallextract mylib.a -Qoption ld -zdefaultextract ... // error
the -z options can be reordered, giving incorrect results.
phase must have one of the following values.
Table A–18 The -Qoption Values
SPARC |
x86 |
---|---|
ccfe |
ccfe |
iropt |
cg386 |
cg |
codegen |
CClink |
CClink |
ld |
ld |
In the following command line, when ld is invoked by the CC driver, –Qoption passes the –i and –m options to ld.
example% CC -Qoption ld -i,-m test.c |
Be careful to avoid unintended effects. For example,
-Qoption ccfe -features=bool,iddollar |
is interpreted as
-Qoption ccfe -features=bool -Qoption ccfe iddollar |
The correct usage is
-Qoption ccfe -features=bool,-features=iddollar |
Same as –Qoption.
Causes the CC driver to produce output of the type sourcetype.
Sourcetype suffixes are defined below.
Table A–19 The -Qproduce Values
Suffix |
Meaning |
---|---|
.i |
Preprocessed C++ source from ccfe |
.o |
Object file the code generator |
.s |
Assembler source from cg |
Same as –Qproduce.
Builds dynamic library search paths into the executable file.
This option is passed to ld.
If the -R option is not present, the library search path that is recorded in the output object and passed to the runtime linker depends upon the target architecture instruction specified by the -xarch option (when -xarch is not present, -xarch=generic is assumed).
Value |
Default Library Search Path |
---|---|
v9, v9a, or v9b |
install-directory/SUNWspro/lib/v9 |
All other values |
install-directory/SUNWspro/lib |
In a default installation, install-directory is /opt.
This option accumulates instead of overrides.
If the LD_RUN_PATH environment variable is defined and the –R option is specified, then the path from –R is scanned and the path from LD_RUN_PATH is ignored.
–norunpath, Linker and Libraries Guide
Compiles and generates only assembly code.
This option causes the CC driver to compile the program and output an assembly source file, without assembling the program. The assembly source file is named with a .s suffix.
Strips the symbol table from the executable file.
This option removes all symbol information from output executable files. This option is passed to ld.
Indicates which C++ libraries, specified by the -library option (including its defaults), by the -xlang option, and by the -xia option, are to be linked statically.
l must be one of the following values.
Table A–20 The -staticlib Values
Value |
Meaning |
---|---|
[no%]library |
[Do not] link library statically. The valid values for library are all the valid values for -library (except %all and %none), all the valid values for -xlang, and interval (to be used in conjunction with -xia). |
%all |
Statically link all the libraries specified in the -library option, all the libraries specified in the -xlang option, and, if -xia is specified in the command line, the interval libraries. |
%none |
Link no libraries specified in the -library option and the -xlang option statically. If -xia is specified in the command line, link no interval libraries statically. |
If –staticlib is not specified, –staticlib=%none is assumed.
The following command line links libCrun statically because Crun is a default value for –library:
example% CC –staticlib=Crun (correct) |
However, the following command line does not link libgc because libgc is not linked unless explicitly specified with the -library option:
example% CC –staticlib=gc (incorrect) |
To link libgc statically, use the following command:
example% CC -library=gc -staticlib=gc (correct) |
With the following command, the librwtool library is linked dynamically. Because librwtool is not a default library and is not selected using the -library option, -staticlib has no effect:
example% CC -lrwtool -library=iostream \ -staticlib=rwtools7 (incorrect) |
This command links the librwtool library statically:
example% CC -library=rwtools7,iostream -staticlib=rwtools7 (correct) |
This command will link the Sun Performance Libraries dynamically because -library=sunperf must be used in conjunction with -staticlib=sunperf in order for the -staticlib option to have an effect on the linking of these libraries:
example% CC -xlic_lib=sunperf -staticlib=sunperf (incorrect) This command links the Sun Performance Libraries statically: |
example% CC -library=sunperf -staticlib=sunperf (correct) |
This option accumulates instead of overrides.
The -staticlib option only works for the C++ libraries that are selected explicitly with the -xia option, the -xlang option, and the -library option, in addition to the C++ libraries that are selected implicitly by default. In compatibility mode (-compat=[4]), libC is selected by default. In standard mode (the default mode), Cstd and Crun are selected by default.
When using -xarch=v9, -xarch=v9a, or -xarch=v9b (or equivalent 64-bit architecture options), some C++ libraries are not available as static libraries.
The set of allowable values for library is not stable and might change from release to release.
When using -xarch=v9, -xarch=v9a, or -xarch=v9b, (or equivalent 64-bit architecture options), some libraries are not available as static libraries.
The options -staticlib=Crun and -staticlib=Cstd do not work on 64-bit Solaris x86 platforms. Sun recommends against linking these libraries statically on any platform. In some cases, static linking can prevent a program from working.
-library, 12.5 Statically Linking Standard Libraries
Use this option when your run-time performance is degraded due to the synchronization between C++ iostreams and C stdio. Synchronization is needed only when you use iostreams to write to cout and stdio to write to stdout in the same program. The C++ standard requires synchronization so the C++ compiler turns it on by default. However, application performance is often much better without synchronization. If your program does not write to both cout and stdout, you can use the option -sync_stdio=no to turn off synchronization.
If you do not specify -sync_stdio, the compiler sets it to -sync_stdio=yes.
Consider the following example:
#include <stdio.h> #include <iostream> int main() { std::cout << "Hello "; printf("beautiful "); std::cout << "world!"; printf("\n"); } |
With synchronization, the program prints on a line by itself
Hello beautiful world! : |
Without synchronization, the output gets scrambled.
This option is only effective for linking of executables, not for libraries.
Defines the directory for temporary files.
This option sets the path name of the directory for storing the temporary files that are generated during the compilation process.
–keeptmp
Enables/disables various template options.
opt must be one of the following values.
Table A–21 The -template Values
Value |
Meaning |
---|---|
[no%]extdef |
[Do not] Search for template definitions in separate source files. |
[no%]geninlinefuncs |
[Do not] Generate unreferenced inline member functions for explicitly instantiated class templates. |
[no%]wholeclass |
[Do not] Instantiate a whole template class, rather than only those functions that are used. You must reference at least one member of the class; otherwise, the compiler does not instantiate any members for the class. |
If the -template option is not specified, -template=no%wholeclass,extdef is assumed.
Consider the following code:
example% cat Example.cc template <class T> struct S { void imf() {} static void smf() {} }; template class S <int>; int main() { } example% |
When you specify -template=geninlinefuncs, even though the two member functions of S are not called in the program, they are generated in the object file.
example% CC -c -template=geninlinefuncs Example.cc example% nm -C Example.o Example.o: [Index] Value Size Type Bind Other Shndx Name [5] 0 0 NOTY GLOB 0 ABS __fsr_init_value [1] 0 0 FILE LOCL 0 ABS b.c [4] 16 32 FUNC GLOB 0 2 main [3] 104 24 FUNC LOCL 0 2 void S<int>::imf() [__1cBS4Ci_Dimf6M_v_] [2] 64 20 FUNC LOCL 0 2 void S<int>::smf() [__1cBS4Ci_Dsmf6F_v_] |
7.2.2 Whole-Class Instantiation, 7.5 Template Definition Searching
Deletes initial definition of the preprocessor symbol name.
This option removes any initial definition of the macro symbol name created by -D on the command line including those implicitly placed there by the CC driver. This option has no effect on any other predefined macros, nor on macro definitions in source files.
To see the -D options that are placed on the command line by the CC driver, add the -dryrun option to your command line.
The following command undefines the predefined symbol __sun. Preprocessor statements in foo.cc such as #ifdef(__sun) will sense that the symbol is undefined.
example% CC -U__sun foo.cc |
You can specify multiple -U options on the command line.
All -U options are processed after any -D options that are present. That is, if the same name is specified for both -D and -U on the command line, name is undefined, regardless of the order the options appear.
-D
Same as –verbose=version.
Deprecated, do not use.
Compatibility mode only (–compat[=4]):
For expressions using delete[], this option generates a call to the runtime library function _vector_deletex_ instead of generating a call to _vector_delete_. The function _vector_delete_ takes two arguments: the pointer to be deleted and the size of each array element.
The function _vector_deletex_ behaves the same as _vector_delete_ except that it takes a third argument: the address of the destructor for the class. This third argument is not used by the function, but is provided to be used by third-party vendors.
The compiler generates a call to _vector_delete_ for expressions using delete[].
This is an obsolete option that will be removed in future releases. Do not use this option unless you have bought some software from a third-party vendor and the vendor recommends using this option.
v must be one of the following values.
Table A–22 The -verbose Values
Value |
Meaning |
---|---|
[no%]diags |
[Do not] Print the command line for each compilation pass. |
[no%]template |
[Do not] Turn on the template instantiation verbose mode (sometimes called the “verify” mode). The verbose mode displays each phase of instantiation as it occurs during compilation. |
[no%]version |
[Do not] Direct the CC driver to print the names and version numbers of the programs it invokes. |
%all |
Invokes all of the above. |
%none |
-verbose=%none is the same as -verbose=no%template,no%diags,no%version. |
If –verbose is not specified, –verbose=%none is assumed.
This option accumulates instead of overrides.
Identifies code that might have unintended consequences. The +w option no longer generates a warning if a function is too large to inline or if a declared program element is unused. These warnings do not identify real problems in the source, and were thus inappropriate to some development environments. Removing these warnings from +w enables more aggressive use of +w in those environments. These warnings are still available with the +w2 option.
This option generates additional warnings about questionable constructs that are:
Nonportable
Likely to be mistakes
Inefficient
If +w is not specified, the compiler warns about constructs that are almost certainly problems.
Some C++ standard headers result in warnings when compiled with +w.
–w, +w2
Emits all the warnings emitted by +w plus warnings about technical violations that are probably harmless, but that might reduce the maximum portability of your program.
The +w2 option no longer warns about the use of implementation-dependent constructs in the system header files. Because the system header files are the implementation, the warning was inappropriate. Removing these warnings from +w2 enables more aggressive use of the option.
Some Solaris OS and C++ standard header files result in warnings when compiled with +w2.
+w
Suppresses most warning messages.
This option causes the compiler not to print warning messages. However, some warnings, particularly warnings regarding serious anachronisms, cannot be suppressed.
+w
Same as –features=iddollar.
Generates code for profiling.
If set at compile time, the TCOVDIR environment variable specifies the directory where the coverage (.d) files are located. If this variable is not set, then the coverage (.d) files remain in the same directory as the source files.
Use this option only for backward compatibility with old coverage files.
The -xprofile=tcov option and the –xa option are compatible in a single executable. That is, you can link a program that contains some files that have been compiled with –xprofile=tcov, and others that have been compiled with –xa. You cannot compile a single file with both options.
The –xa option is incompatible with –g.
If you compile and link in separate steps and you compile with -xa, be sure to link with –xa, or you might get unexpected results.
–xprofile=tcov, tcov(1) man page, Program Performance Analysis Tools.
(SPARC) The C++ compiler can perform type-based alias-analysis and optimizations when you specify the following command:
-xalias_level[=n]
where n is any, simple, or compatible.
-xalias_level=any
At this level of analysis, the compiler assumes that any type may alias any other type. However, despite this assumption, some optimization is possible.
-xalias_level=simple
The compiler assumes that simple types are not aliased. Specifically, a storage object with a dynamic type that is one of the following simple types:
char |
short int |
long int |
float |
signed char |
unsigned short int |
unsigned long int |
double |
unsigned char |
int |
long long int |
long double |
wchar_t |
unsigned int |
unsigned long long int |
enumeration types |
data pointer types |
function pointer types |
data member pointer types |
function member pointer types |
is only accessed through lvalues of the following types:
The dynamic type of the object
A constant or volatile qualified version of the dynamic type of the object, a type that is the signed or unsigned type corresponding to the dynamic type of the object
A type that is the signed or unsigned type corresponding to a constant or volatile qualified version of the dynamic type of the object
An aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union)
A char or unsigned char type
-xalias_level=compatible
The compiler assumes that layout-incompatible types are not aliased. A storage object is only accessed through lvalues of the following types:
The dynamic type of the object
A constant or volatile qualified version of the dynamic type of the object, a type that is the signed or unsigned type which corresponds to the dynamic type of the object
A type that is the signed or unsigned type which corresponds to the constant or volatile qualified version of the dynamic type of the object
An aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union)
A type that is (possibly constant or volatile qualified) base class type of the dynamic type of the object
A char or unsigned char type.
The compiler assumes that the types of all references are layout compatible with the dynamic type of the corresponding storage object. Two types are layout-compatible under the following conditions:
If two types are the same type, then they are layout-compatible types.
If two types differ only in constant or volatile qualification, then they are layout-compatible types.
For each of the signed integer types, there exists a corresponding (but different) unsigned integer type. These corresponding types are layout compatible.
Two enumeration types are layout-compatible if they have the same underlying type.
Two Plain Old Data (POD) struct types are layout compatible if they have the same number of members, and corresponding members (in order) have layout compatible types.
Two POD union types are layout compatible if they have the same number of members, and corresponding members (in any order) have layout compatible types.
References may be non-layout-compatible with the dynamic type of the storage object under limited circumstances:
If a POD union contains two or more POD structs that share a common initial sequence, and if the POD union object currently contains one of those POD structs, it is permitted to inspect the common initial part of any of them. Two POD structs share a common initial sequence if corresponding members have layout compatible types and, as applicable to bit fields, the same widths, for a sequence of one or more initial members.
A pointer to a POD struct object, suitably converted using a reinterpret_cast, points to its initial member, or if that member is a bit field, to the unit in which it resides.
If you do not specify -xalias_level, the compiler sets the option to -xalias_level=any. If you specify -xalias_level but do not provide a value, the compiler sets the option to -xalias_level=compatible.
The compiler does not perform type-based alias analysis at optimization level -xO2 and below.
If you are using reinterpret_cast or an equivalent old-style cast, the program may violate the assumptions of the analysis. Also, union type punning, as shown in the following example, violates the assumptions of the analysis.
union bitbucket{ int i; float f; }; int bitsof(float f){ bitbucket var; var.f=3.6; return var.i; } |
When building a C++ archive that uses templates, it is necessary in most cases to include in the archive those template functions that are instantiated in the template database. Using this option automatically adds those templates to the archive as needed.
Specify -xar to invokes ar -c -r and create an archive from scratch.
The following command line archives the template functions contained in the library and object files.
example% CC -xar -o libmain.a a.o b.o c.o |
Do not add .o files from the template database on the command line.
Do not use the ar command directly for building archives. Use CC –xar to ensure that template instantiations are automatically included in the archive.
ar(1), Table 15–3
Specifies the target instruction set architecture (ISA).
This option limits the code generated by the compiler to the instructions of the specified instruction set architecture. This option does not guarantee use of any target–specific instructions. However, use of this option may affect the portability of a binary program.
Use the -m64 or -m32 option to specify the intended memory model, LP64 (64-bits) or ILP32 (32-bits) respectively. The -xarch option no longer indicates the memory model, except for compatibility with previous releases, as indicated below.
If you compile and link in separate steps, make sure you specify the same value for -xarch in both steps. For complete list of all compiler options that must be specified at both compile time and at link time, see 3.3.3 Compile-Time and Link-Time Options.
The following table gives the details for each of the -xarch keywords on SPARC platforms.
Table A–23 The -xarch Flags for SPARC Platforms
Also note the following:
SPARC instruction set architectures V8 and V8a are binary compatible.
Object binary files (.o) compiled with v8plus and v8plusa can be linked and can execute together, but only on a SPARC V8plusa compatible platform.
Object binary files (.o) compiled with v8plus, v8plusa, and v8plusb can be linked and can execute together, but only on a SPARC V8plusb compatible platform.
-xarch values v9, v9a, and v9b are only available on UltraSPARC 64-bit Solaris operating systems.
Object binary files (.o) compiled with generic64, native64, v9 and v9a can be linked and can execute together, but will run only on a SPARC V9a compatible platform.
Object binary files (.o) compiled with generic64, native64, v9, v9a, and v9b can be linked and can execute together, but will run only on a SPARC V9b compatible platform.
For any particular choice, the generated executable may run much more slowly on earlier architectures. Also, although quad-precision (REAL*16 and long double) floating-point instructions are available in many of these instruction set architectures, the compiler does not use these instructions in the code it generates.
The following table lists the -xarch flags on x86 platforms.
Table A–24 The -xarch Flags on x86
Flag |
Meaning |
---|---|
amd64 |
Is equivalent to -m64 -xarch=sse2 (Solaris only). Legacy makefiles and scripts that use -xarch=amd64 to obtain the 64-bit memory model need only use -m64. |
amd64a |
Is equivalent to -m64 -xarch=sse2a (Solaris only). |
generic |
Uses the instruction set common to most processors. This is the default. |
generic64 |
Compile for good performance on most 64-bit platforms. (Solaris only). This option is equivalent to -m64 -xarch=generic and is provided for compatibility with earlier releases. Use -m64 to specify 64-bit compilation instead of -xarch=generic64. |
native |
Compile for good performance on this system. The compiler chooses the appropriate setting for the current system processor it is running on. |
native64 |
Compile for good performance on this system (Solaris only). This option is equivalent to -m64 -xarch=native and is provided for compatibility with earlier releases. |
pentium_pro |
Limits the instruction set to the 32–bit pentium_pro architecture. |
pentium_proa |
Adds the AMD extensions (3DNow!, 3DNow! extensions, and MMX extensions) to the 32-bit pentium_pro architecture. |
sse |
Adds the SSE instruction set to the pentium_pro architecture. |
ssea |
Adds the AMD extensions (3DNow!, 3DNow! extensions, and MMX extensions) to the 32-bit SSE architecture. |
sse2 |
Adds the SSE2 instruction set to the pentium_pro architecture. |
sse2a |
Adds the AMD extensions (3DNow!, 3DNow! extensions, and MMX extensions) to the 32-bit SSE2 architecture. |
sse3 |
Adds the SSE3 instruction set to SSE2 instruction set. |
There are some important issues to be aware of when compiling for x86 Solaris platforms.
The legacy Sun-style parallelization pragmas are not available on x86. Use OpenMP instead. See the Sun Studio 12: OpenMP API User’s Guide for information on converting legacy parallelization directives to OpenMP.
Programs compiled with -xarch set to sse, sse2, sse2a, or sse3 must be run only on platforms that provide these extensions and features.
OS releases starting with Solaris 9 4/04 are SSE/SSE2-enabled on Pentium 4-compatible platforms. Earlier versions of Solaris OS are not SSE/SSE2-enabled. If an instruction set selected by -xarch is not enabled in the running Solaris OS, the compiler will not be able to generate or link code for that instruction set.
If you compile and link in separate steps, always link using the compiler and using the same -xarch setting to ensure that the correct startup routine is linked.
Numerical results on x86 may differ from results on SPARC due to the x86 80-bit floating-point registers. To minimize these differences, use the -fstore option or compile with -xarch=sse2 if the hardware supports SSE2.
Numerical results can also differ between Solaris and Linux because the intrinsic math libraries (for example, sin(x)) are not the same.
Starting with Sun Studio 11 and the Solaris 10 OS, program binaries compiled and built using these specialized -xarch hardware flags are verified that they are being run on the appropriate platform.
On systems prior to Solaris 10, no verification is done and it is the user's responsibility to ensure objects built using these flags are deployed on suitable hardware.
Running programs compiled with these -xarch options on platforms that are not enabled with the appropriate features or instruction set extensions could result in segmentation faults or incorrect results occurring without any explicit warning messages.
This warning extends also to programs that employ .il inline assembly language functions or __asm() assembler code that utilize SSE, SSE2, SSE2a, and SSE3 instructions and extensions.
The default architecture for which the C++ compiler produces code is now v8plus (UltraSPARC). Support for v7 will be dropped in a future release.
The new default yields higher run-time performance for nearly all machines in current use. However, applications that are intended for deployment on pre-UltraSPARC computers no longer execute by default on those computers. Compile with -xarch=v8 to ensure that the applications execute on those computers.
If you want to deploy on v8 systems, you must specify the option -xarch=v8 explicitly on every compiler command line as well as any link-time commands. The provided system libraries run on v8 architectures.
If you want to deploy on v7 systems, you must specify the option -xarch=v7 explicitly on every compiler command line as well as any link-time commands. The provided system libraries use the v8 instruction set. For this release, the only supported operating system for v7 is the Solaris 8 OS release. When a v8 instruction is encountered, the Solaris 8 OS interprets the instruction in software. The program runs, but performance is degraded.
For x86, -xarch defaults to generic. Note that -fast on x86 expands to -xarch=native. This option limits the code generated by the compiler to the instructions of the specified instruction set architecture. This option does not guarantee use of any target–specific instructions. However, use of this option may affect the portability of a binary program.
Although this option can be used alone, it is part of the expansion of the -xtarget option and may be used to override the –xarch value that is set by a specific -xtarget option. For example, -xtarget=ultra2 expands to -xarch=v8plusa -xchip=ultra2 -xcache=16/32/1:512/64/1. In the following command -xarch=v8plusb overrides the -xarch=v8plusa that is set by the expansion of -xtarget=ultra2.
example% CC -xtarget=ultra2 -xarch=v8plusb foo.cc |
Use of –compat[=4] with -xarch=generic64, -xarch=native64, -xarch=v9, -xarch=v9a, or -xarch=v9b is not supported.
If you use this option with optimization, the appropriate choice can provide good performance of the executable on the specified architecture. An inappropriate choice, however, might result in serious degradation of performance or in a binary program that is not executable on the intended target platform.
If you compile and link in separate steps, make sure you specify the same value for -xarch in both steps.
This option does not accept OpenMP parallelization directives. The Sun-specific MP pragmas have been deprecated and are no longer supported. See the Sun Studio 12: OpenMP API User’s Guide for migration information to the directives of the standard.
(SPARC) 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.
Avoid -xautopar if you do your own thread management.
To achieve faster execution, this option requires a multiple processor system. On a single-processor system, the resulting binary usually runs slower.
To run a parallelized program in a multithreaded environment, you must set the OMP_NUM_THREADS environment variable prior to execution. See the Sun Studio 12: 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 also link with -xautopar.
(SPARC) Instructs the compiler to prepare the binary for later optimizations, transformations and analysis, see binopt(1). This option may be used for building executables or shared objects. 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.
The default is -xbinopt=off.
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.
Compiling with -xbinopt=prepare and -g increases the size of the executable by including debugging information.
Enables or disables better optimization of standard library calls.
By default, the functions declared in standard library headers are treated as ordinary functions by the compiler. However, some of those functions can be recognized as “intrinsic” or “built-in” by the compiler. When treated as a built-in, the compiler can generate more efficient code. For example, the compiler can recognize that some functions have no side effects, and always return the same output given the same input. Some functions can be generated inline directly by the compiler. See the er_src(1) man page for an explanation of how to read compiler commentary in object files to determine for which functions the compiler actually makes a substitution.
The -xbuiltin=%all option asks the compiler to recognize as many of the built-in standard functions as possible. The exact list of recognized functions varies with the version of the compiler code generator.
The -xbuiltin=%none option results in the default compiler behavior, and the compiler does not do any special optimizations for built-in functions.
If the -xbuiltin option is not specified, then the compiler assumes -xbuiltin=%none.
If only -xbuiltin is specified, then the compiler assumes -xbuiltin=%all.
The expansion of the macro -fast includes -xbuiltin=%all.
The following compiler command requests special handling of the standard library calls.
example% CC -xbuiltin -c foo.cc |
The following compiler command request that there be no special handling of the standard library calls. Note that the expansion of the macro -fast includes -xbuiltin=%all.
example% CC -fast -xbuiltin=%none -c foo.cc |
Defines cache properties for use by the optimizer. This option 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.
This release introduces an optional property [/ti] which sets the number of threads that can share the cache.
c must be one of the following values.
Table A–25 The -xcache Values
Value |
Meaning |
---|---|
generic |
This is the default value which directs the compiler to use cache properties for good performance on most x86 and SPARC processors, without major performance degradation on any of them. With each new release, these best timing properties will be adjusted, if appropriate. |
native |
Set the parameters for the best performance on the host environment. |
s1/l1/a1[/t1] |
Defines level 1 cache properties |
s1/l1/a1[/t1]:s2/l2/a2[/t2] |
Defines level 1 and 2 cache properties |
s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3] |
Defines level 1, 2, and 3 cache properties |
The definitions of the cache properties si/li/ai/ti are as follows:
Property |
Definition |
---|---|
si |
The size of the data cache at level i, in kilobytes |
li |
The line size of the data cache at level i, in bytes |
ai |
The associativity of the data cache at level i |
For example, i=1 designates level 1 cache properties, s1/l1/a1.
If –xcache is not specified, the default –xcache=generic is assumed. This value directs the compiler to use cache properties for good performance on most SPARC processors, without major performance degradation on any of them.
If you do not specify a value for t, the default is 1.
–xcache=16/32/4:1024/32/1 specifies the following:
Level 1 Cache Has |
Level 2 Cache Has |
---|---|
16 Kbytes |
1024 Kbytes |
32 bytes line size |
32 bytes line size |
4-way associativity |
Direct mapping associativity |
–xtarget=t
(SPARC) Obsolete, do not use this option. Current Solaris operating system software no longer support SPARC V7 architecture. Compiling with this option generates code that runs slower on current SPARC platforms. Use -O instead and take advantage of compiler defaults for -xarch, -xchip, and -xcache.
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 for o:
Table A–26 The -xchar Values
Value |
Meaning |
---|---|
signed |
Treat character constants and variables declared as char as signed. This impacts the behavior of compiled code, it does not affect the behavior of library routines. |
s |
Equivalent to signed |
unsigned |
Treat character constants and variables declared as char as unsigned. This impacts the behavior of compiled code, it does not affect the behavior of library routines. |
u |
Equivalent to unsigned |
If you do not specify -xchar, the compiler assumes -xchar=s.
If you specify -xchar, but do not specify a value, the compiler assumes -xchar=s.
The -xchar option changes the range of values for the type char only for code compiled with -xchar. This option does not change the range of values for type char in any system routine or header file. In particular, the value of CHAR_MAX and CHAR_MIN, as defined by limits.h, do not change when this option is specified. Therefore, CHAR_MAX and CHAR_MIN no longer represent the range of values encodable in a plain char.
If you use -xchar, be particularly careful when you compare a char against a predefined system macro because the value in the macro may be signed. This is most common for any routine that returns an error code which is accessed through a macro. Error codes are typically negative values so when you compare a char against the value from such a macro, the result is always false. A negative number can never be equal to any value of an unsigned type.
It is strongly recommended that you never use -xchar to compile routines for any interface exported through a library. The Solaris ABI specifies type char as signed, and system libraries behave accordingly. The effect of making char unsigned has not been extensively tested with system libraries. Instead of using this option, modify your code so that it does not depend on whether type char is signed or unsigned. The sign of type char varies among compilers and operating systems.
SPARC: Compiling with -xcheck=stkovf adds 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).
i must be one of the following:
Table A–27 The -xcheck Values
Value |
Meaning |
---|---|
%all |
Perform all checks. |
%none |
Perform no checks. |
stkovf |
Turns on stack-overflow checking. |
no%stkovf |
Turns off stack-overflow checking. |
If you do not specify -xcheck, the compiler defaults to -xcheck=%none.
If you specify -xcheck without any arguments, the compiler defaults to -xcheck=%none.
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 target processor for use by the optimizer.
The –xchip option specifies timing properties by specifying the target processor. This option affects:
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
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.
c must be one of the following values.
Table A–28 The -xchip Values
Platform |
Value |
Optimize for Using Timing Properties |
---|---|---|
SPARC |
generic |
For good performance on most SPARC processors |
native |
For good performance on the system on which the compiler is running |
|
old |
Of processors earlier than the SuperSPARC processor |
|
sparc64vi |
Of the SPARC64 VI processor |
|
super |
Of the SuperSPARC processor |
|
super2 |
Of the SuperSPARC II processor |
|
micro |
Of the microSPARC processor |
|
micro2 |
Of the microSPARC II processor |
|
hyper |
Of the hyperSPARC processor |
|
hyper2 |
Of the hyperSPARC II processor |
|
powerup |
Of the Weitek PowerUp processor |
|
ultra |
Of the UltraSPARC processor |
|
ultra2 |
Of the UltraSPARC II processor |
|
ultra2e |
Of the UltraSPARC IIe processor |
|
ultra2i |
Of the UltraSPARC IIi processor |
|
ultra3 |
Of the UltraSPARC III processor |
|
ultra3cu |
Of the UltraSPARC III Cu processor |
|
ultra3i |
Of the UltraSparc IIIi processors. |
|
ultra4 |
Of the UltraSPARC IV processors. |
|
ultra4plus |
Of the UltraSPARC IVplus processor. |
|
ultraT1 |
Of the UltraSPARC T1 processor. |
|
ultraT2 |
Of the UltraSPARC T2 processor. |
|
x86 |
generic |
Of most x86 processors |
pentium |
Of the Intel Pentium processor |
|
pentium_pro |
Of the Intel Pentium Pro processor |
|
pentium3 |
Of the Intel Pentium 3 style processor |
|
pentium4 |
Of the Intel Pentium 4 style processor |
On most SPARC processors, generic is the default value that directs the compiler to use the best timing properties for good performance without major performance degradation on any of the processors.
SPARC: Specifies the code address space.
You should build shared objects by specifying -xcode=pic13 or -xcode=pic32. It is possible to build workable shared objects with -xarch=v9 -xcode=abs64 and with -xarch=v8, -xcode=abs32, but these will be inefficient. Shared objects built with -xarch=v9, -xcode=abs32 or -xarch=v9, -xcode=abs44 will not work.
a must be one of the following values.
Table A–29 The -xcode Values
Value |
Meaning |
---|---|
abs32 |
Generates 32-bit absolute addresses, which are fast, but have limited range. Code + data + bss size is limited to 2**32 bytes. |
abs44 |
SPARC: Generates 44-bit absolute addresses, which have moderate speed and moderate range. Code + data + bss size is limited to 2**44 bytes. Available only on 64-bit architectures. Do not use this value with dynamic (shared) libraries. |
abs64 |
SPARC: Generates 64-bit absolute addresses, which are slow, but have full range. Available only on 64-bit architectures. |
pic13 |
Generates position-independent code (small model), which is fast, but has limited range. Equivalent to– Kpic. Permits references to at most 2**11 unique external symbols on 32-bit architectures; 2**10 on 64-bit. |
pic32 |
Generates position-independent code (large model), which is slow, but has full range. Equivalent to– KPIC. Permits references to at most 2**30 unique external symbols on 32-bit architectures; 2**29 on 64-bit. |
To determine whether to use –xcode=pic13 or –xcode=pic32, check the size of the Global Offset Table (GOT) by using elfdump -c (see the elfdump(1) man page for more information) and for the section header, sh_name: .got. The sh_size value is the size of the GOT. If the GOT is less than 8,192 bytes, specify -xcode=pic13, otherwise specify -xcode=pic32.
In general, use the following guidelines to determine how you should use -xcode:
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 exceed 8,192 bytes, use -xcode=pic32.
If you are building an archive library for linking into shared libraries you should just use -xcode=pic32.
The default is -xcode=abs32 for 32–bit architectures. The default for 64–bit architectures is-xcode=abs44.
When building shared dynamic libraries, the default -xcode values of abs44 and abs32 will not work with 64–bit architectures. Specify -xcode=pic13 or -xcode=pic32 instead. There are two nominal performance costs with -xcode=pic13 and -xcode=pic32 on SPARC:
A routine compiled with either -xcode=pic13 or -xcode=pic32 executes a few extra instructions upon entry to set a register to point at a table (_GLOBAL_OFFSET_TABLE_) used for accessing a shared library’s global or static variables.
Each access to a global or static variable involves an extra indirect memory reference through _GLOBAL_OFFSET_TABLE_. If the compile is done with -xcode=pic32, there are two additional instructions per global and static memory reference.
When considering the above costs, remember that the use of -xcode=pic13 and -xcode=pic32 can significantly reduce system memory requirements, due to the effect of library code sharing. Every page of code in a shared library compiled -xcode=pic13 or– xcode=pic32 can be shared by every process that uses the library. If a page of code in a shared library contains even a single non-pic (that is, absolute) memory reference, the page becomes nonsharable, and a copy of the page must be created each time a program using the library is executed.
The easiest way to tell whether or not a .o file has been compiled with -xcode=pic13 or –xcode=pic32 is with the nm command:
% nm file.o | grep _GLOBAL_OFFSET_TABLE_ U _GLOBAL_OFFSET_TABLE_ |
A .o file containing position-independent code contains an unresolved external reference to _GLOBAL_OFFSET_TABLE_, as indicated by the letter U.
To determine whether to use -xcode=pic13 or -xcode=pic32, use nm to identify the number of distinct global and static variables used or defined in the library. If the size of _GLOBAL_OFFSET_TABLE_ is under 8,192 bytes, you can use -Kpic. Otherwise, you must use -xcode=pic32.
When you compile and link in separate steps, you must use the same -xarch option in the compile step and the link step.
SPARC: Enables optimization and inlining across source files. -xcrossfile works at compile time and involves only the files that appear on the compilation command. Consider the following command-line example:
example% CC -xcrossfile -xO4 -c f1.cc f2.cc example% CC -xcrossfile -xO4 -c f3.cc f4.cc |
Cross-module optimizations occur between files f1.cc and f2.cc, and between f3.cc and f4.cc. No optimizations occur between f1.cc and f3.cc or f4.cc.
n must be one of the following values.
Table A–30 The -xcrossfile Values
Value |
Meaning |
---|---|
0 |
Do not perform cross-file optimizations or cross-file inlining. |
1 |
Perform optimization and inlining across source files. |
Normally the scope of the compiler’s analysis is limited to each separate file on the command line. For example, when the -xO4 option is passed, automatic inlining is limited to subprograms defined and referenced within the same source file.
With -xcrossfile or -xcrossfile=1, the compiler analyzes all the files named on the command line as if they had been concatenated into a single source file.
If -xcrossfile is not specified, -xcrossfile=0 is assumed and no cross-file optimizations or inlining are performed.
-xcrossfile is the same as -xcrossfile=1.
The -xcrossfile option is effective only when it is used with -xO4 or -xO5.
The files produced from this compilation are interdependent due to possible inlining, and must be used as a unit when they are linked into a program. If any one routine is changed and the files recompiled, they must all be recompiled. As a result, using this option affects the construction of makefiles.
-xldscope
The compiler is migrating the format of debugger information from the stabs format to the dwarf format as specified in ’DWARF Debugging Information Format’. The default setting for this release is -xdebugformat=stabs.
If you maintain software which reads debugging information, you now have the option to transition your tools from the stabs format to the dwarf format.
Use this option as a way of accessing the new format for the purpose of porting tools. There is no need to use this option unless you maintain software which reads debugger information, or unless a specific tool tells you that it requires debugger information in one of these formats.
Table A–31 The -xdebugformat Flags
Value |
Meaning |
---|---|
stabs |
-xdebugformat=stabs generates debugging information using the stabs standard format. |
dwarf |
-xdebugformat=dwarf generates debugging information using the dwarf standard format. |
If you do not specify -xdebugformat, the compiler assumes -xdebugformat=stabs. 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 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.
This is a transitional interface so expect it to change in incompatible ways from release to release, even in a minor release. The details of any specific fields or values in either stabs or dwarf are also evolving.
See also the dumpstabs(1) and dwarfdump(1) man pages for more information.
(SPARC) Analyzes loops for inter-iteration data dependencies and does loop restructuring.
Loop restructuring includes loop interchange, loop fusion, scalar replacement, and elimination of “dead” array assignments. If optimization is not at -xO3 or higher, the compiler raises 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 may help on single-processor systems. However, if you try -xdepend on single-processor systems, you should not use either -xautopar. If -xautoparis on, then the -xdepend optimization is done for multiple-processor systems.
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 through the end of the file or until it is overridden by the dumpmacros or end_dumpmacros pragma. See B.2.5 #pragma dumpmacros.
You can substitute the following arguments in place of value:
Table A–32 The -xdumpmacros Values
Value |
Meaning |
---|---|
[no%]defs |
[Do not] Print all macro defines |
[no%]undefs |
[Do not] Print all macro undefines |
[no%]use |
[Do not] Print information about macros used |
[no%]loc |
[Do not] Print location (path name and line number) also for defs, undefs, and use |
[no%]conds |
[Do not] Print use information for macros used in conditional directives |
[no%]sys |
[Do not] Print all macros defines, undefines, and use information for macros in system header files |
%all |
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. |
%none |
Do not print any macro information |
The option values accumulate so specifying -xdumpmacros=sys -xdumpmacros=undefs has the same effect as -xdumpmacros=undefs,sys.
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.
If you specify -xdumpmacros without any arguments, it means -xdumpmacros=defs,undefs,sys. If you do not specify -xdumpmacros, it defaults to -xdumpmacros=%none.
If you use the option -xdumpmacros=use,no%loc, the name of each macro that is used is printed only once. However, if you want more detail, use the option -xdumpmacros=use,loc so the location and macro name is printed every time a macro is used.
Consider the following file t.c:
example% cat t.c #ifdef FOO #undef FOO #define COMPUTE(a, b) a+b #else #define COMPUTE(a,b) a-b #endif int n = COMPUTE(5,2); int j = COMPUTE(7,1); #if COMPUTE(8,3) + NN + MM int k = 0; #endif |
The following examples show the output for file t.c based on the defs, undefs, sys, and loc arguments.
example% CC -c -xdumpmacros -DFOO t.c #define __SunOS_5_9 1 #define __SUNPRO_CC 0x590 #define unix 1 #define sun 1 #define sparc 1 #define __sparc 1 #define __unix 1 #define __sun 1 #define __BUILTIN_VA_ARG_INCR 1 #define __SVR4 1 #define __SUNPRO_CC_COMPAT 5 #define __SUN_PREFETCH 1 #define FOO 1 #undef FOO #define COMPUTE(a, b) a + b example% CC -c -xdumpmacros=defs,undefs,loc -DFOO -UBAR t.c command line: #define __SunOS_5_9 1 command line: #define __SUNPRO_CC 0x590 command line: #define unix 1 command line: #define sun 1 command line: #define sparc 1 command line: #define __sparc 1 command line: #define __unix 1 command line: #define __sun 1 command line: #define __BUILTIN_VA_ARG_INCR 1 command line: #define __SVR4 1 command line: #define __SUNPRO_CC_COMPAT 5 command line: #define __SUN_PREFETCH 1 command line: #define FOO 1 command line: #undef BAR t.c, line 2: #undef FOO t.c, line 3: #define COMPUTE(a, b) a + b |
The following examples show how the use, loc, and conds arguments report macro behavior in file t.c:
example% CC -c -xdumpmacros=use t.c used macro COMPUTE example% CC -c -xdumpmacros=use,loc t.c t.c, line 7: used macro COMPUTE t.c, line 8: used macro COMPUTE example% CC -c -xdumpmacros=use,conds t.c used macro FOO used macro COMPUTE used macro NN used macro MM example% CC -c -xdumpmacros=use,conds,loc t.c t.c, line 1: used macro FOO t.c, line 7: used macro COMPUTE t.c, line 8: used macro COMPUTE t.c, line 9: used macro COMPUTE t.c, line 9: used macro NN t.c, line 9: used macro MM |
Consider the file y.c:
example% cat y.c #define X 1 #define Y X #define Z Y int a = Z; |
Here is the output from -xdumpmacros=use,loc based on the macros in y.c:
example% CC -c -xdumpmacros=use,loc y.c y.c, line 4: used macro Z y.c, line 4: used macro Y y.c, line 4: used macro X |
Use the dumpmacros pragma and the end_dumpmacros pragma when you want to override the scope of -xdumpmacros.
Checks only for syntax and semantic errors. When you specify -xe, the compiler does not produce any object code. The output for -xe is directed to stderr.
Use the -xe option if you do not need the object files produced by compilation. For example, if you are trying to isolate the cause of an error message by deleting sections of code, you can speed the edit and compile cycle by using -xe.
–c
Enables optimal reordering of functions and variables by the linker.
This option instructs the compiler to place functions and/or data variables into separate section fragments, which enables the linker, using directions in a mapfile specified by the linker’s -M option, to reorder these sections to optimize program performance. Generally, this optimization is only effective when page fault time constitutes a significant fraction of program run time.
Reording of variables can help solve the following problems which negatively impact run-time performance:
Cache and page contention caused by unrelated variables that are near each other in memory.
Unnecessarily large work-set size as a result of related variables which are not near each other in memory.
Unnecessarily large work-set size as a result of unused copies of weak variables that decrease the effective data density.
Reordering variables and functions for optimal performance requires the following operations:
Compiling and linking with -xF.
Following the instructions in the “Program Performance Analysis Tools” 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 or more of the following:
Table A–33 The -xF Values
Value |
Meaning |
---|---|
[no%]func |
[Do not] fragment functions into separate sections. |
[no%]gbldata |
[Do not] fragment global data (variables with external linkage) into separate sections. |
[no%]lcldata |
[Do not] fragment local data (variables with internal linkage) into separate sections. |
%all |
Fragment functions, global data, and local data. |
%none |
Fragment nothing. |
If you do not specify -xF, the default is -xF=%none. If you specify -xF without any arguments, the default is -xF=%none,func.
Using -xF=lcldata inhibits some address calculation optimizations, so you should only use this flag when it is experimentally justified.
analyzer(1), debugger(1), ld(1) man pages
Displays a brief description of each compiler option.
Displays contents of the online readme file.
The readme file is paged by the command specified in the environment variable, PAGER. If PAGER is not set, the default paging command is more.
(SPARC) Enables compiler support for hardware counter-based 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 -gto 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.
An instance of -xhwcprof=enable or -xhwcprof=disable overrides all previous instances of -xhwcprof in the same command line.
-xhwcprof is disabled by default. Specifying -xhwcprof without any arguments is the equivalent to -xhwcprof=enable.
-xhwcprof requires that optimization be turned on and that the debug data format be set to DWARF (-xdebugformat=dwarf).
The combination of -xhwcprof and -g increases compiler temporary file storage requirements by more than the sum of the increases due to -xhwcprof and -g specified alone.
The following command compiles example.cc and specifies support for hardware counter profiling and symbolic analysis of data types and structure members using DWARF symbols:
example% CC -c -O -xhwcprof -g -xdebugformat=dwarf example.cc |
For more information on hardware counter-based profiling, see the Program Performance Analysis Tools manual.
SPARC: Links the appropriate interval arithmetic libraries and sets a suitable floating-point environment.
The C++ interval arithmetic library is compatible with interval arithmetic as implemented in the Fortran compiler.
The -xia option is a macro that expands to -fsimple=0 -ftrap=%none -fns=no -library=interval. If you use intervals and override what is set by -xia by specifying a different flag for -fsimple, -ftrap, -fns or -library, you may cause the compiler to exhibit incorrect behavior.
To use the interval arithmetic libraries, include <suninterval.h>.
When you use the interval arithmetic libraries, you must include one of the following libraries: libC, Cstd, or iostreams. See -library for information on including these libraries.
If you use intervals and you specify different values for -fsimple, -ftrap, or -fns, then your program may have incorrect behavior.
C++ interval arithmetic is experimental and evolving. The specifics may change from release to release.
C++ Interval Arithmetic Programming Reference, Interval Arithmetic Solves Nonlinear Problems While Providing Guaranteed Results (http://www.sun.com/forte/info/features/intervals.html), -library
Specifies which user-written routines can be inlined by the optimizer at -xO3 levels or higher.
func_spec must be one of the following values.
Table A–34 The -xinline Values
Value |
Meaning |
---|---|
%auto |
Enable automatic inlining at optimization levels -xO4 or higher. This argument tells the optimizer that it can inline functions of its choosing. Note that without the %auto specification, automatic inlining is normally turned off when explicit inlining is specified on the command line by -xinline=[no%]func_name... |
func_name |
Strongly request that the optimizer inline the function. If the function is not declared as extern "C", the value of func_name must be mangled. You can use the nm command on the executable file to find the mangled function names. For functions declared as extern "C", the names are not mangled by the compiler. |
no%func_name |
When you prefix the name of a routine on the list with no%, the inlining of that routine is inhibited. The rule about mangled names for func_name applies to no%func_name as well. |
Only routines in the file being compiled are considered for inlining unless you use -xcrossfile[=1]. The optimizer decides which of these routines are appropriate for inlining.
If the -xinline option is not specified, the compiler assumes -xinline=%auto.
If -xinline= is specified with no arguments, no functions are inlined, regardless of the optimization level.
To enable automatic inlining while disabling inlining of the function declared int foo(), use
example% CC -xO5 -xinline=%auto,no%__1cDfoo6F_i_ -c a.cc |
To strongly request the inlining of the function declared as int foo(), and to make all other functions as the candidates for inlining, use
example% CC -xO5 -xinline=%auto,__1cDfoo6F_i_ -c a.cc |
To strongly request the inlining of the function declared as int foo(), and to not allow inlining of any other functions, use
example% CC -xO5 -xinline=__1cDfoo6F_i_ -c a.cc |
The -xinline option has no effect for optimization levels below -xO3. At -xO4 and higher, the optimizer decides which functions should be inlined, and does so without the -xinline option being specified. At -xO4 and higher, the compiler also attempts to determine which functions will improve performance if they are inlined.
A routine is not inlined if any of the following conditions apply. No warnings will be omitted.
Optimization is less than -xO3
The routine cannot be found
Inlining it is not profitable or safe
The source is not in the file being compiled, or, if you use -xcrossfile[=1], the source is not in the files named on the command line
If you force the inlining of a function with -xinline, you might actually diminish performance.
Specify this option to compile and instrument your program for analysis by the Thread Analyzer. For more information on the Thread Analyzer, seetha(1) for details.
You can then use the Performance Analyzer to run the instrumented program with collect -r races to create a data-race-detection 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 separate 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.
Performs interprocedural optimizations.
The -xipo option performs partial-program optimizations by invoking an interprocedural analysis pass. Unlike -xcrossfile, -xipo performs optimizations across all object files in the link step, and the optimizations are not limited to just the source files on the compile command. However, just like -xcrossfile, whole-program optimizations performed with -xipo do not include assembly (.s) source files.
The -xipo option is particularly useful when compiling and linking large multifile applications. Object files compiled with this flag have analysis information compiled within them that enables interprocedural analysis across source and precompiled program files. However, analysis and optimization is limited to the object files compiled with -xipo, and does not extend to object files or libraries.
The -xipo option can have the following values.
Table A–35 The -xipo Values
Value |
Meaning |
---|---|
0 |
Do not perform interprocedural optimizations |
1 |
Perform interprocedural optimizations |
2 |
Perform interprocedural aliasing analysis as well as optimizations of memory allocation and layout to improve cache performance |
If -xipo is not specified, -xipo=0 is assumed.
If only -xipo is specified, -xipo=1 is assumed.
The following example compiles and links in the same step.
example% CC -xipo -xO4 -o prog part1.cc part2.cc part3.cc |
The optimizer performs crossfile inlining across all three source files. This is done in the final link step, so the compilation of the source files need not all take place in a single compilation and could be over a number of separate compilations, each specifying the -xipo option.
The following example compiles and links in separate steps.
example% CC -xipo -xO4 -c part1.cc part2.cc example% CC -xipo -xO4 -c part3.cc example% CC -xipo -xO4 -o prog part1.o part2.o part3.o |
The object files created in the compile steps have additional analysis information compiled within them to permit crossfile optimizations to take place at the link step.
The -xipo option requires at least optimization level -xO4.
You cannot use both the -xipo option and the -xcrossfile option in the same compiler command line.
When compiling and linking are performed in separate steps, -xipo must be specified in both steps to be effective.
Objects that are compiled without -xipo can be linked freely with objects that are compiled with -xipo.
Libraries do not participate in crossfile interprocedural analysis, even when they are compiled with -xipo, as shown in this example.
example% CC -xipo -xO4 one.cc two.cc three.cc example% CC -xar -o mylib.a one.o two.o three.o ... example% CC -xipo -xO4 -o myprog main.cc four.cc mylib.a |
In this example, interprocedural optimizations will be performed between one.cc, two.cc and three.cc, and between main.cc and four.cc, but not between main.cc or four.cc and the routines in mylib.a. (The first compilation may generate warnings about undefined symbols, but the interprocedural optimizations will be performed because it is a compile and link step.)
The -xipo option generates significantly larger object files due to the additional information needed to perform optimizations across files. However, this additional information does not become part of the final executable binary file. Any increase in the size of the executable program will be due to the additional optimizations performed.
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.
-xjobs
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:
Table A–36 The -xipo_archive Flags
Value |
Meaning |
---|---|
writeback |
The compiler optimizes object files passed to the linker with object files compiled with -xipo that reside in the archive library (.a) before producing an executable. Any object files contained in the library that were optimized during the 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. |
readonly |
The compiler optimizes object files passed to the linker with object files compiled with -xipo that reside in the archive library (.a) before producing an executable. The option -xipo_archive=readonly enables cross-module inlining and interprocedural data flow analysis of object files in an archive library specified at link time. However, it does not enable cross-module optimization of the archive library's code except for code that has been inserted into other modules by cross module inlining. To apply cross-module optimization to code within an archive library, -xipo_archive=writeback is required. Note that doing so modifies the contents of the archive library from which the code was extracted. |
none |
This is the 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. |
If you do not specify a setting for -xipo_archive, the compiler sets it to -xipo_archive=none.
It is illegal to specify -xipo_archive without a flag.
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.
You must always specify -xjobs with a value. Otherwise an error diagnostic is issued and compilation aborts.
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 overheads among spawned jobs. Also, using a very high number can exhaust the limits of system resources such as swap space.
Multiple instances of -xjobs on the command line override each other until the right-most instance is reached.
The following example compiles more quickly on a system with two processors than the same command without the -xjobs option.
example% CC -xipo -xO4 -xjobs=3 t1.cc t2.cc t3.cc |
Includes the appropriate runtime libraries and ensures the proper runtime environment for the specified language.
language must be either f77, f90, f95, or c99.
The f90 and f95 arguments are equivalent. The c99 argument invokes ISO 9899:1999 C programming language behavior for objects that were compiled with cc -xc99=%all and are being linked with CC.
The -xlang=f90 and -xlang=f95 options imply -library=f90, and the -xlang=f77 option implies -library=f77. However, the -library=f77 and -library=f90 options are not sufficient for mixed-language linking because only the -xlang option ensures the proper runtime environment.
To determine which driver to use for mixed-language linking, use the following language hierarchy:
C++
Fortran 95 (or Fortran 90)
Fortran 77
C or C99
When linking Fortran 95, Fortran 77, and C++ object files together, use the driver of the highest language. For example, use the following C++ compiler command to link C++ and Fortran 95 object files.
example% CC -xlang=f95... |
To link Fortran 95 and Fortran 77 object files, use the Fortran 95 driver, as follows.
example% f95 -xlang=f77... |
You cannot use the -xlang option and the -xlic_lib option in the same compiler command. If you are using -xlang and you need to link in the Sun Performance Libraries, use -library=sunperf instead.
Do not use -xnolib with -xlang.
If you are mixing parallel Fortran objects with C++ objects, the link line must specify the -mt flag.
-library, -staticlib
Specify the -xldscope option to change the default linker scoping for the definition of extern symbols. Changing the default can result in faster and safer shared libraries and executables because the implementation are better hidden.
v must be one of the following:
Table A–37 The -xldscope Values
Value |
Meaning |
---|---|
global |
Global linker scoping is the least restrictive linker scoping. All references to the symbol bind to the definition in the first dynamic load module that defines the symbol. This linker scoping is the current linker scoping for extern symbols. |
symbolic |
Symbolic linker scoping and is more restrictive than global linker scoping. All references to the symbol from within the dynamic load module being linked bind to the symbol defined within the module. Outside of the module, the symbol appears as though it is global. This linker scoping corresponds to the linker option -Bsymbolic. Although you cannot use -Bsymbolic with C++ libraries, you can use the -xldscope=symbolic without causing problems. See ld(1) for more information on the linker. |
hidden |
Hidden linker scoping is more restrictive than symbolic and global linker scoping. All references within a dynamic load 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. If you specify -xldscope without any values, the compiler issues an error. Multiple instances of this option on the command line override each other until the right most 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 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. See 4.2 Thread-Local Storage.
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.
-xinline, -xO, -xcrossfile
Causes libm to return IEEE 754 values for math routines in exceptional cases.
The default behavior of libm is XPG-compliant.
Numerical Computation Guide
Inlines selected libm library routines for optimization.
This option does not affect C++ inline functions.
There are inline templates for some of the libm library routines. This option selects those inline templates that produce the fastest executables for the floating-point option and platform currently being used.
This option is implied by the –fast option.
-fast, Numerical Computation Guide
Uses library of optimized math routines. You must use default rounding mode by specifying -fround=nearest when you use this option.
This option uses a math routine library optimized for performance and usually generates faster code. The results might be slightly different from those produced by the normal math library; if so, they usually differ in the last bit.
The order on the command line for this library option is not significant.
This option is implied by the –fast option.
–fast, –xnolibmopt, -fround
Deprecated, do not use. Specify -library=sunperf instead. See A.2.49 -library=l[,l...] for more information.
This option is silently ignored by the compiler.
Instructs the compiler to perform link-time optimization on the resulting executable or dynamic library over and above any optimizations in the object files. 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.
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 that are 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).
level sets the level of optimizations performed, and must be 0, 1, or 2. The optimization levels are:
Table A–38 The -xlinkopt Values
Value |
Meaning |
---|---|
0 |
The link optimizer is disabled. (This is the default.) |
1 |
Perform optimizations based on control flow analysis, including instruction cache coloring and branch optimizations, at link time. |
2 |
Perform additional data flow analysis, including dead-code elimination and address computation simplification, at link time. |
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
Note that the level parameter is only used when the compiler is linking. In the example above, the link optimizer level is 2 even though the object binaries are compiled with an implied level of 1.
Specifying -xlinkopt without a level parameter implies -xlinkopt=1.
This option is most effective when you use it to compile the whole program, and with profile feedback. Profiling reveals the most and least used parts of the code and building 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 compiles as follows:
example% cc -o progt -xO5 -xprofile=collect:prog file.c example% progt example% cc -o prog -xO5 -xprofile=use:prog -xlinkopt file.c |
For details on using profile feedback, see A.2.165 -xprofile=p.
Do not use the -zcompreloc linker option when you compile with -xlinkopt.
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 executable by including debugging information.
Runs only the C++ preprocessor on the named C++ programs, requesting that the preprocessor generate makefile dependencies and send the result to the standard output (see make(1) for details about make files and dependencies).
For example:
#include <unistd.h> void main(void) {} |
generates this output:
e.o: e.c e.o: /usr/include/unistd.h e.o: /usr/include/sys/types.h e.o: /usr/include/sys/machtypes.h e.o: /usr/include/sys/select.h e.o: /usr/include/sys/time.h e.o: /usr/include/sys/types.h e.o: /usr/include/sys/time.h e.o: /usr/include/sys/unistd.h |
If you specify -xM and -xMF, the compiler writes all makefile dependency information to the file specified with -xMF. This file is overwritten each time the preprocessor writes to it.
make(1S) (for details about makefiles and dependencies)
Generates makefile dependencies like –xM, except that it does not report dependencies for the /usr/include header files and it does not report dependencies for compiler-supplied header files.
If you specify -xM1 and -xMF, the compiler writes all makefile dependency information to the file specified with -xMF. This file is overwritten each time the preprocessor writes to it.
Generates makefile dependencies like -xM but includes compilation. -xMD generates an output file for the makefile-dependency information based on the input filename but with the addition of a .d suffix. If you specify -xMD and -xMF, the preprocessor appends all makefile dependency information to the file specified with -xMF.
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 the command line.
Use this option to generate makefile dependencies excluding system header files. This is the same functionality as -xM1, but includes compilation. -xMMD generates an output file for the makefile-dependency information based on the input filename but with the addition of a .d suffix. If you specify both -xMMD and -xMF, the compiler uses the filename you provide instead.
SPARC: Merges the data segment with the text segment.
The data in the object file is read-only and is shared between processes, unless you link with ld -N.
ld(1) man page
This command limits the level of pragma opt to the level specified. v is one of off, 1, 2, 3, 4, 5. The default value is -xmaxopt=off which causes pragma opt to be ignored. If you specify -xmaxopt without supplying an argument, that is the 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
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.
The following table lists the alignment and behavior values for -xmemalign
Table A–39 The -xmemalign Alignment and Behavior Values
a |
b | ||
---|---|---|---|
1 |
Assume at most 1 byte alignment. |
i |
Interpret access and continue execution. |
2 |
Assume at most 2 byte alignment. |
s |
Raise signal SIGBUS. |
4 |
Assume at most 4 byte alignment. |
f |
For variants of -xarch=v9 only: Raise signal SIGBUS for alignments less or equal to 4,otherwise interpret access and continue execution. For all other -xarch values, the f flag is equivalent to i. |
8 |
Assume at most 8 byte alignment. | ||
16 |
Assume at most 16 byte alignment |
You must 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 all compiler options that must be specified at both compile time and at link time, see 3.3.3 Compile-Time and Link-Time Options.
The following default values only apply when no -xmemalign option is present:
-xmemalgin=8i for all v8 architectures.
-xmemalign=8s for all v9 architectures.
Here is the default when the -xmemalign option is present but no value is given:
-xmemalign=1i for all -xarch values.
The following table shows how you can use -xmemalign to handle different alignment situations.
Table A–40 Examples of -xmemalign
Command |
Situation |
---|---|
-xmemalign=1s |
There are many misaligned accesses so trap handling is too slow. |
-xmemalign=8i |
There are occasional, intentional, misaligned accesses in code that is otherwise correct. |
-xmemalign=8s |
There should be no misaligned accesses in the program. |
-xmemalin=2s |
You want to check for possible odd-byte accesses. |
-xmemalign=2i |
You want to check for possible odd-byte access and you want the program to work. |
(x86) The -xmodel option enables the compiler to modify the form of 64-bit objects for the Solaris x86 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 must be one of the following:
Table A–41 The -xmodel Flags
Value |
Meaning |
---|---|
small |
This option generates code for the small model in which the virtual address of code executed is known at link time and all symbols are known to be located in the virtual addresses in the range from 0 to 2^31 - 2^24 - 1. |
kernel |
Generates code for the kernel model in which all symbols are defined to be in the range from 2^64 - 2^31 to 2^64 - 2^24. |
medium |
Generates code for the medium model in which no assumptions are made about the range of symbolic references to data sections. Size and address of the text section have the same limits as the small code model. Applications with large amounts of static data might require -xmodel=medium when compiling with -m64. |
This option is not cumulative so the compiler sets the model value according to the rightmost instance of -xmodel on the command-line.
If you do not specify -xmodel, the compiler assumes -xmodel=small. Specifying -xmodel without an argument is an error.
It is not necessary to compile all translation units with this 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.
Disables linking with default system libraries.
Normally (without this option), the C++ compiler links with several system support libraries to support C++ programs. With this option, the -llib options to link the default system support libraries are not passed to ld.
Normally, the compiler links with the system support libraries in the following order:
Standard mode (default mode):
-lCstd -lCrun -lm -lc |
Compatibility mode (-compat):
-lC -lm -lc |
The order of the -l options is significant. The -lm option must appear before -lc.
If the -mt compiler option is specified, the compiler normally links with -lthread just before it links with -lm.
To determine which system support libraries will be linked by default, compile with the -dryrun option. For example, the output from the following command:
example% CC foo.cc -xarch=v9 -dryrun |
Includes the following in the output:
-lCstd -lCrun -lm -lc |
For minimal compilation to meet the C application binary interface (that is, a C++ program with only C support required), use:
example% CC– xnolib test.cc– lc |
To link libm statically into a single-threaded application with the generic architecture instruction set, use:
Standard mode:
example% CC -xnolib test.cc -lCstd -lCrun -Bstatic -lm -Bdynamic -lc |
Compatibility mode:
example% CC -compat -xnolib test.cc -lC -Bstatic -lm -Bdynamic -lc |
Some static system libraries, such as libm.a and libc.a, are not available when linking with -xarch=v9, -xarch=v9a or -xarch=v9b.
If you specify– xnolib, you must manually link all required system support libraries in the given order. You must link the system support libraries last.
If -xnolib is specified, -library is ignored.
Many C++ language features require the use of libC (compatibility mode) or libCrun (standard mode).
This set of system support libraries is not stable and might change from release to release.
–library, –staticlib, –l
Cancels –xlibmil on the command line.
Use this option with –fast to override linking with the optimized math library.
Does not use the math routine library.
Use this option after the –fast option on the command line, as in this example:
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; note the uppercase letter O followed by the digit 1, 2, 3, 4, or 5. In general, program execution speed depends on the level of optimization. The higher the level of optimization, the better the runtime performance. However, higher optimization levels can result in increased compilation time and larger executable files.
In a few cases, –xO2 might perform better than the others, and –xO3 might outperform –xO4. Try compiling with each level to see if you have one of these rare cases.
If the optimizer runs out of memory, it tries to recover by retrying the current procedure at a lower level of optimization. The optimizer resumes subsequent procedures at the original level specified in the -xOlevel option.
There are five levels that you can use with –xO. The following sections describe how they operate on the SPARC platform and the x86 platform.
On the SPARC Platform:
–xO1 does only the minimum amount of optimization (peephole), which is post-pass, assembly-level optimization. Do not use -xO1 unless using -xO2 or -xO3 results in excessive compilation time, or you are running out of swap space.
–xO2 does basic local and global optimization, which includes:
Induction-variable elimination
Local and global common-subexpression elimination
Algebraic simplification
Copy propagation
Constant propagation
Loop-invariant optimization
Register allocation
Basic block merging
Tail recursion elimination
Dead-code elimination
Tail-call elimination
Complicated expression expansion
This level does not optimize references or definitions for external or indirect variables.
–xO3, in addition to optimizations performed at the –xO2 level, also optimizes references and definitions for external variables. This level does not trace the effects of pointer assignments. When compiling either device drivers that are not properly protected by volatile or programs that modify external variables from within signal handlers, use– xO2. In general, this level results in increased code size unless combined with the -xspace option.
–xO4 does automatic inlining of functions contained in the same file in addition to performing– xO3 optimizations. This automatic inlining usually improves execution speed but sometimes makes it worse. In general, this level results in increased code size unless combined with the -xspace option.
–xO5 generates the highest level of optimization. It is suitable only for the small fraction of a program that uses the largest fraction of computer time. This level 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 A.2.165 -xprofile=p.
On the x86 Platform:
–xO1 does basic optimization. This includes algebraic simplification, register allocation, basic block merging, dead code and store elimination, and peephole optimization.
–xO2 performs local common subexpression elimination, local copy and constant propagation, and tail recursion elimination, as well as the optimization done by level 1.
–xO3 performs global common subexpression elimination, global copy and constant propagation, loop strength reduction, induction variable elimination, and loop-variant optimization, as well as the optimization done by level 2.
–xO4 does automatic inlining of functions contained in the same file as well as the optimization done by level 3. This automatic inlining usually improves execution speed, but sometimes makes it worse. This level also frees the frame pointer registration (ebp) for general purpose use. In general this level results in increased code size.
–xO5 generates the highest level of optimization. It uses optimization algorithms that take more compilation time or that do not have as high a certainty of improving execution time.
If you use -g or -g0 and the optimization level is -xO3 or lower, the compiler provides best-effort symbolic information with almost full optimization. Tail-call optimization and back-end inlining are disabled.
If you use -g or -g0 and the optimization level is -xO4 or higher, the compiler provides best-effort symbolic information with full optimization.
Debugging with -g does not suppress –xOlevel, but –xOlevel limits –g in certain ways. For example, the –xOlevel options reduce the utility of debugging so that you cannot display variables from dbx, but you can still use the dbx where command to get a symbolic traceback. For more information, see Debugging a Program With dbx.
The -xcrossfile option is effective only if it is used with -xO4 or -xO5.
The -xinline option has no effect for optimization levels below -xO3. At -xO4, the optimizer decides which functions should be inlined, and does so regardless of whether you specify the -xinline option. At -xO4, the compiler also attempts to determine which functions will improve performance if they are inlined. If you force the inlining of a function with -xinline, you might actually diminish performance.
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 optimize at –xO3 or –xO4 with very large procedures (thousands of lines of code in a single procedure), the optimizer might require an unreasonable amount of memory. In such cases, machine performance can be degraded.
To prevent this degradation from taking place, use the limit command to limit the amount of virtual memory available to a single process (see the csh(1) man page). For example, to limit virtual memory to 16 megabytes:
example% limit datasize 16M |
This command causes the optimizer to try to recover if it reaches 16 megabytes of data space.
The limit cannot be greater than the total available swap space of the machine, and should be small enough to permit normal use of the machine while a large compilation is in progress.
The best setting for data size depends on the degree of optimization requested, the amount of real memory, and virtual memory available.
To find the actual swap space, type: swap– l
To find the actual real memory, type: dmesg | grep mem
-xldscope –fast, -xcrossfile=n, –xprofile=p, csh(1) man page
Use the -xopenmp option to enable explicit parallelization with OpenMP directives. To run a parallelized program in a multithreaded environment, you must set the OMP_NUM_THREADS environment variable prior to execution.
To enable nested parallelism, you must set the OMP_NESTED environment variable to TRUE. Nested parallelism is disabled by default.
The following table lists the values for i:
Table A–42 The -xopenmp Values
Values |
Meaning |
---|---|
parallel |
Enables recognition of OpenMP pragmas. The minimum optimization level under -xopenmp=parallel is -x03. The compiler changes the optimization from a lower level to -x03 if necessary and issues a warning. This flag also defines the preprocessor token _OPENMP. |
noopt |
Enables recognition of OpenMP pragmas. The compiler does not raise the optimization level if it is lower than -O3. If you explicitly set the optimization lower than -O3, as in CC -O2 -xopenmp=noopt, the compiler issues an error. If you do not specify an optimization level with -xopenmp=noopt, the OpenMP pragmas are recognized, the program is parallelized accordingly, but no optimization is done. This flag also defines the preprocessor token _OPENMP. |
none |
This flag is the default and disables recognition of OpenMP pragmas, does not change the optimization level of your program, and does not predefine any preprocessor tokens. |
If you do not specify -xopenmp, the compiler sets the option to -xopenmp=none.
If you specify -xopenmp, but without an argument, the compiler sets the option to -xopenmp=parallel.
If you are debugging an OpenMP program with dbx, compile with -g and -xopenmp=noopt so you can breakpoint within parallel regions and display the contents of variables.
Do not specify -xopenmp, with either -xexplicitpar, or -xparallel.
The default for -xopenmp might change in future releases. You can avoid warning messages by explicitly specifying an appropriate optimization.
If you compile and link in separate steps, specify -xopenmp in both the compilation step and the link step. This is important if you are building a shared object. The compiler which was used to compile the executable must not be any older than the compiler that built the .so with -xopenmp. This is especially important when you compile libraries that contain OpenMP directives. See 3.3.3 Compile-Time and Link-Time Options for a complete list of options that must be specified at both compile time and line time.
Make sure that the latest patch of the OpenMP runtime library, libmtsk.so, is installed on the system for best performance.
For a complete summary of the OpenMP Fortran 95, C, and C++ application program interface (API) for building multiprocessing applications, see the Sun Studio 12: OpenMP API User’s Guide.
Sets the preferred page size for the stack and the heap.
The n value must be one of the following: 4k, 8K, 64K, 512K, 2M, 4M, 32M, 256M, 2G, 16G, or default.
You must specify a valid page size for the target platform. If you do not specify a valid pagesize, the request is silently ignored at run-time.
Use the getpagesize(3C) command on the Solaris operating system to determine the number of bytes in a page. The Solaris operating system offers no guarantee that the page size request will be honored. You can use pmap(1) or meminfo(2) to determine page size of the target platform.
This feature is not available on the Solaris 8 operating system. A program compiled with this option will not link on the Solaris 8 software.
If you specify -xpagesize=default, the Solaris operating system sets the page size.
This option is a macro for -xpagesize_heap and -xpagesize_stack. These two options accept the same arguments as -xpagesize: 4k, 8K, 64K, 512K, 2M, 4M, 32M, 256M, 2G, 16G, or default. You can set them both with the same value by specifying -xpagesize or you can specify them individually with different values.
The -xpagesize option has no effect unless you use it at compile time and at link time. See 3.3.3 Compile-Time and Link-Time Options for a complete list of options that must be specified at both compile time and link time.
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 Solaris command ppgsz(1) with the equivalent options before running the program. See the Solaris man pages for details.
Set the page size in memory for the heap.
n can be 4k, 8K, 64K, 512K, 2M, 4M, 32M, 256M, 2G, 16G, or default. You must specify a valid page size for the target platform. If you do not specify a valid page size, the request is silently ignored at run-time.
Use the getpagesize(3C) command on the Solaris operating system to determine the number of bytes in a page. The Solaris operating system offers no guarantee that the page size request will be honored. You can use pmap(1) or meminfo(2) to determine page size of the target platform.
This feature is not available on the Solaris 8 operating system. A program compiled with this option will not link on the Solaris 8 software.
If you specify -xpagesize_heap=default, the Solaris operating system sets the page size.
The -xpagesize_heap option has no effect unless you use it at compile time and at link time.
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 Solaris command ppgsz(1) with the equivalent options before running the program. See the Solaris man pages for details.
Set the page size in memory for the stack.
n can be 4k, 8K, 64K, 512K, 2M, 4M, 32M, 256M, 2G, 16G, or default. You must specify a valid page size for the target platform. If you do not specify a valid page size, the request is silently ignored at run-time.
Use the getpagesize(3C) command on the Solaris operating system to determine the number of bytes in a page. The Solaris operating system offers no guarantee that the page size request will be honored. You can use pmap(1) or meminfo(2) to determine page size of the target platform.
This feature is not available on the Solaris 8 operating system. A program compiled with this option will not link on the Solaris 8 software.
If you specify -xpagesize_stack=default, the Solaris operating system sets the page size.
The -xpagesize_stack option has no effect unless you use it at compile time and at link time.
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 Solaris command ppgsz(1) with the equivalent options before running the program. See the Solaris man pages for details.
This compiler option activates the precompiled-header feature. The precompiled-header feature may reduce compile time for applications whose source files share a common set of include files containing a large amount of source code. The compiler collects information about a sequence of header files from one source file, and then uses that information when recompiling that source file, and when compiling other source files that have the same sequence of headers. The information that the compiler collects is stored in a precompiled-header file. You can take advantage of this feature through the -xpch and -xpchstop options in combination with the #pragma hdrstop directive.
See Also:
When you specify -xpch=v, v can be collect:pch_filename or use:pch_filename. The first time you use -xpch, you must specify the collect mode. The compilation command that specifies -xpch=collect must only specify one source file. In the following example, the -xpch option creates a precompiled-header file called myheader.Cpch based on the source file a.cc:
CC -xpch=collect:myheader a.cc
A valid precompiled-header filename always has the suffix .Cpch. When you specify pch_filename, you can add the suffix or let the compiler add it for you. For example, if you specify cc -xpch=collect:foo a.cc, the precompiled-header file is called foo.Cpch.
When you create a precompiled-header file, pick a source file that contains the common sequence of include files across all the source files with which the precompiled-header file is to be used. The common sequence of include files must be identical across these source files. Remember, only one source filename value is legal in collect mode. For example, CC -xpch=collect:foo bar.cc is valid, whereas CC -xpch=collect:foo bar.cc foobar.cc is invalid because it specifies two source files.
Specify -xpch=use:pch_filename to use a precompiled-header file. You can specify any number of source files with the same sequence of include files as the source file that was 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.cc foobar.cc.
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, including differences caused by installed patches.
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 precompile 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.
In order to share a precompiled-header file across multiple source files, those source files must share a common set of include files as their initial sequence of tokens. This initial sequence of tokens is known as the viable prefix. The viable prefix must be interpreted consistently across all the source files that use the same precompiled-header file.
The viable prefix of a source file can only be comprised of comments and any of the following pre-processor directives:
#include #if/ifdef/ifndef/else/elif/endif #define/undef #ident (if identical, passed through as is) #pragma (if identical)
Any of these may reference macros. The #else, #elif, and #endif directives must match within 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 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 contain function and variable definitions.
The header file must not use __DATE__ and __TIME__. Use of these pre-processor macros can generate unpredictable results.
The header file must not contain #pragma hdrstop.
The header file must not use __LINE__ and __FILE__ in the viable prefix. It is allowed to use __LINE__ and __FILE__ in included headers.
Here are possible approaches to modifying your make files in order to incorporate -xpch into your builds.
You can use the implicit make rules by using an auxiliary CCFLAGS variable and the KEEP_STATE facility of both make and dmake. The precompiled header is produced as a separate, independent step.
.KEEP_STATE: CCFLAGS_AUX = -O etc CCFLAGS = -xpch=use:shared $(CCFLAGS_AUX) shared.Cpch: foo.cc $(CCC) -xpch=collect:shared $(CCFLAGS_AUX) foo.cc a.out: foo.o ping.o pong.o $(CCC) foo.o ping.o pong.o |
You can also define your own compilation rule instead of trying to use an auxiliary CCFLAGS.
.KEEP_STATE: .SUFFIXES: .o .cc %.o:%.cc shared.Cpch $(CCC) -xpch=use:shared $(CCFLAGS) -c $< shared.Cpch: foo.cc $(CCC) -xpch=collect:shared $(CCFLAGS) foo.cc -xe a.out: foo.o ping.o pong.o $(CCC) foo.o ping.o pong.o |
You can produce the precompiled header as a side effect of regular compilation, and without using KEEP_STATE, but this approach requires explicit compilation commands.
shared.Cpch + foo.o: foo.cc bar.h $(CCC) -xpch=collect:shared foo.cc $(CCFLAGS) -c ping.o: ping.cc shared.Cpch bar.h $(CCC) -xpch=use:shared ping.cc $(CCFLAGS) -c pong.o: pong.cc shared.Cpch bar.h $(CCC) -xpch=use:shared pong.cc $(CCFLAGS) -c a.out: foo.o ping.o pong.o $(CCC) foo.o ping.o pong.o |
Use the -xpchstop=file option to specify the last include file to be considered in creating the precompile-header file with the -xpch option. Using -xpchstop on the command line is equivalent to placing a hdrstop pragma after the first include-directive that references file in each of the source files that you specify with the cc command.
In the following example, the -xpchstop option specifies that the viable prefix for the precompiled header file ends with the include of projectheader.h. Therefore, privateheader.h is not a part of the viable prefix.
example% cat a.cc #include <stdio.h> #include <strings.h> #include "projectheader.h" #include "privateheader.h" . . . example% CC -xpch=collect:foo.Cpch a.cc -xpchstop=projectheader.h -c |
-xpch, pragma hdrstop
Compiles for profiling with the gprof profiler.
The– xpg option compiles self-profiling code to collect data for profiling with gprof. This option invokes a runtime recording mechanism that produces a gmon.out file when the program normally terminates.
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(1) or gprof(1) on 64 bit Solaris platforms or just gprof on 32 bit Solaris platforms and include approximate user CPU times. These times are derived from PC sample data (see pcsample(2)) for routines in the main executable and routines in shared libraries specified as linker arguments when the executable is linked. Other shared libraries (libraries opened after process startup using dlopen(3DL)) are not profiled.
On 32 bit Solaris systems, profiles generated using prof(1) are limited to routines in the executable. 32 bit shared libraries can be profiled by linking the executable with -xpg and using gprof(1).
The Solaris 10 software does not include system libraries compiled with -p. As a result, profiles collected on Solaris 10 platforms do not include call counts for system library routines.
If you compile and link separately, and you compile with –xpg, be sure to link with –xpg. See 3.3.3 Compile-Time and Link-Time Options for a complete list of options that must be specified at both compile time and link time.
–xprofile=p, the analyzer(1) man page, and the Performance Analyzer manual.
Use this option to help you debug code you are porting to a 64-bit environment. Specifically, this option warns against problems such as truncation of types (including pointers), sign extension, and changes to bit-packing that are common when code is ported from a 32-bit architecture such as V7 to a 64-bit architecture such as V9.
The following table lists the valid values for v:
Table A–43 The -xport64 Values
Values |
Meaning |
---|---|
no |
Generate no warnings related to the porting of code from a 32 bit environment to a 64 bit environment. |
implicit |
Generate warning only for implicit conversions. Do not generate warnings when an explicit cast is present. |
full |
Generate all warnings related to the porting of code from a 32 bit environment to a 64 bit environment. This includes warnings for truncation of 64-bit values, sign-extension to 64 bits under ISO value-preserving rules, and changes to packing of bitfields. |
If you do not specify -xport64, the default is -xport64=no. If you specify -xport64, but do not specify a flag, the default is -xport64=full.
This section provides examples of code that can cause truncation of type, sign extension and changes to bit-packing.
When you port to a 64-bit architecture such as V9, your data may be truncated. The truncation could happen implicitly, by assignment, at initialization, or by an explicit cast. The difference of two pointers is the typedef ptrdiff_t, which is a 32-bit integer type in 32-bit mode, and a 64-bit integer type in 64-bit mode. The truncation of a long to a smaller size integral type generates a warning as in the following example.
example% cat test1.c int x[10]; int diff = &x[10] - &x[5]; //warn example% CC -c -xarch=v9 -Qoption ccfe -xport64=full test1.c "test1.c", line 3: Warning: Conversion of 64-bit type value to "int" causes truncation. 1 Warning(s) detected. example% |
Use -xport64=implicit to disable truncation warnings in 64bit compilation mode when an explicit cast is the cause of data truncation.
example% CC -c -xarch=v9 -Qoption ccfe -xport64=implicit test1.c "test1.c", line 3: Warning: Conversion of 64-bit type value to "int" causes truncation. 1 Warning(s) detected. example% |
Another common issue that arises from porting to a 64-bit architecture is the truncation of a pointer. This is always an error in C++. An operation such as casting a pointer to an int which causes such a truncation results in an error diagnostic in V9 when you specify -xport64.
example% cat test2.c char* p; int main() { p =(char*) (((unsigned int)p) & 0xFF); // -xarch=v9 error return 0; } example% CC -c -xarch=v9 -Qoption ccfe -xport64=full test2.c "test2.c", line 3: Error: Cannot cast from char* to unsigned. 1 Error(s) detected. example% |
You can also use the -xport64 option to check for situations in which the normal ISO C value-preserving rules allow for the extension of the sign of a signed-integral value in an expression of unsigned-integral type. Such sign extensions can cause subtle run-time bugs.
example% cat test3.c int i= -1; void promo(unsigned long l) {} int main() { unsigned long l; l = i; // warn promo(i); // warn } example% CC -c -xarch=v9 -Qoption ccfe -xport64=full test3.c "test3.c", line 6: Warning: Sign extension from "int" to 64-bit integer. "test3.c", line 7: Warning: Sign extension from "int" to 64-bit integer. 2 Warning(s) detected. |
Use -xport64 to generate warnings against long bitfields. In the presence of such bitfields, packing of the bitfields might drastically change. Any program which relies on assumptions regarding the way bitfields are packed needs to be reviewed before a successful port can take place to a 64-bit architecture.
example% cat test4.c #include <stdio.h> union U { struct S { unsigned long b1:20; unsigned long b2:20; } s; long buf[2]; } u; int main() { u.s.b1 = 0XFFFFF; u.s.b2 = 0XFFFFF; printf(" u.buf[0] = %lx u.buf[1] = %lx\n", u.buf[0], u.buf[1]); return 0; } example% |
Output in V9:
example% u.buf[0] = ffffffffff000000 u.buf[1] = 0 |
Note that warnings are generated only when you compile in 64-bit mode by specifying options such as -m64.
Enable prefetch instructions on those architectures that support prefetch.
Explicit prefetching should only be used under special circumstances that are supported by measurements.
a must be one of the following values.
Table A–44 The -xprefetch Values
Value |
Meaning |
---|---|
auto |
Enable automatic generation of prefetch instructions |
no%auto |
Disable automatic generation of prefetch instructions |
explicit |
(SPARC) Enable explicit prefetch macros |
no%explicit |
(SPARC) Disable explicit prefetch macros |
latx:factor |
Adjust the compiler’s assumed prefetch-to-load and prefetch-to-store latencies by the specified factor. You can only combine this flag with -xprefetch=auto. The factor must be a positive floating-point or integer number. |
yes |
Obsolete, do not use. Use -xprefetch=auto,explicit instead. |
no |
Obsolete, do not use. Use -xprefetch=no%auto,no%explicit instead. |
With -xprefetch, -xprefetch=auto, and -xprefetch=yes, the compiler is free to insert prefetch instructions into the code it generates. This may result in a performance improvement on architectures that support prefetch.
If you are running computationally intensive codes on large multiprocessors, you might find it advantageous to use -xprefetch=latx:factor. This option instructs the code generator to adjust the default latency time between a prefetch and its associated load or store by the specified factor.
The prefetch latency is the hardware delay between the execution of a prefetch instruction and the time the data being prefetched is available in the cache. The compiler assumes a prefetch latency value when determining how far apart to place a prefetch instruction and the load or store instruction that uses the prefetched data.
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 data sets that reside entirely within the external cache, you may be able to obtain better performance by decreasing the prefetch latency values. To decrease the values, use a factor that is less than 1 (one).
To use the -xprefetch=latx:factor option, start with a factor value near 1.0 and run performance tests against the application. Then increase or decrease the factor, as appropriate, and run the performance tests again. Continue adjusting the factor and running the performance tests until you achieve optimum performance. When you increase or decrease the factor in small steps, you will see no performance difference for a few steps, then a sudden difference, then it will level off again.
If -xprefetch is not specified, -xprefetch=auto,explicit is assumed.
If only -xprefetch is specified, -xprefetch=auto,explicit is assumed.
The default of no%auto is assumed unless explicitly overridden with the use of -xprefetch without any arguments or with an argument of auto or yes. For example, -xprefetch=explicit is the same as -xprefetch=explicit,no%auto.
The default of explicit is assumed unless explicitly overridden with an argument of no%explicit or an argument of no. For example, -xprefetch=auto is the same as -xprefetch=auto,explicit.
If automatic prefetching is enabled, such as with -xprefetch or -xprefetch=yes, but a latency factor is not specified, then -xprefetch=latx:1.0 is assumed.
This option accumulates instead of overrides.
The sun_prefetch.h header file provides the macros for specifying explicit prefetch instructions. The prefetches will be approximately at the place in the executable that corresponds to where the macros appear.
To use the explicit prefetch instructions, you must be on the correct architecture, include sun_prefetch.h, and either exclude -xprefetch from the compiler command or use -xprefetch, -xprefetch=auto,explicit, -xprefetch=explicit or -xprefetch=yes.
If you call the macros and include the sun_prefetch.h header file, but pass -xprefetch=no%explicit or -xprefetch=no, the explicit prefetches will not appear in your executable.
The use of latx:factor is valid only when automatic prefetching is enabled. That is, latx:factor is ignored unless you use it in conjunction with yes or auto, as in -xprefetch=yes,latx:factor.
Explicit prefetching should only be used under special circumstances that are supported by measurements.
Because the compiler tunes the prefetch mechanism for optimal performance across a wide range of machines and applications, you should only use -xprefetch=latx:factor when the performance tests indicate there is a clear benefit. The assumed prefetch latencies may change from release to release. Therefore, retesting the effect of the latency factor on performance whenever switching to a different release is highly recommended.
Where 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 the -xprefetch_level=i option to control the aggressiveness of the automatic insertion of prefetch instructions as determined with -xprefetch=auto. The compiler becomes more aggressive, or in other words, introduces more prefetches, with each higher, level of -xprefetch_level.
The appropriate value for -xprefetch_level depends on the number of cache misses your application has. Higher -xprefetch_level values have the potential to improve the performance of applications with a high number of cache misses.
i must be one of 1, 2, or 3.
Table A–45 The -xprefecth_level Values
Value |
Meaning |
---|---|
1 |
Enables automatic generation of prefetch instructions. |
2 |
Targets additional loops, beyond those targeted at -xprefetch_level=1, for prefetch insertion. Additional prefetches may be inserted beyond those that were inserted at -xprefetch_level=1. |
3 |
Targets additional loops, beyond those targeted at -xprefetch_level=2, for prefetch insertion. Additional prefetches may be inserted beyond those that were inserted at -xprefetch_level=2. |
The default is -xprefetch_level=1 when you specify -xprefetch=auto.
This option is effective only when it is compiled with -xprefetch=auto, with optimization level 3 or greater (-xO3), and on a platform that supports prefetch (v9, v9a, v9b, generic64, native64).
Use this option to first collect and save execution-frequency data so that you can then use the data in subsequent runs to improve performance. This option is only valid when you specify optimization at level -xO2 or above.
Compiling with high optimization levels (for example -xO5) is enhanced by providing the compiler with runtime-performance feedback. In order to produce runtime-performance feedback, you must compile with -xprofile=collect, run the executable against a typical data set, and then recompile at the highest optimization level and with -xprofile=use.
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 optimization at level -xO2 or above.
p must be one of the following values.
collect[:name]
Collects and saves execution frequency for later use by the optimizer with –xprofile=use. The compiler generates code to measure statement execution frequency.
Do not specify -xprofile=collect when you build shared libraries on Linux.
The name is the name of the program that is being analyzed. The name is optional and, if not specified, is assumed to be a.out.
At runtime, a program compiled with –xprofile=collect:name creates the subdirectory name.profile to hold the runtime feedback information. Data is written to the file feedback in this subdirectory. You can use the $SUN_PROFDATA and $SUN_PROFDATA_DIR environment variables to change the location of the feedback information. See the Interactions section for more information.
If you run the program several times, the execution frequency data accumulates in the feedback file; that is, output from prior runs is not lost.
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 3.3.3 Compile-Time and Link-Time Options for a complete list of options that must be specified at both compile time and link time.
use[:name]
The program is optimized by using the executions-frequency data generated and saved in the feedback files from a previous execution of the program that was compiled with –xprofile=collect.
The name is the name of the executable that is being analyzed. The name is optional and, if not specified, is assumed to be a.out.
Except for the -xprofile option which changes from -xprofile=collect to -xprofile=use, 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:name, the same program name name must appear in the optimizing compilation: -xprofile=use:name.
The association between an object file and its profile data is based on the UNIX pathname of the object file when it is compiled with -xprofile=collect. In some circumstances, the compiler will not associate an object file with its profile data: the object file has no profile data because it was not previously compiled with -xprofile=collect, the object file is not linked in a program with -xprofile=collect, the program has never been executed.
The compiler can also become confused if an object file was previously compiled in a different directory with -xprofile=collect and this object file shares a common basename with other object files compiled with -xprofile=collect but they cannot be uniquely identified by the names of their containing directories. In this case, even if the object file has profile data, the compiler will not be able to find it in the feedback directory when the object file is recompiled with -xprofile=use.
All of these situations cause the compiler to loose the association between an object file and its profile data. Therefor, if an object file has profile data but the compiler is unable to associate it with the object file’s pathname when you specify -xprofile=use, use the -xprofile_pathmap option to identify correct directory. See A.2.167 -xprofile_pathmap
tcov
Basic block coverage analysis using the new style tcov.
This option is the new style of basic block profiling for tcov. It has similar functionality to the– xa option, but correctly collects data for programs that have source code in header files or make use of C++ templates. Code instrumentation is similar to that of the -xa option, but.d files are no longer generated. Instead, a single file is generated, the name of which is based on the final executable. For example, if the program is run out of /foo/bar/myprog.profile, then the data file is stored in /foo/bar/myprog.profile/myprog.tcovd.
When running tcov, you must pass it the– x option to force it to use the new style of data. If you do not pass -x, tcov uses the old .d files by default, and produces unexpected output.
Unlike the –xa option, the TCOVDIR environment variable has no effect at compile time. However, its value is used at program runtime.
The –xprofile=tcov and the -xa options are compatible in a single executable. That is, you can link a program that contains some files that have been compiled with -xprofile=tcov and other files compiled with -xa. You cannot compile a single file with both options.
The code coverage report produced by -xprofile=tcov can be unreliable if there is inlining of functions due to the use of -xinline or -xO4.
You can set the environment variables $SUN_PROFDATA and $SUN_PROFDATA_DIR to control where a program that is compiled with -xprofile=collect puts the profile data. If these variables are not set, the profile data is written to name.profile/feedback in the current directory (name is the name of the executable or the name specified in the -xprofile=collect:name flag). If these variables are set, the -xprofile=collect data is written to $SUN_PROFDATA_DIR/$SUN_PROFDATA.
The $SUN_PROFDATA and $SUN_PROFDATA_DIR environment variables similarly control the path and names of the profile data files written by tcov. See the tcov(1) man page for more information.
If you compile and link in separate steps, the same -xprofile option must appear in both the compile command and the link command. Including -xprofile in one step and excluding it from the other step will not affect the correctness of the program, but you will not be able to do profiling.
-xa, tcov(1) man page, Program Performance Analysis Tools.
(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.cc t2.cc example% a.out // run collects feedback data example% CC -xO5 -xprofile=use -xprofile_ircache t1.cc t2.cc |
(SPARC) Use the -xprofile_pathmap=collect_prefix:use_prefix 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.
Controls scratch register usage.
The compiler can generate faster code if it has more registers available for temporary storage (scratch registers). This option makes available additional scratch registers that might not always be appropriate.
r must be one of the following values. The meaning of each value depends upon the -m32|-m64 setting.
Table A–46 The -xregs Values
The SPARC default is -xregs=appl,float.
The x86 default is -xregs=no%frameptr -xregs=frameptr in included in the expansion of -fast.
To compile an application program using all available scratch registers, use -xregs=appl,float.
To compile non-floating-point code that is sensitive to context switch, use -xregs=no%appl,no%float.
SPARC V8 and SPARC V9 ABI
(SPARC) Treats pointer-valued function parameters as restricted pointers . f must be one of the following values:
Table A–47 The -xrestrict Values
Value |
Meaning |
---|---|
%all |
All pointer parameters in the entire file are treated as restricted. |
%none |
No pointer parameters in the file are treated as restricted. |
%source |
Only functions defined within the main source file are restricted. Functions defined within included files are not restricted. |
fn[,fn...] |
A comma-separated list of one or more function names. If you specify a function list, the compiler treats pointer parameters in the specified functions as restricted; Refer to the following section, A.2.169.1 Restricted Pointers, for more information. |
This command-line option can be used on its own, but it is best used with optimization. For example, the command:
%CC -xO3 -xrestrict=%all prog.cc |
treats all pointer parameters in the file prog.c as restricted pointers. The command:
%CC -xO3 -xrestrict=agc prog.cc |
treats all pointer parameters in the function agc in the file prog.c as restricted pointers.
The default is %none; specifying -xrestrict is equivalent to specifying -xrestrict=%source.
In order for a compiler to effectively perform parallel execution of a loop, it needs to determine if certain lvalues designate distinct regions of storage. Aliases are lvalues whose regions of storage are not distinct. Determining if two pointers to objects are aliases is a difficult and time consuming process because it could require analysis of the entire program. Consider function vsq() below:
void vsq(int n, double * a, double * b) { int i; for (i=0; i<n; i++) { b[i] = a[i] * a[i]; } } |
The compiler can parallelize the execution of the different iterations of the loops if it knows that pointers a and b access different objects. If there is an overlap in objects accessed through pointers a and b then it would be unsafe for the compiler to execute the loops in parallel. At compile time, the compiler does not know if the objects accessed by a and b overlap by simply analyzing the function vsq(); the compiler may need to analyze the whole program to get this information.
Restricted pointers are used to specify pointers which designate distinct objects so that the compiler can perform pointer alias analysis. The following is an example of function vsq() in which function parameters are declared as restricted pointers:
void vsq(int n, double * restrict a, double * restrict b) |
Pointers a and b are declared as restricted pointers, so the compiler knows that a and b point to distinct regions of storage. With this alias information, the compiler is able to parallelize the loop.
The keyword restrict is a type-qualifier, like volatile, and it shall only qualify pointer types. restrict is recognized as a keyword when you use -xc99=all (except with -Xs). There are situations in which you may not want to change the source code. You can specify that pointer-valued function-parameters be treated as restricted pointers by using the following command line option:
-xrestrict=[func1,…,funcn] |
If a function list is specified, then pointer parameters in the specified functions are treated as restricted; otherwise, all pointer parameters in the entire C file are treated as restricted. For example, -xrestrict=vsq, qualifies the pointers a and b given in the first example of the function vsq() with the keyword restrict.
It is critical that you use restrict correctly. If pointers qualified as restricted pointers point to objects which are not distinct, the compiler can incorrectly parallelize loops resulting in undefined behavior. For example, assume that pointers a and b of function vsq() point to objects which overlap, such that b[i] and a[i+1] are the same object. If a and b are not declared as restricted pointers the loops will be executed serially. If a and b are incorrectly qualified as restricted pointers the compiler may parallelize the execution of the loops, which is not safe, because b[i+1] should only be computed after b[i] is computed.
Allows debugging by dbx without object (.o) files.
This option causes all the debug information to be copied into the executable. This has little impact on dbx performance or the run-time performance of the program, but it does take more disk space.
SPARC: Allows the compiler to assume that no memory protection violations occur.
This option allows the compiler to use the non-faulting load instruction in the SPARC V9 architecture.
This option takes effect only when used with optimization level -xO5 and one of the following -xarch values: sparc, sparcvis, or sparcvis2 for both -m32 and -m64.
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.
Deprecated - do not use. The source browser functionality is obsolete.
Deprecated - do not use. The source browser functionality is obsolete.
SPARC: Does not allow optimizations that increase code size.
Specifies the target platform for instruction set and optimization.
The performance of some programs can benefit by providing the compiler with an accurate description of the target computer hardware. When program performance is critical, the proper specification of the target hardware could be very important. This is especially true when running on the newer SPARC processors. However, for most programs and older SPARC processors, the performance gain is negligible and a generic specification is sufficient.
The value of t must be one of the following: native, generic, native64, generic64, system-name.
Each specific value for -xtarget expands into a specific set of values for the -xarch, -xchip, and -xcache options. Use the -xdryrun option to determine the expansion of -xtarget=native on a running system.
For example, -xtarget=sun4/15 is equivalent to: -xarch=v8a -xchip=micro -xcache=2/16/1.
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.
Value |
Meaning |
---|---|
native |
Gets the best performance on the host system. The compiler generates code optimized for the host system. It determines the available architecture, chip, and cache properties of the machine on which the compiler is running. |
native64 |
Gets the best performance for 64-bit object binaries on the host system. The compiler generates 64-bit object binaries optimized for the host system. It determines the available 64-bit architecture, chip, and cache properties of the machine on which the compiler is running. |
generic |
This is the default value. Gets the best performance for generic architecture, chip, and cache. |
generic64 |
Sets the parameters for the best performance of 64-bit object binaries over most 64-bit platform architectures. |
system-name |
Gets the best performance for the specified platform. Select a system name from the following lists for which represents the actual system you are targeting. |
Compiling for 64-bit Solaris software on SPARC or UltraSPARC V9 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=ultra... -m64 otherwise the compiler uses a 32-bit memory model.
Table A–49 -xtargetExpansions on SPARC Architecture
-xtarget= |
-xarch |
-xchip |
-xcache |
---|---|---|---|
generic |
generic |
generic |
generic |
cs6400 |
v8plusa |
super |
16/32/4:2048/64/1 |
entr150 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr2 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr2/1170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr2/1200 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr2/2170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr2/2200 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr3000 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr4000 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr5000 |
v8plusa |
ultra |
16/32/1:512/64/1 |
entr6000 |
v8plusa |
ultra |
16/32/1:512/64/1 |
sc2000 |
v8plusa |
super |
16/32/4:2048/64/1 |
solb5 |
v7 |
old |
128/32/1 |
solb6 |
v8 |
super |
16/32/4:1024/32/1 |
ss1 |
v7 |
old |
64/16/1 |
ss10 |
v8 |
super |
16/32/4 |
ss10/20 |
v8 |
super |
16/32/4 |
ss10/30 |
v8 |
super |
16/32/4 |
ss10/40 |
v8 |
super |
16/32/4 |
ss10/402 |
v8 |
super |
16/32/4 |
ss10/41 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/412 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/50 |
v8 |
super |
16/32/4 |
ss10/51 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/512 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/514 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/61 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/612 |
v8 |
super |
16/32/4:1024/32/1 |
ss10/71 |
v8 |
super2 |
16/32/4:1024/32/1 |
ss10/712 |
v8 |
super2 |
16/32/4:1024/32/1 |
ss10/hs11 |
v8 |
hyper |
256/64/1 |
ss10/hs12 |
v8 |
hyper |
256/64/1 |
ss10/hs14 |
v8 |
hyper |
256/64/1 |
ss10/hs21 |
v8 |
hyper |
256/64/1 |
ss10/hs22 |
v8 |
hyper |
256/64/1 |
ss1000 |
v8 |
super |
16/32/4:1024/32/1 |
ss1plus |
v7 |
old |
64/16/1 |
ss2 |
v7 |
old |
64/32/1 |
ss20 |
v8 |
super |
16/32/4:1024/32/1 |
ss20/151 |
v8 |
hyper |
512/64/1 |
ss20/152 |
v8 |
hyper |
512/64/1 |
ss20/50 |
v8 |
super |
16/32/4 |
ss20/502 |
v8 |
super |
16/32/4 |
ss20/51 |
v8 |
super |
16/32/4:1024/32/1 |
ss20/512 |
v8 |
super |
16/32/4:1024/32/1 |
ss20/514 |
v8 |
super |
16/32/4:1024/32/1 |
ss20/61 |
v8 |
super |
16/32/4:1024/32/1 |
ss20/612 |
v8 |
super |
16/32/4:1024/32/1 |
ss20/71 |
v8 |
super2 |
16/32/4:1024/32/1 |
ss20/712 |
v8 |
super2 |
16/32/4:1024/32/1 |
ss20/hs11 |
v8 |
hyper |
256/64/1 |
ss20/hs12 |
v8 |
hyper |
256/64/1 |
ss20/hs14 |
v8 |
hyper |
256/64/1 |
ss20/hs21 |
v8 |
hyper |
256/64/1 |
ss20/hs22 |
v8 |
hyper |
256/64/1 |
ss2p |
v7 |
powerup |
64/32/1 |
ss4 |
v8a |
micro2 |
8/16/1 |
ss4/110 |
v8a |
micro2 |
8/16/1 |
ss4/85 |
v8a |
micro2 |
8/16/1 |
ss5 |
v8a |
micro2 |
8/16/1 |
ss5/110 |
v8a |
micro2 |
8/16/1 |
ss5/85 |
v8a |
micro2 |
8/16/1 |
ss600/120 |
v7 |
old |
64/32/1 |
ss600/140 |
v7 |
old |
64/32/1 |
ss600/41 |
v8 |
super |
16/32/4:1024/32/1 |
ss600/412 |
v8 |
super |
16/32/4:1024/32/1 |
ss600/51 |
v8 |
super |
16/32/4:1024/32/1 |
ss600/512 |
v8 |
super |
16/32/4:1024/32/1 |
ss600/514 |
v8 |
super |
16/32/4:1024/32/1 |
ss600/61 |
v8 |
super |
16/32/4:1024/32/1 |
ss600/612 |
v8 |
super |
16/32/4:1024/32/1 |
sselc |
v7 |
old |
64/32/1 |
ssipc |
v7 |
old |
64/16/1 |
ssipx |
v7 |
old |
64/32/1 |
sslc |
v8a |
micro |
2/16/1 |
sslt |
v7 |
old |
64/32/1 |
sslx |
v8a |
micro |
2/16/1 |
sslx2 |
v8a |
micro2 |
8/16/1 |
ssslc |
v7 |
old |
64/16/1 |
ssvyger |
v8a |
micro2 |
8/16/1 |
sun4/110 |
v7 |
old |
2/16/1 |
sun4/15 |
v8a |
micro |
2/16/1 |
sun4/150 |
v7 |
old |
2/16/1 |
sun4/20 |
v7 |
old |
64/16/1 |
sun4/25 |
v7 |
old |
64/32/1 |
sun4/260 |
v7 |
old |
128/16/1 |
sun4/280 |
v7 |
old |
128/16/1 |
sun4/30 |
v8a |
micro |
2/16/1 |
sun4/330 |
v7 |
old |
128/16/1 |
sun4/370 |
v7 |
old |
128/16/1 |
sun4/390 |
v7 |
old |
128/16/1 |
sun4/40 |
v7 |
old |
64/16/1 |
sun4/470 |
v7 |
old |
128/32/1 |
sun4/490 |
v7 |
old |
128/32/1 |
sun4/50 |
v7 |
old |
64/32/1 |
sun4/60 |
v7 |
old |
64/16/1 |
sun4/630 |
v7 |
old |
64/32/1 |
sun4/65 |
v7 |
old |
64/16/1 |
sun4/670 |
v7 |
old |
64/32/1 |
sun4/690 |
v7 |
old |
64/32/1 |
sun4/75 |
v7 |
old |
64/32/1 |
ultra |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra1/140 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra1/170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra1/200 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra2 |
v8plusa |
ultra2 |
16/32/1:512/64/1 |
ultra2/1170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra2/1200 |
v8plusa |
ultra |
16/32/1:1024/64/1 |
ultra2/1300 |
v8plusa |
ultra2 |
16/32/1:2048/64/1 |
ultra2/2170 |
v8plusa |
ultra |
16/32/1:512/64/1 |
ultra2/2200 |
v8plusa |
ultra |
16/32/1:1024/64/1 |
ultra2/2300 |
v8plusa |
ultra2 |
16/32/1:2048/64/1 |
ultra2e |
v8plusa |
ultra2e |
16/32/1:256/64/4 |
ultra2i |
v8plusa |
ultra2i |
16/32/1:512/64/1 |
ultra3 |
v8plusa |
ultra3 |
64/32/4:8192/512/1 |
ultra3cu |
v8plusa |
ultra3cu |
64/32/4:8192/512/2 |
ultra3i |
v8plusa |
ultra3i |
64/32/4:1024/64/4 |
ultra4 |
v8plusa |
ultra4 |
64/32/4:8192/128/2 |
ultra4plus |
v8plusa |
ultra4plus |
64/32/4:2048/64/4:32768/64/4 |
ultraT1 |
v8plusa |
ultraT1 |
8/16/4/4:3072/64/12/32 |
ultraT2 |
sparcvis2 |
ultraT2 |
8/16/4:4096/64/16 |
sparc64vi |
sparcfmaf |
sparc64vi |
128/64/2:5120/64/10 |
See A.2.111 –xcache=c for more information on the cache properties of the UltraSPARC IVplus, UltraSPARC T1, and UltraSPARC T2 chips. |
Compiling for 64-bit 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.
Table A–50 -xtarget Values on x86 Platforms
-xtarget= |
-xarch |
-xchip |
-xcache |
---|---|---|---|
generic |
generic |
generic |
generic |
opteron |
sse2 |
opteron |
64/64/2:1024/64/16 |
386 |
pentium |
generic |
|
pentium_pro |
pentium_pro |
pentium_pro |
generic |
pentium3 |
sse |
pentium3 |
16/32/4:256/32/4 |
pentium4 |
sse2 |
pentium4 |
8/64/4:256/128/8 |
On both SPARC and x86 devices, if –xtarget is not specified, –xtarget=generic is assumed.
The –xtarget option is a macro that permits a quick and easy specification of the -xarch, –xchip, and –xcache combinations that occur on commercially purchased platforms. The only meaning of –xtarget is in its expansion.
-xtarget=sun4/15 means -xarch=v8a -xchip=micro -xcache=2/16/1.
Compilation for SPARC V9 architecture indicated by the -xarch=v9|v9a|v9b option. Setting –xtarget=ultra or ultra2 is not necessary or sufficient. If -xtarget is specified, the -xarch=v9, v9a, or v9b option must appear after the -xtarget. For example:
-xarch=v9 -xtarget=ultra |
expands to the following and reverts the -xarch value to v8.
-xarch=v9 -xarch=v8 -xchip=ultra -xcache=16/32/1:512/64/1 |
The correct method is to specify -xarch after -xtarget. For example:
–xtarget=ultra -xarch=v9 |
When you compile and link in separate steps, you must use the same -xtarget settings in the compile step and the link step.
Specify -xthreadvar to control the implementation of thread local variables. Use this option 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, specify -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 4.2 Thread-Local Storage.
o must be one of the following:
Table A–51 The -xthreadvar Values
Value |
Meaning |
---|---|
[no%]dynamic |
[Do not] Compile variables for dynamic loading. 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.
Using thread variables on different versions of Solaris software requires different options on the command line.
On Solaris 8 software, objects that use __thread must be compiled with -mt and must be linked with -mt -L/usr/lib/lwp -R/usr/lib/lwp.
On Solaris 9 software, objects that use __thread must be compiled and linked with -mt.
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.
-xcode, -KPIC, -Kpic
Causes the CC driver to report execution time for the various compilation passes.
Enables or disables recognition of trigraph sequences as defined by the ISO/ANSI C standard.
If your source code has a literal string containing question marks (?) that the compiler is interpreting as a trigraph sequence, you can use the -xtrigraph=no suboption to turn off the recognition of trigraph sequences.
You can specify one of the following two values for -xtrigraphs:
Table A–52 The -xtrigraphs Values
Value |
Meaning |
---|---|
yes |
Enables recognition of trigraph sequences throughout the compilation unit |
no |
Disables recognition of trigraph sequences throughout the compilation unit |
When you do not include the -xtrigraphs option on the command line, the compiler assumes -xtrigraphs=yes.
If only -xtrigraphs is specified, the compiler assumes -xtrigraphs=yes.
Consider the following example source file named trigraphs_demo.cc.
#include <stdio.h> int main () { (void) printf("(\?\?) in a string appears as (??)\n"); return 0; } |
Here is the output if you compile this code with -xtrigraphs=yes.
example% CC -xtrigraphs=yes trigraphs_demo.cc example% a.out (??) in a string appears as (] |
Here is the output if you compile this code with -xtrigraphs=no.
example% CC -xtrigraphs=no trigraphs_demo.cc example% a.out (??) in a string appears as (??) |
For information on trigraphs, see the C User’s Guide chapter about transitioning to ANSI/ISO C.
Enables unrolling of loops where possible.
This option specifies whether or not the compiler optimizes (unrolls) loops.
When n is 1, it is a suggestion to the compiler to not unroll loops.
When n is an integer greater than 1, -unroll=n causes the compiler to unroll loops n times.
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++.
Not all files have to be compiled with this option.
Specify -xustr=ascii_utf16_ushort if you need to support an internationalized application that uses ISO10646 UTF-16 string literals. You can turn off compiler recognition of U"ASCII_string" string literals by specifying -xustr=no. The right-most instance of this option on the command line overrides all previous instances.
You can specify -xustr=ascii_ustf16_ushort without also specifying a U"ASCII_string" string literal. It is not an error to do so.
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.
The following example shows a string literal in quotes that is prepended by U. It also shows a command line that specifies -xustr
example% cat file.cc const unsigned short *foo = U"foo"; const unsigned short bar[] = U"bar"; const unsigned short *fun() {return U"fun"}; example% CC -xustr=ascii_utf16_ushort file.cc -c |
Sixteen-bit character-literals are not supported.
Enables automatic generation of calls to the vector library functions and/or the generation of the SIMD (Single Instruction Multiple Data) instructions. You must use default rounding mode by specifying -fround=nearest when you use this option.
a is the equivalent of the following:
Table A–53 The -xvector Flags
Value |
Meaning |
---|---|
[no%]lib |
Does [not] enable 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. |
[no%]simd |
Does [not] direct the compiler to use the native x86 SSE SIMD instructions to improve performance of certain loops. The compiler can only accept this switch if the target architecture supports SIMD instructions. For example, you must specify -xarch=amd64, -xarch=amd64a or -xarch=generic64. You must also specify an optimization level of -xO3 or above as well as -xdepend when you specify -xvector=simd. |
yes |
This option is deprecated, specify -xvector=lib instead. |
no |
This option is deprecated, specify -xvector=none instead. |
The default is -xvector=%none. If you specify -xvector, but do not provide a flag, the compiler assumes -xvector=lib.
If you use -xvector on the command line without previously specifying -xdepend, -xvector triggers -xdepend. The -xvector option also raises the optimization level to -x03 if optimization is not specified or optimization is set lower than -x03.
The compiler includes the libmvec libraries in the load step.
If you compile and link with separate commands, be sure to use -xvector in the linking CC command. See 3.3.3 Compile-Time and Link-Time Options for a complete list of options that must be specified at both compile time and link time.
(SPARC) Use the -xvis=[yes|no] command when you are using the assembly-language templates defined in the VISTM instruction-set Software Developers Kit (VSDK).
The VIS instruction set is an extension to the SPARC v9 instruction set. Even though the UltraSPARC processors are 64-bit, there are many cases, especially in multimedia applications, when the data are limited to eight or 16 bits in size. The VIS instructions can process four 16-bit data with one instruction so they greatly improve the performance of applications that handle new media such as imaging, linear algebra, signal processing, audio, video and networking.
The default is -xvis=no. Specifying -xvis is equivalent to specifying -xvis=yes.
For more information on the VSDK, see http://www.sun.com/processors/vis/.
Converts all warnings to errors by returning nonzero exit status.
Specifies a new path for the location of component c.
If the location of a component is specified, then the new path name for the component is path/component_name. This option is passed to ld.
c must be one of the following values:
Table A–54 The -Y Flags
Value |
Meaning |
---|---|
P |
Changes the default directory for cpp. |
0 |
Changes the default directory for ccfe. |
a |
Changes the default directory for fbe. |
2 (SPARC) |
Changes the default directory for iropt. |
c (SPARC) |
Changes the default directory for cg. |
O (SPARC) |
Changes the default directory for ipo. |
k |
Changes the default directory for CClink. |
l |
Changes the default directory for ld. |
f |
Changes the default directory for c++filt. |
m |
Changes the default directory for mcs. |
u (x86) |
Changes the default directory for ube. |
i (x86) |
Changes the default directory for ube_ipa. |
h (x86) |
Changes the default directory for ir2hf. |
A |
Specifies a directory to search for all compiler components. If a component is not found in path, the search reverts to the directory where the compiler is installed. |
P |
Adds path to the default library search path. This path will be searched before the default library search paths. |
S |
Changes the default directory for startup object files |
You can have multiple -Y options on a command line. If more than one -Y option is applied to any one component, then the last occurrence holds.
Solaris Linker and Libraries Guide
Link editor option. For more information, see the ld(1) man page and the Solaris Linker and Libraries Guide.