Previous Next Contents Index Doc Set Home


Using the C++ Compiler

2

This chapter demonstrates how to compile and link your code, as well as how to use compiler pragmas and options.

Compiler Commands

Before using the CC command, insert the name of the directory in which you have chosen to install the C++ compiler at the beginning of your search path. The default path is:

/opt/SUNWspro/bin

To compile a simple program, myprog, enter the following command:

% CC myprog.cc -o myprog
The resulting executable file is called myprog because this command line uses the -o name argument. Without that argument, the executable file has the default name, a.out.

The possible file name extensions for the source file are: .c, .C, .cc, .cpp, or .cxx.

Command Syntax

The general syntax of the compiler command line is:

CC [options] list_of_files  [-lx]

Items in square brackets indicate optional parameters. The brackets are not part of the command. The options are a list of option keywords prefixed by dash (-). Some keyword options take the next item in the list as an argument. The list_of_files is a list of source, object, or library file names separated by blanks.

Source files, object files, and libraries are compiled and linked in the order in which they appear on the command line.

Compiling and Linking

The sample program testr, used in Appendix A, consists of two modules: the main program module, testr.cc, and the string class module, str.cc and str.h.

When you have a second module like the string class module, both the implementation part of the second module and the main program module must include the header file for the second module. For example, testr.cc and str.cc include the header file, str.h, with a line like:

#include "str.h"
If there is no object file for the second module, you can compile the second module and link it with the program with a command line like:

% CC testr.cc str.cc -o testr
Alternately, you can create an object file for the second module with this command line: 

% CC -c str.cc
This line does not invoke the linker and results in an object file called str.o.

When there is an object file for the unit, you can compile the program and link it with the unit, as follows:

% CC str.o testr.cc -o testr

Compatibility Between C++ 4.0.1 and C++ 4.1

The object files produced by C++ 4.1 and C++ 4.0.1 are binary compatible for most cases. That is, object files created by C++ 4.0.1 can be linked using the C++ 4.1 compiler, and object files created by C++ 4.1 can be linked using the C++ 4.0.1 compiler without any problems. However, this may not be true if you are using exceptions and link statically with libC. Note the following cases:

Compatibility Between C++ 4.1 and C++ 4.2

C++ 4.1 and C++ 4.2 are fully compatible, with one notable exception. If code is compiled with C++ 4.2 and uses the newer cast operations, including runtime type information (RTTI), this code cannot be linked with older versions of libC. This is because runtime functions that are missing in the older versions of the C++ library handle dynamic_cast and some typeid() calls. For code requiring this functionality, you must install the libC.so.5 patch (SPARC: 101242-11; x86: 102859-02; PowerPC: 103721-01).

Multiple File Extensions

The C++ compiler accepts file extensions other than .cc. You can incorporate different file extensions (suffixes) into C++ in two ways: by adding them to the system default makefile or to your makefile.

Suffix Additions to the System Default Makefile

You can add suffixes to C++ by adding them to the system default makefile: /usr/share/lib/make/make.rules

Here is an example of how to add suffixes.

1. Become root.

2. If you use Solaris 2.x, .C and .C~ are already in the SUFFIXES macro.

3. If they are not already present, add these lines to the end of the system default makefile (indented lines are tabbed):

.C: 

    $(LINK.cc) -o $@ $< $(LDLIBS) 

.C.o: 

    $(COMPILE.cc) $(OUTPUT_OPTION) $< 

.C.a: 

    $(COMPILE.cc) -o $% $< 

    $(AR) $(ARFLAGS) $@ $% 

    $(RM) $%

Note - Since .c is supported as a C-language suffix, it is the one suffix that cannot be added to the SUFFIXES macro to support C++. Write explicit rules in your own makefile to handle C++ files with a .c suffix.

Suffix Additions to Your Makefile

The other method of including different file extensions into C++ is to add them to your makefile.The following example adds .C as a valid suffix for C++ files.

1. Add the SUFFIXES macro to your makefile: 

	.SUFFIXES: .C .C~

This line can be located anywhere in the makefile.

2. Add these lines to your makefile (indented lines are tabbed):

.C:

    $(LINK.cc) -o $@ $< $(LDLIBS)

.C.o:

    $(COMPILE.cc) $(OUTPUT_OPTION) $<

.C.a:

    $(COMPILE.cc) -o $% $<

    $(AR) $(ARFLAGS) $@ $%

    $(RM) $%

Components

CC uses the following components to compile C++ source code to object code.

For SPARC, Intel, and PowerPC Platforms:
For SPARC platforms:
For Intel and PowerPC platforms:

Pragmas

A pragma, also called a compiler directive, is a special comment that gives preprocessing instructions to the compiler. Preprocessing lines of the form

#pragma preprocessor-token
specify implementation-defined actions.

The pragmas discussed in this section are recognized in the compilation system. The compiler ignores unrecognized pragmas.

Note - #pragmas in template definition files are ignored.

#pragma align

Use #pragma align integer(variable[,variable]...)to make the parameter variables memory-aligned to integer bytes, overriding the default. The following limitations apply:

#pragma init and #pragma fini

Use #pragma init(identifier [ , identifier ] ...)to mark identifier as an initialization function. Such functions are expected to be of type void, to accept no arguments, and to be called while constructing the memory image of the program at the start of execution. In the case of initializers in a shared object, they are executed during the operation that brings the shared object into memory, either at program start up or during some dynamic loading operation, such as dlopen(). The only ordering of calls to initialization functions is the order in which they are processed by the link editors, both static and dynamic.

Within a source file, the functions specified in #pragma init are executed after the static constructors in that file. You must declare the identifiers before using them in the #pragma.

Use #pragma fini (identifier [, identifier]...) to mark identifier as a finalization function. Such functions are expected to be of type void, to accept no arguments, and to be called either when a program terminates under program control or when the containing shared object is removed from memory. As with initialization functions, finalization functions are executed in the order processed by the link editor.

In a source file, the functions specified in #pragma fini are executed after the static destructors in that file. You must declare the identifiers before using them in the #pragma.

#pragma ident

Use #pragma ident string to place string in the .comment section of the executable.

#pragma pack(n)

Use #pragma pack to control the layout of structure offsets. n is a number, 1, 2, or 4, that specifies the strictest alignment desired for any structure member. If n is omitted, members are aligned on their natural boundaries. If you use #pragma pack (n), be sure to place it after all #includes.

#pragma unknown_control_flow

Use #pragma unknown_control_flow (name, [,name] ...) to specify a list of routines that violate the usual control flow properties of procedure calls. For example, the statement following a call to setjmp() can be reached from an arbitrary call to any other routine. The statement is reached by a call to longjmp().

