Home » Support » Sun cc Compiler Oprions

Sun's cc Compiler Options

This chapter describes the C compiler options. It includes sections on option syntax, the cc options, and options passed to the linker.
If you are porting a K&R C program to ANSI C, make special note of the section on compatibility flags, "-X[a|c|s|t]" on page 23. Using them makes the migration to ANSI C easier. Also, Refer to the book titled Making the Transition to ANSI C.

Option Syntax

The syntax of the cc command is:
% cc [options] filenames [libraries]...
where:
  • options represents one or more of the options described in "The cc Options" on page 6
  • filenames represents one or more files used in building the executable program

    cc accepts a list of C source files and object files contained in the list of files specified by filenames. The resulting executable code is placed in a.out, unless the -o option is used. In this case, the code is placed in the file named by the -o option.

Use cc to compile and link any combination of the following:
  • C source files, with a .c suffix
  • C preprocessed source files, with a .i suffix
  • Object-code files, with .o suffixes
  • Assembler source files, with .s suffixes
After linking, cc places the linked files, now in executable code, into a file named a.out, or into the file specified by the -o option.
  • libraries represents any of a number of standard or user-provided libraries containing functions, macros, and definitions of constants.
See option -YP, dir to change the default directories used for finding libraries. dir is a colon-separated path list. The default library search order for cc is:
/opt/SUNWspro/SC4.2/lib
/usr/ccs/lib
/usr/lib
cc uses getopt to parse command-line options. Options are treated as a single letter or a single letter followed by an argument. See getopt(3c).

The cc Options

This section describes the cc options, arranged alphabetically. These descriptions are also available in the man page, cc(1). See the C 4.x Quick Reference or the -flags option for a one-line summary of these descriptions.
Options noted as being unique to one or more platforms are accepted without error and ignored on all other platforms. For an explanation of the typographic notations used with the options and arguments, refer to Table P-5 on page xxix.

-#

Turns on verbose mode, showing each component as it is invoked.

-###

Shows each component as it would be invoked, but does not actually execute it.

-Aname[(tokens)]

Associates name as a predicate with the specified tokens as if by a #assert preprocessing directive.Preassertions:
  • system(unix)
· machine(sparc) (SPARC)
· machine(i386) (Intel)
· cpu(sparc) (SPARC)
· cpu(i386) (Intel)
· cpu(ppc) (PowerPC)
These preassertions are not valid in -Xc mode.

-B[static|dynamic]

Specifies whether bindings of libraries for linking are static or dynamic, indicating whether libraries are non-shared or shared, respectively.
-Bdynamic causes the link editor to look for files named libx.so and then for files named libx.a when given the -lx option.
-Bstatic causes the link editor to look only for files named libx.a. This option may be specified multiple times on the command line as a toggle. This option and its argument are passed to ld.

-C

Prevents the C preprocessor from removing comments, except those on the preprocessing directive lines.

-c

Directs cc to suppress linking with ld(1) and to produce a .o file for each source file. You can explicitly name a single object file using the -o option.

-Dname[=tokens]

Associates name with the specified tokens as if by a #define preprocessing directive. If no =tokens is specified, the token 1 is supplied.
Predefinitions (not valid in -Xc mode):
  • sun
  • unix
  • sparc (SPARC)
  • i386 (Intel)
The following predefinitions are valid in all modes.
_ _sun
_ _unix
_ _SUNPRO_C=0x400
_ _'uname -s'_'uname -r' (example:         _ _SunOS_5_4)
_ _sparc (SPARC)
_ _i386 (Intel)
_ _BUILTIN_VA_ARG_INCR
_ _SVR4
_ _LITTLE_ENDIAN (PowerPC)
_ _ppc (PowerPC)
The following is predefined in -Xa and -Xt modes only:
    _ _RESTRICT
The compiler also predefines the object-like macro
    _ _PRAGMA_REDEFINE_EXTNAME,
to indicate the pragma will be recognized.

-d[y|n]

-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(1).

-dalign

Allows compiler to generate double-word load/store instructions wherever profitable for improved performance. Assumes that all double and long long type data are double-word aligned. Do not use this option when correct alignment is not assured.

-E

Runs the source file through the preprocessor only and sends the output to stdout.1 Includes the preprocessor line numbering information. See also the -P option.

-erroff=t

Suppresses cc warning messages. Has no effect on error 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 suppresses all warning messages except tag.
Table 2-1 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.

1. The preprocessor is built directly into the compiler, except in -Xs mode, where /usr/ccs/lib/cpp is invoked.

-errtags=a

Displays the message tag for each error message.
a can be either yes or no. The default is -errtags=no. Specifying -errtags is equivalent to specifying -errtags=yes.

-fast

Selects the optimum combination of compilation options for speed. This should provide close to the maximum performance for most realistic applications. Modules compiled with -fast must also be linked with -fast.
The -fast option is unsuitable for programs intended to run on a different target than the compilation machine. In such cases, follow -fast with the appropriate xtarget option. For example:
        cc -fast -xtarget=ultra ...
For C modules that depend on exception handling specified by SVID, follow -fast by -nolibmil:
% cc -fast -nolibmil
With -xlibmil, exceptions may not be noted by setting errno or calling matherr(3m).
The -fast option is unsuitable for programs that require strict conformance to the IEEE 754 Standard.
The set of options selected by -fast differ across platforms:
Table 2-2 -fast selections across platforms
Option SPARC Intel PowerPC
-dalign X -- --
-fns X X X
-fsimple=1 X -- X
-ftrap=%none X X X
-libmil X X X
-native X X X
Table 2-2 -fast selections across platforms
-nofstore -- X --
-xO4 X X X
-fsingle X X X
-fast acts like a macro expansion on the command line. Therefore, the optimization level and code generation option aspects can be overridden by following -fast with the desired optimization level or code generation option. As far as optimization level is concerned, compiling with the -fast -xO4 pair is like compiling with the -xO2 -xO4 pair. The latter specification takes precedence.
In previous releases, the -fast macro option included -fnonstd; now it includes -fns instead.
You can usually improve performance for most programs with this option.

