A P P E N D I X  A

C Compiler Options

This chapter describes the C compiler options. Take note that the C compiler recognizes by default some of the constructs of the 1999 ISO/IEC C standard. Specifically, the supported features are detailed in See Supported Features of C99. Use the -xc99=%none command if you want to limit the compiler to the 1990 ISO/IEC C standard.

If you are porting a K&R C program to ISO C, make special note of the section on compatibility flags, Section A.3.59, -X[c|a|t|s]. Using them makes the transition to ISO C easier. Also refer to the discussion on the transition in Chapter 7.


A.1 Option Syntax

The syntax of the cc command is:

% cc [options] filenames [libraries]...

where:

  • options represents one or more of the options described in Section A.3, The cc Options
  • 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
    • Inline template files, with a .il suffix (only when specified with .c files)
    • 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/prod/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).


A.2 Options Summary

In this section, the compiler options are grouped by function to provide an easy reference. The details are in the sections of the following pages. The following table summarizes the cc compiler options by functionality. Some flags serve more than one purpose and appear more than once.

TABLE A-1 Compiler Options Grouped by Functionality

Licensing

Option Flag

 

Returns information about the licensing system.

-xlicinfo

Optimization and Performance

Option Flag

 

Selects the optimum combination of compilation options for speed of executable code.

-fast

 

Prepares the object code to collect data for profiling

-p

 

Optimizes for the 80386 processor.

-x386

 

Optimizes for the 80486 processor.

-x486

 

Enables the compiler to perform type-based alias analysis and optimizations.

-xalias_level

 

Improve the optimization of code that calls standard library functions.

-xbuiltin

 

Enables optimization and inlining across source files.

-xcrossfile

 

Analyzes loops for inter-iteration data dependencies and does loop restructuring.

-xdepend

 

Enables performance analysis of the executable using the Analyzer.

-xF

 

Tries to inline only those functions specified.

-xinline

 

Performs whole-program optimizations by invoking an interprocedural analysis component.

-xipo

 

Inlines some library routines for faster execution.

-xlibmil

 

Links in the Sun-supplied performance libraries.

-xlic_lib=
sunperf

 

This command limits the level of pragma opt to the level specified.

-xmaxopt

 

Does not inline math library routines.

-xnolibmil

 

Optimizes the object code.

-x0

 

Optimizes for the Pentiumtrademark processor.

-xpentium

 

Enable prefetch instructions.

-xprefetch

 

Control the aggressiveness of automatic insertion of prefetch instructions as set by -xprefetch=auto

-xprefetch_level

 

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

-xprofile

 

Treats pointer-valued function parameters as restricted pointers.

-xrestrict

 

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

-xsafe

 

Does no optimizations or parallelization of loops that increase code size.

-xspace

 

Suggests to the optimizer to unroll loops n times.

-xunroll

Data Alignment

Option Flag

 

Produce an integer constant by placing the characters of a multi-character character-constant in the specified byte order.

-xchar_byte_order

 

Specify maximum assumed memory alignment and behavior of misaligned data accesses.

-xmemalign

Numerics and Floating-Point

Option Flag

 

Causes nonstandard initialization of floating-point arithmetic hardware.

-fnonstd

 

Turns on the SPARC nonstandard floating-point mode.

-fns

 

Initializes the rounding-precision mode bits in the Floating-point Control Word

-fprecision

 

Sets the IEEE 754 rounding mode that is established at runtime during the program initialization.

-fround

 

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

-fsimple

 

Causes the compiler to evaluate float expressions as single precision rather than double precision.

-fsingle

 

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

-fstore

 

Sets the IEEE 754 trapping mode in effect at startup.

-ftrap

 

Does not convert the value of a floating-point expression or function to the type on the left-hand side of an assignment

-nofstore

 

Forces IEEE 754 style return values for math routines in exceptional cases.

-xlibmieee

 

Represents unsuffixed floating-point constants as single precision

-xsfpconst

 

Enable automatic generation of calls to the vector library functions.

-xvector

Parallelization

Option Flag

 

Macro option that expands to -D_REENTRANT -lthread.

-mt

 

Turns on automatic parallelization for multiple processors.

-xautopar

 

Adds a runtime check for stack overflow.

-xcheck

 

Analyzes loops for inter-iteration data dependencies and does loop restructuring.

-xdepend

 

Generates parallelized code based on specification of #pragma MP directives.

-xexplicitpar

 

Shows which loops are parallelized and which are not.

-xloopinfo

 

Supports the OpenMP interface for explicit parallelization including a set of source code directives, run-time library routines, and environment variables

-xopenmp

 

Parallelizes loops both automatically by the compiler and explicitly specified by the programmer.

-xparallel

 

Turns on reduction recognition during automatic parallelization.

-xreduction

 

Treats pointer-valued function parameters as restricted pointers.

-xrestrict

 

Warns about loops that have #pragma MP directives specified but may not be properly specified for parallelization.

-xvpara

 

Creates the program database for lock_lint, but does not generate executable code.

-Zll

Source Code

Option Flag

 

Associates name as a predicate with the specified tokens as if by a #assert preprocessing directive.

-A

 

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

-C

 

Associates name with the specified tokens as if by a #define preprocessing directive.

-D

 

Runs the source file through the preprocessor only and sends the output to stdout.

-E

 

Reports K&R-style function definitions and declarations.

-fd

 

Prints to standard error, one per line, the path name of each file included during the current compilation.

-H

 

Adds directories to the list that is searched for #include files with relative file names.

-I

 

Runs the source file through the C preprocessor only.

-P

 

Removes any initial definition of the preprocessor symbol name.

-U

 

Accepts the C++-style comments.

-xCC

 

Controls compiler recognition of supported C99 features.

-xc99

 

Helps with migration from systems where char is defined as unsigned.

-xchar

 

Allows the C compiler to accept source code written in locales that do not conform to the ISO C source character code requirements

-xcsi

 

Runs only the preprocessor on the named C programs, requesting that it generate makefile dependencies and send the result to the standard output

-xM

 

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

-xM1

 

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

-xP

 

Prepares the object code to collect data for profiling with gprof(1).

-xpg

 

Generates extra symbol table information for the Source Browser.

-xsb

 

Creates the database for the Source Browser.

-xsbfast

 

Determines recognition of trigraph sequences.

-xtrigraphs

Compiled Code

Option Flag

 

Directs the compiler to suppress linking with ld(1) and to produce a .o file for each source file

-c

 

Names the output file

-o

 

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

-S

Compilation Mode

Option Flag

 

Turns on verbose mode, which shows how command options expand and shows each component as it is invoked.

-#

 

Shows each component as it would be invoked, but does not actually execute it. Also shows how command options expand.

-###

 

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

-keeptmp

 

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

-V

 

Passes arguments to C compilation-system components.

-W

 

The -X options specify varying degrees of compliance to the ISO C standard.

-X

 

Preserves the sign of a char

-xchar

 

Displays on-line help information.

-xhelp

 

Sets the directory for temporary files used by cc to dir.

-xtemp

 

Reports the time and resources used by each compilation component.

-xtime

 

Specifies a new directory for the location of a C compilation-system component.

-Y

 

Changes the default directory searched for components.

-YA

 

Changes the default directory searched for include files.

-YI

 

Changes the default directory for finding library files.

-YP

 

Changes the default directory for startup object files.

-YS

Diagnostics

Option Flag

 

Prefix error messages with string "error:" for ready distinction from warning messages.

-errfmt

 

Suppresses compiler warning messages.

-erroff

 

Control how much detail is in the error message produced by the compiler when it discovers a type mismatch.

-errshort

 

Displays the message tag for each warning message.

-errtags

 

If the indicated warning message is issued, cc exits with a failure status.

-errwarn

 

Directs the compiler to perform stricter semantic checks and to enable other lint-like checks.

-v

 

Suppresses compiler warning messages.

-w

 

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

-xe

 