Because such routines render standard flowgraph analysis invalid, routines that call them cannot be safely optimized; hence, they are compiled with the optimizer disabled.

#pragma weak

Use #pragma weak to define a weak global symbol. This pragma is used mainly in source files for building libraries. The linker does not warn you if it cannot resolve a weak symbol. The line:

#pragma weak function_name
defines function_name to be a weak symbol. No error messages are generated if the linker cannot find a definition for function_name. The line:

#pragma weak function_name1 = function_name2
defines function_name1 to be a weak symbol, an alias for the symbol function_name2. You must declare function_name1 and function_name2 before using them in the pragma. For example:

extern void bar(int)

extern void _bar(int)

#pragma weak _bar=bar

The rules are:

Options

This section describes the C++ compiler options, arranged alphabetically. These descriptions are also available in the man page, CC(1).

In addition, these descriptions are summarized in:

Note - In the descriptions are many references to the linker, ld. For details about ld, see the ld(1) man page.

ccfe and ld

The CC driver passes command-line options to the following programs:

The options for ccfe and ld do not conflict.

-386

(Intel) Directs the compiler to generate code for the best performance on the Intel® 80386 microprocessor.

-486

(Intel) Directs the compiler to generate code for best performance on the Intel 80486 microprocessor.

-a

Prepares object code for coverage analysis, using tcov. This option helps you analyze your program at runtime, but is incompatible with -g.

This option is the old style of basic block profiling for tcov. See -xprofile=tcov for information on the new style of profiling, the tcov(1) man page, and Profiling Tools for more details.

If set at compile time, the TCOVDIR environment variable specifies the directory where the .d files are located. If this variable is not set, then the .d files remain in the same directory as the .f files.

The -xprofile=tcov and the -a 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 others that have been compiled with -a. You cannot compile a single file with both options.

-Bbinding

Specifies whether library bindings for linking are dynamic (shared) or static (nonshared). The values for binding are static and dynamic. -Bdynamic is the default. You can use the -B option to toggle several times on a command line. All libraries specified after the -Bstatic option will be linked statically.

For more information on this option on SPARC, x86 and PowerPC platforms, see the ld(1) man page and the Solaris documentation.

-Bdynamic

Directs the link editor to look for liblib.so files. Use this option if you want shared library bindings for linking. If the liblib.so files are not found, it looks for liblib.a files. By default, the CC driver passes the following -l options to ld:

-lC -lC_mtstubs -lm -lw -lcx -lc

For more details on -l, refer to "-llib" on page 31.

To link some of these libraries statically, use -nolib, as described in "-nolib" on page 34. To link libC statically, you can also use the
-staticlib=libC option.

-Bstatic

Directs the link editor to look only for files named liblib.a. The .a suffix indicates that the file is static, that is, nonshared. Use this option if you want nonshared library bindings for linking. On Solaris, this option and its arguments are passed to the linker, ld.

-c

Directs the CC driver to suppress linking with ld and produces 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. For example:

See also "-o filename" on page 39.

-cg[89|92]

(SPARC) Specifies the code generator for floating-point hardware in SPARC systems released in 1989 or 1992. Use the fpversion command to determine which floating-point hardware you have. If you compile one procedure of a program with this option, it does not mean that you must compile all the procedures of that program in the same way.

-cg89

(SPARC)-cg89 expands to:
-xarch=v7 -xchip=old -xcache=64/32/1.

-cg92

(SPARC) -cg92 expands to:
-xarch=v8 -xchip=super -xcache=16/32/4:1024/32/1.

+d

Prevents the compiler from expanding inline functions. This option is turned on when you specify -g, the debugging option.

The debugging option, -g0, does not turn on +d. See "-g0" on page 28.

-Dname[=def]

Defines a macro symbol name to the preprocessor. Doing so is equivalent to including a #define directive at the beginning of the source. If you do not use the argument =def, name is defined as 1. You can use multiple -D options.

The following values are predefined:

SPARC only:

x86 only:

PowerPC only:

The sparc, unix, sun, and i386 macros are not defined if +p is used. The value of __SUNPRO_CC indicates the release number of the compiler. You can use these values in such preprocessor conditionals as #ifdef.

-d[y|n]

-dy specifies dynamic linking, which is the default, in the link editor.

-dn specifies static linking in the link editor.

This option and its arguments are passed to ld.

-dalign

(SPARC) Generates double-word load and store instructions whenever possible for improved performance. This option assumes that all double type data are double-word aligned. If you compile one unit with -dalign, compile all units of a program with -dalign, or you may get unexpected results.

-dryrun

Displays what options the driver has passed to the compiler. This option directs the driver CC to show, but not execute, the commands constructed by the compilation driver.

-E

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.

+e[0|1]

Controls virtual table generation, as follows:

See also Appendix A, "Migration Guide" on page 169.

-fast

Selects a combination of compilation options for optimum execution speed. This option provides near maximum performance for most applications by choosing the following compilation options:



Table  2-1 Compilation Options Selected by -fast 

Option
 		SPARC
 		x86
 		PowerPC

-dalign

X

-fns

X

X

X

-fsimple

X

-ftrap=%none

X

X

X

-libmil

X

X

X

-nofstore

X

-O4

X

X

X

-xlibmopt

X

X

-xtarget=native

X

X

X

The code generation option, optimization level, and use of inline template files can be overridden by subsequent flag switches. For example, although the optimization level set by -fast is -O4, if you specify -fast -O3, the optimization level becomes -O3. The optimization level that you specify will override a previously set optimization level.

Do not use this option for programs that depend on IEEE standard floating-point exception handling; different numerical results, premature program termination, or unexpected SIGFPE signals may occur.

Note - The criteria for the -fast option vary with the C, C++, Fortran 77, and Pascal compilers. Please see the appropriate documentation for the specifics.
The -fast option includes -fns -ftrap=%none; that is, this option turns off all trapping. In previous SPARC releases, the -fast macro option included
-fnonstd; now it does not.

-features=a

Enables/disables various C++ language features. a must be one or more of: [no%]anachronisms, [no%]castop, [no%]rtti

The following table shows the values of a.

Value
 		Meaning

[no%]anachronisms

[Do not] Allow anachronistic constructs

[no%]castop

[Do not] Allow new-style casts (dynamic or otherwise)

[no%]rtti

[Do not] Allow RTTI (dynamic_cast <> and typeid)

-flags

Displays a brief description of each compiler option. Also displayed are phone numbers to call for additional information on Sun products and technical support, and instructions on how to send comments on Sun products.

-fnonstd

Causes nonstandard initialization of floating-point arithmetic hardware. In addition, the -fnonstd option 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. See the Numerical Computation Guide for more information.