-fd

Reports K&R-style function definitions and declarations.

-flags

Prints a summary of each compiler option.

-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 are converted into SIGFPE signals; if the program has no SIGFPE handler, it terminates with a memory dump.
By default, IEEE 754 floating-point arithmetic is nonstop, and underflows are gradual. (See "Nonstandard Floating Point" on page 65 for a further explanation.)
(SPARC) Synonym for -fns -ftrap=common.

-fns

(SPARC) Turns on the SPARC nonstandard floating-point mode.
The default is the SPARC 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) -fprecision={single, double , extended} Initializes the rounding precision mode bits in the Floating-point Control Word to single (24 bits), double (53 bits), or extended (64 bits), respectively. The default floating-point rounding-precision mode is extended.
Note that on Intel, only the precision, not exponent range is affected by the setting of floating-point rounding precision mode.

-fround=r

Sets the IEEE 754 rounding mode that is established at runtime during the program initialization.
r must be one of: nearest, tozero, negative, positive.
The default is -fround=nearest.
The meanings are the same as those for the ieee_flags 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:
  • With no -fsimple[=n], the compiler uses -fsimple=0
  • With only -fsimple, no =n, the compiler uses -fsimple=1
-fsimple=0

  Permits no simplifying assumptions. Preserve strict IEEE 754 conformance.

-fsimple=1
Allows conservative simplifications. 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:
  • IEEE 754 default rounding/trapping modes do not change after process initialization.
  • Computations producing no visible result other than potential floating point exceptions may be deleted.
  • Computations with Infinity or NaNs as operands need not propagate NaNs to their results; e.g., x*0 may be replaced by 0.
  • Computations do not depend on sign of zero.
With -fsimple=1, the optimizer is not allowed to optimize completely without regard to roundoff or exceptions. In particular, a floating-point computation cannot be replaced by one that produces different results with rounding modes held constant at runtime. -fast implies -fsimple=1.
-fsimple=2
Permits aggressive floating point optimizations that may cause many programs to produce different numeric results due to changes in rounding. For example, permit 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.

-fsingle

(-Xt and -Xs modes only) Causes the compiler to evaluate float expressions as single precision rather than double precision. This option has no effect if the compiler is used in either -Xa or -Xc modes, as float expressions are already evaluated as single precision.

-fstore

(Intel) Causes the compiler to convert the value of a floating-point expression or function to the type on the left-hand side of an assignment, when that expression or function is assigned to a variable, or when the expression is cast to a shorter floating-point type, rather than leaving the value in a register. Due to roundoffs and truncation, the results may be different from those that are generated from the register value. 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.
Example: -ftrap=%all,no%inexact means set all traps, except inexact.
The meanings are the same as for the ieee_flags subroutine, except that:
  • %all turns on all the trapping modes.
  • %none, the default, turns off all trapping modes.
  • A no% prefix turns off that specific trapping mode.
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

Passes the option to the link editor to produce a shared object rather than a dynamically linked executable. This option is passed to ld(1), and cannot be used with the -dn option.

-g

Produces additional symbol table information for the debugger.
This option also uses the incremental linker; see -xildon and -xildoff.
When used with the -O option, a limited amount of debugging is available. The combination, -xO4 -g, turns off the inlining that you usually get with -xO4.

-H

Prints to standard output, one per line, the path name of each file included during the current compilation. The display is indented so as to show which files are included by other files.
Here, the program sample.c includes the files, stdio.h and math.h; math.h includes the file, floatingpoint.h, which itself includes functions that use sys/ieeefp.h:

  % cc -H sample.c
       /usr/include/stdio.h
       /usr/include/math.h
            /usr/include/floatingpoint.h
                 /usr/include/sys/ieeefp.h

-h name

Assigns a name to a shared dynamic library as a way to have different versions of a library. In general, the name after -h should be the same as the file name given after the -o option. The space between -h and name is optional.
The linker assigns the specified name to the library and records the name in the library file as the intrinsic name of the library. If there is no -hname option, then no intrinsic name is recorded in the library file.
When the runtime linker loads the library into an executable file, it copies the intrinsic name from the library file into the executable, into a list of needed shared library files. Every executable has such a list. If there is no intrinsic name of a shared library, then the linker copies the path of the shared library file instead.

-Idir

Adds dir to the list of directories that are searched for #include files with relative file names, that is, those not beginning with a / (slash).
The preprocessor first searches for #include files in the directory containing sourcefile, then in directories named with -I options, if any, and finally, in /usr/include or the directory specified by -YI.

-i

Passes the option to the linker to ignore any LD_LIBRARY_PATH setting.

-keeptmp

Retains temporary files created during compilation instead of deleting them automatically.

-KPIC

Produces position-independent code for use in shared libraries. 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.
(SPARC) (PowerPC) With this option, the global offset table spans the range of 32-bit addresses in those rare cases where there are too many global data objects for -Kpic.
(Intel) -KPIC is identical to -Kpic.

-Kpic

Produces position-independent code for use in shared libraries.
(SPARC) (PowerPC) It is similar to -KPIC, but the size of the global offset table is limited to 8Kbytes.
There are two nominal performance costs with -Kpic and -KPIC:
  • A routine compiled with either -Kpic or -KPIC 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 -KPIC, there are two additional instructions per global and static memory reference.