`Issues warnings for the differences between K&R C and Sun ISO C.

-xtransition

 

Warns about loops that have #pragma MP directives specified but may not be properly specified for parallelization.

-xvpara

Debugging

Option Flag

 

Adds a runtime check for stack overflow.

-xcheck

 

Produces additional symbol table information for the debugger.

-g

 

Removes all symbolic debugging information from the output object file.

-s

 

Disables Auto-Read of object files for dbx.

-xs

Linking and Libraries

Option Flag

 

Specifies whether bindings of libraries for linking are static or dynamic.

-B

 

Specifies dynamic or static linking in the link editor.

-d

 

Passes the option to the link editor to produce a shared object rather than a dynamically linked executable.

-G

 

Assigns a name to a shared dynamic library as a way to have different versions of a library.

-h

 

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

-i

 

Adds directories to the list that the linker searches for libraries.

-L

 

Links with object library libname.so, or libname.a.

-l

 

Removes duplicate strings from the .comment section of the object file.

-mc

 

Removes all strings from the .comment section. Can also insert a string in that section of the object file.

-mr

 

Emits or does not emit identification information to the output file.

-Q

 

Passes a colon-separated list of directories used to specify library search directories to the runtime linker.

-R

 

Merges data segments into text segments.

-xMerge

 

Specify code address space.

-xcode

 

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

-xstrconst

 

Turns off the incremental linker and forces the use of ld.

-xildoff

 

Turns on the incremental linker and forces the use of ild in incremental mode.

-xildon

 

Includes interface information inside object files and subsequent shared libraries so that the shared library can interface with code written in the Java[tm] programming language.

-xnativeconnect

 

Does not link any libraries by default

-xnolib

 

Does not inline math library routines.

-xnolibmil

Target Platform

Option Flag

 

Specify instruction set architecture.

-xarch

 

Defines the cache properties for use by the optimizer.

-xcache

 

Specifies values for -xarch, -xchip, and -xcache.

-xcg

 

Specifies the target processor for use by the optimizer.

-xchip

 

Specifies the usage of registers for the generated code.

-xregs

 

Specifies the target system for instruction set and optimization.

-xtarget



A.3 The cc Options

This section describes the cc options, arranged alphabetically. These descriptions are also available in the man page, cc(1). Use the cc -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 Typographic Conventions.

A.3.1 -#

Turns on verbose mode, showing how command options expand. Shows each component as it is invoked.

A.3.2 -###

Shows each component as it would be invoked, but does not actually execute it. Also shows how command options would expand.

A.3.3 -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)

These preassertions are not valid in -Xc mode.

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



Note - Many system libraries, such as libc, are only available as dynamic libraries in the Solaris 64-bit compilation environment. Therefore, do not use -Bstatic as the last toggle on the command line.



A.3.5 -C

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

A.3.6 -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. When the compiler produces object code for each .i or .c input file, it always creates an object (.o) file in the current working directory. If you suppress the linking step, you also suppress the removal of the object files.

A.3.7 -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.

  • __sparcv9 (-xarch=v9, v9a, v9b)
  • __sun
  • __unix
  • __SUNPRO_C=0x540
  • __`uname -s`_`uname -r` (example: __SunOS_5_7)
  • __sparc (SPARC)
  • __i386 (Intel)
  • __BUILTIN_VA_ARG_INCR
  • __SVR4

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.

A.3.8 -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).



Note - Many system libraries are only available as dynamic libraries in the Solaris 64-bit compilation environment. As a result, this option causes fatal errors if you use it in combination with -xarch=v9.



A.3.9 -dalign

-dalign is equivalent to -xmemalign=8s. See Section A.3.96, -xmemalign=ab.

A.3.10 -E

Runs the source file through the preprocessor only and sends the output to stdout. The preprocessor is built directly into the compiler, except in -Xs mode, where
/usr/ccs/lib/cpp is invoked. Includes the preprocessor line numbering information. See also the -P option.

A.3.11 -errfmt[=[no%]error]

Use this option if you want to prefix the string "error:" to the beginning of error messages so they are more easily distinguishable from warning messages. The prefix is also attached to warnings that are converted to errors by -errwarn.

TABLE A-2 The -errfmt Values

Value

Meaning

error

Add the prefix "error:" to all error messages.

no%error

Do not add the prefix "error:" to any error messages.


If you do not use this option, the compiler sets it to -errfmt=no%error. If you use specify -errfmt, but do not supply a value, the compiler sets it to -errfmt=error.

A.3.12 -erroff[=t]

This command suppresses C compiler warning messages and 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. The following table lists the -erroff values:

TABLE A-3 -erroff Arguments

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.

Only warning messages from the C compiler front-end that display a tag when the -errtags option is used can be suppressed with the -erroff option. You can achieve finer control over error message suppression. See Section 2.7.2.5, #pragma error_messages (on|off|default, tag... tag).

A.3.13 -errshort[=i]

Use this option to control how much detail is in the error message produced by the compiler when it discovers a type mismatch. This option is particularly useful when the compiler discovers a type mismatch that involves a large aggregate.

i can be one of the following:

TABLE A-4 The -errshort Values

Value

Meaning

short

Error messages are printed in short form with no expansion of types. Aggregate members are not expanded, neither are function argument and return types.

full

Error messages are printed in full verbose form showing the full expansion of the mismatched types.

tags

Error messages are printed with tag names for types which have tag names. If there is no tag name, the type is shown in expanded form.


If you do not use -errshort, the compiler sets the option to -errshort=full. If you specify -errshort, but do not provide a value, the compiler sets the option to -errshort=tags.

This option does not accumulate, it accepts the last value specified on the command line.

A.3.14 -errtags[=a]

Displays the message tag for each warning message of the C compiler front-end that can be suppressed with the -erroff option or made a fatal error with the -errwarn option. Messages from the C compiler driver and other components of the C compilation system do not have error tags, and cannot be suppressed with -erroff and made fatal with -errwarn.

a can be either yes or no. The default is -errtags=no. Specifying -errtags is equivalent to specifying -errtags=yes.

A.3.15 -errwarn[=t]

Use -errwarn to cause the C compiler to exit with a failure status for the given warning messages.

t is a comma-separated list that consists of one or more of the following: tag, no%tag, %all, %none. Order is important; for example %all,no%tag causes cc to exit with a fatal status if any warning except tag is issued.

The warning messages generated by the C compiler change from release to release as the compiler error checking improves and features are added. Code that compiles using -errwarn=%all without error may not compile without error in the next release of the compiler.

Only warning messages from the C compiler front-end that display a tag when the -errtags option is used can be specified with the -errwarn option to cause the C compiler to exit with a failure status.

The following table details the -errwarn values:

TABLE A-5 -errwarn Values

Value

Meaning

tag

Cause cc to exit with a fatal status if the message specified by this tag is issued as a warning message. Has no effect if tag is not issued.

no%tag

Prevent cc from exiting with a fatal status if the message specified by tag is issued only as a warning message. Has no effect if the message specified by tag is not issued. Use this option to revert a warning message that was previously specified by this option with tag or %all from causing cc to exit with a fatal status when issued as a warning message.

%all

Cause cc to exit with a fatal status if any warning messages are issued. %all can be followed by no%tag to exempt specific warning messages from this behavior.

%none

Prevents any warning message from causing cc to exit with a fatal status should any warning message be issued.


The default is -errwarn=%none. If you specify -errwarn alone, it is equivalent to -errwarn=%all.

A.3.16 -fast

Selects a set of baseline options for optimizing benchmark applications. These optimizations may alter the behavior of programs from that defined by the ISO C and IEEE standards. Modules compiled with -fast must also be linked with -fast.

-fast is a macro option that can be effectively used as a starting point for tuning an executable for maximum runtime performance. -fast is a macro that can change from one release of the compiler to the next and expands to options that are target platform specific. We suggest that you use the -# option to examine the expansion of -fast, and incorporate the appropriate options of -fast into the ongoing process of tunning the executable.

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 SUID, follow -fast by -xnolibmil:

% cc -fast -xnolibmil

With -xlibmil, exceptions cannot 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 following table lists the set of options selected by -fast across platforms.

TABLE A-6 The -fast Expansion Values

Option

SPARC

x86

-dalign

-

X

-fns

X

X

-fsimple=2

X

-

-fsingle

X

X

-ftrap=%none

X

X

-nofstore

-

X

-xalias_level=basic

X

-

-xarch

X

X

-xbuiltin=%all

X

X

-xdepend

X

X

-xlibmil

X

X

-xmemalign=8s

X

-

-xO5

X

X

-xprefetch=auto,explicit

X

-




Note - Some optimizations make certain assumptions about program behavior. If the program does not conform to these assumptions, the application may crash or produce incorrect results. Please refer to the description of the individual options to determine if your program is suitable for compilation with -fast.



The optimizations performed by these options may alter the behavior of programs from that defined by the ISO C and IEEE standards. See the description of the specific option for details.

-fast acts like a macro expansion on the command line. Therefore, you can override the optimization level and code generation option aspects by following -fast with the desired optimization level or code generation option. 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.

-fast also defines the macro __MATHERR_ERRNO_DONTCARE. This macro causes math.h to assert performance-related pragmas such as the following for some math routines prototyped in <math.h>:

  • #pragma does_not_read_global_data
  • #pragma does_not_write_global_data
  • #pragma no_side_effect

If your code relies on the return value of errno in exceptional cases as documented in the matherr(3M) man page, you must turn off the macro by issuing the -U__MATHERR_ERRNO_DONTCARE macro after the -fast option.

You can usually improve performance for most programs with this option.

Do not use this option for programs that depend on IEEE standard exception handling; you can get different numerical results, premature program termination, or unexpected SIGFPE signals.

See Section A.3.1, -# and Section A.3.2, -### for details of how you can see the expansion of macro options.

A.3.17 -fd

Reports K&R-style function definitions and declarations.

A.3.18 -flags

Prints a brief summary of each available compiler option.

A.3.19 -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 Section 2.6, Nonstandard Floating Point for a further explanation.)

(SPARC) Synonym for -fns -ftrap=common.

A.3.20 -fns[={no,yes}]

(SPARC) Turns on the SPARC nonstandard floating-point mode.

The default is -fns=no, the SPARC standard floating-point mode. -fns is the same as -fns=yes.

Optional use of =yes or =no provides a way of toggling the -fns flag following some other macro flag that includes -fns, such as -fast. This flag enables the nonstandard floating point mode when a program begins execution. By default, the non-standard floating point mode will not be enabled automatically.

On some SPARC systems, the nonstandard floating point mode disables "gradual underflow," causing tiny results to be flushed to zero rather than producing subnormal numbers. It also causes subnormal operands to be replaced silently by zero. On those SPARC systems that do not support gradual underflow and subnormal numbers in hardware, use of this option can significantly improve the performance of some programs.

When nonstandard mode is enabled, floating point arithmetic may produce results that do not conform to the requirements of the IEEE 754 standard. See the Numerical Computation Guide for more information.

This option is effective only on SPARC systems and only if used when compiling the main program. On x86 systems, the option is ignored.

A.3.21 -fprecision=p

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

A.3.22 -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.

When r is tozero, negative, or positive, this flag sets the rounding direction mode to round-to-zero, round-to-negative-infinity, or round-to-positive-infinity respectively when a program begins execution. When r is nearest or the -fround flag is not used, the rounding direction mode is not altered from its initial value (round-to-nearest by default).

This option is effective only if used when compiling the main program.

A.3.23 -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; for example, x*0 may be replaced by 0.
  • Computations do not depend on sign of zero.

With -fsimple=1, the optimizer is not allowed to optimize completely without regard to roundoff or exceptions. In particular, a floating-point computation cannot be replaced by one that produces different results with rounding modes held constant at runtime. The -fast macroflag includes -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, -fsimple=2 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.

Even with -fsimple=2, the optimizer is not permitted to introduce a floating point exception in a program that otherwise produces none.

A.3.24 -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.

A.3.25 -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 rounding 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.

A.3.26 -ftrap=t

Sets the IEEE 754 trapping mode in effect at startup.

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.

A.3.27 -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.

A.3.28 -g

Produces additional symbol table information for debugging with dbx(1) and the Performance Analyzer analyzer(1).

This option invokes the incremental linker; see Section A.3.83, -xildoff and Section A.3.84, -xildon. Invoke ild instead of ld unless you are using the -G or -xildoff options, or you are naming source files on the command line.

If you specify -g, and the optimization level is -xO3 or lower, the compiler provides best-effort symbolic information with almost full optimization. Tail-call optimization and back-end inlining are disabled.

If you specify -g and the optimization level is -xO4, the compiler provides best-effort symbolic information with full optimization.

Compile with the -g option to use the full capabilities of the Performance Analyzer. While some performance analysis features do not require -g, you must compile with -g to view annotated source, some function level information, and compiler commentary messages. See the analyzer(1) man page and "Compiling Your Program for Data Collection and Analysis" in Program Performance Analysis Tools for more information.

The commentary messages that are generated with -g describe the optimizations and transformations that the compiler made while compiling your program. Use the er_src(1) command to display the messages, which are interleaved with the source code.

For more information on debugging, see the Debugging a Program With dbx manual.

A.3.29 -H

Prints to standard error, 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

A.3.30 -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.

A.3.31 -I[-|dir]

-I dir 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). -I values accumulate. See Section 2.5, Include Files for a discussion of the search order used to find the include files.

-I- gives you more control over the algorithm that the compiler uses when searching for include files. -I- values do not accumulate. This section first describes the default search algorithms, then it describes the effect of -I- on these algorithms.

For more information on the search pattern of the compiler, see Section 2.5, Include Files.

A.3.32 -i

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

A.3.33 -KPIC

(SPARC) The -KPIC command is equivalent to -xcode=pic32. See also Section A.3.75, -xcode[=v].

(Intel) -KPIC is identical to -Kpic.

A.3.34 -Kpic

(SPARC) The -Kpic command is equivalent to -xcode=pic13. See Section A.3.75, -xcode[=v].

(Intel) Generate position-independent code for use in shared libraries (small model). Permits references to, at most, 2**11 unique external symbols.

A.3.35 -keeptmp

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

A.3.36 -Ldir

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

A.3.37 -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.

A.3.38 -mc

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

A.3.39 -misalign

(SPARC) -misalign is equivalent to -xmemalign=1i. See Section A.3.96, -xmemalign=ab.

A.3.40 -misalign2

(SPARC) -misalign2 is equivalent to -xmemalign=2i. See Section A.3.96, -xmemalign=ab.

A.3.41 -mr[,string]

-mr removes all strings from the .comment section. When you use this flag, mcs -d -a 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 -astring to mcs.

A.3.42 -mt

Macro option that expands to -D_REENTRANT -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.

A.3.43 -native

This option is a synonym for -xtarget=native.

A.3.44 -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 Section A.3.25, -fstore.

A.3.45 -O

Same as -xO2.

A.3.46 -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).

A.3.47 -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.

A.3.48 -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.

A.3.49 -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 suppresses this information.

A.3.50 -qp

Same as -p.

A.3.51 -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.

A.3.52 -S

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

A.3.53 -s

Removes all symbolic debugging information from the output object file. This option cannot be specified with -g.

Passed to ld(1).

A.3.54 -Uname

Undefines the preprocessor symbol name. This option removes any initial definition of the preprocessor symbol name created by -D on the same command line including those placed there by the command-line driver.

-U has no effect on any preprocessor directives in source files. You can give multiple -U options on the command line.

If the same name is specified for both -D and -U on the command line, name is undefined, regardless of the order the options appear. In the following example, -U undefines __sun:

cc -U__sun text.c

Preprocessor statements of the following form in test.c will not take effect because __sun is undefined.

#ifdef(__sun) 

See Section A.3.7, -Dname[=tokens] for a list of predefined symbols.

A.3.55 -V

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

A.3.56 -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("Hello World.\n");
}

compiles and executes without problem. With -v, it still compiles; however, the compiler displays this warning:

"hello.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.

A.3.57 -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. All -W arguments are passed after the regular command-line arguments.

For example, -Wa,-o,objfile passes -o and objfile to the assembler, in that order. Also, -Wl,-I,name causes the linking phase to override the default name of the dynamic linker, /usr/lib/ld.so.1.

The order in which the argument(s) are passed to a tool with respect to the other specified command line options may change.

See TABLE 1-1 for a list of components. c can be one of the following:

a

Assembler: (fbe); (gas)

c

C code generator: (cg) (SPARC);

d

cc driver[1]

h

Intermediate code translator (ir2hf)(Intel)

i

Interprocedure analysis (ube_ipa)(Intel)

l

Link editor (ld)

m

mcs

O

Interprocedural optimizer

p

Preprocessor (cpp)

u

C code generator (ube) (Intel)

0

Compiler (acomp) (ssbd, SPARC)

2

Optimizer: (iropt) (SPARC)


A.3.58 -w

Suppresses compiler warning messages.

This option overrides the error_messages pragma.

A.3.59 -X[c|a|t|s]

The -X (note uppercase X) options specify varying degrees of compliance to the ISO C standard. The value of -xc99 affects which version of the ISO C standard the -X option applies. The -xc99 option defaults to -xc99=%all which supports a subset of the 1999 ISO/IEC C standard. -xc99=%none supports the 1990 ISO/IEC C standard. See Appendix D for a discussion of supported 1999 ISO/IEC features. See Appendix F for a discussion of differences between ISO/IEC C and K&R C.

The default mode is -Xa.

-Xc

(c = conformance) Issues errors and warnings for programs that use non-ISO C constructs. This option is strictly conformant ISO C, without K&R C compatibility extensions. The predefined macro _ _STDC_ _ has a value of 1 with the -Xc option.

-Xa

This is the default compiler mode. ISO C plus K&R C compatibility extensions, with semantic changes required by ISO C. Where K&R C and ISO C specify different semantics for the same construct, the compiler uses the ISO C interpretation. If the -Xa option is used in conjunction with the -xtransition option, the compiler issues warnings about the different semantics. The predefined macro _ _STDC_ _ has a value of 0 with the -Xa option.

-Xt

(t = transition) This option uses ISO C plus K&R C compatibility extensions without semantic changes required by ISO C. Where K&R C and ISO C specify different semantics for the same construct, the compiler uses the K&R C interpretation. If you use the -Xt option in conjunction with the -xtransition option, the compiler issues warnings about the different semantics. The predefined macro _ _STDC_ _ has a value of 0 with the -Xt option.

-Xs

(s = K&R C) Attempts to warn about all language constructs that have differing behavior between ISO C and K&R C. The compiler language includes all features compatible with K&R C. This option invokes cpp for preprocessing. _ _STDC_ _ is not defined in this mode.

A.3.60 -x386

(Intel) Optimizes for the 80386 processor.

A.3.61 -x486

(Intel) Optimizes for the 80486 processor.

A.3.62 -xa

This option is now considered obsolete. Use -xprofile=tcov instead.

A.3.63 -xalias_level[=l]

(SPARC) The compiler uses the -xalias_level option to determine what assumptions it can make in order to perform optimizations using type-based alias-analysis. This option places the indicated alias level into effect for the translation units being compiled.

If you do not specify the -xalias_level command, the compiler assumes -xalias_level=any. If you specify -xalias_level without a value, the default is -xalias_level=layout.

The -xalias_level option requires optimization level -xO3 or above. If optimization is set lower, a warning is issued and the -xalias_level option is ignored.

Remember that if you issue the -xalias_level option but you fail to adhere to all of the assumptions and restrictions about aliasing described for any of the alias levels, the behavior of your program is undefined.

Replace l with one of the terms in the following table.

TABLE A-7 The Levels of Alias-Disambiguation

Term

Meaning

any

The compiler assumes that all memory references can alias at this level. There is no type-based alias analysis at the level of -xalias_level=any.

basic

If you use the -xalias_level=basic option, the compiler assumes that memory references that involve different C basic types do not alias each other. The compiler also assumes that references to all other types can alias each other as well as any C basic type. The compiler assumes that references using char * can alias any other type.

For example, at the -xalias_level=basic level, the compiler assumes that a pointer variable of type int * is not going to access a float object. Therefore it is safe for the compiler to perform optimizations that assume a pointer of type float * will not alias the same memory that is referenced with a pointer of type int *.

weak

If you use the -xalias_level=weak option, the compiler assumes that any structure pointer can point to any structure type.

Any structure or union type that contains a reference to any type that is either referenced in an expression in the source being compiled or is referenced from outside the source being compiled, must be declared prior to the expression in the source being compiled.

You can satisfy this restriction by including all the header files of a program that contain types that reference any of the types of the objects referenced in any expression of the source being compiled.

At the level of -xalias_level=weak, the compiler assumes that memory references that involve different C basic types do not alias each other. The compiler assumes that references using char * alias memory references that involve any other type.

layout

If you use the -xalias_level=layout option, the compiler assumes that memory references that involve types with the same sequence of types in memory can alias each other.

The compiler assumes that two references with types that do not look the same in memory do not alias each other. The compiler assumes that any two memory accesses through different struct types alias if the initial members of the structures look the same in memory. However, at this level, you should not use a pointer to a struct to access some field of a dissimilar struct object that is beyond any of the common initial sequence of members that look the same in memory between the two structs. This is because the compiler assumes that such references do not alias each other.

At the level of -xalias_level=layout the compiler assumes that memory references that involve different C basic types do not alias each other. The compiler assumes that references using char * can alias memory references involving any other type.

strict

If you use the -xalias_level=strict option, the compiler assumes that memory references, that involve types such as structs or unions, that are the same when tags are removed, can alias each other. Conversely, the compiler assumes that memory references involving types that are not the same even after tags are removed do not alias each other.

However, any structure or union type that contains a reference to any type that is part of any object referenced in an expression in the source being compiled, or is referenced from outside the source being compiled, must be declared prior to the expression in the source being compiled.

You can satisfy this restriction by including all the header files of a program that contain types that reference any of the types of the objects referenced in any expression of the source being compiled. At the level of -xalias_level=strict the compiler assumes that memory references that involve different C basic types do not alias each other. The compiler assumes that references using char * can alias any other type.

std

If you use the -xalias_level=std option, the compiler assumes that types and tags need to be the same to alias, however, references using char * can alias any other type. This rule is the same as the restrictions on the dereferencing of pointers that are found in the 1999 ISO C standard. Programs that properly use this rule will be very portable and should see good performance gains under optimization.

strong

If you use the -xalias_level=strong option, the same restrictions apply as at the std level, but additionally, the compiler assumes that pointers of type char * are used only to access an object of type char. Also, the compiler assumes that there are no interior pointers. An interior pointer is defined as a pointer that points to a member of a struct.


A.3.64 -xarch=isa

Specify instruction set architecture (ISA).

Architectures that are accepted by -xarch keyword isa are shown in TABLE A-8:

TABLE A-8 -xarch ISA Keywords

Platform

Valid -xarch Keywords

SPARC

generic, native, v7, v8a, v8, v8plus, v8plusa, v8plusb, v9, v9a, v9b

x86

generic, native, 386, pentium_pro


Note that although -xarch can be used alone, it is part of the expansion of the -xtarget option and may be used to override the -xarch value that is set by a specific -xtarget option. For example:

% cc -xtarget=ultra2 -xarch=v8plusb ...

overrides the -xarch=v8 set by -xtarget=ultra2

If you use this option with optimization, the appropriate choice can provide good performance of the executable on the specified architecture. An inappropriate choice results in a binary program that is not executable on the intended target platform.

A.3.64.1 SPARC Only

The following table details the performance of an executable that is compiled with a given -xarch option and then executed by various SPARC processors. The purpose of this table is to help you identify the best -xarch option for your executable given a particular target machine. Start by identifying the range of machines that are of interest to you and then consider the cost of maintaining multiple binaries versus the benefit of extracting the last iota of performance from newer machines.

TABLE A-9 -xarch Matrix

 

 

 

Instruction Set of SPARC Machine:

 

 

 

V7

V8a

V8

V9 (Non-Sun Processor)

V9

(Sun processor)

V9b

 

v7

N

S

S

S

S

S

 

v8a

PD

N

S

S

S

S

-xarch compilation option

 

v8

PD

PD

N

S

S

S

v8plus

NE

NE

NE

N

S

S

v8plusa

NE

NE

NE

**

N

S

v8plusb

NE

NE

NE

**

NE

N

 

v9

NE

NE

NE

N

S

S

 

v9a

NE

NE

NE

**

N

S

 

v9b

NE

NE

NE

**

NE

N

** Note: An executable compiled with this instruction set may perform nominally on a V9 non-Sun processor chip or it may not execute at all. Check with your hardware vendor to make sure your executable can run on its target machine.

  • N reflects Nominal performance. The program executes and takes full advantage of the processor's instruction set.
  • S reflects Satisfactory performance. The program executes but may not exploit all available processor instructions.
  • PD reflects Performance Degradation. The program executes, but depending on the instructions used, may experience slight to significant performance degradation. The degradation occurs when instructions that are not implemented by the processor are emulated by the kernel.
  • NE means Not Executable. The program will not execute because the kernel does not emulate the instructions that are not implemented by the processor.

If you are going to compile your executable with the v8plus or v8plusa instruction set, consider compiling your executable with v9 or v9a instead. The v8plus and v8plusa options were provided so that programs could take advantage of some SPARC V9 and UltraSPARC features prior to the availability of Solaris 7 with its support for 64-bit programs. Programs compiled with the v8plus or v8plusa option are not portable to SPARC V8 or older machines. Such programs can be recompiled with v9 or v9a, respectively, to take full advantage of all the features of SPARC V9 and UltraSPARC. The V8+ Technical Specification white paper, part number 802-7447-10, is available through your Sun representative and explains the limitations of v8plus and v8plusa.

  • SPARC instruction set architectures V7, V8, and V8a are all binary compatible.
  • Object binary files (.o) compiled with v8plus and v8plusa can be linked and can execute together, but only on a SPARC V8plusa compatible platform.
  • Object binary files (.o) compiled with v8plus, v8plusa, and v8plusb can be linked and can execute together, but only on a SPARC V8plusb compatible platform.
  • -xarch values v9, v9a, and v9b are only available on UltraSPARC 64-bit Solaris environments.
  • Object binary files (.o) compiled with v9 and v9a can be linked and can execute together, but will run only on a SPARC V9a compatible platform.
  • Object binary files (.o) compiled with v9, v9a, and v9b can be linked and can execute together, but will run only on a SPARC V9b compatible platform.

For any particular choice, the generated executable may run much more slowly on earlier architectures. Also, although quad-precision (REAL*16 and long double) floating-point instructions are available in many of these instruction set architectures, the compiler does not use these instructions in the code it generates.

The following table gives details for each of the -xarch keywords on SPARC platforms.

TABLE A-10 -xarch Values for SPARC Platforms

-xarch=

Meaning

generic

Compile for good performance on most systems.
This is the default. This option uses the best instruction set for good performance on most processors without major performance degradation on any of them. With each new release, the definition of "best" instruction set may be adjusted, if appropriate.

native

Compile for good performance on this system.

This is the default for the -fast option. The compiler chooses the appropriate setting for the current system processor it is running on.

v7

Compile for the SPARC-V7 ISA.
Enables the compiler to generate code for good performance on the V7 ISA.

This is equivalent to using the best instruction set for good performance on the V8 ISA, but without integer mul and div instructions, and the fsmuld instruction.

Examples: SPARCstation 1, SPARCstation 2

v8a

Compile for the V8a version of the SPARC-V8 ISA.

By definition, V8a means the V8 ISA, but without the fsmuld instruction.

This option enables the compiler to generate code for good performance on the V8a ISA.

Example: Any system based on the microSPARC I chip architecture

v8

Compile for the SPARC-V8 ISA.

Enables the compiler to generate code for good performance on the V8 architecture.

Example: SPARCstation 10

v8plus

Compile for the V8plus version of the SPARC-V9 ISA.

By definition, V8plus means the V9 ISA, but limited to the 32-bit subset defined by the V8plus ISA specification, without the Visual Instruction Set (VIS), and without other implementation-specific ISA extensions.

  • This option enables the compiler to generate code for good performance on the V8plus ISA.
  • The resulting object code is in SPARC-V8+ ELF32 format and only executes in a Solaris UltraSPARC environment--it does not run on a V7 or V8 processor.

Example: Any system based on the UltraSPARC chip architecture

v8plusa

Compile for the V8plusa version of the SPARC-V9 ISA.

By definition, V8plusa means the V8plus architecture, plus the Visual Instruction Set (VIS) version 1.0, and with UltraSPARC extensions.

  • This option enables the compiler to generate code for good performance on the UltraSPARC architecture, but limited to the 32-bit subset defined by the V8plus specification.
  • The resulting object code is in SPARC-V8+ ELF32 format and only executes in a Solaris UltraSPARC environment--it does not run on a V7 or V8 processor.

Example: Any system based on the UltraSPARC chip architecture

v8plusb

Compile for the V8plusb version of the SPARC-V8plus ISA with UltraSPARC III extensions.

Enables the compiler to generate object code for the UltraSPARC architecture, plus the Visual Instruction Set (VIS) version 2.0, and with UltraSPARC III extensions.

  • The resulting object code is in SPARC-V8+ ELF32 format and executes only in a Solaris UltraSPARC III environment.
  • Compiling with this option uses the best instruction set for good performance on the UltraSPARC III architecture.

v9

Compile for the SPARC-V9 ISA.

Enables the compiler to generate code for good performance on the V9 SPARC architecture.

  • The resulting .o object files are in ELF64 format and can only be linked with other SPARC-V9 object files in the same format.
  • The resulting executable can only be run on an UltraSPARC processor running a 64-bit enabled Solaris operating environment with the 64-bit kernel.
  • -xarch=v9 is only available when compiling in a 64-bit enabled Solaris environment.

v9a

Compile for the SPARC-V9 ISA with UltraSPARC extensions.

Adds to the SPARC-V9 ISA the Visual Instruction Set (VIS) and extensions specific to UltraSPARC processors, and enables the compiler to generate code for good performance on the V9 SPARC architecture.

  • The resulting .o object files are in ELF64 format and can only be linked with other SPARC-V9 object files in the same format.
  • The resulting executable can only be run on an UltraSPARC processor running a 64-bit enabled Solaris operating environment with the 64-bit kernel.
  • -xarch=v9a is only available when compiling in a 64-bit enabled Solaris operating environment.

v9b

Compile for the SPARC-V9 ISA with UltraSPARC III extensions.

Adds UltraSPARC III extensions and VIS version 2.0 to the V9a version of the SPARC-V9 ISA. Compiling with this option uses the best instruction set for good performance in a Solaris UltraSPARC III environment.

  • The resulting object code is in SPARC-V9 ELF64 format and can only be linked with other SPARC-V9 object files in the same format.
  • The resulting executable can only be run on an UltraSPARC III processor running a 64-bit enabled Solaris operating environment with the 64-bit kernel.
  • -xarch=v9b is only available when compiling in a 64-bit enabled Solaris operating environment.

A.3.64.2 x86 Only

TABLE A-11 -xarch Values on x86

Value

Meaning

generic

Limits instruction set to the Intel x86 architecture and is the equivalent of the 386 option.

native

Compile for good performance on this system. This is the default for the -fast option. The compiler chooses the appropriate setting for the current system processor on which it is compiling.

386

Limits the instruction set to the Intel 386/486 architecture.

pentium_pro

Limits the instruction set to the pentium_pro architecture.


A.3.65 -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.

To achieve 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
3	on-line since 01/12/95 10:41:54
4	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.

A.3.66 -xbuiltin[=(%all|%none)]

Use the -xbuiltin[=(%all|%none)] command when you want to improve the optimization of code that calls standard library functions. Many standard library functions, such as the ones defined in math.h and stdio.h, are commonly used by various programs. This command lets the compiler substitute intrinsic functions or inline system functions where profitable for performance.

If you do not specify -xbuiltin, the default is -xbuiltin=%none, which means no functions from the standard libraries are substituted or inlined. If you specify -xbuiltin, but do not provide any argument, the default is -xbuiltin%all, which means the compiler substitutes intrinsics or inlines standard library functions as it determines the optimization benefit.

If you compile with -fast, then -xbuiltin is set to %all.



Note - -xbuiltin only inlines global functions defined in system header files, never static functions defined by the user.



A.3.67 -xCC

When you specify -xc99=%none and -xCC, the compiler accepts the C++-style comments. In particular, // can be used to indicate the start of a comment.

A.3.68 -xc99[=o]

The -xc99 flag controls compiler recognition of the implemented features from the C99 standard (ISO/IEC 9899:1999, Programming Language - C).

o can be one of the following: %all, %none.

-xc99=%none turns off recognition of C99 features. -xc99=%all turns on recognition of supported C99 features.

Specifying -xc99 without any arguments is the same as -xc99=%all.



Note - Though the compiler support-level defaults to the features of C99 listed in Appendix D, the standard headers provided by Solaris in /usr/include do not yet conform with the 1999 ISO/IEC C standard. If you encounter error messages, try using -xc99=%none to obtain the 1990 ISO/IEC C standard behavior for these headers.



A.3.69 -xcache[=c]

Defines the cache properties for use by the optimizer. c must be one of the following:

  • generic
  • 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. The following table lists the -xcache values.

TABLE A-12 The -xcache Values

Value

Meaning

generic

Define the cache properties for good performance on most x86 and SPARC architectures.

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

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

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:

16K bytes

32 bytes line size

4-way associativity

Level 2 cache has:

1024K bytes

32 bytes line size

Direct mapping associativity


A.3.70 -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.

A.3.71 -xchar[=o]

The option is provided solely for the purpose of easing the migration of code from systems where the char type is defined as unsigned. Unless you are migrating from such a system, do not use this option. Only code that relies on the sign of a char type needs to be rewritten to explicitly specify signed or unsigned.

You can substitute one of the following for o:

TABLE A-13 The -xchar Values

Value

Meaning

signed

Treat character constants and variables declared as char as signed. This impacts the behavior of compiled code, it does not affect the behavior of library routines.

s

Equivalent to signed

unsigned

Treat character constants and variables declared as char as unsigned. This impacts the behavior of compiled code, it does not affect the behavior of library routines.

u

Equivalent to unsigned


If you do not specify -xchar, the compiler assumes -xchar=s.

If you specify -xchar, but do not specify a value, the compiler assumes -xchar=s.

The -xchar option changes the range of values for the type char only for code compiled with -xchar. This option does not change the range of values for type char in any system routine or header file. In particular, the value of CHAR_MAX and CHAR_MIN, as defined by limits.h, do not change when this option is specified. Therefore, CHAR_MAX and CHAR_MIN no longer represent the range of values encodable in a plain char.

If you use -xchar, be particularly careful when you compare a char against a predefined system macro because the value in the macro may be signed. This is most common for any routine that returns an error code which is accessed through a macro. Error codes are typically negative values so when you compare a char against the value from such a macro, the result is always false. A negative number can never be equal to any value of an unsigned type.

It is strongly recommended that you never use -xchar to compile routines for any interface exported through a library. By default, the C compiler defines char as signed as per the Solaris ABI and -xchar does not change that. Therefore, users of such a library need to be cautioned to also use this option or otherwise deal with any char values being passed or returned.

A.3.72 -xchar_byte_order[=o]

Produce an integer constant by placing the characters of a multi-character character-constant in the specified byte order. You can substitute one of the following values for o:

  • low: place the characters of a multi-character character-constant in low-to-high byte order.
  • high: place the characters of a multi-character character-constant in high-to-low byte order.
  • default: place the characters of a multi-character character-constant in an order determined by the compilation mode -X[c|a|t|s]. For more information, see Section 2.4.2, Character Constants.

A.3.73 -xcheck[=o]

(SPARC)

Compiling with -xcheck=stkovf adds a runtime check for stack overflow of the main thread in a singly-threaded program as well as slave-thread stacks in a multithreaded program. If a stack overflow is detected, a SIGSEGV is generated. If your application needs to handle a SIGSEGV caused by a stack overflow differently than it handles other address-space violations, see sigaltstack(2).

You can substitute one of the following values for o:

TABLE A-14 The -xcheck Values

Value

Meaning

%none

Perform none of the -xcheck checks.

%all

Perform all of the -xcheck checks.

stkovf

Turns on stack-overflow checking.

no%stkovf

Turns off stack-overflow checking.


If you do not specify -xcheck, the compiler defaults to -xcheck=%none. If you specify -xcheck without any arguments, the compiler defaults to -xcheck=%all which turns on the runtime check for stack overflow.

The -xcheck option does not accumulate on the command line. The compiler sets the flag in accordance with the last occurrence of the command.

A.3.74 -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, ultra2, ultra2e, ultra2i, ultra3, ultra3cu, 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.

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 A-15 The -xchip Values

    Value

    Meaning

    generic

    Use timing properties for good performance on most x86 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 processors.

    super

    Uses timing properties of the SuperSPARC processors.

    super2

    Uses timing properties of the SuperSPARC II processors.

    micro

    Uses timing properties of the microSPARC processors.

    micro2

    Uses timing properties of the microSPARC II processors.

    hyper

    Uses timing properties of the hyperSPARC processors.

    hyper2

    Uses timing properties of the hyperSPARC II processors.

    powerup

    Uses timing properties of the Weitek PowerUp processors.

    ultra

    Uses timing properties of the UltraSPARC processors.

    ultra2

    Uses timing properties of the UltraSPARC II processors.

    ultra2e

    Uses timing properties of the UltraSPARC IIe processors.

    ultra2i

    Uses timing properties of the UltraSPARC IIi processors.

    ultra3

    Uses timing properties of the UltraSPARC III processors.

    ultra3cu

    Uses timing properties of the UltraSPARC III Cu processors.

    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


A.3.75 -xcode[=v]

(SPARC) Specify code address space. v must be one of:

abs32

Generate 32-bit absolute addresses. Code + data + bss size is limited to 2**32 bytes. This is the default on 32-bit architectures: -xarch-generic, v7, v8, v8a, v8plus, v8plusa

abs44

Generate 44-bit absolute addresses. Code + data + bss size is limited to 2**44 bytes. Available only on 64-bit architectures: -xarch=v9, v9a

abs64

Generate 64-bit absolute addresses. Available only on 64-bit architectures: -xarch=v9, v9a

pic13

Generate position-independent code for use in shared libraries (small model). Equivalent to -Kpic. Permits references to at most 2**11 unique external symbols on 32-bit architectures, 2**10 on 64-bit architectures.

The -xcode=pic13 command is similar to -xcode=pic32, except that the size of the global offset table is limited to 8Kbytes.

pic32

Generate position-independent code for use in shared libraries (large model). Equivalent to -KPIC. Permits references to at most 2**30 unique external symbols on 32-bit architectures, 2**29 on 64-bit architectures.

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. 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 -xcode=pic32.


The default is -xcode=abs32 for SPARC V7 and V8, and -xcode=abs64 for SPARC and UltraSPARC V9 (with -xarch=v9|v9a).

When building shared dynamic libraries with -xarch=v9 or v9a or v9b on 64-bit Solaris environments, you can specify -xcode=pic13 or -xcode=pic32 but are not required to do so.

There are two nominal performance costs with -xcode=pic13 and -xcode=pic32:

  • A routine compiled with either -xcode=pic13 or -xcode=pic32 executes a few extra instructions upon entry to set a register to point at a table (_GLOBAL_OFFSET_TABLE_) used for accessing a shared library's global or static variables.
  • Each access to a global or static variable involves an extra indirect memory reference through _GLOBAL_OFFSET_TABLE_. If the compile is done with -xcode=pic32, there are two additional instructions per global and static memory reference.

When considering the above costs, remember that the use of -xcode=pic13 and -xcode=pic32 can significantly reduce system memory requirements, due to the effect of library code sharing. Every page of code in a shared library compiled -xcode=pic13 or -xcode=pic32 can be shared by every process that uses the library. If a page of code in a shared library contains even a single non-pic (that is, absolute) memory reference, the page becomes nonsharable, and a copy of the page must be created each time a program using the library is executed.

The easiest way to tell whether or not a .o file has been compiled with -xcode=pic13 or -xcode=pic32 is with the nm command:

% nm file.o | grep _GLOBAL_OFFSET_TABLE_ U _GLOBAL_OFFSET_TABLE_

A .o file containing position-independent code contains an unresolved external reference to _GLOBAL_OFFSET_TABLE_, as indicated by the letter U.

To determine whether to use -xcode=pic13 or -xcode=pic32, use nm to identify the number of distinct global and static variables used or defined in the library. If the size of _GLOBAL_OFFSET_TABLE_ is under 8,192 bytes, you can use -Kpic. Otherwise, you must use -xcode=pic32.

A.3.76 -xcrossfile[=n]

(SPARC) Enables optimization and inlining across source files. If specified, n can be 0 or 1.

Normally the scope of the compiler's analysis is limited to each separate file on the command line. For example, -xO4's automatic inlining is limited to subprograms defined and referenced within the same source file.

With -xcrossfile, the compiler analyzes all the files named on the command line as if they had been concatenated into a single source file. -xcrossfile is only effective when used with -xO4 or -xO5.

The files produced from this compilation are interdependent due to possible inlining, and must be used as a unit when they are linked into a program. If any one routine is changed and the files recompiled, they must all be recompiled. As a result, using this option affects the construction of make files.

The default is -xcrossfile=0, and no crossfile optimizations are performed. -xcrossfile is equivalent to -xcrossfile=1.

A.3.77 -xcsi

Allows the C compiler to accept source code written in locales that do not conform to the ISO C source character code requirements. These locales include: ja_JP.PCK.

The compiler translation phases required to handle such locales may result in significantly longer compilation times. You should only use this option when you compile source files that contain source characters from one of these locales.

The compiler does not recognize source code written in locales that do not conform to the ISO C source character code requirements unless you specify -xcsi.

A.3.78 -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.

A.3.79 -xe

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

A.3.80 -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.

To get faster code, this option requires a multiprocessor system. On a single-processor system, the generated code usually runs slower.

If you identify 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:

The following is an example of inserting a parallel pragma immediately before the loop:

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

Do not specify -xexplicitpar and -xopenmp together.

A.3.81 -xF

Allow function reordering by the Performance Analyzer. (See the analyzer(1) man pages.) If you compile with the -xF option, and then run the Performance Analyzer, you can 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 file by using the linker -Mmapfile option. It places each function from the executable file into a separate section; for example, functions foo() and bar() are placed in the sections .text%foo and .text%bar, respectively. This option also causes the assembler to generate some debugging information in the object file, necessary for data collection.

A.3.82 -xhelp=f

Displays on-line help information.

f must be either flags, or readme.

-xhelp=flags displays a summary of the compiler options.

-xhelp=readme displays the README file.

A.3.83 -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.

A.3.84 -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.

A.3.85 -xinline=list

The format of the list for -xinline is as follows: [{%auto,func_name,no%func_name}[,{%auto,func_name,no%func_name}]...]

-xinline tries to inline only those functions specified in the optional list. The list is either empty, or comprised of a comma-separated list of func_name, no%func_name, or %auto, where func_name is a function name. -xinline only has an effect at -xO3 or higher.

TABLE A-16 The -xinline Arguments

Value

Meaning

%auto

Specifies that the compiler is to attempt to automatically inline all functions in the source file. %auto only takes effect at -xO4 or higher optimization levels. %auto is silently ignored at -xO3 or lower optimization levels.

func_name

Specifies that the compiler is to attempt to inline the named function.

no%func_name

Specifies that the compiler is not to inline the named function.

no value

Specifies that the compiler is not to attempt to inline any functions in the source files.


The list of values accumulates from left to right. So for a specification of -xinline=%auto,no%foo the compiler attempts to inline all functions except foo. For a specification of -xinline=%bar,%myfunc,no%bar the compiler only tries to inline myfunc.

When you compile with optimization set at -xO4 or above, the compiler normally tries to inline all references to functions defined in the source file. You can restrict the set of functions the compiler attempts to inline by specifying the -xinline option. If you specify only -xinline=, that is you do not name any functions or %auto, this indicates that none of the routines in the source files are to be inlined. If you specify a list of func_name and no%func_name without specifying %auto, the compiler only attempts to inline those functions specified in the list. If %auto is specified in the list of values with the -xinline option at optimization level set at -xO4 or above, the compiler attempts to inline all functions that are not explicitly excluded by no%func_name.

A function is 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.
  • The source for the routine is not in the file being compiled (however, see -xcrossfile).

If you specify multiple -xinline options on the command line, they do not accumulate. The last -xinline on the command line specifies what functions the compiler attempts to inline.

A.3.86 -xipo[=a]

Replace a with 0, 1, or 2. -xipo without any arguments is equivalent -xipo=1. -xipo=0 is the default setting and turns off -xipo.

This compiler performs whole-program optimizations by invoking an interprocedural analysis component. Unlike -xcrossfile, -xipo performs optimizations across all object files in the link step, and is not limited to just the source files of the compile command. With -xipo=1, the compiler performs inlining across all source files. With -xipo=2, the compiler performs interprocedural aliasing analysis as well as optimizations of memory allocation and layout to improve cache performance.

The -xipo option generates significantly larger object files due to the additional information needed to perform optimizations across files. However, this additional information does not become part of the final executable binary file. Any increase in the size of the executable program is due to the additional optimizations performed.The object files created in the compilation steps have additional analysis information compiled within them to permit crossfile optimizations to take place at the link step.

-xipo is particularly useful when compiling and linking large multi-file applications. Object files compiled with this flag have analysis information compiled within them that enables interprocedural analysis across source and pre-compiled program files.

However, analysis and optimization is limited to the object files compiled with -xipo, and does not extend to object files in the libraries.

-xipo is multiphased, so you need to specify -xipo for each step if you compile and link in separate steps.

In this example, compilation and linking occur in a single step:

cc -xipo -xO4 -o prog  part1.c part2.c part3.c

The optimizer performs crossfile inlining across all three source files. This is done in the final link step, so the compilation of the source files need not all take place in a single compilation and could take place over a number of separate compilations, each specifying -xipo.

In this example, compilation and linking occur in separate steps:

cc -xipo -xO4 -c part1.c part2.c 
cc -xipo -xO4 -c part3.c
cc -xipo -xO4 -o prog  part1.o part2.o part3.o

A restriction is that libraries, even if compiled with -xipo, do not participate in crossfile interprocedural analysis, as this example shows:

cc -xipo -xO4 one.c two.c three.c
ar -r mylib.a one.o two.o three.o
...
cc -xipo -xO4 -o myprog main.c four.c mylib.a

Here interprocedural optimizations are performed between one.c, two.c and three.c, and between main.c and four.c, but not between main.c or four.c and the routines on mylib.a. (The first compilation may generate warnings about undefined symbols, but the interprocedural optimizations are performed because it is a compile and link step.)

Other important information about -xipo:

  • It requires an optimization level of at least -xO4.
  • It conflicts with -xcrossfile. If you use these together, the result is a compilation error.
  • Objects that are compiled without -xipo can be linked freely with objects that are compiled with -xipo.

A.3.87 -xlibmieee

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

A.3.88 -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.

-xlibmil inlines a function regardless of any specification of the function as part of the -xinline flag.

A.3.89 -xlic_lib=sunperf

(SPARC) Links in the Sun-supplied performance libraries.

A.3.90 -xlicinfo

Returns information about the license file used, the license tokens accepted, the serial number, the RTUs, trial license and the number of days to expiration. This option does not request compilation or check out a license.

A.3.91 -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.

To achieve faster execution, this option requires a multiprocessor system. On a single-processor system, the generated code usually runs slower.

A.3.92 -xM

Runs only the preprocessor on the named C programs, requesting that it generate makefile dependencies and send the result to the standard output (see make(1) for details about make files and dependencies).

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

A.3.93 -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

Compiling with -xM1 does not report header file dependencies:

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

-xM1 is not available under -Xs mode.

A.3.94 -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.

A.3.95 -xmaxopt[=v]

where v is one of off, 1, 2, 3, 4, 5. This command limits the level of pragma opt to the level specified. The default value is -xmaxopt=off which causes pragma opt to be ignored. If you specify -xmaxopt without supplying an argument, that is the equivalent of specifying -xmaxopt=5.

A.3.96 -xmemalign=ab

Specify maximum assumed memory alignment and behavior of misaligned data accesses. There must be a value for both a (alignment) and b (behavior). a specifies the maximum assumed memory alignment and b specifies the behavior for misaligned memory accesses. The following table lists the alignment and behavior values for -xmemalign

TABLE A-17 -xmemalign Alignment and Behavior Values

a

 

b

 

1

Assume at most 1 byte alignment.

i

Interpret access and continue execution.

2

Assume at most 2 byte alignment.

s

Raise signal SIGBUS.

4

Assume at most 4 byte alignment.

f

Raise signal SIGBUS for alignments less or equal to 4,otherwise interpret access and continue execution.

8

Assume at most 8 byte alignment.

 

16

Assume at most 16 byte alignment

 

 


For memory accesses where the alignment is determinable at compile time, the compiler will generate the appropriate load/store instruction sequence for that alignment of data.

For memory accesses where the alignment cannot be determined at compile time, the compiler must assume an alignment to generate the needed load/store sequence.

The -xmemalign flag allows the user to specify the maximum memory alignment of data to be assumed by the compiler in these indeterminable situations. It also specifies the error behavior to be followed at run time when a misaligned memory access does take place.

Here are the default values for -xmemalign. The following default values only apply when no -xmemalign flag is present:

  • -xmemalgin=4s when -xarch has the value generic, v7, v8, v8a, v8plus, v8plusa.
  • -xmemalign=8s when -xarch has the value v9, v9a.

Here is the default when -xmemalign flag is present but no value is given:

  • -xmemalign=1i for all -xarch values.

The following table shows how you can use -xmemalign to handle different alignment situations.

TABLE A-18 Examples of -xmemalign

Command

Situation

-xmemalign=1s

There are many misaligned accesses so trap handling is too slow.

-xmemalign=8i

There are occasional, intentional, misaligned accesses in code that is otherwise correct.

-xmemalign=8s

There should be no misaligned accesses in the program.

-xmemalign=2s

You want to check for possible odd-byte accesses.

-xmemalign=2i

You want to check for possible odd-byte access and you want the program to work.


A.3.97 -xnativeconnect[=a[,a]...]

Use the -xnativeconnect option when you want to include interface information inside object files and subsequent shared libraries so that the shared library can interface with code written in the Java[tm] programming language (Java code). You must also include -xnativeconnect when you build the shared library with the cc -G command.

When you compile with -xnativeconnect, you are providing the maximum, external, visibility of the native code interfaces. The Native Connector Tool (NCT) enables the automatic generation of Java code and the Java[tm] Native Interface (JNI) so that C shared libraries can be called from Java code. For more information on how to use the NCT, see the Forte Developer online help.

a can be one of the following: %all|%none|[no%]interfaces

If you do not specify -xnativeconnect, the compiler sets the option to -xnativeconnect=%none. If you specify only -xnativeconnect, the compiler sets the option to -xnativeconnect=interfaces.

-xnativeconnect=interfaces forces the generation of Binary Interface Descriptors (BIDS).

A.3.98 -xnolib

Does not link any libraries by default; that is, no -l options are passed to ld(1). 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.

A.3.99 -xnolibmil

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

% cc -fast -xnolibmil....

A.3.100 -xO[1|2|3|4|5]

Optimizes the object code; note the uppercase letter O. When -xO is used with the -g option, a limited amount of debugging is available. For more information, see "Debugging Optimized Code" in Chapter 1 of Debugging a Program With dbx.

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. If you want to control which functions are inlined, see Section A.3.85, -xinline=list.

This level traces the effects of pointer assignments, and usually results in increased code size.

-xO5

Attempts to generate 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 Section A.3.108, -xprofile=p.

(Intel)

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

For more information on debugging, see the Debugging a Program With dbx manual. For more information on optimization, see the Program Performance Analysis Tools manual.

A.3.101 -xopenmp[=i]

(SPARC)

where i is one of parallel, stubs, or none. If you specify -xopenmp but do not include a value, the compiler assumes -xopenmp=parallel. If you do not specify -xopenmp, the compiler assumes -xopenmp=none.

-xopenmp=parallel enables recognition of OpenMP pragmas and applies to SPARC only. The optimization level under -xopenmp=parallel is -xO3. The compiler issues a warning if the optimization level of your program is changed from a lower level to -xO3. -xopenmp=parallel predefines the _OPENMP preprocessor token.

-xopenmp=stubs links with the stubs routines for the OpenMP API routines. Use this option if you need to compile your application to execute serially. -xopenmp=stubs also predefines the _OPENMP preprocessor token.

-xopenmp=none does not enable recognition of OpenMP pragmas, makes no change to the optimization level of your program, and does not predefine any preprocessor tokens.

Do not specify -xopenmp, with either -xexplicitpar, or -xparallel.

For more information on how to compile a program that is OpenMP compliant, see Section 3.2, Parallelizing for OpenMP.

For information that is specific to this implementation of OpenMP, see Appendix G.

A.3.102 -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 **);

A.3.103 -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. Do not use -xparallel if you are issuing -xopenmp. -xparallel sets -xexplicitpar which should not be used if you specify -xopenmp.

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

A.3.104 -xpentium

(Intel) Optimizes for the Pentium processor.

A.3.105 -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.

A.3.106 -xprefetch=[val],val

(SPARC) Enable prefetch instructions on those architectures that support prefetch, such as UltraSPARC II. (-xarch=v8plus, v9plusa, v9, or v9a)

Explicit prefetching should only be used under special circumstances that are supported by measurements.

val must be one of the following:

TABLE A-19 -xprefetch Arguments

Value

Meaning

latx:factor

Adjust the compiler's assumed prefetch-to-load and prefetch-to-store latencies by the specified factor. See Prefetch Latency Ratio

[no%]auto

[Disable] Enable automatic generation of prefetch instructions

[no%]explicit

[Disable] Enable explicit prefetch macros

yes

Same as -xprefetch=auto,explicit

no

Same as -xprefetch=no%auto,no%explicit


If you do not specify -xprefetch, the default is -xprefetch=no%auto,explicit. If you specify -xprefetch without a value, that is equivalent to -xprefetch=auto,explicit.

The sun_prefetch.h header file provides the macros that you can use to specify explicit prefetch instructions. The prefetches are approximately at the place in the executable that corresponds to where the macros appear.

A.3.106.1 Prefetch Latency Ratio

The prefetch latency is the hardware delay between the execution of a prefetch instruction and the time the data being prefetched is available in the cache.

The factor must be a positive number of the form n.n.

The compiler assumes a prefetch latency value when determining how far apart to place a prefetch instruction and the load or store instruction that uses the prefetched data. The assumed latency between a prefetch and a load may not be the same as the assumed latency between a prefetch and a store.

The compiler tunes the prefetch mechanism for optimal performance across a wide range of machines and applications. This tuning may not always be optimal. For memory-intensive applications, especially applications intended to run on large multiprocessors, you may be able to obtain better performance by increasing the prefetch latency values. To increase the values, use a factor that is greater than 1 (one). A value between .5 and 2.0 will most likely pro vide the maximum performance.

For applications with datasets that reside entirely within the external cache, you may be able to obtain better performance by decreasing the prefetch latency values. To decrease the values, use a factor that is less than one.

To use the latx:factor suboption, start with a factor value near 1.0 and run performance tests against the application. Then increase or decrease the factor, as appropriate, and run the performance tests again. Continue adjusting the factor and running the performance tests until you achieve optimum performance. When you increase or decrease the factor in small steps, you will see no performance difference for a few steps, then a sudden difference, then it will level off again.

A.3.107 -xprefetch_level=l

Use the -xprefetch_level option to control the aggressiveness of automatic insertion of prefetch instructions as determined with -xprefetch=auto. l must be 1, 2, or 3. The compiler becomes more aggressive, or in other words, introduces more prefetches with each, higher, level of -xprefetch_level.

The appropriate value for the -xprefetch_level depends on the number of cache misses the application may have. Higher -xprefetch_level values have the potential to improve the performance of applications.

This option is effective only when it is compiled with -xprefetch=auto, with optimization level 3 or greater, and generate code for a platform that supports prefetch (v8plus, v8plusa, v9, v9a, v9b, generic64, native64).

-xprefetch_level=1 enables automatic generation of prefetch instructions. -xprefetch_level=2 enables additional generation beyond level 1 and -xprefetch_level=3 enables additional generation beyond level 2.

The default is -xprefetch_level=1 when you specify -xprefetch=auto.

A.3.108 -xprofile=p

(SPARC)

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

p must be collect[:name], use[:name], or 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 -xO2 or above.

  • 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.
You can set the environment variables SUN_PROFDATA and SUN_PROFDATA_DIR to control where a program compiled with -xprofile=collect stores the profile data. If set, the -xprofile=collect data is written to SUN_PROFDATA_DIR/SUN_PROFDATA.
These environment variables similarly control the path and names of the profile data files written by tcov, as described in the tcov(1) man page.
If these environment variables are not set, the profile data is written to name.profile/feedback in the current directory, where name is the name of the executable or the name specified in the -xprofile=collect:name flag. -xprofile does not append .profile to name if name already ends in .profile. If you run the program several times, the execution frequency data accumulates in the feedback file; that is, output from prior executions is not lost.


Note - Compiling shared libraries with -xprofile=collect is not supported.



  • 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.
Except for the -xprofile option, the source files and other compiler options must be exactly the same as those used for the compilation that created the compiled program which in turn generated the feedback file. The same version of the compiler must be used for both the collect build and the use build as well. If compiled with -xprofile=collect: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 Section A.3.62, -xa for information on the old style of profiling, the tcov(1) man page, and Program Performance Analysis Tools 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 Program Performance Analysis Tools for more details.


Note - tcov's code coverage report can be unreliable if there is inlining of routines due to -xO4 or -xinline.



When you use -xprofile=collect to compile a program for profile collection and -xprofile=use to compile a program for profile feedback, the source files and compiler options other than -xprofile=collect and -xprofile=use must be identical in both compilations.

The profile feedback directory names specified by the -xprofile=use:name option are accumulated from all instances of the option in a single invocation of the compiler. For example, assume that profile directories a.profile, b.profile and c.profile are created as a result of executing profiled binaries named a, b, and c respectively.

cc -O -c foo.c -xprofile=use:a -xprofile=use:b -xprofile=use:c

All three profile directories are used. Any valid profile feedback data pertaining to a particular object file is accumulated from the specified feedback directories when the object file is compiled.

If both -xprofile=collect and -xprofile=use are specified in the same command line, the rightmost -xprofile option in the command line is applied as follows:

  • If the rightmost -xprofile option is -xprofile=use, all profile feedback directory names specified by the -xprofile=use options are used for feedback-directed optimization, and the previous -xprofile=collect options are ignored.
  • If the rightmost -xprofile option is -xprofile=collect, all profile feedback directory names specified by -xprofile=use options are ignored, and instrumentation for profile generation is enabled.

A.3.109 -xreduction

(SPARC) Turns on reduction recognition during automatic parallelization. -xreduction must be specified with -xautopar, or -xparallel.

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.

A.3.110 -xregs=r[,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 A-20 The -xregs Values

Value

Meaning

appl

Allows the use of the following registers:

g2, g3, g4 (v8a, v8, v8plus, v8plusa, v8plusb)

g2, g3 (v9, v9a, v9b)

For more information on SPARC instruction sets, see Section A.3.64, -xarch=isa.

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: g2, g3, g4 (v8a, v8, v8plus, v8plusa, v8plusb) g2, g3 (v9, v9a, v9b). It is strongly recommended that all system software and libraries be compiled using -xreg=no%appl. System software (including shared libraries) must preserve these registers' values for the application. Their use is intended to be controlled by the compilation system and must be consistent throughout the application.

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.

It is strongly recommended that you compile code intended for shared libraries that will link with applications, with -xregs=no%appl,float. At the very least, the shared library should explicitly document how it uses the application registers so that applications linking with those libraries know how to cope with the issue.

For example, an application using the registers in some global sense (such as using a register to point to some critical data structure) would need to know exactly how a library with code compiled without -xregs=no%appl is using the application registers in order to safely link with that library.

A.3.111 -xrestrict[=f]

(SPARC) Treats pointer-valued function parameters as restricted pointers . f is %all, %none, or a comma-separated list of one or more function names: {%all|%none|fn[,fn...]}.

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 Section 3.8.2, Restricted Pointers, for more information.

This command-line option can be used on its own, but it is best used with optimization. For example, the command:

%cc -xO3 -xrestrict=%all prog.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.

A.3.112 -xs

Disables Auto-Read of .o files by 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.

A.3.113 -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. It is only effective when you specify -xO5 optimization and -xarch=v8plus|v8plusa|v9|v9a.



Note - Because non-faulting loads do not cause a trap when a fault such as address misalignment or segmentation violation occurs, you should use this option only for programs in which such faults cannot occur. Because few programs incur memory-based traps, you can safely use this option for most programs. Do not use this option for programs that explicitly depend on memory-based traps to handle exceptional conditions.



A.3.114 -xsb

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

A.3.115 -xsbfast

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

A.3.116 -xsfpconst

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

A.3.117 -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.

A.3.118 -xstrconst

Inserts string literals into the read-only data section of the text segment instead of the default data segment. Duplicate strings will be eliminated and the remaining copy shared amongst references in the code.

A.3.119 -xtarget=t

Specifies the target system for instruction set and optimization.

The value of t must be one of the following: native, generic, system-name (SPARC, x86).

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 A-21 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 See -xtarget Expansions on SPARC 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 A-22 for the values. For example:

-xtarget=sun4/15 is equivalent to: -xarch=v8a -xchip=micro

-xcache=2/16/1

TABLE A-22 -xtarget Expansions on SPARC

-xtarget=

-xarch

-xchip

-xcache

generic

generic

generic

generic

cs6400

v8

super

16/32/4:2048/64/1

entr150

v8

ultra

16/32/1:512/64/1

entr2

v8plusa

ultra

16/32/1:512/64/1

entr2/1170

v8plusa

ultra

16/32/1:512/64/1

entr2/1200

v8plusa

ultra

16/32/1:512/64/1

entr2/2170

v8plusa

ultra

16/32/1:512/64/1

entr2/2200

v8plusa

ultra

16/32/1:512/64/1

entr3000

v8plusa

ultra

16/32/1:512/64/1

entr4000

v8plusa

ultra

16/32/1:512/64/1

entr5000

v8plusa

ultra

16/32/1:512/64/1

entr6000

v8plusa

ultra

16/32/1:512/64/1

sc2000

v8

super

16/32/4:2048/64/1

solb5

v7

old

128/32/1

solb6

v8

super

16/32/4:1024/32/1

ss1

v7

old

64/16/1

ss10

v8

super

16/32/4

ss10/20

v8

super

16/32/4

ss10/30

v8

super

16/32/4

ss10/40

v8

super

16/32/4

ss10/402

v8

super

16/32/4

ss10/41

v8

super

16/32/4:1024/32/1

ss10/412

v8

super

16/32/4:1024/32/1

ss10/50

v8

super

16/32/4

ss10/51

v8

super

16/32/4:1024/32/1

ss10/512

v8

super

16/32/4:1024/32/1

ss10/514

v8

super

16/32/4:1024/32/1

ss10/61

v8

super

16/32/4:1024/32/1

ss10/612

v8

super

16/32/4:1024/32/1

ss10/71

v8

super2

16/32/4:1024/32/1

ss10/712

v8

super2

16/32/4:1024/32/1

ss10/hs11

v8

hyper

256/64/1

ss10/hs12

v8

hyper

256/64/1

ss10/hs14

v8

hyper

256/64/1

ss10/hs21

v8

hyper

256/64/1

ss10/hs22

v8

hyper

256/64/1

ss1000

v8

super

16/32/4:1024/32/1

ss1plus

v7

old

64/16/1

ss2

v7

old

64/32/1

ss20

v8

super

16/32/4:1024/32/1

ss20/151

v8

hyper

512/64/1

ss20/152

v8

hyper

512/64/1

ss20/50

v8

super

16/32/4

ss20/502

v8

super

16/32/4

ss20/51

v8

super

16/32/4:1024/32/1

ss20/512

v8

super

16/32/4:1024/32/1

ss20/514

v8

super

16/32/4:1024/32/1

ss20/61

v8

super

16/32/4:1024/32/1

ss20/612

v8

super

16/32/4:1024/32/1

ss20/71

v8

super2

16/32/4:1024/32/1

ss20/712

v8

super2

16/32/4:1024/32/1

ss20/hs11

v8

hyper

256/64/1

ss20/hs12

v8

hyper

256/64/1

ss20/hs14

v8

hyper

256/64/1

ss20/hs21

v8

hyper

256/64/1

ss20/hs22

v8

hyper

256/64/1

ss2p

v7

powerup

64/32/1

ss4

v8a

micro2

8/16/1

ss4/110

v8a

micro2

8/16/1

ss4/85

v8a

micro2

8/16/1

ss5

v8a

micro2

8/16/1

ss5/110

v8a

micro2

8/16/1

ss5/85

v8a

micro2

8/16/1

ss600/120

v7

old

64/32/1

ss600/140

v7

old

64/32/1

ss600/41

v8

super

16/32/4:1024/32/1

ss600/412

v8

super

16/32/4:1024/32/1

ss600/51

v8

super

16/32/4:1024/32/1

ss600/512

v8

super

16/32/4:1024/32/1

ss600/514

v8

super

16/32/4:1024/32/1

ss600/61

v8

super

16/32/4:1024/32/1

ss600/612

v8

super

16/32/4:1024/32/1

sselc

v7

old

64/32/1

ssipc

v7

old

64/16/1

ssipx

v7

old

64/32/1

sslc

v8a

micro

2/16/1

sslt

v7

old

64/32/1

sslx

v8a

micro

2/16/1

sslx2

v8a

micro2

8/16/1

ssslc

v7

old

64/16/1

ssvyger

v8a

micro2

8/16/1

sun4/110

v7

old

2/16/1

sun4/15

v8a

micro

2/16/1

sun4/150

v7

old

2/16/1

sun4/20

v7

old

64/16/1

sun4/25

v7

old

64/32/1

sun4/260

v7

old

128/16/1

sun4/280

v7

old

128/16/1

sun4/30

v8a

micro

2/16/1

sun4/330

v7

old

128/16/1

sun4/370

v7

old

128/16/1

sun4/390

v7

old

128/16/1

sun4/40

v7

old

64/16/1

sun4/470

v7

old

128/32/1

sun4/490

v7

old

128/32/1

sun4/50

v7

old

64/32/1

sun4/60

v7

old

64/16/1

sun4/630

v7

old

64/32/1

sun4/65

v7

old

64/16/1

sun4/670

v7

old

64/32/1

sun4/690

v7

old

64/32/1

sun4/75

v7

old

64/32/1

ultra

v8plusa

ultra

16/32/1:512/64/1

ultra1/140

v8plusa

ultra

16/32/1:512/64/1

ultra1/170

v8plusa

ultra

16/32/1:512/64/1

ultra1/200

v8plusa

ultra

16/32/1:512/64/1

ultra2

v8plusa

ultra2

16/32/1:512/64/1

ultra2/1170

v8plusa

ultra

16/32/1:512/64/1

ultra2/1200

v8plusa

ultra

16/32/1:1024/64/1

ultra2/1300

v8plusa

ultra2

16/32/1:2048/64/1

ultra2/2170

v8plusa

ultra

16/32/1:512/64/1

ultra2/2200

v8plusa

ultra

16/32/1:1024/64/1

ultra2/2300

v8plusa

ultra2

16/32/1:2048/64/1

ultra2e

v8plusa

ultra2e

16/32/1:256/64/4

ultra2i

v8plusa

ultra2i

16/32/1:512/64/1

ultra3

v8plusa

ultra3

64/32/4:8192/512/1

ultra3cu

v8plusa

ultra3cu

64/32/4:8192/512/2


The following table lists the -xtarget values for the Intel Architecture:

TABLE A-23 -xtarget Expansions on Intel Architecture

-xtarget=

-xarch

-xchip

-xcache

generic

generic

generic

generic

386

386

386

generic

486

386

486

generic

pentium

386

pentium

generic

pentium_pro

pentium_pro

pentium_pro

generic


A.3.120 -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.

A.3.121 -xtime

Reports the time and resources used by each compilation component.

A.3.122 -xtransition

Issues warnings for the differences between K&R C and Sun ISO C.

The -xtransition option issues warnings in conjunction with the -Xa and -Xt options. You can eliminate all warning messages about differing behavior through appropriate coding. The following warnings no longer appear unless you issue the -xtransition option:

  • \a is ISO C "alert" character
  • \x is ISO 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 ISO 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
  • ISO C treats constant as unsigned: operator
  • semantics of operator change in ISO C; use explicit cast

A.3.123 -xtrigraphs

The -xtrigraphs option determines whether the compiler recognizes trigraph sequences as defined by the ISO C standard.

By default, the compiler assumes -xtrigraphs=yes and recognizes all trigraph sequences throughout the compilation unit.

If your source code has a literal string containing question marks (?) that the compiler is interpreting as a trigraph sequence, you can use the -xtrigraph=no suboption to turn off the recognition of trigraph sequences. The -xtrigraphs=no option turns off recognition of all trigraphs throughout the entire compilation unit.

Consider the following example source file named trigraphs_demo.c.

#include <stdio.h>
 
int main ()
{
 
  (void) printf("(\?\?) in a string appears as (??)\n");
 
  return 0;
}

Here is the output if you compile this code with -xtrigraphs=yes.

example% cc -xtrigraphs=yes trigraphs_demo.c
example% a.out
(??) in a string appears as (]

Here is the output if you compile this code with -xtrigraphs=no.

example% cc -xtrigraphs=no trigraphs_demo.c
example% a.out
(??) in a string appears as (??)

A.3.124 -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.

A.3.125 -xvector[={yes|no}]

Enable automatic generation of calls to the vector library functions.

-xvector=yes permits the compiler to transform math library calls within loops into single calls to the equivalent vector math routines when such transformations are possible. Such transformations could result in a performance improvement for loops with large loop counts.

If you do not specify -xvector, the default is -xvector=no. -xvector=no undoes a previously specified -xvector=yes. If you specify -xvector but do not supply a value, the default is -xvector=yes.

If you use -xvector on the command line without previously specifying -xdepend, -xvector triggers -xdepend. The -xvector option also raises the optimization level to -x03 if optimization is not specified or optimization is set lower than -x03.

The compiler includes the libmvec libraries in the load step. If you compile and link with separate commands, be sure to use -xvector in the linking cc command.

A.3.126 -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.

Use -xvpara with the -xexplicitpar option or the -xparallel option and the #pragma MP. See Section 3.8.3, Explicit Parallelization and Pragmas for more information.

A.3.127 -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.

A.3.128 -YA, dir

Changes the default directory searched for components.

A.3.129 -YI, dir

Changes the default directory searched for include files.

A.3.130 -YP, dir

Changes the default directory for finding library files.

A.3.131 -YS, dir

Changes the default directory for startup object files.

A.3.132 -Zll

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


A.4 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.

 


1 (TableFootnote) You cannot use -Wd to pass the cc options listed in this chapter to the C compiler.