By default, IEEE 754 floating-point arithmetic is nonstop, and underflows are gradual.

This option is a synonym for -fns -ftrap=common.

-fns

Turns on the nonstandard floating-point mode. The default is the standard floating-point mode.

If you compile one routine with -fns, then compile all routines of the program with the -fns option; otherwise, you can get unexpected results.

-fprecision=p

(Intel) Sets floating-point rounding precision mode.

p must be one of: single, double, extended. The following table shows the values of p.

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

-fround=r

Sets the IEEE 754 rounding mode.

r must be one of nearest, tozero, negative, or positive.

The default is -fround=nearest.

This option sets the IEEE 754 rounding mode that:

The meanings are the same as those for the ieee_flags subroutine.

If you compile one routine with -fround=r, compile all routines of the program with the same -fround=r option; otherwise, you can get unexpected results.

-fsimple[=n]

Allows the optimizer to make simplifying assumptions concerning floating-point arithmetic.

If n is present, it must be 0, 1 or 2. The defaults are:

-fsimple=0

Permits no simplifying assumptions. Preserves strict IEEE 754 conformance.

-fsimple=1

Allows conservative simplification. The resulting code does not strictly conform to IEEE 754, but numeric results of most programs are unchanged.

With -fsimple=1, the optimizer can assume the following:

With -fsimple=1, the optimizer is not allowed to optimize completely without regard to roundoff or exceptions. In particular, a floating point computation cannot be replaced by one that produces different results with rounding modes held constant at runtime. -fast implies -fsimple=1.

-fsimple=2

Permits aggressive floating point optimization that may cause many programs to produce different numeric results due to changes in rounding. For example, permits the optimizer to replace all computations of x/y in a given loop with x*z, where x/y is guaranteed to be evaluated at least once in the loop, z=1/y, and the values of y and z are known to have constant values during execution of the loop.

-fstore

Causes the compiler to convert the value of a floating-point expression or function to the type on the left side of an assignment--when that expression or function is assigned to a variable, or when the expression is cast to a shorter floating-point type rather than leaving the value in a register. Due to roundoffs and truncation, the results may be different from those that are generated from the register values. This is the default mode.

To turn off this option, use the -nofstore option.

-ftrap=t

Sets the IEEE 754 trapping mode.

t is a comma-separated list that consists of one or more of the following: %all, %none, common, [no%]invalid, [no%]overflow, [no%]underflow, [no%]division, [no%]inexact.

The default is -ftrap=%none.

This option sets the IEEE 754 trapping modes that are established at program initialization. Processing is left to right. The common exceptions, by definition, are invalid, division (by zero), and overflow.

For example: -ftrap=%all,no%inexact means to set all traps except inexact.

The meanings are the same as for the ieee_flags subroutine, except that:

If you compile one routine with -ftrap=t, compile all routines of the program with the same -ftrap=t option; otherwise, you can get unexpected results.

-G

Instructs the linker to build a shared library; see the ld(1) man page and the C++ Library Reference. All source files specified in the command line are compiled with -pic.

Use this option when building shared libraries of templates. Any generated templates are then automatically included in the library.

The following text options are passed to ld:

-g

Instructs both the compiler and the linker to prepare the file or program for debugging. The tasks include:

This option makes -xildon the default incremental linker option in order to speed up the compile-edit-debug cycle. See "-xildon" and
"-xildoff." Invokes ild in place of ld unless any of the following are true:

See also the descriptions for "-g0" and "+d," as well as the ld(1) man page. The dbx User's Guide provides details about stabs and "lazy stabs."

-g0

Instructs the compiler to prepare the file or program for debugging, but not to disable inlining. This option is the same as -g, except that +d is not enabled.

See also "+d" on page 20.

-H

Prints, one per line, the path name of each #include file included during the current compilation on the standard error output (stderr).

-help

Same as -flags, as described in "-flags" on page 23.

-hname

Names a shared dynamic library and provides a way to have versions of a shared dynamic 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 needed shared library files. When the runtime linker links the library into an executable file, the linker copies the intrinsic name from the library into that list of needed shared library files. If there is no intrinsic name of a shared library, then the linker copies the path of the shared library file instead. This command line is an example:

% CC -G -o libx.so.1 -h libx.so.1 a.o b.o c.o

-i

Tells the linker to ignore any LD_LIBRARY_PATH setting.

-Ipathname

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 preprocessor searches for #include files in this order:

1. For includes of the form #include "foo.h" (where quotation marks are used), the directory containing the source file is searched.

For includes of the form #include <foo.h> (where angle brackets are used), the directory containing the source file is not searched

2. In the directories named with -I options, if any

3. In the standard directory for C++ header files:


 
/opt/SUNWspro/SC4.2/include/CC

4. In the standard directory for ANSI C header files:


 
/opt/SUNWspro/SC4.2/include/cc

5. In /usr/include.

Note - If -ptipath is not used, the compiler looks for template files in -Ipath. Use -Ipath instead of -ptipath.

-inline=rlst

Inlines the routines that you specify in the rlst list--a comma-separated list of functions and subroutines. This option is used by the optimizer.

Note - This option does not affect C++ inline functions and is not related to the +d option.
If a function specified in the list is not declared as extern "C", the function name should 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.

If you compile with the flag -O3, using this option can increase optimization by restricting inlining to only those routines in the rlst list.

If you compile with the flag -O4, the compiler tries to inline all user-written subroutines and functions.

A routine is not inlined if any of the following conditions apply--no warning is issued.

-instances=a

Instantiates templates with the linkage you specify within the current object.

a must be one of: static, extern, global. These linkages are mutually exclusive. The following table shows the values of a.

Value
 		Meaning

extern

Instantiates generated templates within the template database, reinstantiating only as necessary. The current compilation unit references the instantiation by extern symbols. (Default)

static

Instantiates generated templates in the current compilation unit. Generated templates are then made static. The only restriction is that all template definitions must be located in the source or headers you are compiling.

global

Instantiates generated templates in the current compilation unit. Generated templates are then made global. The only restriction is that all template definitions must be located in the source or headers you are compiling.

-keeptmp

Retains the temporary files that are created during compilation. Along with the -v option, this option is useful for debugging, especially when you have template functions or classes.

-KPIC

Same as the -PIC option, as described in "-PIC" on page 40.

-Kpic

Same as the -pic option, as described in "-pic" on page 40.

-Ldir

Adds dir to the list of directories to be searched by the linker for libraries that contain object-library routines during the link step with ld. The directory, dir, is searched before compiler-provided directories.

C++ Library Reference and Tools.h++ Class Library Reference contain further information on some of the C++ libraries.

-llib