When considering the above costs, remember that the use of -Kpic and -KPIC can significantly reduce system memory requirements, due to the effect of library code sharing. Every page of code in a shared library compiled -Kpic or -KPIC 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 -Kpic or -KPIC 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 -Kpic or -KPIC, 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 -KPIC.

-Ldir

Adds dir to the list of directories searched for libraries by ld(1). This option and its arguments are passed to ld.

-lname

Links with object library libname.so, or libname.a. The order of libraries in the command-line is important, as symbols are resolved from left to right.
This option must follow the sourcefile arguments.

-mc

Removes duplicate strings from the .comment section of the object file. When you use the -mc flag, mcs -c is invoked.

-misalign

(SPARC, PowerPC) Informs the compiler that the data in your program is not properly aligned, as 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 data, one byte at a time. Using this option can cause significant degradation in the performance when you run the program. If you compile and link in separate steps, compiling with the -misalign option requires the option on the link step as well.

-misalign2

(SPARC, PowerPC) Like -misalign, assumes that data is not properly aligned, but that data is at least halfword-aligned. Though conservative uses of loads and stores must be used for data, the performance degradation when running a program is less than that seen for -misalign. If you compile and link in separate steps, compiling with the -misalign2 option requires the option on the link step as well.

-mr

Removes all strings from the .comment section. When you use this flag, mcs -d is invoked.

-mr,string

Removes all strings from the .comment section and inserts string in that section of the object file. If string contains embedded blanks, it must be enclosed in quotation marks. A null string results in an empty .comment section. This option is passed as -d "string" to mcs.

-mt

Passes -D_REENTRANT to the preprocessor. Appends -lthread. If you are doing your own multithread coding, you must use this option in the compile and link steps. To obtain faster execution, this option requires a multiprocessor system. On a single-processor system, the resulting executable usually runs more slowly with this option.

-native

Ascertains which code-generation options (SPARC) or which processor (Intel) (PowerPC) are available on the machine running the compiler, and directs the compiler to generate code targeted for that machine.
This option is a synonym for -xtarget=native.
The -fast macro includes -native in its expansion.

-nofstore

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

-noqueue

Instructs the compiler not to queue this compile request if a license is not available. Under normal circumstances, if no license is available, the compiler waits until one becomes available. With this option, the compiler returns immediately.

-O

Same as -xO2.

-o filename

Names the output file filename (as opposed to the default, a.out). filename cannot be the same as sourcefile, since cc does not overwrite the source file. This option and its arguments are passed to ld(1).

-P

Runs the source file through the C preprocessor only. It then puts the output in a file with a .i suffix. Unlike -E, this option does not include preprocessor-type line number information in the output. See also the -E option.

-p

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

-Q[y|n]

Emits or does not emit identification information to the output file. -Qy is the default.
If -Qy is used, identification information about each invoked compilation tool is added to the .comment section of output files, which is accessible with mcs. This option can be useful for software administration.
-Qn supresses this information.

-qp

Same as -p.

-Rdir[:dir]

Passes a colon-separated list of directories used to specify library search directories to the runtime linker. If present and not null, it is recorded in the output object file and passed to the runtime linker.
If both LD_RUN_PATH and the -R option are specified, the -R option takes precedence.

-S

Directs cc to produce an assembly source file but not to assemble the program.

-s

Removes all symbolic debugging information from the output object file. This option cannot be specified with -g.
Passed to ld(1).

-Uname

Removes any initial definition of the preprocessor symbol name. This option is the inverse of the -D option. You can give multiple -U options.

-V

Directs cc to print the name and version ID of each pass as the compiler executes.

-v

Directs the compiler to perform stricter semantic checks and to enable other lint-like checks. For example, the code:

  #include <stdio.h>
  main(void)
  {
      printf("Solipsism isn't for everybody.\n");
  }
compiles and executes without problem. With -v, it still compiles; however, the compiler displays this warning:
"solipsism.c", line 5:  warning:  function has no return
    statement: main
-v does not give all the warnings that lint(1) does. Try running the above example through lint.

-Wc,arg

Passes the argument arg to a specified component c. Each argument must be separated from the preceding only by a comma. All -W arguments are passed after the regular command-line arguments. A comma can be part of an argument by escaping it by an immediately preceding \ (backslash) character.
c can be one of the following:
a Assembler: (fbe) ; (gas)
c C code generator: (cg) (SPARC); (codegen) (Intel)(PowerPC)
l Link editor (ld)
m mcs (Solaris 2.x)
p Preprocessor (cpp)
0 Compiler (acomp and ssbd)
2 Optimizer: (iropt) (SPARC); intermediate code translator: (cg386) (Intel), (cgppc) (PowerPC)

-w

Suppresses compiler warning messages.

-X[a|c|s|t]

The -X (note uppercase X) options specify varying degrees of compliance to the ANSI C standard. -Xa is the default mode.
-Xa
(a = ANSI) ANSI C plus K&R C compatibility extensions, with semantic changes required by ANSI C. Where K&R C and ANSI C specify different semantics for the same construct, the compiler issues warnings about the conflict and uses the ANSI C interpretation. This is the default compiler mode.
-Xc
(c = conformance) Issues errors and warnings for programs that use non-ANSI C constructs. This option is maximally conformant ANSI C, without K&R C compatibility extensions.
-Xs
(s = K&R C) Attempts to warn about all language constructs that have differing behavior between ANSI C and K&R C. The compiler language includes all features compatible with K&R C. This option invokes /usr/ccs/lib/cpp for preprocessing. __STDC__ is not defined in this mode. Differences between ANSI C and K&R C are discussed in the C 4.2 Transition Guide.
-Xt
(t = transition) This option uses ANSI C plus K&R C compatibility extensions without semantic changes required by ANSI C. Where K&R C and ANSI C specify different semantics for the same construct, issues warnings about the conflict and uses the K&R C interpretation.

-x386

(Intel) Optimizes for the 80386 processor.

-x486

(Intel) Optimizes for the 80486 processor.

-xa

Inserts code to count how many times each basic block is executed. This option is the old style of basic block profiling for tcov. See -xprofile=p for information on the new style of profiling and the tcov(1) man page for more details. See also the Profiling Tools manual.
Invokes a runtime recording mechanism that creates a .d file for every .c file at normal termination. The .d file accumulates execution data for the corresponding source file. tcov(1) can then be run on the source file to generate statistics about the program. Since this option entails some optimization, it is incompatible with -g.
If set at compile-time, the TCOVDIR environment variable specifies the directory where the .d files are located. If this variable is not set, the .d files remain in the same directory as the .c files.
The -xprofile=tcov and the -xa 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 -xa. You cannot compile a single file with both options.

-xarch=a

Specifies the set of instructions the compiler may use.
a must be one of: generic, v7, v8a, v8, v8plus, v8plusa, 386, pentium_pro, ppc, ppc_nofma.
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 of the specified architecture, and allows the specified set of instructions. The option does not guarantee the specified set is used; however, under optimization, the set 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.
v7, v8, and v8a are all binary compatible. v8plus and v8plusa are binary compatible with each other and forward, but not backward. For any particular choice, the generated executable can run much more slowly on earlier architectures (to the left in the above list).
Table 2-3 The -xarch Values
Value Meaning
generic Gets good performance on most Intel, PowerPC and SPARC architectures, major degradation on none.

This is the default. This option uses the best instruction set for good performance on most Intel, PowerPC, and 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 V8 architecture.

Example: Any machine based on MicroSPARC(TM)I chip architecture.

Table 2-3 The -xarch Values (Continued)
Value Meaning
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, or V8+, 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 V8+ architecture. In V8+, 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(TM)chip architecture.

Use of this option also causes the .o file to be marked as a V8+ binary; such files will not run on a v7 or v8 machine.

v8plusa Limits instruction set to the V8plusa version of the V9 architecture. 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 UltraSPARC architecture but limited to the 32-bit subset defined by the V8+ 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 V8+ binary; such files will not run on a v7 or v8 machine.

Table 2-3 The -xarch Values (Continued)
Value Meaning
386 Limits instruction set to the Intel x86 architecture.
pentium_pro Limits instruction set to the Intel pentium_pro architecture.
ppc Limits instruction set to the PowerPC architecture.
ppc_nofma Same as ppc but will not issue "fused multipy-add" instruction.

-xautopar