Specifies additional libraries for linking with object files. This option behaves like the -l option when it is used with CC or ld. Normal libraries have names like libsomething.a, where the lib and .a parts are required. You can specify the something part with this option. Put as many libraries as you want on a single command line; they are searched in the order specified with -L.

Use this option after your file name.

-libmieee

Causes libm to return values in the spirit of IEEE 754. The default behavior of libm is SVID-compliant.

-libmil

Inlines some library routines for faster execution. This option selects the best assembly language inline templates for the floating-point option and platform on your system.

Note - This option does not affect C++ inline functions.

-library=l

Determines C++ library use.

If a library is specified with -library, the proper -I (as well as -L,
-Y P,-R and -l) paths are passed to the compiler in order to use a particular library. During the link phase, the correct libraries will be presented to the linker.

l must be one of: [no%]rwtools7, [no%]rwtools6, [no%]libC,[no%]libm, [no%]complex, %all, %none. The following table shows the values of l.



Value
 		Meaning

[no%]rwtools7

[Do not] Use Tools.h++ v 7

[no%]rwtools6

[Do not] Use Tools.h++ v 6

[no%]libC

[Do not] Use libC

[no%]libm

[Do not] Use libm

[no%]complex

[Do not] Use libcomplex

%all

Use all libraries, in the order: rwtools7, complex, libC, libm

%none

Use no C++ libraries

If selected, libraries are linked in the order: rwtools7, rwtools6, complex, libC, libm. The default is -library=%none, libC, libm.

See also "-staticlib=l" on page 43.

-migration

Displays the contents of the C++ Migration Guide, which contains information about incompatibilities between C++ 3.0, based on Cfront, and the current compiler.

Move through the contents of the file using the command specified by the environment variable, PAGER. If this environment variable is not set, the default paging command is more.

-misalign

(SPARC) (PowerPC) Permits misaligned data, which would otherwise generate an error, in memory, as shown in the following code:

char b[100];

int f(int *ar){

return   *(int *)(b +2) +  *ar;

}

Thus, very conservative loads and stores must be used for the data, that is, one byte at a time. Using this option can cause significant degradation in performance when you run the program.

If possible, do not link aligned and misaligned parts of the program.

-mt

Compiles and links a multithreaded program and passes -D_REENTRANT to the preprocessor. The following command is passed to ld: 

-lC -lm -lw -lthread -lcx -lc
instead of:

-lC -lm -lC_mtstubs -lw -lcx -lc
Note - To ensure proper library linking order, use this option rather than -lthread, to link with libthread.

-native

Chooses the correct code generator option. This option directs the compiler to generate code targeted for the machine that is doing the compilation.

Native floating-point--use what is best for this machine.

This option is a synonym for -xtarget=native.

The -fast macro includes -native in its expansion.

-noex

Instructs the compiler not to generate code that supports C++ exceptions.

-nofstore

(Intel) Does not convert the value of a floating-point expression or function to the type on the left side of an assignment when that expression or function is assigned to a variable, or is cast to a shorter floating-point type; rather, leaves the value in a register.

See also "-fstore" on page 26.

-nolib

Does not link with any system or library by default; that is, no -l options are passed to ld. You can then link some of the default libraries statically instead of dynamically.

You must pass all -l options explicitly. The CC driver normally passes the following options to ld:

-lC -lm -lC_mtstubs -lw -lcx -lc

You can link libC, libm, and libw statically, and link libc dynamically, as follows:

% CC test.c -nolib -Bstatic -lC -lm -lC_mtstubs -lw -lcx \

 -Bdynamic -lc
The order of the -l options is significant. The -lC, -lm, -lC_mtstubs, -lw,and -lcx options must appear before -lc.

See also "-library=l" on page 32 and "-staticlib=l" on page 43.

(PowerPC only) In this release, all C++ programs will be linked with -labi, which the driver adds to the link line. If you choose to use -nolib, you must manually link with -labi. If you do not link with -labi, the following three entry points required for exception handling will not be defined, and the program will not link:

_add_module_tags

_delete_module_tags

_tag_lookup_pc

In the next OS release, these entry points will appear in libc, and -labi will cease to exist.

As above, the order of the options is significant. The -lC option must appear before -labi.

-nolibmil

Resets -fast so that it does not include inline templates. Use this option after the -fast option, as in:

% CC -fast -nolibmil

-noqueue

If no license is available, returns without queuing your request and without compiling. A nonzero status is returned for testing makefiles.

-norunpath

Does not build the 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 helpful if you have installed the compiler in some nonstandard location, and you ship an executable file to your customers, who need not work with that nonstandard location.