(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 emitted.
Avoid -xautopar if you do your own thread management.
Parallelization options require a WorkShop license. To get faster execution, this option requires a multiple processor system. On a single-processor system, the resulting binary usually runs slower.
To determine how many processors you have, use the psrinfo command:

  % psrinfo
  0   on-line      since 01/12/95 10:41:54
  1   on-line      since 01/12/95 10:41:54
  2   on-line      since 01/12/95 10:41:54
  3   on-line      since 01/12/95 10:41:54
To request a number of processors, set the PARALLEL environment variable. The default is 1.
  • Do not request more processors than are available.
  • If N is the number of processors on the machine, then for a one-user, multiprocessor system, try PARALLEL=N-1.
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.

-xcache=c

Defines the cache properties for use by the optimizer.
c must be one of the following:
  • generic (SPARC,Intel)
  • s1/l1/a1
  • s1/l1/a1:s2/l2/a2
  • s1/l1/a1:s2/l2/a2:s3/l3/a3
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.
This option specifies the cache properties that the optimizer can use. It does not guarantee that any particular cache property is used.
Table 2-4 The -xcache Values
Value Meaning
generic Define the cache properties for good performance on most Intel, PowerPC, and SPARC architectures.

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

With each new release, these best timing properties will be adjusted, if appropriate.

s1/l1/a1 Define level 1 cache properties.
s1/l1/a1:s2/l2/a2 Define levels 1 and 2 cache properties.
s1/l1/a1:s2/l2/a2:s3/l3/a3 Define levels 1, 2, and 3 cache properties.
Example: -xcache=16/32/4:1024/32/1 specifies the following:
Level 1 cache has: Level 2 cache has:
16K bytes 1024K bytes
32 bytes line size 32 bytes line size
4-way associativity Direct mapping associativity

-xCC

Accepts the C++-style comments. In particular, // can be used to indicate the start of a comment.

-xcg[89|92]

(SPARC).
-xcg89 is a macro for: -xarch=v7 -xchip=old -xcache=64/32/1.
-xcg92 is a macro for: -xarch=v8 -xchip=super -xcache=16/32/4:1024/32/1.

-xchip=c

Specifies the target processor for use by the optimizer.
c must be one of the following: generic, old, super, super2, micro,
micro2, hyper, hyper2, powerup, ultra,386,486,pentium,
pentium_pro, 603, 604.
Although this option can be used alone, it is part of the expansion of the -xtarget option; its primary use is to override a value supplied by the -xtarget option.
This option specifies timing properties by specifying the target processor.
Some effects are:
  • The ordering of instructions, that is, scheduling
  • The way the compiler uses branches
  • The instructions to use in cases where semantically equivalent alternatives are available
Table 2-5 The -xchip Values
Value Meaning
generic Use timing properties for good performance on most Intel, PowerPC, and SPARC architectures.

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

old Uses timing properties of pre-SuperSPARC(TM) processors.
super Uses timing properties of the SuperSPARC chip.
super2 Uses timing properties of the SuperSPARC II chip.
micro Uses timing properties of the microSPARC chip.
micro2 Uses timing properties of the microSPARC II chip.
hyper Uses timing properties of the hyperSPARC(TM) chip.
hyper2 Usse timing properties of the hyperSPARC II chip.
powerup ® Uses timing properties of the Weitek PowerUp(TM) chip.
ultra Uses timing properties of the UltraSPARC chip.
386 Uses timing properties of the Intel 386 architecture.
486 Uses timing properties of the Intel 486 architecture
pentium Uses timing properties of the Intel pentium architecture
pentium_pro Uses timing properties of the Intel pentium_pro architecture
603 Uses timing properties of the PowerPC 603 chip.
604 Uses timing properties of the PowerPC 604 chip.

-xcrossfile

(SPARC) Enables optimization and inlining across source files.
Only effective with -xO4 or -xO5, the compiler is allowed to analyze all the files on the command line as if they had been concatenated into a single file.

-xdepend

(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, optimization is raised to -xO3 and a warning is issued.
Dependency analysis is also included with -xautopar or -xparallel. The dependency analysis is done at compile time.
Dependency analysis may help on single-processor systems. However, if you try -xdepend on single-processor systems, you should not use either -xautopar or -xexplicitpar. If either of them is on, then the -xdepend optimization is done for multiple-processor systems.

-xe

Performs only syntax and semantic checking on the source file, but does not produce any object or executable code.

-xexplicitpar

(SPARC) Generates parallelized code based on specification of #pragma MP directives. You do the dependency analysis: analyze and specify loops for inter-iteration data dependencies. The software parallelizes the specified loops. If optimization is not at -xO3 or higher, optimization is raised to -xO3 and a warning is issued. Avoid -xexplicitpar if you do your own thread management.
Parallelization options require a WorkShop license. To get faster code, this option requires a multiprocessor system. On a single-processor system, the generated code usually runs slower.
If you indentify a loop for parallelization, and the loop has dependencies, you can get incorrect results, possibly different ones with each run, and with no warnings. Do not apply an explicit parallel pragma to a reduction loop. The explicit parallelization is done, but the reduction aspect of the loop is not done, and the results can be incorrect.
In summary, to parallelize explicitly:
  • Analyze the loops to find those that are safe to parallelize.
An example of inserting a parallel pragma immediately before the loop is:

  #pragma MP taskloop
    for (j=0; j<1000; j++){
    ...
    }
If you use -xexplicitpar and compile and link in one step, then linking automatically includes the microtasking library and the threads-safe C runtime library. If you use -xexplicitpar and compile and link in separate steps, then you must also link with -xexplicitpar.

-xF

Enables performance analysis of the executable using the Analyzer. (See the analyzer(1) man pages.) Produces code that can be reordered at the function level. Each function in the file is placed in a separate section; for example, functions foo() and bar() are placed in the sections .text%foo and .text%bar, respectively. Function ordering in the executable can be controlled by using -xF in conjunction with the -M option to ld (see ld(1)). This option also causes the assembler to generate some debugging information in the object file, necessary for data collection.

-xhelp=f

Displays on-line help information.
f must be one of: flags, readme, or errors.
-xhelp=flags displays a summary of the compiler options.
-xhelp=readme displays the README file.
-xhelp=errors displays the Error and Warning Messages file.

-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, or you do use the -G option, or any source files are present on the command line. 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, and you do not use the -G option, and there are no source files present on the command line. Override this default by using the -xildoff option.

-xinline=[f1,...,fn]

Tries to inline only those named in the list f1 to fn for user-written routines. The list is a comma-separated list of functions and subroutines.
If you are compiling with -xO3, you can use this option to increase optimization by inlining some routines. The -xO3 option does not inline by itself.
If you are compiling with -xO4, using this option can decrease optimization by restricting inlining to only those routines in the list. With -xO4, the compiler normally tries to inline all user-written subroutines and functions. When xinline= is specified with an empty rlst, it indicates that none of the routines in the source file are to be inlined.
A routine is not inlined if any of the following conditions apply. No warning is issued.
  • Optimization is less than -xO3.
  • The routine cannot be found.
  • Inlining the routine does not look practicable to the optimizer.
  • Source for the routine is not in the file being compiled (however, see -xcrossfile).

-xlibmieee

Forces IEEE 754 style return values for math routines in exceptional cases. In such cases, no exception message is printed, you should not rely on errno.

-xlibmil

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

-xlic_lib=l

(SPARC, Intel) Links in the Sun-supplied licensed libraries specified in l, where l is a comma-separated list of libraries.

-Xlic_lib=sunperf

Links with specified Sun-supplied licensed libraries. Specifies a comma-separated list of license-controlled libraries to link with. For example:
cc -o pgx pgx.c -xlic_lib=sunpref
This option, like -l, should appear at the end of the command line, after source or object filenames.

-xlicinfo

Returns information about the licensing system. In particular, this option returns the name of the license server and the IDs of users who have checked out licenses. When you give this option, the compiler is not invoked, and a license is not checked out.

-xloopinfo

(SPARC) Shows which loops are parallelized and which are not. Gives a short reason for not parallelizing a loop. The -xloopinfo option is valid only if -xautopar, or -xparallel, or -xexplicitpar is specified; otherwise, the compiler issues a warning.
Parallelization options require a WorkShop license. To get faster code, this option requires a multiprocessor system. On a single-processor system, the generated code usually runs slower.

-xM

Runs only the macro preprocessor on the named C programs, requesting that it generate makefile dependencies and send the result to the standard output (see make(1) for details about makefiles and dependencies).
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

-xM1

Collects dependencies like -xM, but excludes /usr/include files.For example:

  more hello.c
  #include<stdio.h>
  main()
  {
   (void)printf("hello\n");
  }
  cc -xM hello.c
  hello.o: hello.c
  hello.o: /usr/include/stdio.h
Compilng with -xM1 does not report header file dependencies:

  cc -xM1 hello.c
  hello.o: hello.c

-xMerge

Merges data segments into text segments. Data initialized in the object file produced by this compilation is read-only and (unless linked with ld -N) is shared between processes.

-xnolib

Does not link any libraries by default; that is, no -l options are passed to ld. Normally, the cc driver passes -lc to ld.
When you use -xnolib, you have to pass all the -l options yourself. For example:
% cc test.c -xnolib -Bstatic -lm -Bdynamic -lc
links libm statically and the other libraries dynamically.

-xnolibmil

Does not inline math library routines. Use it after the -fast option. For example: % cc -fast -xnolibmil....

-xO[1|2|3|4|5]

Optimizes the object code. Specifying -xO is equivalent to specifying -xO2.
When -O is used with the -g option, a limited amount of debugging is available.
The levels (1, 2, 3, 4, or 5) you can use with -xO differ according to the platform you are using.
(SPARC)
-xO1
   Does basic local optimization (peephole).

-xO2
Does basic local and global optimization. This is 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, and complex expression expansion.
The -xO2 level does not assign global, external, or indirect references or definitions to registers. It treats these references and definitions as if they were declared volatile. In general, the -xO2 level results in minimum code size.
-xO3
Performs like -xO2, but also optimizes references or definitions for external variables. Loop unrolling and software pipelining are also performed. This level does not trace the effects of pointer assignments. When compiling either device drivers, or programs that modify external variables from within signal handlers, you may need to use the volatile type qualifier to protect the object from optimization. In general, the -xO3 level results in increased code size.
-xO4
Performs like -xO3, but also automatically inlines functions contained in the same file; this usually improves execution speed. This level traces the effects of pointer assignments, and usually results in increased code size.
-xO5
   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.
(Intel) (PowerPC)
-xO1
   Preloads arguments from memory, cross-jumping (tail-merging), as well
   as the single pass of the default optimization.

-xO2
Schedules both high- and low-level instructions and performs improved spill analysis, loop memory-reference elimination, register lifetime analysis, enhanced register allocation, and elimination of global common subexpressions.
-xO3
   Performs loop strength reduction, induction variable elimination, as well
   as the optimization done by level 2.

-xO4
Performs loop unrolling, avoids creating stack frames when possible, and automatically inlines functions contained in the same file, as well as the optimization done by levels 2 and 3. Note that this optimization level can cause stack traces from adb and dbx to be incorrect.
-xO5
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. Some of these include generating local calling convention entry points for exported functions, further optimizing spill code and adding analysis to improve instruction scheduling.
If the optimizer runs out of memory, it tries to recover by retrying the current procedure at a lower level of optimization and resumes subsequent procedures at the original level specified in the command-line option.
If you optimize at -xO3 or -xO4 with very large procedures (thousands of lines of code in the same procedure), the optimizer may require a large amount of virtual memory. In such cases, machine performance may degrade.

-xP

Prints prototypes for all K&R C functions defined in this module.

  f()
  {
  }

  main(argc,argv)
  int argc;
  char *argv[];
  {
  }
produces this output:

  int f(void);
  int main(int, char **);

-xparallel

(SPARC) Parallelizes loops both automatically by the compiler and explicitly specified by the programmer. The -xparallel option is a macro, and is equivalent to specifying all three of -xautopar, -xdepend, and -xexplicitpar. With explicit parallelization of loops, there is a risk of producing incorrect results. If optimization is not at -xO3 or higher, optimization is raised to -xO3 and a warning is issued.
Avoid -xparallel if you do your own thread management.
Parallelization options require a WorkShop license. To get faster code, this option requires a multiprocessor system. On a single-processor system, the generated code usually runs slower.
If you compile and link in one step, -xparallel links with the microtasking library and the threads-safe C runtime library. If you compile and link in separate steps, and you compile with -xparallel, then link with -xparallel

-xpentium

(Intel) Optimizes for the Pentium(TM) processor.

-xpg

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

-xprofile=p

Collects data for a profile or uses a profile to optimize.
(SPARC) p must be collect[:name], use[:name], or tcov.
(Intel) (PowerPC) p must be tcov.
This option causes execution frequency data to be collected and saved during execution, then the data can be used in subsequent runs to improve performance. This option is only valid when you specify a level of optimization.
collect[:name]
Collects and saves execution frequency data for later use by the optimizer with -xprofile=use. The compiler generates code to measure statement execution frequency.
The name is the name of the program that is being analyzed. This name is optional. If name is not specified, a.out is assumed to be the name of the executable.
At runtime a program compiled with -xprofile=collect:name will create the subdirectory name.profile to hold the runtime feedback information. Data is written to the file feedback in this subdirectory. 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.
use[:name]
Uses execution frequency data to optimize strategically.
As with collect:name, the name is optional and may be used to specify the name of the program.
The program is optimized by using the execution frequency data previously generated and saved in the feedback files written by a previous execution of the program compiled with -xprofile=collect.
The source files and other compiler options must be exactly the same as those used for the compilation that created the compiled program that generated the feedback file. If compiled with -xprofile=collect:name, the same program name name must appear in the optimizing compilation: -xprofile=use:name.
tcov
  Basic block coverage analysis using "new" style tcov.
The -xprofile=tcov 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. See -xa for information on the old style of profiling, the tcov(1) man page, and the Performance Profiling Tools manual for more details.
Code instrumentation is performed similarly 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, the data file is stored in /foo/bar/myprog.profile/myprog.tcovd.
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 others with -xa. You cannot compile a single file with both options.
When running tcov, you must pass it the -x option to make it use the new style of data. If not, tcov uses the old .d files, if any, by default for data, 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. See tcov(1) and the Performance Profiling Tools manual for more details.

-xreduction

(SPARC) Turns on reduction recognition during automatic parallelization. -xreduction must be specified with -xautopar, or -xparallel.
Parallelization options require a WorkShop license.
When reduction recognition is enabled, the compiler parallelizes reductions such as dot products, maximum and minimum finding. These reductions yield different roundoffs than obtained by unparallelized code.

-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-6 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.

Table 2-6 The -xregs Values
Value Meaning
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.

-xrestrict=f

(SPARC) Treats pointer-valued function parameters as restricted pointers. f is a comma-separated list that consists of one or more function parameters, %all, or %none.
If a function list is specified with this option, pointer parameters in the specified functions are treated as restricted; if -xrestrict=%all is specified, all pointer parameters in the entire C file are treated as restricted. Refer to Chapter 3, "Sun ANSI C Compiler-Specific Information", "_Restrict Keyword" on page 59, 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.c
treats all pointer parameters in the file prog.c as restricted pointers. The command:
%cc -xO3 -xrestrict=agc prog.c
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=%all.

-xs

Disables Auto-Read for dbx. Use this option in case you cannot keep the .o files around. It 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 distributed in the .o files, so that dbx loads the symbol table information only if and when it is needed. Hence, the linker links faster, and dbx initializes faster.
With -xs, if you move the executables to another directory, then to use dbx, you can ignore the object (.o) files.
Without -xs, if you move the executables, you must move both the source files and the object (.o) files, or set the path with the dbx pathmap or use command.

-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

Generates extra symbol table information for the SourceBrowser.This option is not valid with the -Xs mode of the compiler.

-xsbfast

Creates the database for the SourceBrowser. Does not compile source into an object file. This option is not valid with the -Xs mode of the compiler.

-xsfpconst

Represents unsuffixed floating-point constants as single precision, instead of the default mode of double precision. Not valid with -Xc.

-xspace

Does no optimizations or parallelization of loops that increase code size.
Example: The compiler will not unroll loops or parallelize loops if it increases code size.

-xstrconst

Inserts string literals into the read-only data section of the text segment instead of the default data segment.

-xtarget=t

Specifies the target system for instruction set and optimization.
t must be one of: native, generic, system-name (SPARC, Intel, ppc).
The -xtarget option is a macro that permits a quick and easy specification of the -xarch, -xchip, and -xcache combinations that occur on real systems. The only meaning of -xtarget is in its expansion.
Table 2-7 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-8 that lists the mnemonic
encodings of the actual system name and numbers.
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.
Each specific value for -xtarget expands into a specific set of values for the -xarch, -xchip, and -xcache options. See Table 2-8 for the values. For example:
-xtarget=sun4/15 is equivalent to: -xarch=v8a -xchip=micro -xcache=2/16/1
Table 2-8 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
Table 2-8 The -xtarget Expansions (Continued)
-xtarget -xarch -xchip -xcache
sslx v8a micro 2/16/1
sslx2 v8a micro2 8/16/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/16/1
ss4/85 v8a micro2 8/16/1
ss4/110 v8a micro2 8/16/1
ss5 v8a micro2 8/16/1
ss5/85 v8a micro2 8/16/1
ss5/110 v8a micro2 8/16/1
ssvyger 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
Table 2-8 The -xtarget Expansions (Continued)
-xtarget -xarch -xchip -xcache
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 v8 super 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/50 v8 super 16/32/4
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/151 v8 hyper 512/64/1
ss20/152 v8 hyper 512/64/1
ss20/502 v8 super 16/32/4
ss20/512 v8 super 16/32/4:1024/32/1
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
Table 2-8 The -xtarget Expansions (Continued)
-xtarget -xarch -xchip -xcache
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/512 v8 super 16/32/4:1024/32/1
ss600/514 v8 super 16/32/4:1024/32/1
ss600/612 v8 super 16/32/4:1024/32/1
ss1000 v8 super 16/32/4:1024/32/1
sc2000 v8 super 16/32/4:2048/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
ultra2 v8 ultra2 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/200 v8 ultra 16/32/1:512/64/1
ultra2/1170 v8 ultra 16/32/1:512/64/1
ultra2/1200 v8 ultra 16/32/1:1024/64/1
ultra2/1300 v8 ultra2 16/32/1:2048/64/1
ultra2/2170 v8 ultra 16/32/1:512/64/1
ultra2/2200 v8 ultra 16/32/1:1024/64/1
ultra2/2300 v8 ultra2 16/32/1:2048/64/1
entr2 v8 ultra 16/32/1:512/64/1
entr2/1170 v8 ultra 16/32/1:512/64/1
entr2/2170 v8 ultra 16/32/1:512/64/1
entr2/1200 v8 ultra 16/32/1:512/64/1
entr2/2200 v8 ultra 16/32/1:512/64/1
Table 2-8 The -xtarget Expansions (Continued)
-xtarget -xarch -xchip -xcache
entr150 v8 ultra 16/32/1:512/64/1
entr3000 v8 ultra 16/32/1:512/64/1
entr4000 v8 ultra 16/32/1:512/64/1
entr5000 v8 ultra 16/32/1:512/64/1
entr6000 v8 ultra 16/32/1:512/64/1
For PowerPC: -xtarget= accepts generic or native.
For Intel: -xtarget= accepts:
  • generic or native
  • 386 (equivalent to -386 option) or 486 (equivalent to -486 option)
  • pentium (equivalent to -pentium option) or pentium_pro

-xtemp=dir

Sets the directory for temporary files used by cc to dir. No space is allowed within this option string. Without this option, temporary files go into /tmp. -xtemp has precedence over the TMPDIR environment variable.

-xtime

Reports the time and resources used by each compilation component.

-xtransition

Issues warnings for the differences between K&R C and Sun ANSI C. The following warnings no longer appear unless the -xtransition option is used:
\a is ANSI C "alert" character
\x is ANSI C hex escape
bad octal digit
base type is really type tag: name
comment is replaced by "##"
comment does not concatenate tokens
declaration introduces new type in ANSI C: type tag
macro replacement within a character constant
macro replacement within a string literal
no macro replacement within a character constant
no macro replacement within a string literal
operand treated as unsigned
trigraph sequence replaced
ANSI C treats constant as unsigned: operator
semantics of operator change in ANSI C; use explicit cast

-xunroll=n

Suggests to the optimizer to unroll loops n times. n is a positive integer. When n is 1, it is a command, and the compiler unrolls no loops. When n is greater than 1, the -xunroll=n merely suggests to the compiler that it unroll loops n times.

-xvpara

(SPARC) Warns about loops that have #pragma MP directives specified when the loop may not be properly specified for parallelization. For example, when the optimizer detects data dependencies between loop iterations, it issues a warning.
Parallelization options require a WorkShop license.
Use -xvpara with the -xexplicitpar option or the -xparallel option and the #pragma MP. See the Section , "Explicit Parallelization and Pragmas" in Chapter , "Sun ANSI C Compiler-Specific Information," for more information.

-Yc, dir

Specifies a new directory dir for the location of component c. c can consist of any of the characters representing components that are listed under the -W option.
If the location of a component is specified, then the new path name for the tool is dir/tool. If more than one -Y option is applied to any one item, then the last occurrence holds.

-YA, dir

Changes the default directory searched for components.

-YI, dir

Changes the default directory searched for include files.

-YP, dir

Changes the default directory for finding libraries files.

-YS, dir

Changes the default directory for startup object files.

-Zll

(SPARC) Creates the program database for lock_lint, but does not actually compile. Refer to the lock_lint(1) man page for more details.

-Zlp

(SPARC) Prepares object files for the loop profiler, looptool. The looptool(1) utility can then be run to generate loop statistics about the program. Use this option with -xdepend; if -xdepend is not explicitly or implicitly specified, turns on -xdepend and issues a warning. If optimization is not at -xO3 or higher, optimization is raised to -xO3 and a warning is issued. Generally, this option is used with one of the loop parallelization options: -xexplicitpar, -xautopar, or -xparallel.
Parallelization options require a WorkShop license. To get faster code, this option requires a multiprocessor system. On a single-processor system, the generated code usually runs slower.
If you compile and link in separate steps, and you compile with -Zlp, then be sure to link with -Zlp.
If you compile one subprogram with -Zlp, you need not compile all subprograms of that program with -Zlp. However, you get loop information only for the files compiled with -Zlp, and no indication that the program includes other files.

-Ztha

(SPARC) Prepares code for analysis by the Thread Analyzer, the performance analysis tool for multithreaded code. The -Ztha instrumentation performs two actions. It inserts calls to the profiling library at all procedure entries and exits in much the same way the -p does. However, instead of linking with the profiled libraries in /usr/lib/libp, code compiled with
-Ztha links with the library libtha.so.

Options Passed to the Linker

cc recognizes -a, -e, -r, -t, -u, and -z and passes these options and their arguments to ld. cc passes any unrecognized options to ld with a warning.

Localization of Error Messages

The messages from the C compiler, and lint, can be localized using gencat. See gencat(1) and catges(3C) for more information on message catalogs.
The C compiler message text source file can be found relative to where the C compiler is installed. Using the default installation directory, the C compiler message text source files can be found in
/opt/SUNWspro/SC4.2/lib/locale/C/LC_MESSAGES.
The C compiler message text source files are named:
SUNW_SPRO_SC_acomp.msg (C front end components acomp and ssbd)
SUNW_SPRO_SC_cc.msg        (cc and lint command)
After translating the messages, the gencat utility can be used to create the formatted message database catfiles. The C compiler uses these catfiles when issuing messages. In order for the C compiler to use the formatted message database catfiles, they must be:
  • Named corretly
  • Installed in the default location for the locale being used
  • Referenced via the correct path in the environment variable NLSPATH
The formatted message database catfiles must be named:
SUNW_SPRO_SC_acomp.cat (c front end components acomp & ssbd)
SUNW_SPRO_SC_cc.cat       (cc and lint command)
To enable all users to use the message database catfiles, they should be installed in the proper location based on the locale. For example, if the locale is French (fr), and using the default installation of the C compiler, these files must reside in the directory: /opt/SUNWspro/SC4.2/lib/locale/fr/LC_MESSAGES and the environment variable LC_MESSAGES must be set to "fr" prior to invoking the cc command:
using csh shell:
% setenv LC_MESSAGES fr
Using sh shell:
$ LC_MESSAGES= fr
$ export LC_MESSAGES
Alternatively, they can be installed in a directory of choice and accessed by the C compiler by setting NLSPATH prior to invoking the C compiler. For example, if they are installed in /usr/local/MyMessDir.NLSPATH can be set as follows:
Using csh shell:
% setenv NLSPATH /usr/local/MyMessDir/%N.cat:$NLSPATH
Using sh shell:
$ NLSPATH=/usr/local/MyMessDir/%N.cat:$NLSPATH
$ export NLSPATH

Note - These formatted message database catfiles are shared between the cc and lint commands. For messages not translated, the default C locale translation is used.

cflow(1) and cxref(1) have their own message catalogs:
SUN_SPRO_SC_cflow.msg       SUNW_SPRO_SC_cflow.cat          cflow command
SUNW_SPRO_SC_cxref.msg SUNW_SPRO_SC_cxref.cat               cxref command