If you use any shared libraries under the compiler installed area (default location /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 run time to specify the location of the shared libraries. This will allow the runtime linker to find the shared libraries.

-Olevel

Optimizes the execution time. Omitting level is equivalent to using level -O2.

There are five levels that you can use with -O. The following sections describe how they differ for SPARC systems, for x86, and for all systems.

For SPARC Systems

-O1: Does only the minimum amount of optimization (peephole), which is postpass, assembly-level optimization. Do not use -O1 unless using -O2 or -O3 results in excessive compilation time, or you are running out of swap space.

-O2: Does basic local and global optimization, which includes:

This level does not optimize references or definitions for external or indirect variables. Do not use -O2 unless using -O3 results in excessive compilation time, or you are running out of swap space. In general, this level results in minimum code size.

-O3: Also optimizes references and definitions for external variables in addition to optimizations performed at the -O2 level. This level does not trace the effects of pointer assignments. Do not use it when compiling either device drivers, or programs that modify external variables from within signal handlers. In general, this level results in increased code size.

-O4: Does automatic inlining of functions contained in the same file in addition to performing -O3 optimizations. This automatic inlining usually improves execution speed, but sometimes makes it worse. In general, this level results in increased code size.

-O5: Generates the highest level of optimization. Uses optimization algorithms that take more compilation time or that do not have as high a certainty of improving execution time. Optimization at this level is more likely to improve performance if it is done with profile feedback. See"-xprofile=p" on page 56.

For Intel and PowerPC Systems

-O1: Preloads arguments from memory; causes cross jumping (tail merging), as well as the single pass of the default optimization.

-O2: Schedules both high- and low-level instructions and performs improved spill analysis, loop memory-reference elimination, register lifetime analysis, enhanced register allocation, global common subexpression elimination, as well as the optimization done by level 1.

-O3: Performs loop strength reduction and inlining, as well as the optimization done by level 2.

-O4: Performs architecture-specific optimization, as well as the optimization done by level 3.

-O5: Generates the highest level of optimization. Uses optimization algorithms that take more compilation time or that do not have as high a certainty of improving execution time.

For All Systems

For most programs:

In a few cases, -O2 may perform better than the others, and -O3 may outperform -O4. 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 then resumes subsequent procedures at the original level specified in the -O option.

If you optimize at -O3 or -O4 with very large procedures (thousands of lines of code in a single procedure) the optimizer may require an unreasonable amount of memory. In such cases, machine performance may 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:

% limit datasize 16M
This command causes the optimizer to try to recover if it reaches 16 megabytes of data space.

This limit cannot be greater than the total available swap space of the machine, and the limit should be small enough to permit normal use of the machine while a large compilation is in progress.

For example, on a machine with 32 megabytes of swap space, the limit datasize 16M command ensures that a single compilation never consumes more than half of the machine swap space.

The best setting for data size depends on the degree of optimization requested, the amount of real memory, and virtual memory available.

-o filename

Sets the name of the output file (with the suffix, .o) or the executable file to filename. The file name 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.

+p

Use -features=no%anachronisms.

-P

Runs a source file through the preprocessor, which outputs a file with a .i suffix. This option does not include preprocessor-type line number information in the output.

-p

Prepares the object code to collect data for profiling with prof. This option invokes a runtime recording mechanism that produces a mon.out file at normal termination.

You can also perform this task with the Analyzer. Refer to the analyzer(1) man page.

-pentium

(Intel) Use -xtarget=pentium.

-pg

Prepares the object code to collect data for profiling with gprof. This option invokes a runtime recording mechanism that produces a gmon.out file at normal termination.

You can also perform this task with the Analyzer. Refer to the analyzer(1) man page.

-PIC

(Intel) Produces position-independent code.

Same as -pic.

(SPARC) (PowerPC) Similar to -pic, but the global offset table spans the range of 32-bit addresses in those rare cases where there are too many global data objects for --pic.

-pic

Produces position-independent code. Use this option to compile source files when building a shared library.

Each reference to a global datum is generated as a dereference of a pointer in the global offset table. Each function call is generated in pc-relative addressing mode through a procedure linkage table. The size of the global offset table is limited to 8 Kbytes on SPARC processors.

-pta

Use -template=wholeclass. See also "-template=w" on page 44.

-ptipath

Specifies an additional search directory for template source.

This option is an alternative to the normal search path set by
-Ipathname. If the -ptipath flag is used, the compiler looks for template definition files on this path and ignores the -Ipathname flag. It is recommended that you use the -Ipathname flag instead of -ptipath.

-pto

Use -instances=static. See also "-instances=a" on page 30.

-ptrdatabase-path

Specifies the directory of primary and secondary build repositories. The template database is named Templates.DB; database-path is the directory containing the database, but does not include the name itself.

For example:

You can use multiple -ptr options. However, all repositories specified, except the first one, are read-only; no templates are instantiated into these directories.

If you omit this option, a default database, ./Templates.DB, is created for you. To avoid confusion when multiple databases are involved, use -ptr. as the first entry on the command line.

-ptv

Use -verbose=template. See also "-verbose=v" on page 46.

-Qoption|-qoption prog opt

Passes the option, opt, to the phase, prog. Refer to "Components" on page 13 for more information on compiler phases.

Table 2-2 shows the possible values for prog:

Table  2-2 Compiler Phases

SPARC Architecture
 		x86 Architectures

ccfe

ccfe

iropt

cg386

cg

codegen

tdb_link

tdb_link

ld

ld

To pass more than one option, specify them in order as a comma-separated list. In the following command line, when ld is invoked by the CC driver, -Qoption passes the -i and -m options to ld:

% CC -Qoption ld -i,-m test.c

-qp

Use -p.

-Qproduce|-qproduce sourcetype

Causes the CC driver to produce source code of the type sourcetype. Source code types are shown in Table 2-3.

Table  2-3 Source Code Types

.i

Preprocessed C++ source from ccfe

.o

Object file from cg, the code generator

.s

Assembler source from cg

-R pathname

Passes a colon-separated list of search paths to the linker for library searching during runtime linking.

Multiple instances of -Rpathname are concatenated, with each pathname separated by a colon. Without this option specified, the compiler passes a default search path to the linker:

/opt/SUNWspro/lib (for standard installs)

<install_path>/lib (for non-standard installs into <install_path>)

With -Rpathname specified, the listed library search paths are added to the default paths passed to the linker and built into the object program.

(The LD_RUN_PATH environment variable is always ignored.)

-readme

Displays the contents of the README file, paged by the command specified by the environment variable, PAGER. If PAGER is not set, the default paging command is more.

For a description of the contents of this file, see "README file" on page xxiii.

-S

Causes the CC driver to compile the program and output an assembly source file, but not assemble the program. The assembly source file is named with a .s suffix.

-s

Removes all symbol information from output executable files. This option is passed to ld.

-sb

Causes the CC driver to generate extra symbol table information in a SourceBrowser database in the .sb directory for the sbrowser program.

-sbfast

Runs only the ccfe phase to generate extra symbol table information in a SourceBrowser database in the .sb directory for the sbrowser program. No object file is generated.

-staticlib=l

Determines whether C++ libraries are linked statically.

If a library is specified with both -library and with -staticlib, that library is linked statically. If the library is specified with -staticlib, but not with -library, -staticlib is ignored.The default for -staticlib is staticlib=%none.

l must be one or more of [no%]rwtools6, [no%]rwtools7, [no%]libC,[no%]libm,[no%]complex, %all, %none.

The following table shows the values of l.

Value
 		Meaning

[no%]rwtools6

Tools.h++ v 6 [not] linked statically

[no%]rwtools7

Tools.h++ v 7 [not] linked statically

[no%]libC

libC [not] linked statically

[no%]libm

libm [not] linked statically

[no%]complex

libcomplex [not] linked statically

%all

All libraries specified in the -library option linked statically. If no libraries are specified using -library, then %all means link the libraries libC and libm statically.

%none

Dynamic linking

For example, you can link libC statically as follows:

% CC test.c -staticlib=libC

-temp=dir

Sets the name of the directory for temporary files, generated during the compilation process, to dir. See also "-keeptmp" on page 31.

-template=w

Enables/disables various template options.

The following table shows the values of w.

Value
 		Meaning

[no%]wholeclass

Directs the compiler [not] to instantiate a whole template class, rather than only those functions that are used. This option creates a .o file for each member of a class. You must reference at least one member of the class, otherwise, the compiler does not instantiate any members for the class.

-time

Causes the CC driver to report execution times for various compilation passes.

-Uname

Removes any initial definition of the macro symbol name. This option:

You can specify multiple -U options on the command line.

-unroll=n

Specifies whether or not the compiler optimizes (unrolls) loops.

-V

Use -verbose=version.

-v

Use -verbose=diags.

-verbose=v

Controls verbosity during compilation.

v must be one or more of: template, diags, version.

You may specify more than one option, for example, -verbose=template, diags

The following table shows the values of v.

Value
 		Meaning

template

Turns on the verbose mode, sometimes called the verify mode. The verbose mode displays each phase of instantiation as it occurs during compilation. Use this option if you are new to templates.

diags

Prints the command line for each compilation pass

version

Directs the CC driver to print the names and version numbers of the programs it invokes.

+w

Generates additional warnings about questionable constructs that are:

By default, the compiler warns about constructs that are almost certainly problems.

-w

Causes the CC driver to not print warning messages from the compiler.

-xa

Same as the -a option, as described in "-a" on page 18.

-xar

Creates archive libraries.

When compiling 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.

For example:

CC -xar -O libmain.a a.o b.o c.o
archives the template functions contained in the library and object files.

-xarch=a

Limits the set of instructions the compiler may use.

Target architectures specified by keyword a are:

Table  2-4 The -xarch Architecture Keywords

On SPARC: 

generic, v7, v8a, v8, v8plus, v8plusa

On PowerPC: 

generic, ppc, ppc_nofma

On Intel: 

generic, 386, pentium_pro

Although this option can be used alone, it is part of the expansion of the
-xtarget option; its primary use is to override a value supplied by the
-xtarget option.

This option limits the instructions generated to those appropriate to the specified architecture, and allows the specified set of instructions. The option does not guarantee an instruction will be used; however, under optimization, it is usually used.

If this option is used with optimization, the appropriate choice can provide good performance of the executable on the specified architecture. An inappropriate choice can result in serious degradation of performance.

SPARC architectures v7, v8a, and v8 are all binary compatible. v8plus and v8plusa are binary compatible with each other, and they are forward but not backward compatible.

For any particular choice, the generated executable can run much more slowly on earlier architectures.



Table  2-5 The -xarch Values 

Value
 		Meaning

generic

Gets good performance on most SPARCs, major degradation on none.

This is the default. This option uses the best instruction set for good performance on most SPARC processors without major performance degradation on any of them. With each new release, this best instruction set will be adjusted, if appropriate.

v7

Limits instruction set to V7 architecture.

This option uses the best instruction set for good performance on the V7 architecture, but without the quad-precision floating-point instructions. This is equivalent to using the best instruction set for good performance on the V8 architecture, but without the following instructions:

The quad-precision floating-point instructions

The integer mul and div instructions

The fsmuld instruction

Examples: SPARCstation 1, SPARCstation 2

v8a

Limits instruction set to the V8a version of the V8 architecture.

By definition, V8a means the V8 architecture, but without:

The quad-precision floating-point instructions

The fsmuld instruction

This option uses the best instruction set for good performance on the V8a architecture.

Example: Any machine based on MicroSPARC I chip architecture

v8

Limits instruction set to V8 architecture.

This option uses the best instruction set for good performance on the V8 architecture, but without quad-precision floating-point instructions.

Example: SPARCstation 10

v8plus

Limits instruction set to the V8plus version of the V9 architecture.

By definition, V8plus means the V9 architecture, except:

Without the quad-precision floating-point instructions

Limited to the 32-bit subset defined by the V8+ specification

Without the VIS instructions

This option uses the best instruction set for good performance on the V8plus chip architecture. In V8plus, a system with the 64-bit registers of V9 runs in 32-bit addressing mode, but the upper 32 bits of the i and l registers must not affect program results.

Example: Any machine based on UltraSPARC chip architecture.

Use of this option also causes the .o file to be marked as a V8plus binary. Such files will not run on a V7 or V8 machine.

v8plusa

Limits instruction set to the V8plusa architecture variation.

By definition, V8plusa means the V8plus architecture, plus:

The UltraSPARC-specific instructions

The VIS instructions

This option uses the best instruction set for good performance on the UltraSPARCTM architecture, but limited to the 32-bit subset defined by the V8plus specification.

Example: Any machine based on UltraSPARC chip architecture

Use of this option also causes the .o file to be marked as a Sun-specific V8plus binary. Such files will not run on a V7 or V8 machine.

For PowerPC:

generic and ppc are equivalent in this release and direct the compiler to produce code for the PowerPC 603 and 604 instruction set.

ppc_nofma is the same as ppc except that the compiler will not issue the "fused multiply-add" instruction.

For Intel:

generic and 386 are equivalent in this release.

pentium_pro directs the compiler to issue instructions for the Intel PentiumPro chip.

-xcache=c

(SPARC) Defines the cache properties that the optimizer can use. It does not guarantee that any particular cache property is used.

c must be one of the following:

That is, -xcache={generic |s1/l1/a1[:s2/l2/a2[:s3/l3/a3]]}, where the si/li/ai are defined as follows:

si

The size of the data cache at level i, in kilobytes

li

The line size of the data cache at level i, in bytes

ai

The associativity of the data cache at level i

Although this option can be used alone, it is part of the expansion of the
-xtarget option; its primary use is to override a value supplied by the
-xtarget option.

.

Table  2-6 The -xcache Values 

Value
 		Meaning

generic

Defines the cache properties for good performance on most SPARC processors.

This is the default value that directs the compiler to use cache properties for good performance on most SPARC processors, without major performance degradation on any of them.

s1/l1/a1

Defines level 1 cache properties.

s1/l1/a1:s2/l2/a2

Defines levels 1 and 2 cache properties.

s1/l1/a1:s2/l2/a2:s3/l3/a3

Defines levels 1, 2, and 3 cache properties

Example: -xcache=16/32/4:1024/32/1 specifies the following:

Level 1 cache has:

16 Kbytes

32 bytes line size

4-way associativity

Level 2 cache has:

1024 Kbytes

32 bytes line size

Direct mapping associativity

-xcg89

(SPARC) Same as the -cg89 option. See "-cg[89|92]" on page 19.

-xcg92

(SPARC) Same as the -cg92 option. See "-cg[89|92]" on page 19.

-xchip=c

(SPARC) Specifies the target processor for use by the optimizer.

c must be one of the following:

On SPARC: generic, old, super, super2, micro, micro2, hyper, hyper2, powerup, ultra

On PowerPC: generic, 603, 604

On Intel: 386, 486, pentium, pentium_pro.

Although this option can be used alone, it is part of the expansion of the
-xtarget option; its primary use is to override a value supplied by the
-xtarget option.

This option specifies timing properties by specifying the target processor.

This option affects:



Table  2-7 The -xchip Values 


Value
 		Meaning

SPARC:

generic

Uses timing properties for good performance on most SPARC processors.

This is the default value that directs the compiler to use the best timing properties for good performance on most SPARC processors, without major performance degradation on any of them.

old

Uses timing properties of pre-SuperSPARCTM processors.

super

Uses timing properties of the SuperSPARC chip.

super2

Uses timing properties of the SuperSPARC II chip.

micro

Uses timing properties of the MicroSPARCTM chip.

micro2

Uses timing properties of the MicroSPARC II chip.

hyper

Uses timing properties of the HyperSPARCTM chip.

hyper2

Uses timing properties of the HyperSPARC II chip.

powerup

Uses timing properties of the Weitek PowerUpTM chip.

ultra

Uses timing properties of the UltraSPARC chip.

PowerPC

generic

Uses timing properties for good performance on most PowerPC processors.

603

Uses timing properties of the PowerPC 603 chip.

604

Uses timing properties of the PowerPC 604 chip.

Intel:

generic

Uses timing properties for good performance on most Intel x86 processors.

386

Uses timing properties of the Intel 386 chip.

486

Uses timing properties of the Intel 486 chip.

pentium

Uses timing properties of the Intel Pentium chip.

pentium_pro

Uses timing properties of the Intel Pentium Pro chip.

-xF

With -noex, enables reordering of functions, using the compiler, the Analyzer, and the linker.

If you compile with the -xF option, and then run the Analyzer, you generate a map file that shows an optimized order for the functions. The subsequent link to build the executable file can be directed to use that map by using the linker -Mmapfile option.

If you include the O flag in the string of segment flags within the mapfile, then the static linker, ld, attempts to place sections in the order in which they appear in the mapfile, for example:

LOAD ? RXO
Note - The -xF option will not work unless you also specify the -noex option.
The analyzer(1) and ld(1) man pages provide further details on this option.

-xildoff

Turns off the incremental linker and forces the use of ld. This option is the default if you do not use the -g option. Override this default by using the
-xildon option.

-xildon

Turns on the incremental linker and forces the use of ild in incremental mode. This option is the default if you use the -g option. Override this default by using the -xildoff option.

For more information on the incremental linker, refer to the ild man page.

-xinline=rlst

Same as -inline, as described in "-inline=rlst" on page 29.

-xlibmieee

Same as -libmieee, as described in "-libmieee" on page 31.

-xlibmil

Same as -libmil, as described in "-libmil" on page 32.

-xlibmopt

(SPARC)(Intel) Uses a math routine library optimized for performance. The results may be slightly different from those produced by the normal math library. This option is implied by the -fast option.

See also "-fast" on page 22 and "-xnolibmopt" on page 56.

-xlic_lib=l

(SPARC)(Intel) Links in the Sun-supplied, licensed libraries specified in l. For example, to link with the Sun Performance Library, use -xlic_lib=sunperf. This option, like -l, should appear at the end of the command line, after source or object file names.

For further information regarding the performance library, see the performance_library README.

-xlicinfo

Displays information on the licensing system. In particular, this option returns the license-server name and the user ID for each user who has a license checked out. When you use this option, the compiler is not invoked, and a license is not checked out.

-Xm

Allows the use of the character $ in identifier names, except as the first character.

-xM

Outputs makefile dependency information. For example, with the following code, hello.c:

#include <stdio.h>

main()

{

	(void) printf ("hello0");

}

When you compile with this option:

% CC -xM hello.c
The output shows the dependencies:

hello.o: hello.c

hello.o: /usr/include/stdio.h
See make(1) for details about makefiles and dependencies.

-xM1

Same as -xM, except that this option does not output dependencies for the /usr/include header files. When you compile the same code provided with the -xM option, the output is:

hello.o: hello.c

-xMerge

Merges the data segment with the text segment. The data in the object file is read-only, and is shared between processes, unless you link with ld -N.

-xnolib

Same as -nolib, as described in "-nolib" on page 34.

-xnolibmopt

(SPARC)(Intel) Disables -fast and does not use the math routine library.

Use this option after the -fast option on the command line, as in:
CC -fast -xnolibmopt

-xOlevel

Same as -Olevel, as described in "-Olevel" on page 36.

-xpg

Same as -pg, as described in "-pg" on page 39.

-xprofile=p

Collects data for a profile or uses a profile to optimize.

p must be collect, use[:executable name] or tcov. Executable name is the name of the executable that is being analyzed. The executable name is optional. If it is not specified, the executable name is assumed to be a.out.

This option causes execution frequency data to be collected and saved during the execution. The data can be used in subsequent runs to improve performance.

The -xprofile=tcov and the -a options are compatible in a single executable. That is, you can link a program that contains some files which have been compiled with -xprofile=tcov and others with -a. You cannot compile a single file with both options.



Table  2-8 The -xprofile Values

Value
 		Meaning

collect

Collects and saves execution frequency for later use by the optimizer.

The compiler inserts code to measure the execution frequency at a low level. During execution, the measured frequency data is written into .prof files that correspond to each of the source files.

If you run the program several times, the execution frequency data accumulates in the .prof files; that is, output from prior runs is not lost.

use[:en]

Uses execution frequency data saved by the compiler.

Where en stands for executable name, the name of the executable that is being analyzed. The executable name is optional. If it is not specified, the executable name is assumed to be a.out.

Optimizes by using the execution frequency data previously generated and saved in the .prof files by the compiler.

The source files and the compiler options (excepting only this option), must be exactly the same as for the compilation used to create the compiled program that was executed to create the .prof files.

tcov

This option is the new style of basic block profiling for tcov. It has similar functionality to the -a option, but correctly collects data for programs that have source code in header files or make use of C++ templates. See -a for information on the old style of profiling, the tcov(1) man page, and Profiling Tools for more details.

Code instrumentation is performed similarly to that of the -a option, but .d files are no longer generated. Instead, a single file is generated, whose name is based on the final executable. For example, if the program is run out of /foo/bar/myprog, then the data file is stored in /foo/bar/myprog.profile/myprog.tcovd.

The -xprofile=tcov and the -a options are compatible in a single executable. That is, you can link a program that contains some files which have been compiled with -xprofile=tcov and others with -a. You cannot compile a single file with both options.

When running tcov, you must pass it the -x option to force it to use the new style of data. If you don't, tcov uses the old .d files by default, and produces unexpected output.

Unlike -a, the TCOVDIR environment variable has no effect at compile time. However, its value is used at program runtime.

-xregs=r

(SPARC) Specifies the usage of registers for the generated code.

r is a comma-separated list that consists of one or more of the following: [no%]appl, [no%]float.

Example: -xregs=appl,no%float

Table  2-9 The -xregs Values

Value
 		Meaning

appl

Allows using the registers g2, g3, and g4.

In the SPARC ABI, these registers are described as application registers. Using these registers can increase performance because fewer load and store instructions are needed. However, such use can conflict with some old library programs written in assembly code.

no%appl

Does not use the appl registers.

float

Allows using the floating-point registers as specified in the SPARC ABI. You can use these registers even if the program contains no floating-point code.

no%float

Does not use the floating-point registers.

With this option, a source program cannot contain any floating-point code.

The default is -xregs=appl,float.

-xs

Disables Auto-Read for dbx. Use this option in case you cannot keep the .o files around. This option passes the -s option to the assembler.

No Auto-Read is the older way of loading symbol tables. It places all symbol tables for dbx in the executable file. The linker links more slowly, and dbx initializes more slowly.

Auto-Read is the newer and default way of loading symbol tables. With Auto-Read the information is placed in the .o files, so that dbx loads the information only if and when it is needed. Hence the linker links faster, and dbx initializes faster.

With -xs, if you move executables to another directory, when using dbx you do not have to move the object (.o) files.

Without -xs, if you move the executables to another directory, to use dbx you must move both the source files and the object (.o) files.

-xsafe=mem

(SPARC) Allows the compiler to assume no memory-based traps occur.

This option grants permission to use the speculative load instruction on V9 machines.

-xsb

Same as -sb, as described in "-sb" on page 43.

-xsbfast

Same as -sbfast, as described in "-sbfast" on page 43.

-xspace

(SPARC) Does no optimizations that increase code size.

Example: Do not unroll loops.

-xtarget=t

Specifies the target system for instruction set and optimization.

t must be one of native, generic, or system-name. See Table 2-10 for the meanings of these -xtarget values.

The performance of some programs may 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.

Table  2-10 The -xtarget Values

Value
 		Meaning

native

Gets the best performance on the host system.

The compiler generates code for the best performance on the host system. It determines the available architecture, chip, and cache properties of the machine on which the compiler is running.

generic

Gets the best performance for generic architecture, chip, and cache.

The compiler expands -xtarget=generic to:

-xarch=generic -xchip=generic -xcache=generic

This is the default value.

system-name

Gets the best performance for the specified system.

You select a system name from Table 2-11 that lists the mnemonic encodings of the actual system name and numbers.

The -xtarget option is a macro. Each specific value for -xtarget expands into a specific set of values for the -xarch, -xchip, and -xcache options. See Table 2-9 for the values. For example:

-xtarget=sun4/15 is equivalent to:
-xarch=v8a -xchip=micro -xcache=2/16/1

On PowerPC, -xtarget= accepts generic or native.

On Intel, -xtarget= accepts:






Table  2-11	 The -xtarget Expansions  






-xtarget



-xarch



-xchip



-xcache






sun4/15




v8a




micro




2/16/1





sun4/20




v7




old




64/16/1





sun4/25




v7




old




64/32/1





sun4/30




v8a




micro




2/16/1





sun4/40




v7




old




64/16/1





sun4/50




v7




old




64/32/1





sun4/60




v7




old




64/16/1





sun4/65




v7




old




64/16/1





sun4/75




v7




old




64/32/1





sun4/110




v7




old




2/16/1





sun4/150




v7




old




2/16/1





sun4/260




v7




old




128/16/1





sun4/280




v7




old




128/16/1





sun4/330




v7




old




128/16/1





sun4/370




v7




old




128/16/1





sun4/390




v7




old




128/16/1





sun4/470




v7




old




128/32/1





sun4/490




v7




old




128/32/1





sun4/630




v7




old




64/32/1





sun4/670




v7




old




64/32/1





sun4/690




v7




old




64/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/64/1





ssslc




v7




old




64/16/1





ss1




v7




old




64/16/1





ss1plus




v7




old




64/16/1





ss2




v7




old




64/32/1





ss2p




v7




powerup




64/32/1





ss4




v8a




micro2




8/64/1





ss5




v8a




micro2




8/64/1





ssvygr




v8a




micro2




8/16/1





ss10




v8




super




16/32/4





ss10/hs11




v8




hyper




256/64/1





ss10/hs12




v8




hyper




256/64/1





ss10/hs14




v8




hyper




256/64/1





ss10/20




v8




super




16/32/4





ss10/hs21




v8




hyper




256/64/1





ss10/hs22




v8




hyper




256/64/1





ss10/30




v8




super




16/32/4





ss10/40




v8




super




16/32/4





ss10/41




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/61




v8




super




16/32/4:1024/32/1





ss10/71




v8




super2




16/32/4:1024/32/1





ss10/402




v8




super




16/32/4





ss10/412




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/612




v8




super




16/32/4:1024/32/1





ss10/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





ss20/51




v8




super




16/32/4:1024/32/1





ss20/61




v8




super




16/32/4:1024/32/1





ss20/71




v8




super2




16/32/4:1024/32/1





ss20/502




v8




super




16/32/4





ss20/514




v8




super




16/32/4:1024/32/1





ss20/612




v8




super




16/32/4:1024/32/1





ss20/712




v8




super




16/32/4:1024/32/1





ss600/41




v8




super




16/32/4:1024/32/1





ss600/51




v8




super




16/32/4:1024/32/1





ss600/61




v8




super




16/32/4:1024/32/1





ss600/120




v7




old




64/32/1





ss600/140




v7




old




64/32/1





ss600/412




v8




super




16/32/4:1024/32/1





ss600/




v8




super




16/32/4:1024/32/1





ss1000




v8




super




16/32/4:1024/32/1





sc2000




v8




super




16/32/4:1024/64/1





cs6400




v8




super




16/32/4:2048/64/1





solb5




v7




old




128/32/1





solb6




v8




super




16/32/4:1024/32/1





ultra




v8




ultra




16/32/1:512/64/1





ultra1/140




v8




ultra




16/32/1:512/64/1





ultra1/170




v8




ultra




16/32/1:512/64/1





ultra1/1170




v8




ultra




16/32/1:512/64/1





ultra1/2170




v8




ultra




16/32/1:512/64/1





ultra1/2200




v8




ultra




16/32/1:1024/64/1

-xtime

Same as -time, as described in "-time" on page 45.

-xunroll=n

Same as -unroll=n, as described in "-unroll=n" on page 45.

-xwe

Converts all warnings to errors by returning non zero exit status.

-Ztha

(SPARC) Prepares code for analysis by the Thread Analyzer, the performance analysis tool for multithreaded code.

If you compile and link in separate steps, you should use this option in both steps. Code linked with this option is linked with the libtha.s library.

-ztext

Forces a fatal error if any relocations remain against non writable, allocatable sections.



Previous Next Contents Index Doc Set Home