CC man page on SunOS

Man page or keyword search:  
man Server   20652 pages
apropos Keyword Search (all sections)
Output format
SunOS logo
[printable version]

CC(1)									 CC(1)

NAME
       CC - C++ compiler

SYNOPSIS
       CC     [-#] [-###] [-B{dynamic|static|symbolic}] [-c] [-compat[={5|g}]]
	      [+d] [-Dname[=def]] [-d{y|n}] [-dalign] [-dryrun] [-E]
	      [-erroff[=t[,t...]]]  [-errtags[=a]] [-errwarn[=t[,t...]]]
	      [-fast] [-features=a[,a...]]  [-filt[=filter[,filter...]]
	      [-flags] [-fma[={none|fused}]] [-fnonstd] [-fns[={yes|no}]]
	      [-fprecision=a] [-fround=a] [-fsimple[=n]] [-fstore]
	      [-ftrap=a[,a...]]	 [-G] [-g] [-g0] [-g3] [-H] [-h[ ]lname]
	      [-help] [-Ipathname] [-I-] [-i] [-include] [-inline]
	      [-instances=i] [-instlib=file] [-KPIC] [-Kpic] [-keeptmp]
	      [-Lpath] [-llib] [-libmieee] [-libmil] [-library=lib[,lib...]]
	      [-m32|-m64] [-mc] [-misalign] [-mr[,string]] [-mt] [-native]
	      [-noex] [-nofstore] [-nolib] [-nolibmil] [-noqueue]
	      [-norunpath] [-O[n]] [-O[level]] [-o file] [+p] [-P] [-p] [-pen‐
	      tium] [-pg] [-PIC] [-pic] [-pta] [-ptipath] [-pto] [-ptv]
	      [{-Qoption|-qoption} phase [,option...]]	[{-Qproduce|-qpro‐
	      duce}type] [-qp] [-Rpath[:path...]]  [-S] [-s] [-stati‐
	      clib=l[,l...]]  [-sync_stdio=[yes|no]] [-temp=path] [-tem‐
	      plate=a[,a...]]  [-time] [-traceback[=list]] [-Uname]
	      [-unroll=n] [-V] [-v] [-verbose=a[,a...]]	 [-Wc,arg] [+w] [+w2]
	      [-w] [-Xlinker arg] [-Xm] [-xaddr32[={yes|no}]]
	      [-xalias_level[=n]] [-xanalyze={code|no}] [-xannotate] [-xar]
	      [-xarch=isa] [-xautopar] [-xbinopt={a}] [-xbuiltin[={a}]
	      [-xcache=c] [-xchar[=o]] [-xcheck[=n]] [-xchip=c] [-xcode=v]
	      [-xdebugformat=[stabs|dwarf]] [-xdepend[={yes|no}]] [-xdump‐
	      macros[=value[,value...]]	 [-xe] [-xF[=v]] [-xhelp=flags]
	      [-xhwcprof[={enable|disable}]] [-xia] [-xin‐
	      line[=func_spec[,func_spec...]]  [-xinstrument=[no%]datarace]
	      [-xipo[={0|1|2}] [-xipo_archive[=a]] [-xivdep[=p]] [-xjobs=n]
	      [-xkeepframe[=p]] [-xlang=language[,language]] [-xldscope=[v]]
	      [-xlibmieee] [-xlibmil] [-xlibmopt] [-xlic_lib=sunperf]
	      [-xlicinfo] [-xlinkopt[=level]] [-xloopinfo] [-xM] [-xM1] [-xMD]
	      [-xMF] [-xMMD] [-xMerge] [-xmaxopt[=v]] [-xmemalign=ab]
	      [-xmodel=[a]] [-xnolib] [-xnolibmil] [-xnolibmopt] [-xOn]
	      [-xopenmp] [-xpagesize=n] [-xpagesize_heap=n] [-xpage‐
	      size_stack=n] [-xpch=v] [-xpchstop] [-xpec] [-xpg]
	      [-xport64[=v]] [-xprefetch[=a[,a]] [-xprefetch_auto_type=[a]
	      [-xprefetch_level[=l]] [-xprofile=p] [-xprofile_ircache[=path]]
	      [-xprofile_pathmap=collect_prefix:use_prefix]
	      [-xreduction] [-xregs=r[,r...]]  [-xrestrict[=f]] [-xs]
	      [-xsafe=mem] [-xspace] [-xtarget=t] [-xthreadvar[=o]] [-xtime]
	      [-xtrigraphs[={yes|no}]] [-xunroll=n]
	      [-xustr={ascii_utf16_ushort|no}] [-xvector[=a]] [-xvis]
	      [-xvpara] [-xwe] [-Yc,path] [-z arg] [file] ...

DESCRIPTION
       Oracle Solaris Studio 12.3 C++ Compiler

       This man page details the options or flags for the Oracle Solaris Stu‐
       dio 12.3 C++ compiler.

       Complete documentation for this release is available on the Oracle
       Technical Network (OTN) Solaris Studio website:

       http://oracle.com/technetwork/server-storage/solarisstudio

       The OTN website is a complete resource for Oracle Solaris Studio and
       includes many technical articles detailing best practices and deep
       dives into various programming technologies and other topics.

       For the complete description of all new features and functionality in
       the Oracle Solaris Studio suite, see the What's New in this Release
       guide.

       A man page, by definition, is a quick reference. For more detailed
       information on the C++ compiler and its options, see the C++ User's
       Guide.

COMPILING FOR 64-BIT PLATFORMS:
       Use the -m32 and -m64 options to specify the memory model of the target
       compilation, ILP32 or LP64 respectively.

       The -xarch option no longer carries an implicit memory model defini‐
       tion, and should be used only to specify the instruction set of the
       target processor.

       The ILP32 model specifies that C-language int, long, and pointer data
       types are all 32-bits wide. The LP64 model specifies that long and
       pointer data types are all 64-bits wide. The Oracle Solaris and Linux
       OS also support large files and large arrays under the LP64 memory
       model.

       When compiling with -m64, the resulting executable will work only on
       64-bit SPARC or x86 processors under Oracle Solaris OS or Linux OS run‐
       ning a 64-bit kernel.  Compilation, linking, and execution of 64-bit
       objects can only take place in a Oracle Solaris or Linux OS that sup‐
       ports 64-bit execution.

SPECIAL x86 NOTES
       There are some important issues to be aware of when compiling for x86
       Oracle Solaris platforms.

       Programs compiled with -xarch set to sse,  sse2, sse2a, or sse3 and
       beyond must be run only on platforms that provide these extensions and
       features.

       If you compile and link in separate steps, always link using the com‐
       piler and with same -xarch setting to ensure that the correct startup
       routine is linked.

       Numerical results on x86 might differ from results on SPARC due to the
       x86 80-bit floating-point registers. To minimize these differences, use
       the -fstore option or compile with -xarch=sse2 if the hardware supports
       SSE2.

       Numerical results can also differ between Oracle Solaris and Linux
       because the intrinsic math libraries (for example, sin(x)) are not the
       same.

       Binary Compatibility Verification
       Program binaries compiled and built using specialized -xarch hardware
       flags are verified that they are being run on the appropriate platform.
       Running programs compiled with specialized -xarch options on platforms
       that are not enabled with the appropriate features or instruction set
       extensions could result in segmentation faults or incorrect results
       occurring without any explicit warning messages.

       This warning extends also to programs that employ .il inline assembly
       language functions or __asm() assembler code that utilize SSE, SSE2,
       SSE2a, and SSE3 (and beyond) instructions and extensions.

Overview of the C++ Compiler
       CC converts C++ and assembly source files to object files, and links
       object files and libraries into executable programs.

       Programs that contain C++ objects must be linked with CC.

       CC takes arguments ending in .c, .C, .cc, .cxx, .c++, .cpp, or .i to be
       C++ source programs.  Arguments ending in .s are presumed to be assem‐
       bly source files.  Arguments ending in .o are presumed to be object
       files.

       Files whose names do not end with the above suffixes are treated as
       object programs or libraries and are handed over to the link editor.
       Unless -c, -S, -E, or -P is specified, these programs and libraries,
       together with the results of any specified compilations or assemblies,
       are linked in the order given to produce an output file named a.out.
       You can specify a different name for the executable by using the -o
       option.

       If a single file is compiled and linked all at once, the intermediate
       files are deleted.

       Before you use the CC command, insert into your search path the name of
       the directory in which you have chosen to install the C++ compilation
       system.	For instructions on setting your search path, see the csh(1)
       or the sh(1) man page.

User-Supplied Default Compiler Options Startup File
       The default compiler options file enables the user to specify a set of
       default options that are applied to all compiles, unless otherwise
       overridden. For example, the file could specify that all compiles
       default at -xO2, or automatically include the file setup.il.

       At startup, the compiler searches for a default options file listing
       default options it should include for all compiles.  The environment
       variable SPRO_DEFAULTS_PATH specifies a colon-separated list of direc‐
       tories to search for the the defaults file.

       If the environment variable is not set, a standard set of defaults is
       used.  If the environment variable is set but is empty, no defaults are
       used.

       The defaults file name must be of the form  compiler.defaults, where
       compiler is one of the following: cc, c89, c99, CC, ftn, or lint.  For
       example, the defaults for the C++ compiler would be  CC.defaults

       If a defaults file for the compiler is found in the directories listed
       in SPRO_DEFAULTS_PATH, the compiler will read the file and process the
       options prior to processing the options on the command line.  The first
       defaults file found will be used and the search terminated.

       System administrators may create system-wide default files in Studio-
       install-path/prod/etc/config.  If the environment variable is set, the
       installed defaults file will not be read.

       The format of a defaults file is similar to the command line.  Each
       line of the file may contain one or more compiler options separated by
       white space. Shell expansions, such as wild cards and substitutions,
       will not be applied to the options in the defaults file.

       The value of the SPRO_DEFAULTS_PATH and the fully expanded command line
       will be displayed in the verbose output produced by options -#, -###,
       and -dryrun.

       Options specified by the user on the command line will usually override
       options read from the defaults file. For example, if the defaults file
       specifies compiling with -xO4 and the user specifies -xO2 on the com‐
       mand line, -xO2 will be used.

       Some options appearing in the default options file will be appended
       after the options specified on the command line.	 These are the pre‐
       processor option -I, linker options -B, -L, -R, and -l, and all file
       arguments, such as source files, object files, archives, and shared
       objects.

       The following is an example of how a user-supplied default compiler
       option startup file might be used.

       demo% cat /project/defaults/CC.defaults
       -fast -I/project/src/hdrs -L/project/libs -llibproj -xvpara
       demo% setenv SPRO_DEFAULTS_PATH /project/defaults
       demo% CC -c -I/local/hdrs -L/local/libs -lliblocal tst.cc

       The compiler command is now equivalent to:
       CC -fast -xvpara -c -I/local/hdrs -L/local/libs -lliblocal \
	      tst.cc -I/project/src/hdrs -L/project/libs -llibproj

       While the compiler defaults file provides a convenient way to set the
       defaults for an entire project, it can become the cause of hard to
       diagnose problems. Set the environment variable SPRO_DEFAULTS_PATH  to
       an absolute path rather than the current directory to avoid such prob‐
       lems.

       The interface stability of the default options file is uncommitted. The
       order of option processing is subject to change in a future release.

OPTIONS
       All platform-specific options are silently accepted on all platforms.
       Any exceptions to this rule are noted under the specific option.

       Options valid only on SPARC platforms are marked (SPARC).
       Options valid only on x86/x64 platforms are marked (x86).

       Deprecated options are marked (Obsolete) and should not be used going
       forward. They are provided only for compatibility with earlier
       releases. Use the indicated replacement option.

       See ld(1) for linker options.

       In the syntax of the command-line options, items shown in square brack‐
       ets ( [] ) are optional. Curly brackets enclose a bar-separated list of
       literal items to be chosen, as in {yes | no | maybe } .	The first item
       in a list usually indicates the default value when the flag appears
       without a value.

       For example, -someoption[={no|yes}] implies -someoption is the same as
       -someoption=no .

       In general, compiler options are processed from left to right (with the
       exception that the -U options are processed after all -D options),
       allowing selective overriding of macro options (options that include
       other options).	This rule does not apply to linker options.

       For a complete description of the C++ compiler options, including exam‐
       ples, see the C++ User's Guide.

       CC accepts the following options.

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

       -###   Shows each component as it would be invoked, but does not actu‐
	      ally execute it. Also shows how command options would expand.

       -Bbinding
	      Specifies whether a library binding for linking is symbolic,
	      dynamic (shared), or static (nonshared).

	      -Bdynamic is the default.	 You can use the -B option several
	      times on a command line.

	      For more information on the -Bbinding option, see the ld(1) man
	      page and the Oracle Solaris documentation.

	      -Bdynamic directs the link editor to look for liblib.so files.
	      Use this option if you want shared library bindings for linking.
	      If the liblib.so files are not found, it looks for liblib.a
	      files.

	      -Bstatic directs the link editor to look only for liblib.a
	      files.  The .a suffix indicates that the file is static, that
	      is, nonshared.  Use this option if you want nonshared library
	      bindings for linking.

	      -Bsymbolic forces symbols to be resolved within a shared library
	      if possible, even when a symbol is already defined elsewhere.
	      For an explanation of -Bsymbolic, see the ld(1) man page.

	      This option and its arguments are passed to the linker, ld.  If
	      you compile and link in separate steps and are using the -Bbind‐
	      ing option, you must include the option in the link step.

	      Warning:

	      Never use -Bsymbolic with programs containing C++ code, use
	      linker scoping instead. See the C++ User's Guide for more infor‐
	      mation on linker scoping. See also the -xldscope option.

	      With -Bsymbolic, references in different modules can bind to
	      different copies of what is supposed to be one global object.

	      The exception mechanism relies on comparing addresses. If you
	      have two copies of something, their addresses won't compare
	      equal, and the exception mechanism can fail because the excep‐
	      tion mechanism relies on comparing what are supposed to be
	      unique addresses.

       -c     Compile and produce a .o file for each source file without link‐
	      ing.  You can explicitly name a single object file by using the
	      -o option. When the compiler produces object code for each .i or
	      .c input file, it always creates an object file in the current
	      working directory.  If you suppress the linking step, you also
	      suppress the removal of the object files.

	      For example:

	      o	     CC -c x.cc generates the object file x.o.

	      o	     CC -c -o y.o x.cc generates the object file y.o.

	      Warnings:

	      When the compiler produces object code for an input file (for
	      example, .cc, .c, or .i), the compiler always produces a .o file
	      in the working directory.	 If you suppress the linking step, the
	      .o files are not removed.

	      See also:

	      -o filename.

       -compat={5|g}
	      Sets the major release compatibility mode of the compiler.  This
	      option controls the __SUNPRO_CC_COMPAT preprocessor symbol.

	      Standard mode, -compat=5, accepts constructs according to the
	      ANSI/ISO 1998 C++ standard as corrected in 2003 and is the
	      default with the release of Oracle Solaris Studio 12.3.  ("Com‐
	      patibility Mode", -compat=4, was removed in this release.)

	      -compat=g adds compatibility with the gcc/g++ compiler on x86
	      Oracle Solaris and Linux platforms.

	      Value  Meaning

	      -compat=5
		     (Standard mode) Set the language and binary compatibility
		     to ANSI/ISO standard mode and is the default. Sets the
		     __SUNPRO_CC_COMPAT preprocessor macro to 5).

	      -compat=g
		     (x86 Only) enables recognition of g++ language extensions
		     and causes the compiler to generate code that is binary-
		     compatible with g++ on x86 Oracle Solaris and  Linux
		     platforms.

		     The binary compatibility extends only to shared (dynamic
		     or .so) libraries, not to individual .o files or archive
		     (.a) libraries.

		     Sets the __SUNPRO_CC_COMPAT preprocessor macro to 'G'.

		     Example 1, linking g++ shared library to x86 Oracle
		     Solaris Studio C++ main program

		     % g++ -shared -o libfoo.so -fpic a.cc b.cc c.cc
		     % CC -compat=g main.cc -L. -lfoo

		     Example 2, linking x86 Oracle Solaris Studio C++ shared
		     library to g++ main program

		     % CC -compat=g -G -o libfoo.so -Kpic a.cc b.cc c.cc
		     % g++ main.cc -L. -lfoo

	      Defaults:

	      If the -compat option is not specified, -compat=5 is assumed.

	      Interactions:

	      See -features for additional information.

       +d     Prevents the compiler from expanding C++ inline functions.

	      Under the C++ language rules, a C++ inline function is a func‐
	      tion for which one of the following statements is true.

	      o The function is defined using the inline keyword.

	      o The function is defined (not just declared) inside a class
	      definition

	      o The function is a compiler-generated class member function

	      Under the C++ language rules, the compiler can choose whether
	      actually to inline a call to an inline function. The C++ com‐
	      piler inlines calls to an inline function unless:

	      o The function is too complex

	      o The +d option is selected

	      o The -g option is selected with no optimization option

	      Interactions:

	      This option is automatically turned on when you specify -g, the
	      debugging option, unless a -O or -xO optimization level is also
	      specified..

	      The -g0 debugging option does not turn on +d.

	      The +d option has no effect on the automatic inlining that is
	      performed when you use -xO4 or -xO5.

       -Dname[=def]
	      Defines a macro symbol name to the preprocessor.	Doing so is
	      equivalent to including a #define directive at the beginning of
	      the source.  You can use multiple -D options.

	      The following values are predefined.

	      SPARC and x86 platforms:

	      __ARRAYNEW
	      __BUILTIN_VA_ARG_INCR
	      __DATE__
	      __FILE__
	      __LINE__
	      __STDC__ = 0
	      __SUNPRO_CC = 0x5130
	      __SUNPRO_CC_COMPAT = 5 or G
	      __TIME__
	      __cplusplus
	      __sun
	      __unix
	      _BOOL if type bool is enabled
	      (see "-features=[no%]bool")
	      _WCHAR_T
	      sun
	      unix
	      __SVR4 (Oracle Solaris)
	      __SunOS_5_10  (Oracle Solaris)
	      __SunOS_5_11  (Oracle Solaris)

	      SPARC only:
	      sparc
	      sparcv8
	      __SUN_PREFETCH = 1
	      __sparc

	      SPARC V9 only:
	      __sparcv9 (with -m64)

	      x86 only:
	      linux
	      __amd64 (with -m64)
	      __gnu__linux__
	      __linux
	      __linux__
	      __x86_64 (with -m64)

	      Note that __sun is only defined on Oracle Solaris platforms. Use
	      __SUNPRO_CC to determine if the compiler is the Oracle Solaris
	      Studio CC compiler.

	      Defaults:

	      If you do not use [=def], name is defined as 1.

	      Interactions:

	      If +p is used, sun, unix, sparc and i386 are not defined.

       -d{y|n}
	      Allows or disallows dynamic libraries for the entire executable.

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

	      Interactions:

	      This option causes fatal errors if you use it in combination
	      with dynamic libraries. Most system libraries are only available
	      as dynamic libraries.

       -dalign
	      (SPARC) Obsolete. You should not use this option. Use -xmema‐
	      lign=8s instead. For a complete list of obsolete options, see
	      the C++ User's Guide.

	      This option is silently ignored on x86/x64 platforms.

       -dryrun
	      Directs the CC driver to show, but not execute, the commands
	      constructed by the compilation driver.

       -E     Directs the CC driver to only preprocess the C++ source files,
	      and to send the result to stdout (standard output). No compila‐
	      tion is done; no .o files are generated.

	      This option causes preprocessor-type line number information to
	      be included in the output.

	      To compile the output of the -E option when the source code
	      involves templates, you might need to use the -tem‐
	      plate=no%extdef option with the -E option.  If application code
	      uses the "definitions separate" template source code model, the
	      output of the -E option might still not compile.	Refer to the
	      C++ Users Guide chapters on templates for more information.

       -erroff[=t[,t...] ]
	      Suppresses compiler warning messages but has no effect on error
	      messages.	 This option applies to all warning messages whether
	      or not they have been designated by -errwarn to cause a non-zero
	      exit status.

	      Values:

	      The -erroff values are members of a comma-separated list that
	      consists of one or more of the following:

	      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. This is the default.

	      Order is important; for example, %all,no%tag suppresses all
	      warning messages except tag.

	      Defaults:

	      The default is -erroff=%none.  Specifying -erroff is equivalent
	      to specifying -erroff=%all.

	      Warnings:

	      Only warning messages from the C++ compiler front-end that dis‐
	      play a tag when the -errtags option is used can be suppressed
	      with the -erroff option.

       -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 sup‐
	      pressed with -erroff and made fatal with -errwarn.

	      Values and Defaults:

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

       -errwarn [ = t[,t...]]
	      Use the -errwarn option to cause the C++ compiler to exit with a
	      failure status for the given warning messages.

	      Values:

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

	      The following table details the -errwarn values:

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

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

	      %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 messages from causing CC to exit
		       with a fatal status should any warning tag be issued.
		       This is the default.

	      Defaults:

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

	      Warnings:

	      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 dis‐
	      play 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.

	      See Also:

	      -erroff, -errtags

       -fast  This option is a macro that you can effectively use as a start‐
	      ing point for tuning an executable for maximum run-time perfor‐
	      mance. The expansion of -fast can change from one release of the
	      compiler to the next and includes options that are target plat‐
	      form specific. Use the -dryrun option to examine the expansion
	      of -fast, and incorporate the appropriate options of -fast into
	      the ongoing process of tuning the executable.

	      Modules that are compiled with -fast must also be linked with
	      -fast. For a complete list of compiler options that must be
	      specified at both compile time and at link time, see the C++
	      User's Guide.

	      The expansion of -fast includes the -xlibmopt option, which
	      enables the compiler to use a library of optimized math rou‐
	      tines. For more information, see the description of -xlibmopt in
	      this man page.

	      This option provides near maximum performance for most applica‐
	      tions by expanding the following compilation options:

	      -fns (SPARC, x86)
	      -fsimple=2 (SPARC, x86)
	      -nofstore (x86)
	      -xbuiltin=%all (SPARC, x86)
	      -xdepend (SPARC, x86)
	      -xlibmil (SPARC, x86)
	      -xlibmopt (SPARC, x86)
	      -xmemalign (SPARC)
	      -xO5 (SPARC, x86)
	      -xregs=frameptr (x86)
	      -xtarget=native (SPARC, x86)

	      Note that this selection of component option flags is subject to
	      change with each release of the compiler.	 You can view an
	      expansion of the -fast options by running the command

	      CC -fast -xdryrun |& grep ###

	      For details on the options set by -fast, see the C++ User's
	      Guide.

	      Interactions:

	      You can override the values set by -fast by specifying different
	      values to the right of -fast on the command line.	 For example,
	      although the optimization level set by -fast  is -xO5, if you
	      specify -fast, -xO3, the optimization level becomes -xO3.

	      The -fast macro expands into compilation options that may affect
	      other specified options. For example, in the following command,
	      the expansion of the -fast macro includes -xtarget=native which
	      reverts -xarch to one of the 32-bit architecture options.

	      Incorrect:

	      example% CC -xarch=sparcvis3 -fast test.cc

	      Correct:

	      example% CC -fast -xarch=sparcvis3 test.cc

	      See the description for each option to determine possible inter‐
	      actions.

	      Warnings:

	      Code compiled with the -fast option is not portable. For exam‐
	      ple, compiling code using the following command on an Ultra‐
	      SPARC(TM) III system will generate a binary that will not exe‐
	      cute on an UltraSPARC II system.

	      example% CC -fast test.cc

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

	      The -fast option includes -fns -ftrap=%none; that is, this
	      option turns off all trapping.

	      The -fast option on x86 includes -xregs=frameptr.	 Be sure to
	      read the discussion of -xregs=frameptr especially when compiling
	      mixed C, Fortran, and C++ source codes.

	      The expansion of the -fast option includes -D_MATH‐
	      ERR_ERRNO_DONTCARE.

	      See also:

	      Numerical Computation Guide, ieee_sun(3m).

       -features=a
	      Enables/disables various C++ language features.

	      The following table lists the -features suboption keywords and
	      their meanings.  The prefix no% applied to a suboption disables
	      that suboption.

	      Value	     Meaning

	      %all Deprecated.	Do not use %all. See warning below.

	      %none
		   Deprecated. Do not use %none. See warning below.

	      [no%]altspell
		   Recognize alternative token spellings (for example, and for
		   &&).	 The default is altspell.

	      [no%]anachronisms
		   Allow anachronistic constructs. When disabled (that is
		   -feature=no%anachronisms), no anachronistic constructs are
		   allowed. The default is anachronisms.

	      [no%]bool
		   Allow the bool type and literals. When enabled, the macro
		   _BOOL = 1.  When disabled, the macro is not defined. The
		   default is bool.

	      [no%]conststrings
		   Put literal strings in read-only memory. The default is
		   conststrings.

	      cplusplus_redef
		   Allow the normally pre-defined macro __cplusplus to be
		   redefined by a -D option on the command line. Attempting to
		   redefine __cplusplus with a #define directive in source
		   code is not allowed.

		   Example:
		    CC -features=cplusplus_redef -D__cplusplus=1 ...

		   The g++ compiler typically predefines the __cplusplus macro
		   to 1, and source code might depend on this non-standard
		   value.  (The standard value is 199711L for compilers imple‐
		   menting the 1998 C++ standard or the 2003 update. Future
		   standards will require a larger value for the macro.)

		   Do not use this option unless you need to redefine __cplus‐
		   plus to 1 in order to compile code intended for g++.

	      [no%]except
		   Allow C++ exceptions. When C++ exceptions are disabled
		   (that is, -features=no%except), a throw-specification on a
		   function is accepted but ignored; the compiler does not
		   generate exception code. Note that the keywords try, throw,
		   and catch are always reserved. The default is except.

	      explicit
		   Recognizes the keyword explicit. no%explicit is not
		   allowed.

	      [no%]export
		   Recognize the keyword export.  The default is export.

	      [no%]extensions
		   Allow non-standard code that is commonly accepted by other
		   C++ compilers. See chapter 4 of the C++ User's Guide for an
		   explanation of the invalid code that is accepted by the
		   compiler when you use the -features=extensions option.  The
		   default is -features=no%extensions.

	      [no%]iddollar
		   Allow $ as a non-initial identifier character.  The default
		   is no%iddollar.

	      [no%]localfor
		   Use standard-conforming local-scope rules for the for
		   statement. The default is localfor.

	      [no%]mutable
		   Recognize the keyword mutable.  The default is mutable.

	      namespace
		   Recognize the keyword namespace. no%namespace is not
		   allowed.

	      [no%]nestedaccess
		   Allow nested classes to access private members of the
		   enclosing class.
		   Default: -features=nestedacces

	      [no%]rvalueref
		   Allow binding a non-const reference to an rvalue or tempo‐
		   rary.
		   Default: -features=no%rvalueref
		   The C++ compiler has traditionally been lax in enforcing
		   the rule that a non-const reference cannot be bound to a
		   temporary or rvalue.	 The C++ compiler accepts the invalid
		   code by default.  To restore the old compiler behavior, use
		   the option -features=rvalueref.

	      rtti Allow runtime type identification (RTTI).  -fea‐
		   tures=no%rtti is not allowed.

	      [no%]split_init
		   Put initializers for nonlocal static objects into individ‐
		   ual functions. When you use -features=no%split_init, the
		   compiler puts all the initializers in one function. Using
		   -features=no%split_init minimizes code size at the possible
		   expense of compile time. The default is split_init.

	      [no%]strictdestorder
		   Follow the requirements specified by the C++ standard
		   regarding the order of the destruction of objects with
		   static storage duration. The default is strictdestrorder.

	      [no%]tmplife
		   Clean up the temporary objects that are created by an
		   expression at the end of the full expression, as defined in
		   the ANSI/ISO C++ Standard.  (When -features=no%tmplife is
		   in effect, most temporary objects are cleaned up at the end
		   of their block.) The default is tmplife.

	      [no%]tmplrefstatic
		   Allow function templates to refer to dependent static func‐
		   tions or static function templates. The default is the
		   standard conformant no%tmplrefstatic.

	      [no%]transitions
		   Allow ARM language constructs that are problematic in stan‐
		   dard C++ and that may cause the program to behave differ‐
		   ently than expected or that may be rejected by future com‐
		   pilers. When you use -features=no%transitions, the compiler
		   issues warnings about these constructs instead of error
		   messages.

	      Interactions:

	      This option accumulates instead of overrides.

	      Use of the following is not compatible with the standard
	      libraries and headers:

		o no%bool
		o no%except
		o no%mutable

	      Warnings:

	      Do not use -features=%all or -features=%none.  These suboptions
	      are deprecated and might be removed in a future release.
	      Results can be unpredictable.

	      The behavior of a program might change when you use -fea‐
	      tures=tmplife.  Testing whether the program works both with and
	      without the -features=tmplife option is one way to test the pro‐
	      gram's portability.

       -filt[=filter[,filter...]]
	      Suppress the filtering that CC normally applies to linker error
	      messages.

	      The prefix no% applied to a suboption disables that suboption.

	      filter must be one of the following values

	      [no%]errors    Show the C++ explanations of the linker error
			     messages.	The suppression of the explanations is
			     useful when the linker diagnostics are provided
			     directly to another tool.

	      [no%]names     Demangle the C++ mangled linker names.

	      [no%]returns   Demangle the return types of functions.  Suppres‐
			     sion of this demangling helps you to identify
			     function names more quickly, but note that in the
			     case of co-variant returns, some functions differ
			     only in the return type.

	      [no%]stdlib    Simplify names from the standard library in both
			     the linker and compiler error messages. This
			     makes it easier for you to recognize the name of
			     standard-library functions.

	      %all	     Equivalent to -filt=errors,names,returns,stdlib.
			     This is the default behavior.

	      %none	     Equivalent to
			     -filt=no%errors,no%names,no%returns,no%stdlib.

	      Defaults:

	      If you do not specify the -filt option, or if you specify -filt
	      without any values, then the compiler assumes
	      -filt=errors,names,returns,stdlib.

	      Interactions:

	      [no%]returns has no effect when used with no%names.  That is,
	      the following options are equivalent:

		-filt=no%names
		-filt=no%names,no%returns
		-filt=no%names,returns

	      See also c++filt(1).

       -flags Same as -xhelp=flags.

       -fma[={none|fused}]
	      (SPARC) Enables automatic generation of floating-point, fused,
	      multiply-add instructions. -fma=none disables generation of
	      these instructions.  -fma=fused allows the compiler to attempt
	      to find opportunities to improve the performance of the code by
	      using floating-point, fused, multiply-add instructions.

	      The default is -fma=none.

	      The minimum requirements are -xarch=sparcfmaf and an optimiza‐
	      tion level of at least -xO2 for the compiler to generate fused
	      multiply-add instructions. The compiler marks the binary program
	      if fused multiply-add instructions are generated in order to
	      prevent the program from executing on platforms that do not sup‐
	      port them.

	      Fused multiply-adds eliminate the intermediate rounding step
	      between the multiply and the add.	 Consequently, programs may
	      produce different results when compiled with -fma=fused,
	      although precision will tend to be increased rather than
	      decreased.

       -fnonstd
	      This is a macro that expands to -ftrap=common on x86, and -fns
	      -ftrap=common on SPARC.

	      See -fns and -ftrap=common as well as the Numerical Computation
	      Guide for more information.

       -fns[={no|yes}]

	      For SPARC, this option causes the nonstandard floating-point
	      mode to be enabled when a program begins execution.

	      For x86, this option selects SSE flush-to-zero mode and, where
	      available, denormals-are-zero mode. This option causes subnormal
	      results to be flushed to zero on x86. Where available, this
	      option also causes subnormal operands to be treated as zero.
	      This option has no effect on traditional x86 floating-point
	      operations that do not utilize the SSE or SSE2 instruction set.

	      On some SPARC platforms, the nonstandard floating-point mode
	      disables "gradual underflow," causing tiny results to be flushed
	      to zero rather than to produce subnormal numbers. It also causes
	      subnormal operands to be silently replaced by zero.

	      On those SPARC platforms that do not support gradual underflow
	      and subnormal numbers in hardware, use of this option can sig‐
	      nificantly improve the performance of some programs.

	      Optional use of =yes or =no provides a way of toggling the -fns
	      flag following some other macro flag that includes -fns, such as
	      -fast.

	      -fns is the same as -fns=yes.
	      -fns=yes selects non-standard floating point.
	      -fns=no selects standard floating point.

	      Defaults:

	      If -fns is not specified, the nonstandard floating-point mode is
	      not enabled automatically. Standard IEEE 754 floating-point com‐
	      putation takes place, that is, underflows are gradual.

	      If only -fns is specified -fns=yes is assumed.

	      Warnings:

	      When nonstandard mode is enabled, floating-point arithmetic may
	      produce results that do not conform to the requirements of the
	      IEEE 754 standard.

	      On SPARC systems, this option is effective only if used when
	      compiling the main program.

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

       -fprecision=a
	      (x86 platform) Sets floating-point rounding precision mode. a
	      must be one of: single, double, extended.

	      The -fprecision flag sets the rounding precision mode bits in
	      the Floating Point Control Word. These bits control the preci‐
	      sion to which the results of basic arithmetic operations (add,
	      subtract, multiply, divide, and square root) are rounded.

	      The following table shows the meanings of the values of a.

	      Value	Meaning

	      single	Rounds to an IEEE single-precision value

	      double	Rounds to an IEEE double-precision value

	      extended	Rounds to the maximum precision available

	      When a is single or double, this flag causes the rounding preci‐
	      sion mode to be set to single or double precision, respectively,
	      when a program begins execution. When p is extended or the
	      -fprecision flag is not used, the rounding precision mode
	      remains as the extended precision.

	      The single precision rounding mode causes results to be rounded
	      to 24 significant bits, and double precision rounding mode
	      causes results to be rounded to 53 significant bits. In the
	      default extended precision mode, results are rounded to 64 sig‐
	      nificant bits. This mode controls only the precision to which
	      results in registers are rounded, and it does not affect the
	      range. All results in register are rounded using the full range
	      of the extended double format. Results that are stored in memory
	      are rounded to both the range and precision of the destination
	      format.

	      The nominal precision of the float type is single.  The nominal
	      precision of the long double type is extended.

	      Defaults:

	      When the -fprecision flag is not specified, the rounding preci‐
	      sion mode defaults to extended.

	      Warnings:

	      This option is effective only on x86 systems and only if used
	      when compiling the main program, but is ignored if compiling for
	      64-bit platforms (-m64), or SSE2-enabled processors
	      (-xarch=sse2).  -fprecision is ignored on SPARC platforms.

       -fround=a
	      Sets the IEEE rounding mode in effect at startup.

	      a must be one of: nearest, tozero, negative, positive.

	      Value	Meaning

	      nearest	Rounds towards the nearest number and breaking ties to
			even numbers.

	      tozero	Round-to-zero.

	      negative	Round-to-negative-infinity.

	      positive	Round-to-positive-infinity.

	      This option sets the IEEE 754 rounding mode that:

	      o Can be used by the compiler in evaluating constant expres‐
		sions.

	      o Is established at runtime during the program initialization.

	      The meanings are the same as those for the  ieee_flags function,
	      which may be used to change the mode at runtime.

	      Defaults:

	      When the -fround option is not specified, the rounding mode
	      defaults to -fround=nearest.

	      Warnings:

	      If you compile one routine with -fround=a, compile all routines
	      of the program with the same -fround=a option; otherwise, you
	      can get unexpected results.  This option is effective only if
	      used when compiling the main program.

	      Note that compiling with -xvector or -xlibmopt require default
	      rounding. Programs that link with libraries compiled with either
	      -xvector or -xlibmopt or both must ensure that default rounding
	      is in effect.

       -fsimple[=n]
	      Selects floating-point optimization preferences.

	      If n is present, it must be 0, 1 or 2.

	      The following table shows the -fsimple values.

	      Value	Meaning

	      0		Permits no simplifying assumptions. Preserves strict
			IEEE 754 conformance.

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

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

			With -fsimple=1, the optimizer can assume the follow‐
			ing:

			o IEEE 754 default rounding/trapping modes do not
			  change after process initialization.

			o Computation producing no visible result other than
			  potential floating-point exceptions may be deleted.

			o Computation with Infinity or NaNs as operands need
			  not propagate NaNs to their results. For example,
			  x*0 may be replaced by 0.

			o Computations do not depend on sign of zero.

	      2		Includes all the functionality of -fsimple=1, and also
			enables the use of SIMD instructions to compute reduc‐
			tions when -xvector=simd is in effect.

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

	      Defaults:

	      If -fsimple is not designated, the compiler uses -fsimple=0.

	      If -fsimple is designated but no value is given for n, the com‐
	      piler uses -fsimple=1.

	      Warnings:

	      This option can break IEEE 754 conformance.

	      See Also:

	      Techniques for Optimizing Applications: High Performance Comput‐
	      ing written by Rajat Garg and Ilya Sharapov for a more detailed
	      explanation of how optimization can impact precision.  See also
	      articles on performance and precision on the OTN Oracle Solaris
	      Studio website:
	      oracle.com/technetwork/server-storage/solarisstudio/

       -fstore
	      (x86 platform) Forces precision of floating-point expressions.

	      This option causes the compiler to convert the value of a float‐
	      ing-point expression or function to the type on the left side of
	      an assignment - when that expression or function is assigned to
	      a variable, or when that expression is cast to a shorter float‐
	      ing-point type rather than leaving the value in a register.

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

	      Warnings:

	      Due to roundoffs and truncation, the results may be different
	      from those that are generated from the register values.

       -ftrap=a[,a...]
	      Sets the IEEE trapping mode in effect at startup but does not
	      install a SIGFPE handler. You can use ieee_handler(3M) or
	      fex_set_handling(3M) to simultaneously enable traps and install
	      a SIGFPE handler. If you specify more than one value, the list
	      is processed sequentially from left to right.

	      a must be one of the following values.

	      Value	     Meaning

	      [no%]division
			      Trap on division by zero.

	      [no%]inexact
			      Trap on inexact result.

	      [no%]invalid
			      Trap on invalid operation.

	      [no%]overflow
			      Trap on overflow.

	      [no%]underflow
			      Trap on underflow.

	      %all	     Trap on all the above.

	      %none	     Trap on none of the above.

	      common	     Trap on invalid, division by zero, and overflow.

	      Note that the [no%] prefix is used only to modify the meanings
	      of the %all or common value and must be used with one of these
	      values, as shown in the example. The [no%] prefix by itself does
	      not explicitly cause a particular trap to be disabled.

	      Defaults:

	      If you do not specify -ftrap, the compiler assumes -ftrap=%none.

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

	      Warnings:

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

	      Use the -ftrap=inexact trap with caution, as it will result in
	      the trap being issued whenever a floating-point value cannot be
	      represented exactly. For example, the following statement may
	      generate this condition:

	      x = 1.0 / 3.0;

       -G     Build a dynamic shared library instead of an executable file;
	      see the ld(1) man page and the C++ User's Guide.	All source
	      files specified in the command line are compiled with
	      -xcode=pic13 by default.

	      When building a shared library from files that involve templates
	      and were compiled with the -instances=extern option, any tem‐
	      plate instances referenced by the .o files will be included from
	      the template cache automatically.

	      If you are creating a shared object by specifying -G along with
	      other compiler options that must be specified at both compile
	      time and link time, make sure that those same options are also
	      specified at both compile time and link time when you link with
	      the resulting shared object.

	      When you create a shared object, all the object files that are
	      compiled for 64-bit SPARC architectures must also be compiled
	      with an explicit -xcode value as documented under the descrip‐
	      tion of -xcode.

	      The following options are passed to ld if -c is not specified:

	      o -dy

	      o -G

	      o -R

	      Do not use ld -G to build shared libraries; use CC -G. The CC
	      driver automatically passes several options to ld that are
	      needed for C++.

	      When you use the -G option, the compiler does not pass any
	      default -l options to ld. If you want the shared library to have
	      a dependency on another shared library, you must pass the neces‐
	      sary -l option on the command line. For example, if you want the
	      shared library to be dependent upon libCrun, you must pass
	      -lCrun on the command line.

       -g     Instructs both the compiler and the linker to prepare the file
	      or program for debugging with dbx(1) or the performance ana‐
	      lyzer(1).	 The tasks include:

	      o Producing more detailed information in the symbol table of the
		object files and the executable

	      o Producing some "helper functions," which the Debugger can call
		to implement some of its features

	      o Disabling the inline generation of functions, if no optimiza‐
		tion level is specified; that is, using this option implies
		the +d option if no optimization level is also specified.  -g
		with any -O or -xO level does not disable inlining.

	      o Disabling certain levels of optimization

	      Interactions:

	      If you use this option with -xO[level] (or its equivalent
	      options, such as -O), you will get inlining and limited debug‐
	      ging information. For more information, see the entry for -xO.

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

	      If you use this option and the optimization level is -xO4 or
	      higher, the compiler provides best effort symbolic information
	      with full optimization.

	      When you specify this option, the +d option is specified auto‐
	      matically unless -O or -xO are also specified.

	      To use the full capabilities of the Performance Analyzer, com‐
	      pile with the -g option. While some performance analysis fea‐
	      tures do not require -g, you must compile with -g to view anno‐
	      tated source, some function level information, and compiler com‐
	      mentary messages. See the analyzer(1) man page and the Perfor‐
	      mance Analyzer manual for more information.

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

	      Warnings

	      If you compile and link your program in separate steps, then
	      including the -g option in one step and excluding it from the
	      other step will not affect the correctness of the program, but
	      it will affect the ability to debug the program. Any module that
	      is not compiled with -g (or -g0), but is linked with -g (or -g0)
	      will not be prepared properly for debugging. Note that compiling
	      the module that contains the function main with the -g option
	      (or the -g0 option) is usually necessary for debugging.

	      See also:

	      For more information, see the explanations for -g0, -xs, and +d,
	      as well as the ld(1) man page.

       -g0    Instructs the compiler to prepare the file or program for debug‐
	      ging, but not to disable inlining.  This option is the same as
	      -g, except that +d is disabled and dbx cannot step into inlined
	      functions.

	      See also:

	      +d

       -g3    Produce additional debugging information.

	      -g3 is the same as -g0 with additional debugging symbol table
	      information so that dbx can display how macros in the source
	      code have been expanded.	This added symbol table information
	      can result in an increase in the size of the debug information
	      in the resulting .o and executable when compared to only using
	      -g0.

       -H     On the standard error output (stderr), prints, one per line, the
	      path name of each #include file contained in the current compi‐
	      lation.

       -h[ ]lname
	      Assigns the name lname to the generated shared dynamic library.

	      This is a loader option that is passed to ld.  In general, the
	      name after -h should be exactly the same as the one after -o.  A
	      space between the -h and lname is optional.

	      The compile-time loader assigns the specified name to the shared
	      dynamic library you are creating.	 It records the name in the
	      library file as the intrinsic name of the library.  If there is
	      no
	      -hlname option, then no intrinsic name is recorded in the
	      library file.

	      Every executable file has a list of needed shared library files.
	      When the runtime linker links the library into an executable
	      file, the linker copies the intrinsic name from the library into
	      that list of needed shared library files.	 If there is no
	      intrinsic name of a shared library, then the linker copies the
	      path of the shared library file instead.	This command line is
	      an example:

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

	      Interactions:

	      This option accumulates instead of overrides.

       -help  Same as -xhelp=flags.

       -Ipathname
	      Adds pathname to the list of directories that are searched for
	      files with relative file names — those that do not begin with a
	      slash.

	      The compiler searches for quote-included files (of the form
	      #include "foo.h") in this order:

	      1.     In the directory containing the source

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

	      3.     In the include directories for compiler-provided C++
		     header files, ANSI C header files, and special-purpose
		     files

	      4.     In usrinclude

	      The compiler searches for bracket-included files (of the form
	      #include <foo.h>) in this order:

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

	      2.     In the include directories for compiler-provided C++
		     header files, ANSI C header files, and special-purpose
		     files

	      3.     In usrinclude

	      Note — If the spelling matches the name of a standard header
	      file, also refer to "Standard Header Implementation" in the C++
	      User's Guide.

	      Interactions:

	      This option accumulates instead of overrides.

	      The -I- option allows you to override the default search rules.

	      If -library=no%Cstd is specified, then the compiler-provided
	      Cstd header files are not searched.

	      Note — If -ptipath is not used, the compiler looks for template
	      files in -Ipathname.  It is recommended that you use -Ipathname
	      instead of -ptipath.

	      Warnings

	      Never specify the compiler installation area, /usr/include,
	      /lib, /usr/lib, as search directories.

       -I-    Change the include-file search rules to the following:

	      o	     For include files of the form #include "foo.h", search
		     the directories in the following order:

		     1.	    The directories named with -I options (both before
			    and after -I-)

		     2.	    The directories for compiler-provided C++ header
			    files, ANSI C header files, and special-purpose
			    files.

		     3.	    The /usr/include directory.

	      o	     For include files of the form #include <foo.h>, search
		     the directories in the following order:

		     1.	    The directories named with the -I options that
			    appear after -I-.

		     2.	    The directories for compiler-provided C++ header
			    files, ANSI C header files, and special-purpose
			    files.

		     3.	    The /usr/include directory.

	      Warnings

	      Never specify the compiler installation area, /usr/include,
	      /lib, /usr/lib, as search directories.

	      Only the first -I- in a command line causes the described behav‐
	      ior.

       -i     Tells the linker, ld(1), to ignore any LD_LIBRARY_PATH or
	      LD_LIBRARY_PATH_64 setting.

       -include filename
	      This option causes the compiler to treat filename as if it
	      appears in the first line of a primary source file as a #include
	      preprocessor directive.

	      The first directory the compiler searches for filename is the
	      current working directory and not the directory containing the
	      main source file, as is the case when a file is explicitly
	      included. If the compiler cannot find filename in the current
	      working directory, it searches the normal directory paths. If
	      you specify multiple -include options, the files are included in
	      the order they appear on the command line.

       -inline
	      Same as -xinline.

       -instances=a
	      Controls the placement and linkage of template instances.	 The
	      following table shows the meanings of the values of a.

	      Value	Meaning

	      extern	Places all needed instances into the template reposi‐
			tory within comdat sections and gives them global
			linkage. (If an instance in the repository is out of
			date, it is reinstantiated.)
			Note: If you are compiling and linking in separate
			steps and you specify -instance=extern for the compi‐
			lation step, you must also specify it for the link
			step.

	      explicit	Places explicitly instantiated instances into the cur‐
			rent object file within comdat sections and gives them
			global linkage. Does not generate any other needed
			instances.

	      global	Places all needed instances into the current object
			file within comdat sections and gives them global
			linkage.

	      semiexplicit
			Places explicitly instantiated instances and all
			instances needed by the explicit instances into the
			current object file within comdat sections and gives
			them global linkage.

	      static	Note: -instances=static is deprecated. There is no
			longer any reason to use -instances=static, because
			-instances=global now gives you all the advantages of
			static without the disadvantages.  This option was
			provided in earlier compilers to overcome problems
			that do not exist in this version of the compiler.
			Places all needed instances into the current object
			file and gives them static linkage.

	      Defaults:

	      If instances is not specified, -instances=global is assumed.

	      Warnings:

	      static and semiexplicit values may produce invalid results.  See
	      C++ User's Guide for more information.

       -instlib=file

	      Use this option to inhibit the generation of a template
	      instances that are duplicated in a library, either static or
	      shared, and the current object.  In general, if your program
	      shares large numbers of instances with libraries, try
	      -instlib=file and see whether compilation time improves.

	      Values:

	      Use the file argument to specify the library that contains tem‐
	      plate instances that could be generated by the current compila‐
	      tion.  The filename argument must contain a forward slash '/'
	      character. For paths relative to the current directory, use dot-
	      slash './'.

	      Defaults:

	      The -instlib=file option has no default and is only used if you
	      specify it. This option can be specified multiple times and
	      accumulates.

	      Example:

	      Assume that the libfoo.a and libbar.so libraries instantiate
	      many template instances that are shared with your source file
	      a.cc.  Adding -instlib=file and specifying the libraries helps
	      reduce compile time by avoiding the redundancy.

	      example% CC -c -instlib=./libfoo.a -instlib=./libbar.so a.cc

	      Interactions:

	      When you compile with -g, if the library specified with
	      -instlib=file is not compiled with -g, those template instances
	      will not be debuggable. The workaround is to avoid -instlib=file
	      when you use -g.

	      The -L path is not searched to find file.

	      Warning

	      If you specify a library with -instlib, you must link with that
	      library.

	      See Also:

	      -template, -instances, -pti

       -KPIC  (SPARC)(Obsolete)	 Use -xcode=pic32 instead.

	      (x86) Same as -Kpic on x86 architectures.

       -Kpic  (SPARC)(Obsolete) Use -xcode=pic13 instead.

	      (x86) Produces position-independent code. Use this option to
	      compile source files when building a shared library. Each refer‐
	      ence to a global datum is generated as a dereference of a
	      pointer in the global offset table. Each function call is gener‐
	      ated in pc-relative addressing mode through a procedure linkage
	      table.

       -keeptmp
	      Retains the temporary files that are created during compilation.
	      Along with -verbose=diags, this option is useful for debugging.

       -Lpath Adds path to the library search paths.

	      This option is passed to ld.  The linker searches the directory
	      specified by path before it searches the compiler-provided
	      directories.

	      Interactions:

	      This option accumulates instead of overrides.

	      Warnings

	      Never specify the /usr/include, lib, /usr/lib, or the compiler
	      installation area as search directories.

       -llib  Add library liblib.a or liblib.so to linker's list of search
	      libraries.

	      This option is passed to ld.  Normal libraries have names such
	      as liblib.a or liblib.so where the lib and .a or .so parts are
	      required. You can specify the lib part with this option. Put as
	      many libraries as you want on a single command line; they are
	      searched in the order specified with -Lpath.

	      Use this option after your object file names.

	      Interactions:

	      This option accumulates instead of overrides.

	      Warnings:

	      If you are building a multithreaded application or linking your
	      application to a multithreaded library, you must compile and
	      link your program with the -mt option instead of linking your
	      application directly with -lthread. (See -mt)

       -libmieee
	      Use -xlibmieee.

       -libmil
	      Use -xlibmil.

       -library=lib[,lib...]
	      Incorporates specified CC-provided libraries into compilation
	      and linking.

	      When the -library option is used to specify a CC-provided
	      library, the proper -I paths are set during compilation and the
	      proper -L, -Y, -P, and -R paths and -l options are set during
	      linking.

	      Values:

	      The prefix no% applied to a suboption disables that suboption.

	      The following table shows the meanings of the values for lib.

	      Value		  Meaning

	      [no%]f77		  Deprecated. Do not use. Use -xlang=f77.

	      [no%]f90		  Deprecated. Do not use. Use -xlang=f90.

	      [no%]f95		  Deprecated. Do not use. Use -xlang=f95.

	      [no%]rwtools7	  Use classic-iostreams Tools.h++ version 7.

	      [no%]rwtools7_dbg	  Use debug-enabled Tools.h++ version 7.

	      [no%]rwtools7_std	  Use standard-iostreams Tools.h++ version 7.

	      [no%]rwtools7_std_dbg
				  Use debug_enabled standard-iostreams
				  Tools.h++ version 7.

	      [no%]interval	  Deprecated. Do not use. Use -xia.

	      [no%]iostream	  Use libiostream, the classic iostreams
				  library.

	      [no%]Cstd		  Use libCstd, the C++ standard library.
				  include the compiler-provided C++ standard
				  library header files.

	      [no%]stlport4	  Use STLport's implementation of the standard
				  library. If you specify -library=stlport4,
				  the command expands to -library=no%Cstd,stl‐
				  port4.

	      [no%]stlport4_dbg	  Use STLport's debug-enabled library.

	      [no%]stdcxx4	  Use the Apache stdcxx version 4 library
				  installed as part of Oracle Solaris, instead
				  of the default libCstd.  This option also
				  sets the -mt option implicitly. The stdcxx
				  library requires multi-threading mode.  This
				  option must be used consistently on every
				  compilation and link command in the entire
				  application. Code compiled with
				  -library=stdcxx4 cannot be used in the same
				  program as code compiled with the default
				  -library=Cstd or the optional -library=stl‐
				  port4.

	      [no%]Crun
				   Use libCrun, the C++ runtime library

	      [no%]gc		  Use libgc, garbage collection.

	      [no%]sunperf	  Use the Sun Performance Library.

	      %none		  Use no C++ libraries except for libCrun.

	      Note that -library=libC is not allowed.

	      Defaults:

	      The libCstd library is always included unless it is specifically
	      excluded by using -library=%none, -library=no%Cstd,
	      -library=stdcxx4, or -library=stlport4.

	      Also, the libm and libc libraries are always included, even if
	      you specify -library=%none. libCrun is always included.

	      Examples:

	      To link without any C++ libraries (except libCrun), use:

	      example% CC -library=%none

	      To include the classic-iostreams Rogue Wave tools.h++ library
	      use:

	      example% CC -library=rwtools7,iostream

	      To include the standard-iostreams Rogue Wave tools.h++ library
	      use:

	      example% CC -library=rwtools7_std

	      When you include the classic-iostreams Rogue Wave tools library
	      you must also include libiostream (see the C++ Migration Guide
	      for additional information). You can use the standard-iostreams
	      Rogue Wave tools library in standard mode only. The following
	      command examples show both valid and invalid use of the Rogue
	      Wave tools.h++ library options.

	      Valid:
	      example% CC -compat -library=rwtools7 foo.cc
	      Invalid:
	      example% CC -compat -library=rwtools7_std foo.cc

	      Valid, classic iostreams
	      example% CC -library=rwtools7,iostream foo.cc
	      Invalid example% CC -library=rwtools7 foo.cc

	      Valid, standard iostreams
	      example% CC -library=rwtools7_std foo.cc
	      Invalid
	      example% CC -library=rwtools7_std,iostream foo.cc

	      If you include both libCstd and libiostream, you must be careful
	      to not use the old and new forms of iostreams (for example, cout
	      and std::cout) within a program to access the same file.	Mixing
	      standard iostreams and classic iostreams in the same program is
	      likely to cause problems if the same file is accessed from both
	      classic and standard iostream code.

	      If -xnolib is specified, -library is ignored.

	      Interactions:

	      If a library is specified with -library, the proper -I paths are
	      set during compilation. The proper -L, -Y, -P, -R, paths and -l
	      options are set during linking.

	      This option accumulates instead of overrides.

	      Only one rwtool library can be used at a time and you cannot use
	      any rwtool library with -library=stlport4 or -library=stdcxx4..

	      You can specify at most one of either -library=stlport4,
	      -library=stdcxx4,	 or -library=Cstd on the same command line.

	      You cannot use -library=sunperf and -xlic_lib=sunperf on the
	      same command line.

	      Use of the -library option ensures that the -l options for the
	      specified libraries are emitted in the right order.  For exam‐
	      ple, the -l options are passed to ld in the order -lrwtool
	      -liostream for both -library=rwtools7,iostream and
	      -library=iostream,rwtools7.

	      When you use the interval arithmetic libraries, you must include
	      one of the following libraries: libC, libCstd, or libiostreams.

	      The specified libraries are linked before the system support
	      libraries are linked.

	      Warnings:

	      The so-called "Classic" iostreams is the original 1986 version
	      of iostreams, which was replaced in the 1998 C++ standard. It is
	      selected through the -library=rwtools7,iostream option. No two
	      implementations of "classic" iostreams are the same, so apart
	      from being obsolete, code using it is not portable. Note that
	      this library will be discontinued in future Oracle Solaris Stu‐
	      dio releases.

	      The RW Tools.h++ toolset provided with legacy Sun Studio and
	      with Oracle Solaris Studio dates from the 1990's and has not
	      been significantly updated since.	 The time/date classes have
	      serious issues regarding daylight savings time that cannot be
	      fixed. (The functionality of this toolset is currently available
	      in the C++ Standard Library, and in open source libraries like
	      BOOST.) RW Tools.h++ is selected by the options
	      -library=rwtools7 or -library=rwtools7_std and will be discon‐
	      tinued in future Oracle Solaris Studio releases.

	      Do not redefine or modify any of the configuration macros for
	      STLport or Oracle Solaris Studio C++ libraries. The libraries
	      are configured and built in a way that works with the C++ com‐
	      piler. libCstd, libstdcxx4, and Tool.h++ are configured to
	      inter-operate so modifying the configuration macros results in
	      programs that will not compile, will not link, or do not run
	      properly.

	      If you compile and link in separate steps, the set of -library
	      options that appear in the compile command must appear in the
	      link command.

	      The set of libraries is not stable and might change from release
	      to release.

	      The stlport4, stdcxx4, Cstd and iostream libraries provide their
	      own implementation of I/O streams. Specifying more than one of
	      these with the -library option can result in undefined program
	      behavior.

	      See also:

	      -I,-l,-R, -staticlib, -xia, -xlang, -xnolib,
	      C++ Interval Arithmetic Programming Reference,
	      Tools.h++ User's Guide,
	      Tools.h++ Class Library Reference,
	      C++ Standard Reference Library

       -m32|-m64
	      Specifies the memory model for the compiled binary object.

	      Use -m32 to create 32-bit executables and shared libraries. Use
	      -m64 to create 64-bit executables and shared libraries.

	      The ILP32 memory model (32-bit int, long, pointer data types) is
	      the default on all Oracle Solaris platforms and on Linux plat‐
	      forms that are not 64-bit enabled. The LP64 memory model (64-bit
	      long, pointer data types) is the default on Linux platforms that
	      are 64-bit enabled. -m64 is permitted only on platforms that are
	      enabled for the LP64 model.

	      Object files or libraries compiled with -m32 cannot be linked
	      with object files or libraries compiled with -m64.

	      When compiling applications with large amounts of static data
	      using -m64, -xmodel=medium may also be required. Be aware that
	      some Linux platforms do not support the medium model.

	      Modules that are compiled with -m32|-m64 must also be linked
	      with -m32|-m64. For a complete list of compiler options that
	      must be specified at both compile time and at link time, see the
	      C++ User's Guide.

	      Note that in previous compiler releases, the memory model, ILP32
	      or LP64, was implied by the choice of the instruction set with
	      -xarch. Starting with the Sun Studio 12 compilers, this is no
	      longer the case. On most platforms, just adding -m64 to the com‐
	      mand line is sufficient to create 64-bit objects.

	      On Oracle Solaris, -m32 is the default. On Linux systems sup‐
	      porting 64-bit programs, -m64 -xarch=sse2 is the default.

	      See also -xarch.

       -mc    Removes duplicate strings from the .comment section of the
	      object file.  When you use the -mc option, the mcs -c command is
	      invoked. (See the mcs(1) man page.)

       -misalign
	      (SPARC) Obsolete. You should not usethis option. Use the -xmema‐
	      lign=2i option instead.

       -mr[,string]
	      Removes all strings from the .comment section of the object file
	      and, if string is supplied, places string in that section. If
	      the string contains blanks, the string must be enclosed in quo‐
	      tation marks. When you use this option, the command mcs -d [-a
	      string] is invoked.

	      Interactions:

	      This option is not valid when -S is specified.

       -mt[={yes|no}]
	      Use this option to compile and link multithreaded code using the
	      Oracle Solaris threads or POSIX threads API.  The -mt=yes option
	      assures that libraries are linked in the appropriate order.

	      This option passes -D_REENTRANT to the preprocessor.

	      To use Oracle Solaris threads, include the thread.h header file
	      and compile with the -mt=yes option. To use POSIX threads on
	      Oracle Solaris platforms, include the pthread.h header file and
	      compile with the -mt=yes option.

	      On Linux platforms, only the POSIX threads API is available.
	      (There is no libthread on Linux platforms.)  Consequently,
	      -mt=yes on Linux platforms adds -lpthread instead of -lthread.
	      To use POSIX threads on Linux platforms, compile with -mt.

	      Note that when compiling with -G, neither -ltread nor -lpthread
	      are automatically included by -mt=yes.  You will need to explic‐
	      itly list these libraries when building a shared library.

	      The -xopenmp option (for using the OpenMP shared-memory paral‐
	      lelization API) includes -mt=yes automatically.

	      If you compile with -mt=yes and link in a separate step, you
	      must use the -mt=yes option in the link step as well as the com‐
	      pile step.  If you compile and link one translation unit with
	      -mt=yes, you must compile and link all units of the program with
	      -mt=yes

	      -mt=yes is the default behavior of the compiler.	If this behav‐
	      ior is not desired use the option -mt=no.

	      The option -mt is equivalent to -mt=yes.

	      See also: -xnolib

       -native
	      Use -xtarget=native.

       -noex  Use -features=no%except.

       -nofstore
	      (x86) Cancel -fstore on command line

	      Cancels forcing expressions to have the precision of the desti‐
	      nation variable invoked by -fstore.

	      -nofstore is invoked by -fast.  -fstore is the usual default.

       -nolib Use -xnolib.

       -nolibmil
	      Use -xnolibmil.

       -noqueue
	      (Obsolete). This option silently does nothing.

       -norunpath
	      Does not build the path for shared libraries into the exe‐
	      cutable.

	      If an executable file uses shared libraries, then the compiler
	      normally builds in a path that points the runtime linker to
	      those shared libraries.  To do so, the compiler passes the -R
	      option to ld.  The path depends on the directory where you have
	      installed the compiler.

	      This option is recommended for building executables that will be
	      shipped to customers who may have a different path for the
	      shared libraries that are used by the program.

	      Interactions:

	      If you use any shared libraries under the compiler installed
	      area (default location <installpath>/lib ) and you also use
	      -norunpath, then you should either use the -R option at link
	      time or set the environment variable LD_LIBRARY_PATH at run time
	      to specify the location of the shared libraries. This will allow
	      the runtime linker to find the shared libraries.

       -O     The -O macro expands to -xO3.  Compiling with this option yields
	      higher run-time performance. However, optimization level -xO3
	      may be inappropriate for programs that rely on all variables
	      being automatically considered volatile. Typical programs that
	      might have this assumption are device drivers and older multi-
	      threaded applications that implement their own synchronization
	      primitives. The work around is to compile with -xO2 instead of
	      -O.

       -O[level]
	      Use -xOlevel.

       -o filename
	      Names the output file filename, instead of the default a.out.
	      filename cannot be the same as sourcefile since cc does not
	      overwrite the source file.

	      filename must have an appropriate suffix.	 When used with -c,
	      filename specifies the target .o object file; with -G it speci‐
	      fies the target .so library file.	 This option and its argument
	      are passed to ld.

       +p     Ignore non-standard preprocessor asserts.

	      Defaults:

	      If +p is not present, the compiler recognizes nonstandard pre‐
	      processor asserts.

	      Interactions:

	      If +p is used, the sun, unix, sparc, and i386 macros are not
	      defined.

       -P     Only preprocesses source: does not compile. (Outputs a file with
	      a .i suffix.)

	      This option does not include preprocessor-type line number
	      information in the output.

       -p     Obsolete See -xpg.

       -pentium
	      (x86 platform) Use -xtarget=pentium.

       -pg    (Obsolete) Use -xpg.

       -PIC   SPARC: Same as -xcode=pic32.

	      x86: Same as -KPIC.

       -pic   SPARC: Same as -xcode=pic13.

	      x86: Same as -Kpic.

       -pta   Use -template=wholeclass.

       -ptipath
	      Specifies an additional search directory for template source.

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

	      Using the -Ipathname flag instead of -ptipath produces less con‐
	      fusion.

	      Interactions:

	      This option accumulates instead of overrides.

       -pto   Use -instances=static.

       -ptv   Use -verbose=template.

       -Qoption phase option[,option...]
	      Passes option to the compilation phase.

	      To pass multiple options, specify them in order as a comma-sepa‐
	      rated list.  Options that are passed to components with -Qoption
	      can be reordered. Options that the driver recognizes are kept in
	      the correct order. Do not use -Qoption for options that the
	      driver already recognizes. For example, the C++ compiler recog‐
	      nizes the -z option for the linker (ld). If you issue a command
	      like this

	      CC -G -zallextract mylib.a -zdefaultextract ... // correct

	      the -z options are passed in order to the linker. But if you
	      specify the command like this

	      CC -G -Qoption ld -zallextract mylib.a -Qoption ld -zdefaultex‐
	      tract ... // error

	      the -z options can be reordered, giving incorrect results.

	      The following table shows the possible values for phase.

	      SPARC		x86

	      ccfe		ccfe

	      iropt		iropt

	      cg		ube

	      CClink		CClink

	      ld		ld

	      Examples:

	      When the CC driver invokes ld in the following command, -Qoption
	      passes the -i option to ld:

	      example% CC -Qoption ld -i test.cc

	      Warnings:

	      Be careful to avoid unintended effects.  For example,

	      -Qoption ccfe -features=bool,iddollar

	      is interpreted as

	      -Qoption ccfe -features=bool -Qoption ccfe iddollar

	      The correct usage is

	      -Qoption ccfe -features=bool,-features=iddollar

	      Note that these features do not require -Qoption and are used
	      only as an example.

       -qoption phase option
	      Use -Qoption.

       -qp    Same as -p.

       -Qproduce sourcetype
	      Causes the CC driver to produce source code of the type source‐
	      type.  Source code types are shown in the following table.

	      Value	     Meaning

	      .i	     Preprocessed C++ source from ccfe

	      .o	     Object file from the code generator

	      .s	     Assembler source from the code generator

       -qproduce sourcetype
	      Use -Qproduce.

       -Rpath[:path...]
	      Builds dynamic library search paths into the executable file.

	      This option is passed to ld.

	      Defaults:

	      If the -R option is not present, the default library search path
	      is recorded in the output object and passed to the runtime
	      linker.  The default library search order can be seen by using
	      the -dryrun option and examining the -Y option of the ld invoca‐
	      tion.

	      Interactions:

	      This option accumulates instead of overrides.

	      If both the LD_RUN_PATH environment variable and the -R option
	      are specified, then the path from -R is scanned, and the path
	      from LD_RUN_PATH is ignored.

	      See also:

	      -norunpath

       -S     Compiles and generates only assembly code.  This option causes
	      the CC driver to compile the program and output an assembly
	      source file, but not assemble the program.  The assembly source
	      file is named with a .s suffix.

       -s     Strip the symbol table from the executable file.	This option
	      removes all symbol information from output executable files.
	      This option is passed to ld.

       -staticlib=l[,l...]
	      Indicates which C++ libraries specified by the -library option
	      (including its defaults), by the -xlang option, and by the -xia
	      option are to be linked statically.

	      Values:

	      l must be one of the following values.

	      Value	     Meaning

	      [no%]library   Link library statically. The valid values for
			     library are all valid values for -library (except
			     %all and %none ) all the valid values for -xlang,
			     and interval (to be used in conjunction with
			     -xia).  Use the prefix no% to disable linking
			     library.

	      %all	     Link statically all the libraries specified by
			     the -library option, all the library specified in
			     the -xlang option, and, if -xia is specified, the
			     interval libraries.

	      %none	     Link no libraries specified in the -library
			     option and the -xlang option statically. If -xia
			     is specified in the command line, link no inter‐
			     val libraries statically.

	      Defaults:

	      If -staticlib is not specified, -staticlib=%none is assumed.

	      Interactions:

	      This option accumulates instead of overrides.

	      The -staticlib option only works for the C++ libraries that are
	      selected explicitly with the -xia, the -xlang option, and the
	      -library option, in addition to the C++ libraries that are
	      selected implicitly by default.  Cstd and Crun are selected by
	      default.

	      Examples:

	      The following command links libCrun statically because Crun is a
	      default value for -library.

	      (correct)
	      example% CC -staticlib=Crun test.cc

	      However, the following command does not link libgc because libgc
	      is not linked unless explicitly specified with the -library
	      option.

	      (incorrect)
	      example% CC -staticlib=gc test.cc

	      With the following command, the librwtool library is linked
	      dynamically.  Because librwtool is not a default library and is
	      not selected using the -library option, -staticlib has no
	      effect.

	      (incorrect)
	      example% CC -lrwtool -library=iostream \
	      -staticlib=rwtools7

	      This command links the Tools.h++ library statically.

	      (correct)
	      example% CC -library=rwtools7,iostream \
	      -staticlib=rwtools7

	      Warnings:

	      The set of allowable values for libraries is not stable and
	      might change from release to release.

	      On Oracle Solaris platforms, system libraries not available as
	      static libraries.

	      The options -staticlib=Crun and -staticlib=Cstd do not work on
	      64-bit Oracle Solaris x86 platforms. It is recommended not to
	      link these libraries statically on any platform. In some cases,
	      static linking can prevent a program from working.

       -sync_stdio=[yes|no]
	      Use this option when your run-time performance is degraded due
	      to the synchronization between C++ iostreams and C stdio. Syn‐
	      chronization is needed only when you use iostreams to write to
	      cout and stdio to write to stdout in the same program. The C++
	      standard requires synchronization so the C++ compiler turns it
	      on by default. However, application performance is often much
	      better without synchronization. If your program does not write
	      to both cout and stdout, you can use the option -sync_stdio=no
	      to turn off synchronization.

	      Defaults:

	      If you do not specify -sync_stdio, the compiler sets it to
	      -sync_stdio=yes.

	      Examples:

	      Consider the following example:

	      #include <stdio.h>
	      #include <iostream>
	      int main()
	      {
		    std::cout << "\nHello ";
		    printf("beautiful ");
		    std::cout << "world!";
		    printf("\n");
	      }

	      With synchronization, the program prints on a line by itself

		   Hello beautiful world!

	      Without synchronization, the output gets scrambled.

	      Warnings:

	      This option is only effective for linking of executables, not
	      for libraries.

       -temp=path
	      Defines the directory for temporary files.

	      This option sets path as the directory for the temporary files
	      which are generated during the compilation process. The compiler
	      gives precedence to the value set by -temp over the value of
	      TMPDIR.

	      See also:

	      -keeptmp

       -template=a[,a...]
	      Enables/disables various template options.

	      a must be one of the following values.  The prefix no% applied
	      to a suboption disables that suboption.

	      Value		  Meaning

	      [no%]extdef
				   search for template definitions in separate
				  source files.

	      [no%]geninlinefuncs
				   instantiate inline member functions of the
				  explicitly instantiated class template which
				  were not generated previously.

	      [no%]wholeclass
				   Instantiate a whole template class, rather
				  than only those functions that are used. You
				  must reference at least one member of the
				  class; otherwise, the compiler does not
				  instantiate any members for the class.

	      When -template=no%extdef is specified, the compiler predefines
	      the macro _TEMPLATE_NO_EXTDEF.

	      Defaults:

	      -template=no%wholeclass,extdef,no%geninlinefuncs

       -time  Use -xtime.

       -traceback[={%none|common|signals_list}]
	      Issue a stack trace if a severe error occurs in execution.

	      The -traceback option causes the executable to issue a stack
	      trace to stderr, dump core, and exit if certain signals are gen‐
	      erated by the program.  If multiple threads generate a signal, a
	      stack trace will only be produced for the first one.

	      To use traceback, add the -traceback option to the compiler com‐
	      mand line when linking.  The option is also accepted at compile-
	      time but is ignored unless an executable binary is generated.
	      Using -traceback with -G to create a shared library is an error.

	      %none or none
		     disables traceback

	      common specifies that a stack trace should be issued if any of a
		     set of common signals is generated -- sigill, sigfpe,
		     sigbus, sigsegv, and sigabrt.

	      signals_list
		     specifies a comma-separated list of names of signals
		     which should generate a stack trace, in lower case.  The
		     following signals (those that cause the generation of a
		     core file) can be caught:

		     sigquit, sigill, sigtrap, sigabrt, sigemt, sigfpe, sig‐
		     bus, sigsegv, sigsys, sigxcpu, sigxfsz

		     Any of these can be preceeded with no% to disable catch‐
		     ing the signal.

		     For example: -traceback=sigsegv,sigfpe will produce a
		     stack trace and core dump if either sigsegv or sigfpe is
		     generated.

	      If the option is not specified, the default is -traceback=%none

	      -traceback without any = sign implies -traceback=common

	      Note: If the core dump is not wanted, users may set the core‐
	      dumpsize limit to zero using:

		   % limit coredumpsize 0

	      The -traceback option has no effect on runtime performance.

       -Uname Deletes initial definition of the preprocessor symbol name. This
	      option removes any initial definition of the macro symbol name
	      that was created by -D on the same command line, including those
	      implicitly placed there by the command-line driver.

	      This option has no effect on any other predefined macros nor on
	      macro definitions in source files.

	      To see the -D options that are placed on the command line by the
	      command-line driver, add the -dryrun option to your command
	      line.

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

	      Examples:

	      The following command undefines the predefined symbol __sun.
	      Preprocessor statements in test.cc such as #ifdef(__sun) will
	      sense that the symbol is undefined.

	      example% CC -U__sun test.cc

	      Interactions:

	      This option accumulates instead of overrides.

	      All -U options are processed after any -D options that are
	      present.

       -unroll=n
	      Same as -xunroll=n.

       -V     Same as -verbose=version.

       -v     Same as -verbose=diags.

       -verbose=a[,a...]
	      Controls compiler verbosity.

	      a must be one of the following values.  The prefix no% applied
	      to a suboption disables that suboption when used with %all.

	      Value	Meaning

	      [no%]template
				   Turn on the template instantiation verbose
				  mode, sometimes called the verify mode. The
				  verbose mode displays each phase of instan‐
				  tiation as it occurs during compilation.

	      [no%]diags
				   Print the command line for each compilation
				  pass.

	      [no%]version	  Direct the CC driver to print the names and
				  version numbers of the programs it invokes.

	      %all		  Invokes all the above.

	      %none		  Invokes none of the above.

	      Defaults:

	      If -verbose is not specified, the compiler assumes -ver‐
	      bose=%none.

	      Interactions:

	      This option accumulates instead of overrides.

       -Wc,arg
	      Passes the argument arg to component c.  Each argument must be
	      separated from the preceding by only a comma.  (A comma can be
	      part of an argument by escaping it by an immediately preceding
	      backslash (\) character; the backslash is removed from the
	      resulting argument.)  All -W arguments are passed after the reg‐
	      ular command-line arguments.

	      c can be one of the following:

		 a	Assembler: (fbe), (gas)
		 c	C++ code generator: (cg)(SPARC)
		 d	CC driver
		 l	Link editor (ld)
		 m	mcs
		 O	(Capital letter 'O') Interprocedural optimizer
		 o	Postoptimizer
		 p	Preprocessor (cpp)
		 0	(The number zero) Compiler (ccfe)
		 2	Optimizer: (iropt)

	      Note: You cannot use -Wd to pass the CC options listed in this
	      man page to the C++ compiler.

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

       +w     Identifies code that might have unintended consequences.

	      (The +w option no longer generates a warning if a function is
	      too large to inline or if a declared program element is unused.
	      These warnings do not identify real problems in the source, and
	      were thus inappropriate to some development environments. Remov‐
	      ing these warnings from +w enables more aggressive use of +w in
	      those environments. These warnings are still available with the
	      +w2 option.)

	      Generates additional warnings about questionable constructs that
	      are:

	      o	     Nonportable

	      o	     Likely to be mistakes

	      o	     Inefficient

	      Defaults:

	      If +w is not specified, the compiler warns about constructs that
	      are almost certainly problems.

	      Interactions:

	      Some C++ standard headers result in warnings when compiled with
	      +w.

       +w2    Emits the same warnings as +w as well as warnings about techni‐
	      cal violations that are probably harmless, but that might reduce
	      the maximum portability of your program.

	      The +w2 option no longer warns about the use of implementation-
	      dependent constructs in the system header files. Because the
	      system header files are the implementation, the warning was
	      inappropriate. Removing these warnings from +w2 enables more
	      aggressive use of the option.

	      Warnings:

	      Some Oracle Solaris software and C++ standard header files
	      result in warnings when compiled with +w2.

       -w     Suppresses warning messages.

	      This option causes the compiler not to print warning messages.
	      Some warnings, particularly warnings regarding serious anachro‐
	      nisms, cannot be suppressed.

       -Xlinker arg
	      Passes arg to linker ld(1)

	      Equivalent to -z arg

       -Xm    Use -features=iddollar.

       -xaddr32[={yes|no}]
	      (x86/x64 only) The -xaddr32=yes compilation flag restricts the
	      resulting executable or shared object to a 32-bit address space.

	      An executable that is compiled in this manner results in the
	      creation of a process that is restricted to a 32-bit address
	      space.

	      When -xaddr32=no is specified a usual 64 bit binary is produced.

	      If the -xaddr32 option is not specified, -xaddr32=no is assumed.

	      If only -xaddr32 is specified -xaddr32=yes is assumed.

	      This option is only applicable to -m64 compilations and only on
	      Oracle Solaris platforms supporting SF1_SUNW_ADDR32 software
	      capability.

	      Since Linux kernel does not support addres space limitation this
	      option is not available on Linux.	 The -xaddr32 option is
	      ignored on Linux.

	      When linking, if a single object file was compiled with
	      -xaddr32=yes the whole output file is assumed to be compiled
	      with -xaddr32=yes.

	      A shared object that is restricted to a 32-bit address space
	      must be loaded by a process that executes within a restricted
	      32-bit mode address space.

	      For more information refer to the SF1_SUNW_ADDR32 software capa‐
	      bilities definition, described in the Linker and Libraries
	      Guide.

       -xalias_level[= n]
	      Allows the compiler to perform type-based alias-analysis.

	      Defaults:

	      n must be any, simple, or compatible.

	      o -xalias_level

		If you do not specify -xalias_level, the compiler sets it to
		-xalias_level=any. If you specify -xalias_level without any
		values, the compiler sets it to -xalias_level=compatible.

	      o -xalias_level=any

		At this level of analysis, the compiler assumes that any type
		may alias any other type. However, despite this assumption,
		some optimization is possible.

	      o -xalias_level=simple

		The compiler assumes that fundamental types are not aliased.
		Specifically, a storage object with a dynamic type that is one
		of the following fundamental types:

		  * char, signed char, and unsigned char,
		  * wchar_t
		  * short int, unsigned short int,
		  * int, unsigned int,
		  * long int, unsigned long int,
		  * long long int, unsigned long long int,
		  * float, double, long double,
		  * enumeration types,
		  * data pointer types,
		  * function pointer types,
		  * data member pointer types, or
		  * function member pointer types

		will only be accessed through lvalues of the following types:

		  * the dynamic type of the object,

		  * a constant or volatile qualified version
		    of the dynamic type of the object,

		  * a type that is the signed or unsigned type
		    corresponding to the dynamic type of the
		    object,

		  * a type that is the signed or unsigned type
		    corresponding to a constant or volatile
		    qualified version of the dynamic type of
		    the object,

		  * an aggregate or union type that includes
		    one of the aforementioned types among its
		    members (including, recursively, a member of
		    a subaggregate or contained union), or

		  * a char or unsigned char type.

	      o -xalias_level=compatible

		The compiler assumes that layout-incompatible types are not
		aliased. A storage object is only accessed through lvalues of
		the following types:

		* the dynamic type of the object,

		* a constant or volatile qualified version of
		  the dynamic type of the object,

		* a type that is the signed or unsigned type
		  which corresponds to the dynamic type of
		  the object,

		* a type that is the signed or unsigned type
		  which corresponds to the constant or volatile
		  qualified version of the dynamic type of
		  the object,

		* an aggregate or union type that includes one
		  of the aforementioned types among its members
		  (including, recursively, a member of a
		  subaggregate or contained union),

		* a type that is (possibly constant or volatile
		  qualified) base class type of the dynamic
		  type of the object, or

		* a char or unsigned char type.

		The compiler assumes that the types of all references are lay‐
		out compatible with the dynamic type of the corresponding
		storage object. Two types are layout-compatible under the fol‐
		lowing conditions:

		* If two types are the same type, then they are
		  layout-compatible types.

		* If two types differ only in constant or
		  volatile qualification, then they are
		  layout-compatible types.

		* For each of the signed integer types, there
		  exists a corresponding (but different)
		  unsigned integer type. These corresponding
		  types are layout compatible.

		* Two enumeration types are layout-compatible if
		  they have the same underlying type.

		* Two Plain Old Data (POD) struct types are
		  layout compatible if they have the same number
		  of members, and corresponding members
		  (in order) have layout compatible types.

		* Two POD union types are layout compatible
		  if they have the same number of members, and
		  corresponding members (in any order) have
		  layout compatible types.

		References may be non-layout-compatible with the dynamic type
		of the storage object under limited circumstances:

		* If a POD union contains two or more POD
		  structs that share a common initial sequence,
		  and if the POD union object currently contains
		  one of those POD structs, it is permitted to
		  inspect the common initial part of any of
		  them. Two POD structs share a common initial
		  sequence if corresponding members have layout
		  compatible types and, as applicable to bit
		  fields, the same widths, for a sequence of
		  one or more initial members.

		* A pointer to a POD struct object, suitably
		  converted using a reinterpret_cast, points
		  to its initial member, or if that member is
		  a bit field, to the unit in which it resides.

	      Interactions:

	      The compiler does not perform type-based alias analysis at opti‐
	      mization level -xO2 and below.

       -xanalyze={code|no}
	      Compile with this option to produce a static analysis of the
	      source code that can be viewed using the Code Analyzer.

	      When compiling with -xanalyze=code and linking in a separate
	      step, include -xanalyze=code also on the link step.

	      The default is -xanalyze=no.

	      See the Oracle Solaris Studio Code Analyzer documentation for
	      further information.

       -xannotate[={yes|no}]
	      (Oracle Solaris) Instructs the compiler to create binaries that
	      can later be used by the optimization and observability tools
	      binopt(1), code-analyzer(1), discover(1), collect(1), and
	      uncover(1).

	      The default is -xannotate=yes. Specifying -xannotate without a
	      value is equivalent to -xannotate=yes.

	      For optimal use of the optimization and observability tools,
	      -xannotate=yes must be in effect at both compile and link time.

	      Compile and link with -xannotate=no to produce slightly smaller
	      binaries and libraries when optimization and observability tools
	      will not be used.

	      This option is not available on Linux systems.

       -xar   Creates archive libraries.

	      When building a C++ archive that uses templates, it is necessary
	      in most cases to include in the archive those template functions
	      that are instantiated in the template repository.	 The template
	      repository is used only when at least one object file was com‐
	      piled with the -instances=extern option.	Using with -xar auto‐
	      matically adds those templates to the archive as needed.

	      However, since the compiler default is not to use a template
	      cache, the -xar option is often not needed. You can use the
	      standard system ar(1) command to create .a archive files of C++
	      code, unless some code was compiled with -instances. In that
	      case use the -xar compiler option instead.

	      Values:

	      Specify -xar to invokes ar -c-r and create an archive from
	      scratch.

	      Examples:

	      The following command archives the template functions contained
	      in the repository and the object files.

	      example% CC -xar -o libmain.a a.o b.o c.o

	      Warnings:

	      Do not add .o files from the template repository on the command
	      line.

	      Do not use the ar command directly for building archives. Use CC
	      -xar to ensure that template instantiations are automatically
	      included in the archive.

	      See Also:

	      ar(1)

       -xarch= isa
	      Specifies the target architecture instruction set (ISA).

	      This option limits the code generated by the compiler to the
	      instructions of the specified instruction set architecture by
	      allowing only the specified set of instructions. This option
	      does not guarantee use of any target-specific instructions.
	      However, use of this option can affect the portability of a
	      binary program.  See the Notes and Warnings sections at the end
	      of this entry.

	      Note: The compiler and linker will mark .o files and executables
	      that require a particular instruction set architecture (ISA) so
	      that the executable will not be loaded at runtime if the running
	      system does not support that particular ISA.

	      Note: Use the -m64 or -m32 option to specify the intended memory
	      model, LP64 (64-bits) or ILP32 (32-bits) respectively. The
	      -xarch flag no longer indicates the memory model, except for
	      compatibility with previous releases, as indicated below.

	      Code using _asm statements or inline templates (.il files) that
	      use architecture-specific instructions might require compiling
	      with the appropriate -xarch values to avoid compilation errors.

	      If you compile and link in separate steps, make sure you specify
	      the same value for -xarch in both steps.

	      Values (all platforms):

	      Value	Meaning

	      generic	This option uses the instruction set common to most
			processors.

	      generic64 Compile for good performance on most 64-bit platforms.
			(Oracle Solaris only)

			This option is equivalent to
			    -m64 -xarch=generic
			and is provided for compatibility with earlier
			releases.  Use -m64 to specify 64-bit compilation
			instead of -xarch=generic64

	      native	Compile for good performance on this system

			The compiler chooses the appropriate setting for the
			current system processor it is running on.

	      native64	Compile for good performance on this system (Oracle
			Solaris only)

			This option is equivalent to
			-m64 -xarch=native and is provided for compatibility
			with earlier releases.

	      Values on SPARC platforms:

	      sparc	Compile for the SPARC-V9 ISA.

			Compile for the V9 ISA, but without the Visual
			Instruction Set (VIS), and without other implementa‐
			tion-specific ISA extensions.  This option enables the
			compiler to generate code for good performance on the
			V9 ISA.

	      sparc4	Compile for the SPARC4 version of the SPARC-V9 ISA.

			Enables the compiler to use instructions from the
			SPARC-V9 instruction set, plus the UltraSPARC exten‐
			sions, which includes VIS 1.0, the UltraSPARC-III
			extensions, which includes VIS2.0, the fused floating-
			point multiply-add instructions, VIS 3.0, and SPARC4
			instructions.

	      sparcvis	Compile for the SPARC-V9 ISA plus VIS.

			Compile for SPARC-V9 plus the Visual Instruction Set
			(VIS) version 1.0, and with UltraSPARC extensions.
			This option enables the compiler to generate code for
			good performance on the UltraSPARC architecture.

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

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

	      sparcvis3 Compile for the SPARC-V9 ISA with UltraSPARC III and
			VIS 3 extensions.

			Enables the compiler to use instructions from the
			SPARC-V9 instruction set, plus the UltraSPARC exten‐
			sions, including the Visual Instruction Set (VIS) ver‐
			sion 1.0, the UltraSPARC-III extensions, including the
			Visual Instruction Set (VIS) version 2.0, the fused
			multiply-add instructions, and the Visual Instruction
			Set (VIS) version 3.0

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

			Enables the compiler to use instructions from the
			SPARC-V9 instruction set, plus the UltraSPARC exten‐
			sions, including the Visual Instruction Set (VIS) ver‐
			sion 1.0, the UltraSPARC-III extensions, including the
			Visual Instruction Set (VIS) version 2.0, and the
			SPARC64 VI extensions for floating-point multiply-add.

			Note that you must use -xarch=sparcfmaf in conjunction
			with -fma=fused and some optimization level to get the
			compiler to attempt to find opportunities to use the
			multiply-add instructions automatically.

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

			Enables the compiler to use instructions from the
			SPARC-V9 instruction set, plus the UltraSPARC exten‐
			sions, including the Visual Instruction Set (VIS) ver‐
			sion 1.0, the UltraSPARC-III extensions, including the
			Visual Instruction Set (VIS) version 2.0, the SPARC64
			VI extensions for floating-point multiply-add, and the
			SPARC64 VII extensions for integer multiply-add.

	      v9	Is equivalent to -m64 -xarch=sparc
			Legacy makefiles and scripts that use -xarch=v9 to
			obtain the 64-bit memory model need only use -m64.

	      v9a	Is equivalent  to -m64 -xarch=sparcvis and is provided
			for compatibility with earlier releases.

	      v9b	Is equivalent  to -m64 -xarch=sparcvis2 and is pro‐
			vided for compatibility with earlier releases.

	      Notes:

	      o Legacy 32-bit SPARC instruction set architectures V7 and V8
		imply -m32 and cannot be combined with -m64.

	      o Object binary files (.o) compiled with sparc and sparcvis can
		be linked and can execute together, but only on a sparcvis
		compatible platform.

	      o Object binary files (.o) compiled with sparc, sparcvis, and
		sparcvis2 can be linked and can execute together, but only on
		a sparcvis2 compatible platform.

		For any particular choice, the generated executable could run
		much more slowly on earlier architectures.  Also, although
		quad-precision floating-point instructions are available in
		many of these instruction set architectures, the compiler does
		not use these instructions in the code it generates.

	      Values specific for x86 platforms:

	      Value	Meaning

	      pentium_pro
			Limits the instruction set to pentium_pro architec‐
			ture.

	      sse	Adds the SSE instruction set to the pentium_pro
			instruction set.

	      sse2	Supplements the pentium_pro and SSE instruction sets
			with the SSE2 instruction set.

	      sse3	Supplements the pentium_pro, SSE, and SSE2 instruction
			sets with the SSE3 instruction set.

	      ssse3	Supplements the pentium_pro, SSE, SSE2, and SSE3
			instruction sets with the SSSE3 instruction set.

	      sse4_1	Supplements the pentium_pro, SSE, SSE2, SSE3, and
			SSSE3 instruction sets with the SSE4.1 instruction
			set.

	      sse4_2	Supplements the pentium_pro, SSE, SSE2, SSE3, SSSE3,
			and SSE4.1 instruction sets with the SSE4.2 instruc‐
			tion set.

	      amdsse4a	Uses the AMD SSE4a Instruction set.

	      amd64	Is equivalent  to -m64 -xarch=sse2  (Oracle Solaris
			only)
			Legacy makefiles and scripts that use -xarch=amd64 to
			obtain the 64-bit memory model need only use -m64.

	      pentium_proa
			Adds the AMD extensions (3DNow!, 3DNow! extensions,
			and MMX extensions) to the  pentium_pro architecture.

	      ssea	Adds the AMD extensions (3DNow!, 3DNow!	 extensions,
			and MMX extensions) to the 32-bit SSE architecture.

	      sse2a	Adds the AMD extensions (3DNow!, 3DNow!	 extensions,
			and MMX extensions) to the  SSE2 architecture.

	      amd64a	Is equivalent to -m64 -xarch=sse2a  (Oracle Solaris
			only)

	      avx	Adds the Advanced Vector Extensions to the Intel x86
			instruction set.

	      aes	Adds the Advanced Encryption Standard instructions.
			Note that the compiler does not generate AES instruc‐
			tions automatically when -xarch=aes is specified
			unless the source code includes .il inline code, _asm
			statements, or assembler code that use AES instruc‐
			tions, or references to AES intrinsic functions.

	      Note:	If any part of a program is compiled or linked on an
			x86 platform with -m64, then all parts of the program
			must be compiled with one of these options as well.

			For details on the various Intel instruction set
			architectures (SSE, SSE2, SSE3, SSSE3, and so on)
			refer to the Intel-64 and IA-32 Intel Architecture
			Software Developer's Manual

	      Defaults:
		If -xarch=isa is not specified, the defaults are:
		      -xarch=generic  on SPARC platforms
		      -xarch=generic   on x86 platforms

	      Interactions:
		Although this option can be used alone, it is part of the
		expansion of the -xtarget option and can be used to override
		the -xarch value that is set by a specific -xtarget option.

		For example, -xtarget=ultra4 expands to
		-xarch=sparcvis2 -xcache=64/32/4:8192/128/2 -xchip=ultra4

	      Warnings:
		If this option is used with optimization, the appropriate
		choice can provide good performance of the executable on the
		specified architecture. An inappropriate choice, however,
		might result in serious degradation of performance or in in a
		binary program that is not executable on all intended target
		platforms.

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

	      Note that -xautopar does not accept OpenMP parallelization
	      directives.

	      Avoid -xautopar if you do your own thread management.

	      To get faster execution, this option requires a multiple proces‐
	      sor system.  On a single-processor system, the resulting binary
	      usually runs slower.

	      Use the OMP_NUM_THREADS environment variable to specify the num‐
	      ber of threads to use when running a program automatically par‐
	      allelized by the -xautopar compiler option.  If OMP_NUM_THREADS
	      is not set, the default number of threads used is 2.  To use
	      more threads, set OMP_NUM_THREADS to a higher value.  Set
	      OMP_NUM_THREADS to 1 to run with just one thread.	 In general,
	      set OMP_NUM_THREADS to the available number of virtual proces‐
	      sors on the running system, which can be determined by using the
	      Oracle Solaris psrinfo(1) command.  See the OpenMP API User's
	      Guide for more information.

	      If you use -xautopar and compile and link in one step, then
	      linking automatically includes the microtasking library and the
	      threads-safe C runtime library. If you use -xautopar and compile
	      and link in separate steps, then you must link with CC -xautopar
	      as well.

       -xbinopt={prepare|off}
	      (SPARC) This option is now obsolete and will be removed in a
	      future release of the compilers. See -xannotate.

	      Instructs the compiler to prepare the binary for later optimiza‐
	      tions, transformations and analysis (see binopt(1)). This option
	      may be used for building executables or shared objects. This
	      option must be used with optimization level -xO1 or higher to be
	      effective. There is a modest increase in size of the binary when
	      built with this option.

	      If you compile in separate steps, -xbinopt must appear on both
	      compile and link steps:

	       example% CC -c -xO1 -xbinopt=prepare a.cc b.cc

	       example% CC -o myprog -xbinopt=prepare a.o

	      If some source code is not available for compilation, this
	      option may still be used to compile the remainder of the code.
	      It should then be used in the link step that creates the final
	      binary. In such a situation, only the code compiled with this
	      option can be optimized, transformed or analyzed.

	      Compiling with -xbinopt=prepare and -g increases the size of the
	      executable by including debugging information. The default is
	      -xbinopt=off.

       -xbuiltin[={%all|%default|%none}]
	      Use the -xbuiltin option to improve the optimization of code
	      that calls standard library functions.  This option lets the
	      compiler substitute intrinsic functions or inline system func‐
	      tions where profitable for performance. See the er_src(1) man
	      page to learn how to read compiler commentary output to deter‐
	      mine which functions were substituted by the compiler.

	      With -xbuiltin=%all, substitutions can cause the setting of
	      errno to become unreliable. If your program depends on the value
	      of errno, avoid this option.

	      -xbuiltin=%default only inlines functions that do not set errno.
	      The value of errno is always correct at any optimization level,
	      and can be checked reliably.  With -xbuiltin=%default at -xO3 or
	      lower, the compiler will determine which calls are profitable to
	      inline, and not inline others.

	      The -xbuiltin=%none option turns off all substitutions of
	      library functions.

	      If you do not specify -xbuiltin, the default is
	      -xbuiltin=%default when compiling with an optimization level
	      -xO1 and higher, and -xbuiltin=%none at -xO0.  If you specify
	      -xbuiltin without an argument, the default is -xbuiltin=%all and
	      the compiler substitutes intrinsics or inlines standard library
	      functions much more aggressively.

	      Compiling with -fast adds -xbuiltin=%all.

	      Note: The -xbuiltin option only inlines global functions defined
	      in system header files, never static functions defined by the
	      user. User code that attempts to interpose on global functions
	      may result in undefined behavior.

       -xcache=c
	      Define cache properties for use by optimizer.

	      c must be one of the following:
		 o generic
		 o native
		 o s1/l1/a1[/t1]
		 o s1/l1/a1[/t1]:s2/l2/a2[/t2]
		 o s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]

	      The si, li, ai, and ti, 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

	      ti The number of hardware threads sharing the cache at level i
		 The ti parameters are optional. A value of 1 is used if not
		 present.

	      This option specifies the cache properties that the optimizer
	      can use.	It does not guarantee that any particular cache prop‐
	      erty is used.

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

	      The -xcache values are:

	      generic
		    Define the cache properties for good performance on most
		    platforms. This is the default.

	      native
		    Define the cache properties for good performance on this
		    host platform.

	      s1/l1/a1[/t1]
		    Define level 1 cache properties.

	      s1/l1/a1[/t1]:s2/l2/a2[/t2]
		    Define levels 1 and 2 cache properties.

	      s1/l1/a1[/t1]:s2/l2/a2[/t2]:s3/l3/a3[/t3]
		    Define levels 1, 2, and 3 cache properties.

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

	      Values:

	      You can substitute one of the following values for o:

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

	      o s: equivalent to signed.

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

	      o u: equivalent to unsigned.

	      Defaults:

	      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.

	      Interactions:

	      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 speci‐
	      fied. Therefore, CHAR_MAX and CHAR_MIN no longer represent the
	      range of values encodable in a plain char.

	      Warnings:

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

	      It is strongly recommended that you never use -xchar to compile
	      routines for any interface exported through a library. The Ora‐
	      cle Solaris ABI specifies type char as signed, and system
	      libraries behave accordingly. The effect of making char unsigned
	      has not been extensively tested with system libraries. Instead
	      of using this option, modify your code so that it does not
	      depend on whether type char is signed or unsigned. The sign of
	      type char varies among compilers and operating systems.

       -xcheck[=n]
	      Enables a runtime check for stack overflow.

	      Values:

	      n must be one of the following values.

	      Value	     Meaning

	      %all	     Perform all checks.

	      %none	     Does not perform any checks.

	      stkovf	     Perform a runtime check for stack overflow of the
			     main thread in a singly-threaded program as well
			     as slave-thread stacks in a multithreaded pro‐
			     gram. 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).

	      no%stkovf	     Turns off stack-overflow checking.

	      init_local     Initialize local variables. See the C User's
			     Guide description of this option for a list of
			     the predefined values used by the compiler to
			     initialize variables.

	      no%init_local  Do not initialize local variables.

	      Interactions:

	      If you specify -xcheck without any arguments, the compiler
	      defaults to -xcheck=%none.

       -xchip=c
	      Specifies the target processor for use by the optimizer.

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

	      This option specifies timing properties by specifying the target
	      processor.

	      This option affects:

	      o The ordering of instructions, that is, scheduling

	      o The way the compiler uses branches

	      o The instructions to use in cases where semantically equivalent
		alternatives are available

	      The -xchip values for SPARC platforms are:

	      Value	Meaning

	      generic	Uses timing properties for good performance on most
			SPARC processors.

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

	      native	Set the parameters for the best performance on the
			host environment.

	      sparc64vi Optimize for the SPARC64 VI processor.

	      sparc64vii
			Optimize for the SPARC64 VII processor.

	      super	Optimize for the SuperSPARC processor.

	      super2	Optimize for the SuperSPARC II processor.

	      micro	Optimize for the MicroSPARC(TM) processor.

	      micro2	Optimize for the MicroSPARC II processor.

	      hyper	Optimize for the HyperSPARC(TM) processor.

	      hyper2	Optimize for the HyperSPARC II processor.

	      ultra	Optimize for the UltraSPARC(TM) processor.

	      ultra2	Optimize for the UltraSPARC II processor.

	      ultra2e	Optimize for the UltraSPARC IIe processor.

	      ultra2i	Optimize for the UltraSPARC IIi processor.

	      ultra3	Optimize for the UltraSPARC III processor.

	      ultra3cu	Optimize for the UltraSPARC IIIcu processor.

	      ultra3i	Optimize for the UltraSPARC IIIi processor.

	      ultra4	Optimize for the UltraSPARC IV processor.

	      ultra4plus
			Optimize for the UltraSPARC IVplus processor.

	      ultraT1	Optimize for the UltraSPARC T1 processor.

	      ultraT2	Optimize for the UltraSPARC T2 processor.

	      ultraT2plus
			Optimize for the UltraSPARC T2+ processor.

	      T3	Optimize for the SPARC T3 processor.

	      T4	Optimize for the SPARC T4 processor.

	      sparc64viiplus
			Optimize for the SPARC64 VII plus processor.

	      The -xchip values for x86 platforms are:

	      Value	Meaning

	      generic	Optimize for good performance on most x86 processors.

	      native	Optimize for this host processor.

	      core2	Optimize for the Intel Core2 processor.

	      nehalem	Optimize for the Intel Nehalem processor.

	      opteron	Optimize for the AMD Opteron processor.

	      penryn	Optimize for the Intel Penryn processor.

	      pentium	Optimize for the Intel Pentium processor.

	      pentium_pro
			Optimize for the Intel Pentium Pro processor.

	      pentium3	Optimize for the Intel Pentium 3 processor

	      pentium4	Optimize for the Intel Pentium 4 processor

	      sandybridge
			Optimize for the Intel Sandy Bridge processor

	      westmere	Optimize for the Intel Westmere processor

	      amdfam10	Optimize for the AMD FAM10 processor

       -xcode=a
	      (SPARC) Specifies code address space.

	      Note: It is highly recommended that you build shared objects by
	      specifying -xcode=pic13 or -xcode=pic32. It is possible to build
	      workable shared objects with -m64 -xcode=abs64, but these will
	      be inefficient. Shared objects built with -m64 -xcode=abs32 or
	      -m64 -xcode=abs44 will not work.

	      The following table shows the -xcode values.

	      Value	Meaning

	      abs32	Generate 32-bit absolute addresses, which are fast,
			but have limited range. Code + data + bss size is lim‐
			ited to 2**32 bytes.  This is the default on 32-bit
			architectures.

	      abs44	SPARC: Generate 44-bit absolute addresses, which have
			moderate speed and moderate range. Code + data + bss
			size is limited to 2**44 bytes.	 This is the default
			on 64-bit architectures. Do not use this value with
			dynamic (shared) libraries.

	      abs64	SPARC: Generate 64-bit absolute addresses, which are
			slow, but have full range. Available only on 64-bit
			architectures.

	      pic13	Generates position-independent code (small model),
			which is fast, but has limited range. Equivalent to
			-Kpic.	Permits references to at most 2**11 unique
			external symbols on 32-bit architectures, 2**10 on
			64-bit architectures.

	      pic32	Generates position-independent code (large model),
			which is slow, but has full range. Equivalent to
			-KPIC.	Permits references to at most 2**30 unique
			external symbols on 32-bit architectures, 2**29 on
			64-bit architectures.

	      To determine whether to use -xcode=pic13 or -xcode=pic32, check
	      the size of the Global Offset Table (GOT) by using elfdump -c
	      (see the elfdump(1) man page for more information) and for the
	      section header, sh_name: .got. The sh_size value is the size of
	      the GOT.	If the GOT is less than 8,192 bytes, specify
	      -xcode=pic13, otherwise specify -xcode=pic32.

	      In general, use the following guidelines to determine how you
	      should use -xcode:

	      o	 If you are building an executable you should not use
	      -xcode=pic13 or -xcode=pic32.

	      o	 If you are building an archive library only for linking into
	      executables you should not use -xcode=pic13 or -xcode=pic32.

	      o	 If you are building a shared library, start with -xcode=pic13
	      and once the GOT size exceed 8,192 bytes, use -xcode=pic32.

	      o	 If you are building an archive library for linking into
	      shared libraries you should just use -xcode=pic32.

	      Defaults:

	      The default is -xcode=abs32 for 32-bit architectures.

	      The default is -xcode=abs44 for 64-bit processors.

	      Warnings:

	      When you compile and link in separate steps, you must use the
	      same -xarch option in the compile step and the link step.

       -xdebugformat=[stabs|dwarf]
	      The C++ compiler	default format of debugger information is the
	      dwarf format -xdebugformat=dwarf.

	      Use this option as a way of accessing the new format for the
	      purpose of porting tools. There is no need to use this option
	      unless you maintain software which reads debugger information,
	      or unless a specific tool tells you that it requires debugger
	      information in one of these formats.

	      -xdebugformat=stabs generates debugging information using the
	      stabs standard format. The stabs format is no longer supported.

	      -xdebugformat=dwarf generates debugging information using the
	      dwarf standard format.

	      If you do not specify -xdebugformat, the compiler assumes -xde‐
	      bugformat=dwarf. This option requires an argument.

	      This option affects the format of the data that is recorded with
	      the -g option.  Some small amount of debugging information is
	      recorded even without -g, and the format of that information is
	      also controlled with this option.	 So -xdebugformat has a an
	      effect even when -g is not used.

	      The details of any specific fields or values in either stabs or
	      dwarf are also evolving.

	      See also the dumpstabs(1) and dwarfdump(1) man pages for more
	      information.

       -xdepend[=[yes|no] ]
	      Analyzes loops for inter-iteration data dependencies and per‐
	      forms loop restructuring.	 Loop restructuring includes loop
	      interchange, loop fusion, scalar replacement, and elimination of
	      "dead" array assignments.

	      On SPARC, -xdepend is turned on for all optimization levels -xO3
	      and above, and is off for lower opt levels. Also, an explicit
	      setting of -xdepend overrides any implicit setting.

	      On x86, if optimization is not at -xO3 or higher, the compiler
	      raises the optimization to -xO3 and issues a warning.

	      If you do not specify -xdepend, the default is -xdepend=no which
	      means the compiler does not analyze loops for data dependencies.
	      If you specify -xdepend but do not specify an argument, the com‐
	      piler sets the option to -xdepend=yes which means the compiler
	      analyzes loops for data dependencies.

	      Dependency analysis is included in -xautopar.  The dependency
	      analysis is done at compile time.

	      Dependency analysis may help on single-processor systems. How‐
	      ever, if you try -xdepend on single-processor systems, you
	      should not use -xautopar. If you do so, the -xdepend optimiza‐
	      tion is done for multiple-processor systems.

	      See Also: -xprefetch_auto_type

       -xdumpmacros[=value[,value...]]
	      Use this option when you want to see how macros are behaving in
	      your program. This option provides information such as macro
	      defines, undefines, and instances of usage. It prints output to
	      the standard error (stderr), based on the order macros are pro‐
	      cessed. The -xdumpmacros option is in effect until the end of
	      the file or until it is overridden by the dumpmacros or
	      end_dumpmacros pragma.

	      Values:

	      The prefix no% applied to a suboption disables that suboption.

	      Value	     Meaning

	      [no%]defs
			      Print all macro defines

	      [no%]undefs
			      Print all macro undefines

	      [no%]use
			      Print information about macros used

	      [no%]loc
			      Print location (path name and line number) also
			     for defs, undefs, and use

	      [no%]conds
			      Print use information for macros used in condi‐
			     tional directives

	      [no%]sys
			      Print all macros defines, undefines, and use
			     information for macros in system header files

	      %all	     Sets the option to -xdump‐
			     macros=defs,undefs,use,loc,conds,sys. A good way
			     to use this argument is in conjunction with the
			     [no%] form of the other arguments. For example,
			     -xdumpmacros=%all,no%sys would exclude system
			     header macros from the output but still provide
			     information for all other macros.

	      %none	     Do not print any macro information

	      The option values accumulate so specifying -xdumpmacros=sys
	      -xdumpmacros=undefs has the same effect as -xdump‐
	      macros=undefs,sys.

	      Note: The sub-options loc, conds, and sys are qualifiers for
	      defs, undefs and use options. By themselves, loc, conds, and sys
	      have no effect. For example, -xdumpmacros=loc,conds,sys has no
	      effect.

	      Defaults:

	      If you specify -xdumpmacros without any arguments, it means
	      -xdumpmacros=defs,undefs,sys. If you do not specify -xdump‐
	      macros,
	       it defaults to -xdumpmacros=%none.

       -xe    Check only for syntax and semantic errors. When you specify -xe
	      the compiler does not produce any object code. The output for
	      -xe is directed to stderr.

	      Use the -xe option if you do not need the object files produced
	      by compilation. For example, if you are trying to isolate the
	      cause of an error message by deleting sections of code, you can
	      speed the edit and compile cycle by using -xe.

       -xF[=v]
	      The -xF option enables the optimal reordering of functions and
	      variables by the linker.

	      This option instructs the compiler to place functions and/or
	      data variables into separate section fragments, which enables
	      the linker, using directions in a mapfile specified by the
	      linker's -M option, to reorder these sections to optimize pro‐
	      gram performance. Generally, this optimization is only effective
	      when page fault time constitutes a significant fraction of pro‐
	      gram run time.

	      Reordering functions and variables for optimal performance
	      requires the following operations:

	      1. Compiling and linking with -xF.

	      2. Following the instructions in the Performance Analyzer manual
	      regarding how to generate a mapfile for functions or following
	      the instructions in the Linker and Libraries Guide regarding how
	      to generate a mapfile for data.

	      3. Relinking with the new mapfile by using the linker's -M
	      option.

	      4. Re-executing under the Analyzer to verify improvement.

	      Values:

	      The prefix no% applied to a suboption disables that suboption.

	      v can be one of the following values:

	      Value	     Meaning

	      [no%]func
			      fragment functions into separate sections.

	      [no%]gbldata
			      fragment global data (variables with external
			     linkage) into separate sections.

	      [no%]lcldata
			      fragment local data (variables with internal
			     linkage) into separate sections.

	      %all	     Fragment functions, global data, and local data.

	      %none	     Fragment nothing.

	      Defaults:

	      If you do not specify -xF, the default is -xF=%none. If you
	      specify -xF without any arguments, the default is
	      -xF=%none,func.

	      Interactions:

	      Using -xF=lcldata inhibits some address calculation optimiza‐
	      tions, so you should only use this flag when it is experimen‐
	      tally justified.

	      See Also:

	      analyzer(1), ld(1)

       -xhelp=flags
	      Displays a brief description of each compiler flag.

       -xhwcprof[={enable|disable}]
	      (SPARC) Use the -xhwcprof option to enable compiler support for
	      dataspace profiling.

	      When -xhwcprof is enabled, the compiler generates information
	      that helps tools associate profiled load and store instructions
	      with the data-types and structure members (in conjunction with
	      symbolic information produced with -g) to which they refer.  It
	      associates profile data with the data space of the target,
	      rather than the instruction space, and provides insight into
	      behavior that is not easily obtained from only instruction pro‐
	      filing.

	      You can compile a specified set of object files with -xhwcprof
	      however, -xhwcprof is most useful when applied to all object
	      files in the application. This will provide coverage to identify
	      and correlate all memory references distributed in the applica‐
	      tion's object files.

	      If you are compiling and linking in separate steps, use
	      -xhwcprof at link time as well. Future extensions to -xhwcprof
	      may require its use at link time.

	      An instance of -xhwcprof=enable or -xhwcprof=disable overrides
	      all previous instances of -xhwcprof in the same command line.

	      -xhwcprof is disabled by default. Specifying -xhwcprof without
	      any arguments is the equivalent to -xhwcprof=enable.

	      -xhwcprof requires that optimization be turned on and that the
	      debug data format be set to dwarf (-xdebugformat=dwarf), which
	      is the default with current Oracle Solaris Studio compilers.

	      The combination of -xhwcprof and -g increases compiler temporary
	      file storage requirements by more than the sum of the increases
	      due to -xhwcprof and -g specified alone.

	      The following command compiles example.cc and specifies support
	      for hardware counter profiling and symbolic analysis of data
	      types and structure members using DWARF symbols:

	      example% CC -c -O -xhwcprof -g example.cc

	      For more information on hardware counter-based profiling, see
	      the Performance Analyzer manual.

       -xia   Link the appropriate interval arithmetic libraries and set a
	      suitable floating-point environment.

	      The -xia option is a macro that expands to
	      -fsimple=0 -ftrap=%none -fns=no -library=interval.

	      Interactions:

	      To use the interval arithmetic libraries, include <suninter‐
	      val.h>.

	      When you use the interval arithmetic libraries, you must include
	      one of the following libraries: Cstd, or iostreams.  See
	      -library for information on including these libraries.

	      Warnings:

	      If you use intervals and you specify different values for -fsim‐
	      ple, -ftrap, or -fns, then your program may have incorrect
	      behavior.

	      C++ interval arithmetic is experimental and evolving. The
	      specifics may change from release to release.

	      On x86 platforms, -xarch=sse2 must be specified for 32-bit com‐
	      pilations. Also, -xia is not available on Linux platforms.

	      See also:

	      -library
	      C++ Interval Arithmetic Programming Reference

       -xinline[=func_spec[,func_spec...]]
	      Specifies which user-written routines can be inlined by the
	      optimizer at -xO3 or higher.

	      Values:

	      The prefix no% applied to a suboption disables that suboption.

	      func_spec can be one of the following:

	      Value		  Meaning

	      %auto		  Enable automatic inlining at optimization
				  level -xO4 or higher.	 This argument tells
				  the optimizer that it can inline functions
				  of its choosing. Note that without the %auto
				  specification, automatic inlining is nor‐
				  mally turned off when explicit inlining is
				  specified on the command line by -xin‐
				  line=[no%]func_name...

	      func_name		  Strongly request that the optimizer inline
				  the function. If the function is not
				  declared as extern "C", the value of
				  func_name must be mangled. You can use the
				  nm command on the executable file to find
				  mangled function names. For functions
				  declared as extern "C", the names are not
				  mangled by the compiler.

	      no%func_name	  When you prefix the name of a routine on the
				  list with no%, the inlining of that routine
				  is inhibited. The rule about mangled names
				  for func_name applies to no%func_name as
				  well.
	      Only routines in the file being compiled are considered for
	      inlining unless you use -xipo[=1|2]. The optimizer decides which
	      of these routines are appropriate for inlining.

	      Defaults:

	      If the -xinline option is not specified, the compiler assumes
	      -xinline=%auto. If -xinline= is specified with no arguments, no
	      functions are inlined regardless of the optimization level.

	      Examples:

	      To enable automatic inlining while disabling inlining of the
	      function declared int foo(), use

	      example% CC -xO5 -xinline=%auto,no%__1cDfoo6F_i_ -c a.cc

	      To strongly request the inlining of the function declared as int
	      foo(), and to make all other functions as the candidates for
	      inlining, use:

	      example% CC -xO5 -xinline=%auto, __1cDfoo6F_i_ -c a.cc

	      To strongly request the inlining of the function declared as int
	      foo(), and to not allow inlining of any other functions use:

	      example% CC -xO5 -xinline=__1cDfoo6F_i_ -c a.cc

	      Interactions:

	      The -xinline option has no effect for optimization levels below
	      -xO3. At -xO4 and higher, the optimizer decides which functions
	      should be inlined, and does so without the -xinline option being
	      specified. At -xO4 or higher, the compiler also attempts to
	      determine which functions will improve performance if inlined.

	      A routine is inlined if any of the following conditions apply.

		     o Optimization is set at -xO3 or higher

		     o Inlining is judged to be profitable and safe

		     o The function is in the file being compiled, or the
		       function is in a file that was compiled with
		       -xipo[=1|2].

		     Warnings:

		     If you force the inlining of a function with -xinline,
		     you might actually diminish performance.

	      See Also:

	      -xldscope

       -xinstrument=[no%]datarace]

	      Specify this option to compile and instrument your program for
	      analysis by the Thread Analyzer. For more information on the
	      Thread Analyzer, see tha(1) for details.

	      You can then use the Performance Analyzer to run the instru‐
	      mented program with collect -r races to create a data-race-
	      detection experiment. You can run the instrumented code stand‐
	      alone but it runs more slowly.

	      Values

	      Value	     Meaning

	      datarace	     Prepare the code for analysis by the Thread Ana‐
			     lyzer and define __THA_NOTIFY.

	      no%datarace    This is the default. Do not prepare the code for
			     analysis by the Thread Analyzer and do not define
			     __THA_NOTIFY.

	      Interactions

	      If you compile and link in seperate steps, you must specify
	      -xinstrument=datarace in both the compilation and linking steps.

	      This option defines the preprocessor token __THA_NOTIFY. You can
	      specify #ifdef __THA_NOTIFY to guard calls to libtha(3) rou‐
	      tines.

	      This option also sets -g0.

	      Warnings

	      It is illegal to specify -xinstrument without an argument.

       -xipo[={0|1|2}]
	      Performs interprocedural optimizations.

	      The -xipo option performs partial-program optimizations by
	      invoking an interprocedural analysis pass.  It performs opti‐
	      mizations across all object files in the link step, and the
	      optimizations are not limited to just the source files on the
	      compile command. However, whole-program optimizations performed
	      with -xipo do not include assembly (.s) source files.

	      The -xipo option is particularly useful when compiling and link‐
	      ing large multifile applications. Object files compiled with
	      this flag have analysis information compiled within them that
	      enables interprocedural analysis across source and precompiled
	      program files.  However, analysis and optimization is limited to
	      the object files compiled with -xipo, and does not extend to
	      object files or libraries.

	      Values:

	      Value	     Meaning

	      0		     Do not perform interprocedural optimizations.

	      1		     Perform interprocedural optimizations.

	      2		     Perform interprocedural aliasing analysis as well
			     as optimization of memory allocation and layout
			     to improve cache performance.
	      Defaults:

	      If -xipo is not specified, -xipo=0 is assumed.

	      If only -xipo is specified, -xipo=1 is assumed.

	      Examples:

	      The following example compiles and links in the same step.

	      example% CC -xipo -xO4 -o prog part1.cc part2.cc part3.cc

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

	      The following example compiles and links in separate steps.

	      example% CC -xipo -xO4 -c part1.cc part2.cc

	      example% CC -xipo -xO4 -c part3.cc

	      example% CC -xipo -xO4 -o prog part1.o part2.o part3.o

	      The object files created in the compile steps have additional
	      analysis information compiled within them to permit crossfile
	      optimizations to take place at the link step.

	      Interactions:

	      The -xipo option requires at least optimization level -xO4.

	      Warnings:

	      When compiling and linking are performed in separate steps,
	      -xipo must be specified in both steps to be effective. Objects
	      that are compiled without -xipo can be linked freely with
	      objects that are compiled with -xipo. Libraries do not partici‐
	      pate in crossfile interprocedural analysis, even when they are
	      compiled with -xipo as shown in this example:

	       example% CC -xipo -xO4 one.cc two.cc three.cc

	       example% CC -xar -o mylib.a one.o two.o three.o

	       example% CC -xipo -xO4 -o myprog main.cc four.cc mylib.a

	      In this example, interprocedural optimizations will be performed
	      between one.cc, two.cc, and three.cc, and between main.cc and
	      four.cc, but not between main.cc or four.cc and the routines in
	      mylib.a. The first compilation may generate warnings about unde‐
	      fined symbols, but the interprocedural optimizations will be
	      performed because it is a compile and link step.

	      The -xipo option generates significantly larger object files due
	      to the additional information needed to perform optimizations
	      across the files. However, this additional information does not
	      become part of the final executable binary file. Any increase in
	      the size of the executable program will be due to the additional
	      optimizations performed.

	      When Not To Use -xipo=2 Interprocedural Analysis

	      The compiler tries to perform whole-program analysis and opti‐
	      mizations as it works with the set of object files in the link
	      step. The compiler makes the following two assumptions for any
	      function (or subroutine) foo() defined in this set of object
	      files:

	      (1) foo() is not called explicitly by another routine that is
	      defined outside this set of object files at runtime.

	      (2) The calls to foo() from any routine in the set of object
	      files are not interposed upon by a different version of foo()
	      defined outside this set of object files.

	      Do not compile with -xipo=2 if assumption (1) is not true for
	      the given application.

	      Do not compile with either -xipo=1 or -xipo=2 if assumption (2)
	      is not true.

	      As an example, consider interposing on the function malloc()
	      with your own version and compiling with -xipo=2. Consequently,
	      all the functions in any library that reference malloc() that
	      are linked with your code have to be compiled with -xipo=2 also
	      and their object files need to participate in the link step.
	      Since this might not be possible for system libraries, do not
	      compile your version of malloc() with -xipo=2.

	      As another example, suppose that you build a shared library with
	      two external calls, foo() and bar() inside two different source
	      files. Furthermore, suppose that bar() calls foo(). If there is
	      a possibility that foo() could be interposed at runtime, then do
	      not compile the source file for foo() or for bar() with -xipo=1
	      or -xipo=2.  Otherwise, foo() could be inlined into bar(), which
	      could cause incorrect results.

       -xipo_archive[=a]
	      The -xipo_archive option enables the compiler to optimize object
	      files that are passed to the linker with object files that were
	      compiled with -xipo and that reside in the archive library (.a)
	      before producing an executable. Any object files contained in
	      the library that were optimized during the compilation are
	      replaced with their optimized version.

	      a is one of the following:

	      writeback
	       The compiler optimizes object files passed to the linker with
	       object files compiled with -xipo that reside in the archive
	       library (.a) before producing an executable. Any object files
	       contained in the library that were optimized during the compi‐
	       lation are replaced with an optimized version.

	       For parallel links that use a common set of archive
	       libraries,each link should create its own copy of archive
	       libraries to be optimized before linking.

	      readonly
	       The compiler optimizes object files passed to the linker with
	       object files compiled with -xipo that reside in the archive
	       library (.a) before producing an executable.

	       The option -xipo_archive=readonly enables cross-module inlining
	       and interprocedural data flow analysis of object files in an
	       archive library specified at link time.	However, it does not
	       enable cross-module optimization of the archive library's code
	       except for code that has been inserted into other modules by
	       cross module inlining.

		To apply cross-module optimization to code within an archive
	       library, -xipo_archive=writeback is required. Note that doing
	       so modifies the contents of the archive library from which the
	       code was extracted.

	      none
	       Default. There is no processing of archive files. The compiler
	       does not apply cross-module inlining or other cross-module
	       optimizations to object files compiled using -xipo and
	       extracted from an archive library at link time. To do that,
	       both -xipo and either -xipo_archive=readonly or -xipo_ar‐
	       chive=writeback must be specified at link time.

	      It is illegal to specify -xipo_archive without a flag.

       -xivdep[=p]
	      Disable or set interpretation of ivdep pragmas

	      The ivdep pragmas tell a compiler to ignore some or all loop-
	      carried dependences on array references that it finds in a loop
	      for purposes of optimization.  This enables a compiler to per‐
	      form various loop optimizations such as microvectorization, dis‐
	      tribution, software pipelining, etc., which would not be other‐
	      wise possible.  It is used in cases where the user knows either
	      that the dependences do not matter or that they never occur in
	      practice.

	      The interpretation of #pragma ivdep directives depend upon the
	      value of the -xivdep option.

	      The following values for p are interpreted as follows:

	      loop - ignore assumed loop-carried vector dependences
	      loop_any - ignore all loop-carried vector dependences
	      back - ignore assumed backward loop-carried vector dependences
	      back_any - ignore all backward loop-carried vector dependences
	      none - do not ignore any dependences (disables ivdep pragmas)

	      These interpretations are provided for compatibility with other
	      vendor's interpretations of the ivdep pragma.

       -xjobs=n
	      Compile with multiple processors.

	      Specify the -xjobs option to set how many processes the compiler
	      creates to complete its work. This option can reduce the build
	      time on a multi-cpu machine. Currently, -xjobs works only with
	      the -xipo option. When you specify -xjobs=n, the interprocedural
	      optimizer uses n as the maximum number of code generator
	      instances it can invoke to compile different files.

	      Generally, a safe value for n is 1.5 multiplied by the number of
	      available processors. Using a value that is many times the num‐
	      ber of available processors can degrade performance because of
	      context switching overheads among spawned jobs. Also, using a
	      very high number can exhaust the limits of system resources such
	      as swap space.

	      You must always specify -xjobs with a value. Otherwise an error
	      diagnostic is issued and compilation aborts.

	      Multiple instances of -xjobs on the command line override each
	      other until the rightmost instance is reached.

	      The following example compiles more quickly on a system with two
	      processors than the same command without the -xjobs option.

	      example% CC -xipo -xO4 -xjobs=3 t1.cc t2.cc t3.cc

       -xkeepframe[=[%all,%none,function_name,no%function_name]]
	      Prohibit stack related optimizations for the named functions.

	      %all - prohibit stack related optimizations for all the code
	      %none - allow stack related optimizations for all the code

	      If not specified on the command line, the compiler assumes
	      -xkeepframe=%none

	      If specified on the command line without a value, the compiler
	      assumes -xkeepframe=%all This option is accumulative and can
	      appear on the command line multiple times. For example, -xkeep‐
	      frame=%all  -xkeepframe=no%func1 indicates that the stack frame
	      should be kept for all functions except func1.  Also, -xkeep‐
	      frame overrides -xregs=frameptr. For example, -xkeep‐
	      frame=%all -xregs=frameptr indicates that the stack should be
	      kept for all functions, but the optimizations for
	      -xregs=frameptr would not be done.

       -xlang=language[,language]
	      Includes the appropriate runtime libraries and ensures the
	      proper runtime environment for the specified language.

	      language must be either f77, f90, f95 or c99.

	      The -f90 and -f95 arguments are equivalent.  The c99 argument
	      invokes ISO 9899:1999 C programming language behavior for
	      objects that were compiled with cc -xc99=%all and are being
	      linked with CC.

	      Interactions:

	      The -xlang=f90 and -xlang=f95 options imply -library=f90, and
	      the -xlang=f77 option implies -library=f77. However, the
	      -library=f77 and -library=f90 options are not sufficient for
	      mixed-language linking because only the -xlang option insures
	      the proper runtime environment.

	      To determine which driver to use for mixed-language linking, use
	      the following language hierarchy:

	      1. C++

	      2. Fortran 95 (or Fortran 90)

	      3. Fortran 77

	      4. C or C99

	      When linking Fortran 95, Fortran 77, and C++ object files
	      together, use the driver of the highest language. For example,
	      use the following C++ compiler command to link C++ and Fortran
	      95 object files.

	      example% CC -xlang=f95...

	      To link Fortran 95 and Fortran 77 object files, use the Fortran
	      95 driver as follows:

	      example% f95 -xlang=f77...

	      You cannot use the -xlang option and the -xlic_lib option in the
	      same compiler command. If you are using -xlang and you need to
	      link in the Sun Performance Library, use the -library=sunperf
	      instead.

	      Warnings:

	      Do not use -xnolib with -xlang.

	      If you are mixing parallel Fortran objects with C++ objects, the
	      link line must specify the -mt flag.

	      See also:

	      -library, -staticlib"

       -xldscope={v}
	      Changes the default linker scoping for the definition of extern
	      symbols.	Changing the default can result in faster and safer
	      shared libraries because the implementation will be better hid‐
	      den.

	      Values

	      v must be one of the following:

	      Value	     Meaning

	      global	     Symbol definitions have global linker scoping
			     which is the least restrictive linker scoping.
			     All references to the symbol bind to the defini‐
			     tion in the first dynamic load module that
			     defines the symbol. This linker scoping is the
			     current linker scoping for extern symbols.

	      symbolic	     Symbol definitions have symbolic linker scoping
			     which is more restrictive than global linker
			     scoping. All references to the symbol from within
			     the dynamic load module being linked bind to the
			     symbol defined within the module. Outside of the
			     module, the symbol appears as though it is
			     global. This linker scoping corresponds to the
			     linker option -Bsymbolic. Although you cannot use
			     -Bsymbolic with C++ libraries, you can use the
			     -xldscope=symbolic option without causing prob‐
			     lems.

	      hidden	     Hidden linker scoping is more restrictive than
			     symbolic and global linker scoping. All refer‐
			     ences within a dynamic load module will bind to a
			     definition within that module. The symbol will
			     not be visible outside of the module.

	      Defaults

	      If you do not specify -xldscope, the compiler assumes -xld‐
	      scope=global. If you specify -xldscope without any values, the
	      compiler issues an error. Multiple instances of this option on
	      the command line override each other until the rightmost
	      instance is reached.

	      Warnings

	      If you intend to allow a client to override a function in a
	      library, you must be sure that the function is not generated
	      inline during the library build. The compiler inlines a function
	      if you specify the function name with -xinline, if you compile
	      at -xO4 or higher in which case inlining can happen automati‐
	      cally, if you use the inline specifier, or if you are using
	      cross-file optimization.

	      For example, suppose library ABC has a default allocator func‐
	      tion that can be used by library clients, and is also used
	      internally in the library:

	      void* ABC_allocator(size_t size) { return malloc(size); }

	      If you build the library at -xO4 or higher, the compiler inlines
	      calls to ABC_allocator that occur in library components. If a
	      library client wants to replace ABC_allocator with a customized
	      version, the replacement will not occur in library components
	      that called ABC_allocator.  The final program will include dif‐
	      ferent versions of the function.

	      Library functions declared with the __hidden or __symbolic spec‐
	      ifiers can be generated inline when building the library. They
	      are not supposed to be overridden by clients. For more informa‐
	      tion, see chapter 4 "Language Extensions" of the C++ User's
	      Guide.

	      Library functions declared with the __global specifier, should
	      not be declared inline, and should be protected from inlining by
	      use of the -xinline compiler option.

	      See Also

	      -xinline, -xO, ld(1).

       -xlibmieee
	      Causes libm to return IEEE 754 values for math routines in
	      exceptional cases.  The default behavior of libm is XPG-compli‐
	      ant.

	      This option has an impact on the value of the errno variable set
	      by certain floating-point math library routines. See the NOTES
	      section at the end of this man page for more information.

       -xlibmil
	      Inlines selected library routines for optimization.

	      There are inline templates for some of the libm library rou‐
	      tines. This option selects those inline templates that produce
	      the fastest executables for the floating-point option and plat‐
	      form currently being used.

	      Note — This option does not affect C++ inline functions.	This
	      option has an impact on the value of the errno variable set by
	      certain floating-point math library routines. See the NOTES sec‐
	      tion at the end of this man page for more information.

       -xlibmopt
	      Uses a library of optimized math routines. You must use default
	      rounding mode by specifying -fround=nearest when you use this
	      option.

	      This option uses a math routine library optimized for perfor‐
	      mance, and usually generates faster code. The results may be
	      slightly different from those produced by the normal math
	      library. If so, they usually differ in the last bit.

	      The order on the command line for this library option is not
	      significant.

	      Interactions:

	      This option is implied by the -fast option.

	      See also:

	      -fast
	      -xnolibmopt

	      This option has an impact on the value of the errno variable set
	      by certain floating-point math library routines. See the NOTES
	      section at the end of this man page for more information.

       -xlic_lib=sunperf
	      Deprecated, do not use. Specify -library=sunperf instead.

       -xlicinfo
	      This option is silently ignored by the compiler.

       -xlinkopt[=level]
	      (SPARC) Perform link-time optimizations on relocatable object
	      files.

	      The link optimizer performs a number of advanced performance
	      optimizations on the binary object code at link-time. The value
	      level sets the level of optimizations performed, and must be 0,
	      1, or 2.

	      The optimization levels are:

	      0	       The link optimizer is disabled. (This is the default.)

	      1	       Perform optimizations based on control flow analysis,
		       including instruction cache coloring and branch opti‐
		       mizations, at link time.

	      2	       Perform additional data flow analysis, including dead-
		       code elimination and address computation simplifica‐
		       tion, at link time.

	      Specifying -xlinkopt without a level parameter implies
	      -xlinkopt=1.

	      These optimizations are performed at link time by analyzing the
	      object binary code. The object files are not rewritten but the
	      resulting executable code may differ from the original object
	      codes.

	      This option is most effective when used to compile the whole
	      program, and with profile feedback.

	      When compiling in separate steps, -xlinkopt must appear on both
	      compile and link steps:

	      example% CC -c -xlinkopt a.cc b.cc
	      example% CC -o myprog -xlinkopt=2 a.o b.o

	      Note that the level parameter is only used when the compiler is
	      linking. In the example above, the link optimizer level is 2
	      even though the object binaries were compiled with an implied
	      level of 1.

	      Do not use the -zcombreloc linker option when you compile with
	      -xlinkopt.

	      You must use -xlinkopt on at least some of the compilation com‐
	      mands for -xlinkopt to be useful at link time. The optimizer can
	      still perform some limited optimizations on object binaries not
	      compiled with -xlinkopt.

	      -xlinkopt will optimize code coming from static libraries that
	      appear on the compiler command line, but it will skip and not
	      optimize code coming from shared (dynamic) libraries that appear
	      on the command line.  You can also use -xlinkopt when building
	      shared libraries (compiling with -G ).

	      The link optimizer is most effective when used with run-time
	      profile feedback. Profiling reveals the most and least used
	      parts of the code and directs the optimizer to focus its effort
	      accordingly.  This is particularly important with large applica‐
	      tions where optimal placement of code performed at link time can
	      reduce instruction cache misses.	Typically, this would be com‐
	      piled as follows:

	      example% CC -o progt -xO5 -xprofile=collect:profdir file.cc
	      example% progt
	      example% CC -o prog -xO5 -xprofile=use:profdir -xlinkopt file.cc

	      For details on using profile feedback, see -xprofile

	      Note that compiling with this option increases link time
	      slightly.	 Object file sizes also increase, but the size of the
	      executable remains the same. Compiling with -xlinkopt and -g
	      increases the size of the executable by including debugging
	      information.

       -xloopinfo

	      Shows which loops are parallelized and which are not. This
	      option is normally for use with the -xautopar option.

       -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 makefiles
	      and dependencies).

	      However, -xM only reports dependencies of the included headers
	      and not the associated template definition files. You can use
	      the .KEEP_STATE feature in your makefile to generate all the
	      dependencies in the .make.state file that is created by make.

	      See make(1) for details about makefiles and dependencies.

       -xM1   This option is the same as -xM, except that this option does not
	      report dependencies for the /usr/include header files and it
	      does not report dependencies for compiler-supplied header files.

       -xMD   Generates makefile dependencies like -xM but compilation contin‐
	      ues.  -xMD generates an output file for the makefile-dependency
	      information derived from the -o output filename, if specified,
	      or the input source filename, replacing (or adding) the filename
	      suffix with .d . If you specify -xMD and -xMF, the preprocessor
	      writes all makefile dependency information to the file specified
	      with -xMF. Compiling with -xMD -xMF or -xMD -o filename with
	      more than one source file is not allowed and generates an error.
	      The dependency file is overwritten if it already exists.

       -xMF filename
	      Use this option to specify a file for the makefile- dependency
	      output. There is no way to specify individual filenames for mul‐
	      tiple input files with -xMF on one command line. Compiling with
	      -xMD -xMF or -xMMD -xMF with more than one source file is not
	      allowed and generates an error.  The dependency file is over‐
	      written if it already exists.

       -xMMD  Use this option to generate makefile dependencies excluding sys‐
	      tem header files. This is the same functionality as -xM1, but
	      compilation continues. -xMMD generates an output file for the
	      makefile-dependency information derived from the -o output file‐
	      name, if specified, or the input source filename, replacing (or
	      adding) the filename suffix with .d .  If you specify -xMF, the
	      compiler uses the filename you provide instead.  Compiling with
	      -xMMD -xMF or -xMMD -o filename with more than one source file
	      is not allowed and generates an error.  The dependency file is
	      overwritten if it already exists.

       -xMerge
	      Merges the data segment with the text segment.

	      The data in the object file is read-only, and is shared between
	      processes, unless you link with

	      -xMerge -ztext -xprofile=collect should not be used together.
	      While -xMerge forces statically initialized data into read-only
	      storage, -ztext prohibits position-dependent symbol relocations
	      in read-only storage, and -xprofile=collect generates statically
	      initialized, position-dependent symbol relocations in writable
	      storage.	ld -N.

       -xmaxopt[=v]
	      This command limits the level of pragma opt to the level speci‐
	      fied. v must be one of the following: off, 1, 2, 3, 4, or 5.
	      The default value is -xmaxopt=off which causes pragma opt to be
	      ignored. If you specify -xmaxopt without supplying an argument,
	      that is the equivalent of specifying -xmaxopt=5.

       -xmemalign[=ab]
	      (SPARC) Use the -xmemalign option to control the assumptions the
	      compiler makes about the alignment of data. By controlling the
	      code generated for potentially misaligned memory accesses and by
	      controlling program behavior in the event of a misaligned
	      access, you can more easily port your code to SPARC.

	      Specify the maximum assumed memory alignment and behavior of
	      misaligned data accesses. There must be a value for both a
	      (alignment) and b (behavior). a specifies the maximum assumed
	      memory alignment and b specifies the behavior for misaligned
	      memory accesses.

	      For memory accesses where the alignment is determinable at com‐
	      pile time, the compiler generates the appropriate load/store
	      instruction sequence for that alignment of data.

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

	      If actual data alignment at runtime is less than the specified
	      alignment, the misaligned access attempt (a memory read or
	      write) generates a trap. The two possible responses to the trap
	      are as follows:

	      o The OS converts the trap to a SIGBUS signal. If the program
	      does not catch the signal, the program aborts. Even if the pro‐
	      gram catches the signal, the misaligned access attempt will not
	      have succeeded.

	      o The OS handles the trap by interpreting the misaligned access
	      and returning control to the program as if the access had suc‐
	      ceeded normally.

	      Values:

	      Accepted values for a are:

		     1	    Assume at most 1 byte alignment.

		     2	    Assume at most 2 byte alignment.

		     4	    Assume at most 4 byte alignment.

		     8	    Assume at most 8 byte alignment.

		     16	    Assume at most 16 byte alignment.

	      Accepted values for b are:

		     i	    Interpret access and continue execution.

		     s	    Raise signal SIGBUS.

		     f	    For 64-bit SPARC programs (-m64) only. Raise sig‐
			    nal SIGBUS for alignments less than or equal to 4,
			    otherwise interpret access and continue execution.
			    For 32-bit programs, the f flag is equivalent to
			    i.

	      You must also specify -xmemalign whenever you want to link to an
	      object file that was compiled with the value of b set to either
	      i or f. For a complete list of compiler options that must be
	      specified at both compile time and at link time, see the C++
	      User's Guide.

	      Defaults:

	      The default for SPARC 64-bit programs (-m64) is -xmemalign=8s.

	      The default for SPARC 32-bit programs (-m32) is -xmemalign=8i.

	      If you do specify -xmemalign but do not provide a value, the
	      default is -xmemalign=1i for all platforms.

       -xmodel=[a]
	      (x86) The -xmodel option determines the data address model for
	      shared objects on the Oracle Solaris x64 platforms and should
	      only be specified for the compilation of such objects.

	      This option is valid only when -m64 is also specified on 64-bit
	      enabled x64 processors.

	      a is one of the following:

	      small
		   This option generates code for the small model in which the
		   virtual address of code executed is known at link time and
		   all symbols are known to be located in the virtual
		   addresses in the range from 0 to 2^31 - 2^24 - 1.

	      kernel
		   Generates code for the kernel model in which all symbols
		   are defined to be in the range from 2^64 - 2^31 to 2^64 -
		   2^24.

	      medium
		   Generates code for the medium model in which no assumptions
		   are made about the range of symbolic references to data
		   sections. Size and address of the text section have the
		   same limits as the small code model. Applications with
		   large amounts of static data might require -xmodel=medium
		   when compiling with -m64.

	      This option is not cumulative so the compiler sets the model
	      value according to the rightmost instance of -xmodel on the com‐
	      mand-line.

	      If you do not specify -xmodel, the compiler assumes
	      -xmodel=small.  Specifying -xmodel without an argument is an
	      error.

	      It is not necessary to compile all translation units with this
	      option. You can compile select files as long as you ensure the
	      object you are accessing is within reach.

	      Be aware that not all Linux system support the medium model.

       -xnolib
	      Disables linking with default system libraries.

	      Normally (without this option), the C++ compiler links with sev‐
	      eral system support libraries to support C++ programs. With this
	      option, the -llib options to link the default system support
	      libraries are not passed to ld.

	      Normally, the compiler links with the system support libraries
	      in the following order:

	      For default -compat=5 mode:

	      -lCstd -lCrun -lm -lc

	      For -compat=g on Linux, the libraries are:

	      -lstdc++ -lCrunG3 -lm -lc

	      For -compat=g on Oracle Solaris x86, the libraries are:

	      -lstdc++ -lgcc_s -lCrunG3 -lm -lc

	      The order of the -l options is significant. The -lm option must
	      appear before -lc.

	      Note — If the -mt option is specified, the compiler normally
	      links with -lthread just before it links with -lm.

	      To determine which system support libraries will be linked by
	      default, compile with the -dryrun option. For example, the out‐
	      put from the following command:

	      CC foo.cc -m64 -dryrun

	      includes the following

	      -lCstd -lCrun -lm -lc

	      Examples:

	      For minimal compilation to meet the C application binary inter‐
	      face, that is, a C++ program with only C support required, use:

	       CC -xnolib test.cc -lc

	      To link libm statically into a single threaded application with
	      the generic instruction set, use:

	      CC -xnolib test.cc -lCstd -lCrun -Bstatic -lm -Bdynamic -lc

	      Interactions:

	      No static system libraries are available on Oracle Solaris plat‐
	      forms.

	      If you specify -xnolib, you must manually link all required sys‐
	      tem support libraries in the given order. You must link the sys‐
	      tem support libraries last.

	      If -xnolib is specified, -library is ignored.

	      Warnings:

	      Many C++ language features require the use of libCrun

	      The set of system support libraries is not stable and might
	      change from release to release.

       -xnolibmil
	      Cancels -xlibmil on the command line.

	      Use this option with -fast to override linking with the opti‐
	      mized math library.

       -xnolibmopt
	      Cancels -xlibmopt on the command line.

	      Interactions:

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

       -xOn   Specifies optimization level (n).	 (Note the uppercase letter O,
	      followed by a digit 1, 2, 3, 4, or 5)

	      The default is no optimization. However, this is only possible
	      if you do not specify an optimization level. If you specify an
	      optimization level, there is no option for turning optimization
	      off.

	      If you are trying to avoid setting an optimization level, be
	      sure not to specify any option that implies an optimization
	      level.  For example, -fast is a macro option that sets optimiza‐
	      tion at -xO5. All other options that imply an optimization level
	      give a warning message that optimization has been set. The only
	      way to compile without any optimization is to delete all options
	      from the command line or makefile that specify an optimization
	      level.

	      Generally, the higher the level of optimization with which a
	      program is compiled, the better the runtime performance. How‐
	      ever, higher optimization levels may result in increased compi‐
	      lation time and larger executable files.

	      There are five levels that you can use with -xOn.	 The actual
	      optimizations performed by the compiler at each level may change
	      with each compiler release. They are only summarized here.

	      If the optimizer runs out of memory, it attempts to proceed over
	      again at a lower level of optimization, resuming compilation of
	      subsequent routines at the original level.

	      Values:

	      -xO1   Do only the basic local optimizations.

	      -xO2   Do basic local and global optimization. This level usu‐
		     ally gives minimum code size.

	      -xO3   Adds global optimizations at the function level.  In gen‐
		     eral, this level, and -xO4, usually result in the minimum
		     code size when used with the -xspace option.

	      -xO4   Adds automatic inlining of functions in the same file. In
		     general, -xO4 results in larger code unless combined with
		     -xspace.

		     See -inline to control which routines are inlined.

	      -xO5   Does the highest level of optimization, suitable only for
		     the small fraction of a program that uses the largest
		     fraction of computer time. Uses optimization algorithms
		     that take more compilation time or that do not have as
		     high a certainty of improving execution time.  Optimiza‐
		     tion at this level is more likely to improve performance
		     if it is done with profile feedback. See -xprofile=col‐
		     lect|use.

	      Interactions:

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

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

	      Debugging with -g does not suppress -xOn, but -xOn limits -g in
	      certain ways. For example, the optimization options reduce the
	      utility of debugging so that you cannot display variables from
	      dbx, but you can still use the dbx where command to get a sym‐
	      bolic traceback.	For more information, see Debugging a Program
	      With dbx.

	      The -xinline option has no effect for optimization levels below
	      -xO3. At -xO4, the optimizer decides which functions should be
	      inlined, and does so regardless of whether you specify the -xin‐
	      line option. At -xO4, the compiler also attempts to determine
	      which functions will improve performance if they are inlined.
	      If you force the inlining of a function with -xinline, you might
	      actually diminish performance.

	      Warnings:

	      If you optimize at -xO3 or -xO4 with very large procedures,
	      thousands of lines of code in a single procedure, the optimizer
	      might require an unreasonable amount of memory. In such cases,
	      machine performance can be degraded.

	      To prevent this degradation from taking place, use the limit
	      command to limit the amount of virtual memory available to a
	      single process (see the csh(1) man page). For example, to limit
	      virtual memory to 16 megabytes:

	      example% limit datasize 16M

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

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

	      The best setting for data size depends on the degree of opti‐
	      mization requested, the amount of real memory, and virtual mem‐
	      ory available.

	      To find the actual swap space, type: swap -1

	      To find the actual real memory, type: dmesg | grep mem

	      See also:

	      -xldscope, -fast, -xprofile=p, csh(1) man page

	      Performance Analyzer discusses the effects of the different lev‐
	      els of optimization on the Performance Analyzer's data.

       -xopenmp[=i]

	      Enable explicit parallelization with OpenMP directives.

	      The following table details the -xopenmp values:

	      Value	Meaning

	      parallel Enables recognition of OpenMP pragmas. The optimization
		       level under -xopenmp=parallel is -xO3. The compiler
		       changes the optimization level to -xO3 if necessary and
		       issues a warning. This flag also defines the preproces‐
		       sor token _OPENMP.

		       The _OPENMP token is defined to have the decimal value
		       yyyymm where yyyy and mm are the year and month desig‐
		       nations of the version of the OpenMP API that the
		       implementation supports.	 Refer to the Oracle Solaris
		       Studio OpenMP API User's Guide for the value of the
		       _OPENMP macro for a particular release.

	      noopt    Enables recognition of OpenMP pragmas. The compiler
		       does not raise the optimization level if it is lower
		       than -O3. If you explicitly set the optimization lower
		       than -O3, as in cc -O2 -xopenmp=noopt, the compiler
		       issues an error. If you do not specify an optimization
		       level with -xopenmp=noopt, the OpenMP pragmas are rec‐
		       ognized, the program is parallelized accordingly, but
		       no optimization is done. This flag also defines the
		       preprocessor token _OPENMP.

	      none     This flag is the default and does not enable recogni‐
		       tion of OpenMP pragmas, makes no change to the opti‐
		       mization level of your program, and does not predefine
		       any preprocessor tokens.

	      If you specify -xopenmp, but do not include an argument, the
	      compiler assumes -xopenmp=parallel. This default could change in
	      future releases.	If you do not specify -xopenmp, the compiler
	      assumes -xopenmp=none.

	      If you are debugging an OpenMP program with dbx, compile with -g
	      -xopenmp=noopt so you can breakpoint within parallel regions and
	      display the contents of variables.

	      The default for -xopenmp might change in future releases. You
	      can avoid warning messages by explicitly specifying an appropri‐
	      ate optimization.

	      Use the OMP_NUM_THREADS environment variable to specify the num‐
	      ber of threads to use when running an OpenMP program.  If
	      OMP_NUM_THREADS is not set, the default number of threads used
	      is 2.  To use more threads, set OMP_NUM_THREADS to a higher
	      value.  Set OMP_NUM_THREADS to 1 to run with just one thread.
	      In general, set OMP_NUM_THREADS to the available number of vir‐
	      tual processors on the running system, which can be determined
	      by using the Oracle Solaris psrinfo(1) comma nd.	See the OpenMP
	      API User's Guide for more information.

	      To enable nested parallelism, you must set the OMP_NESTED envi‐
	      ronmen t variable to TRUE. Nested parallelism is disabled by
	      default. See the Or acle Solaris Studio OpenMP API User's Guide
	      for details.

	      If you compile and link in seperate steps, specify -xopenmp in
	      both the compilation step and the link step. This is important
	      if you are building a shared object. The compiler which was used
	      to compile the executable must not be any older than the com‐
	      piler that built the .so with -xopenmp.  This is especially
	      important when you compile libraries that contain OpenMP direc‐
	      tives.

	      Make sure that the latest patch of the OpenMP runtime library,
	      libmtsk.so, is installed on the system for best performance.

	      For a complete summary of the OpenMP Fortran 95, C, and C++
	      application program interface (API) for building multiprocessing
	      applications, see the OpenMP API User's Guide.

       -xpagesize=n
	      Set the preferred page size for the stack and the heap.

	      The n value must be one of the following:

	      On SPARC:
	       4K 8K 64K 512K 2M 4M 32M 256M 2G 16G or default.

	      On x86/x64:
	       4K 2M 4M 1G or default.

	      You must specify a valid page size for the target platform.  If
	      you do not specify a valid pagesize, the request is silently
	      ignored at run-time.

	      Use the pagesize(1) command on the Oracle Solaris operating sys‐
	      tem to determine the number of bytes in a page. The Oracle
	      Solaris operating system offers no guarantee that the page size
	      request will be honored.	You can use pmap(1) or meminfo(2) to
	      determine page size of the target platform.

	      The -xpagesize option has no effect unless you use it at compile
	      time and at link time. For a complete list of compiler options
	      that must be specified at both compile time and at link time,
	      see the C++ User's Guide.

	      If you specify -xpagesize=default, the Oracle Solaris operating
	      system sets the page size.

	      This option is a macro for -xpagesize_heap and -xpagesize_stack.
	      These two options accept the same arguments as -xpagesize. You
	      can set them both with the same value by specifying -xpagesize=n
	      or you can specify them individually with different values.

	      Compiling with this option has the same effect as setting the
	      LD_PRELOAD environment variable to mpss.so.1 with the equivalent
	      options, or running the Oracle Solaris command ppgsz(1) with the
	      equivalent options before running the program. See the Oracle
	      Solaris man pages for details.

       -xpagesize_heap=n
	      Set the page size in memory for the heap.

	      The n value is the same as -xpagesize.

	      You must specify a valid page size for the target platform. If
	      you do not specify a valid pagesize, the request is silently
	      ignored at run-time.

	      For details, see -xpagesize.

       -xpagesize_stack=n
	      Set the page size in memory for the stack.

	      The n value is the same as -xpagesize.

	      You must specify a valid page size for the Oracle Solaris oper‐
	      ating system on the target platform. If you do not specify a
	      valid pagesize, the request is silently ignored at run-time.

	      For details, see -xpagesize.

       -xpch=v
	      This compiler option activates the precompiled-header feature. v
	      can be auto, autofirst, collect:pch_filename, or use:pch_file‐
	      name. You can take advantage of this feature through the -xpch
	      and -xpchstop options in combination with the #pragma hdrstop
	      directive.

	      Use the -xpch option to create a precompiled-header file and
	      improve your compilation time. The precompiled-header file is
	      designed to reduce compile time for applications whose source
	      files share a common set of include files containing a large
	      amount of source code. A precompiled header works by collecting
	      information about a sequence of header files from one source
	      file, and then using that information when recompiling that
	      source file, and when compiling other source files that have the
	      same sequence of headers.

	      Creating a Precompiled-Header File Automatically
	      You can let the compiler generate the precompiled-header file
	      for you automatically. Choose between one of the following two
	      ways to do this.	One way is for the compiler to create the pre‐
	      compiled-header file from the first include file it finds in the
	      source file. The other way is for the compiler to select from
	      the set of include files found in the source file starting with
	      the first include file and extending through a well-defined
	      point that determines which include file is the last one. Use
	      one of the following two flags to determine which method the
	      compiler uses to automatically generate a precompiled header:

	      -xpch=auto
		     The contents of the precompiled-header file is based on
		     the longest viable prefix (see the following section for
		     an explanation of how a viable prefix is identified) that
		     the compiler finds in the source file. This flag produces
		     a precompiled header file that consists of the largest
		     possible number of header files.

	      -xpch=autofirst
		     This flag produces a precompiled-header file that con‐
		     tains only the first header found in the source file.

	      Creating the Precompiled-Header File Manually
	      If you decide to create your precompiled-header file manually,
	      you must start by first using -xpch and specify the collect
	      mode.  The compilation command that specifies -xpch=collect must
	      only specify one source file. In the following example, the
	      -xpch option creates a precompiled-header file called
	      header.Cpch based on the source file a.cc:
	      CC -xpch=collect:myheader a.cc

	      A valid precompiled-header filename always has the suffix .Cpch.
	      When you specify pch_filename, you can add the suffix or let the
	      compiler add it for you. For example, if you specify CC
	      -xpch=collect:foo a.cc, the precompiled-header file is called
	      foo.Cpch.

	      How the Compiler Handles an Existing Precompiled-Header File
	      Here are the rules the compiler uses to determine how it handles
	      an existing precompiled-header file.

	      If the compiler finds an existing precompiled-header file, it
	      only uses the file when the following attributes of the file
	      match the same information derived from the current compilation:

		 - The viable prefix matches
		 - The command line options are exactly the same
		 - The current working directory is the same
		 - The source-directory path-name is the same
		 - The compiler and precompiled header version numbers match

	      The following must be true for a viable prefix to qualify as a
	      match:

		 - The #include filenames are all the same
		 - All #define and #undef directives reference the same sym‐
	      bols
		 and the directives appear in the same order
		 - The associated values for #define are identical
		 - Any pragmas that are present appear in their original order

	      Note that #ident/#pragma idents are passed through "as is" in
	      the viable prefix and are unchecked for equality. The string
	      argument is typically different for each source file and, if
	      checked, would inhibit use of the existing precompiled-header
	      file.

	      The compiler version used in the match condition is the same as
	      that returned by the compiler's -V option.

	      Directing the Compiler to Use a Specific Precompiled-Header File
	      You can also direct the compiler to use a specific precompiled
	      header.  Specify -xpch=use:pch_filename to do this.  You can
	      specify any number of source files with the same sequence of
	      include files as the source file used to create the precompiled-
	      header file. For example, your command in use mode could look
	      like this:
	      CC -xpch=use:foo.Cpch foo.cc bar.cc foobar.cc

	      You should only use an existing precompiled-header file if the
	      following is true. If any of the following is not true, you
	      should recreate the precompiled-header file:

	      - The compiler that you are using to access the precompiled-
	      header file is the same as the compiler that created the precom‐
	      piled-header file. A precompiled-header file created by one ver‐
	      sion of the compiler may not be usable by another version of the
	      compiler.

	      - Except for the -xpch option, the compiler options you specify
	      with -xpch=use must match the options that were specified when
	      the precompiled-header file was created.

	      - The set of included headers you specify with -xpch=use is
	      identical to the set of headers that were specified when the
	      precompiled header was created.

	      - The contents of the included headers that you specify with
	      -xpch=use is identical to the contents of the included headers
	      that were specified when the precompiled header was created.

	      - The current directory (that is, the directory in which the
	      compilation is occurring and attempting to use a given precom‐
	      piled-header file) is the same as the directory in which the
	      precompiled-header file was created.

	      - The initial sequence of pre-processing directives, including
	      #include directives, in the file you specified with -xpch=col‐
	      lect are the same as the sequence of pre-processing directives
	      in the files you specify with -xpch=use.

	      The Viable Prefix
	      In order to share a precompiled-header file across multiple
	      source files, those source files must share a common set of
	      include files as their initial sequence of tokens. A token is a
	      keyword, name or punctuation mark. Comments and code that is
	      excluded by #if directives are not recognized by the compiler as
	      tokens. This initial sequence of tokens is known as the viable
	      prefix. In other words, the viable prefix is the top portion of
	      the source file that is common to all source files. The compiler
	      uses this viable prefix as the basis for creating a precompiled-
	      header file and thereby determining which header files from the
	      source are pre-compiled.

	      The viable prefix that the compiler finds during the current
	      compilation must match the viable prefix that it used to create
	      the precompiled-header file. In other words, the viable prefix
	      must be interpreted consistently by the compiler across all the
	      source files that use the same precompiled-header file.

	      The viable prefix consists of any of the following pre-processor
	      directives:

	      #include
	      #if/ifdef/ifndef/else/elif/endif
	      #define/undef
	      #ident
	      #pragma

	      Any of these may reference macros. The #else, #elif, and #endif
	      directives must match within the viable prefix. Comments are
	      ignored.

	      The compiler determines the end point of the viable prefix auto‐
	      matically when you specify -xpch=auto or -xpch=autofirst and is
	      defined as follows. For -xpch=collect or -xpch=use, the viable
	      prefix ends with a #pragma hdrstop.

	      - The first declaration/definition statement
	      - The first #line directive
	      - A #pragma hdrstop directive
	      - After the named include file if you specify -xpch=auto and
	      -xpchstop
	      - The first include file if you specify -xpch=autofirst

	      Note: An end point within a conditional statement generates a
	      warning and disables the automatic creation of a precompiled-
	      header file. Also, if you specify both the #pragma hdrstop and
	      the -xpchstop option, then the compiler uses the earlier of the
	      two stop points to terminate the viable prefix.

	      Within the viable prefix of each file that shares a precompiled-
	      header file, each corresponding #define and #undef directive
	      must reference the same symbol (in the case of #define, each one
	      must reference the same value). Their order of appearance within
	      each viable prefix must be the same as well. Each corresponding
	      pragma must also be the same and appear in the same order across
	      all the files sharing a precompiled header.

	      Screening Header Files for Problems
	      What makes a header file precompilable? A header file is precom‐
	      pilable when it is interpreted consistently across different
	      source files. Specifically, when it contains only complete dec‐
	      larations. That is, a declaration in any one file must stand
	      alone as a valid declaration. Incomplete type declarations, such
	      as struct S;, are valid declarations. The complete type declara‐
	      tion can appear in some other file. Consider these example
	      header files:

	      file a.h
	      struct S {
		   #include "x.h" /* not allowed */
	      };

	      file b.h
	      struct T; // ok, complete declaration
	      struct S {
		   int i;
	      [end of file, continued in another file] /* not allowed */

	      file c.h
	      namespace N {
	      int foo();
	      [end of file, continued in another file] /* not allowed */

	      file d.h
	      extern "C" {
	      int foo();
	      [end of file, continued in another file] /* not allowed */

	      file e.h
	      namespace N {
	      int foo();
	      }	      /* OK, a stand-alone namespace declaration */

	      file f.h
	      namespace N {
	      int bar();
	      }	      /* OK, namespace re-opened, but still stand-alone */

	      A header file that is incorporated into a precompiled-header
	      file must not violate the following. The results of compiling a
	      program that violate any of these constraints is undefined.

	      - The header file must not use __DATE__ and __TIME__.
	      - The header file must not contain #pragma hdrstop.

	      The Precompiled-Header File Cache
	      When the compiler creates a precompiled-header file automati‐
	      cally, the compiler writes it to the SunWS_cache directory. This
	      directory always resides in the location where the object file
	      is created. Updates to the file are preformed under a lock so
	      that it works properly under dmake.

	      If you need to force the compiler to rebuild automatically-gen‐
	      erated precompiled-header files, you can clear the PCH cache
	      directory with the CCadmin tool. See the CCadmin(1) man page for
	      more information.

	      Warnings

	      o Do not specify conflicting -xpch flags on the command line.
	      For example, specifying both -xpch=collect and -xpch=auto, or
	      specifying both -xpch=autofirst with -xpchstop=<include> gener‐
	      ates an error.

	      o If you specify -xpch=autofirst or you specify -xpch=auto with‐
	      out -xpchstop, any declaration, definition, or #line directive
	      that appears prior to the first include file, or appears prior
	      to the include file that is specified with -xpchstop for
	      -xpch=auto, generates a warning and disables the automatic gen‐
	      eration of the precompiled-header file.

	      o A #pragma hdrstop before the first include file under
	      -xpch=autofirst or -xpch=auto disables the automatic generation
	      of the precompiled-header file.

	      Precompiled-Header File Dependencies and make Files
	      The compiler generates dependency information for precompiled-
	      header files when you specify -xpch=collect. You need to create
	      the appropriate rules in your make files to take advantage of
	      these dependencies. Consider this sample make file:

	      .KEEP_STATE:
	      %.o : %.cc shared.Cpch
	      $(CC) -xpch=use:shared -xpchstop=foo.h -c $<
	      default : a.out
	      foo.o + shared.Cpch : foo.cc
	      $(CC) -xpch=collect:shared -xpchstop=foo.h foo.cc -c
	      a.out : foo.o bar.o foobar.o
	      $(CC) foo.o bar.o foobar.o
	      clean :
	      rm -f *.o shared.Cpch .make.state a.out

	      These make rules, along with the dependencies generated by the
	      compiler, force a manually created precompiled-header file to be
	      recreated if any source file you used with -xpch=collect, or any
	      of the headers that are part of the precompiled-header file,
	      have changed. This prevents the use of an out of date precom‐
	      piled-header file.

	      For -xpch=auto or -xpch=autofirst, you do not have to create any
	      additional make rules in your makefiles.

	      See Also: -xpchstop

       -xpchstop=file
	      where file is the last include file to be considered in creating
	      a precompiled-header file.  Using -xpchstop on the command line
	      is equivalent to placing a hdrstop pragma after the first
	      include-directive that references file in each of the source
	      files that you specify with the cc command.

	      Use -xpchstop=<include> with -xpch=auto to create a precompiled-
	      header file that is based on header files up through and includ‐
	      ing <include>. This flag overrides the default -xpch=auto behav‐
	      ior of using all header files contained in the entire viable
	      prefix.

	      See Also: -xpch

       -xpec[={yes|no}]
	      (Oracle Solaris) Generates a Portable Executable Code (PEC)
	      binary.

	      Generates a Portable Executable Code (PEC) binary. This option
	      puts the program intermediate representations in the object file
	      and the binary. This binary may be used later for tuning and
	      troubleshooting.

	      A binary that is built with -xpec is usually five to ten times
	      larger than if it is built without -xpec.

	      If you do not specify -xpec, the compiler sets it to -xpec=no.
	      If you specify -xpec, but do not supply a flag, the compiler
	      sets it to -xpec=yes.

       -xpg   Compiles for profiling with the gprof profiler.

	      The -xpg	option compiles self-profiling code to collect data
	      for profiling with gprof. This option invokes a runtime record‐
	      ing mechanism that produces a gmon.out  file when the program
	      normally terminates.

	      Note: There is no advantage for -xprofile if you specify -xpg.
	      The two do not prepare or use data provided by the other.

	      Profiles are generated by using prof or gprof on 64 bit Oracle
	      Solaris platforms or just gprof on 32 bit Solaris platforms
	      include approximate user CPU times. These times are derived from
	      PC sample data (see pcsample(2)) for routines in the main exe‐
	      cutable and routines in shared libraries specified as linker
	      arguments when the executable is linked.	Other shared libraries
	      (libraries opened after process startup using dlopen(3DL)) are
	      not profiled.

	      On 32 bit Oracle Solaris systems, profiles generated using
	      prof(1) are limited to routines in the executable. 32 bit shared
	      libraries can be profiled by linking the executable with -xpg
	      and using gprof(1).

	      The Solaris 10 software does not include system libraries com‐
	      piled with -p. As a result, profiles collected on Solaris 10
	      platforms do not include call counts for system library rou‐
	      tines.

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

	      Warnings:

	      If you specify -xpg at compile time, you must also specify it at
	      link time. See the C++ User's Guide for a complete list of
	      options that must be specified at both compile time and link
	      time.

	      Note: Binaries compiled with -xpg for gprof profiling should not
	      be used with binopt(1), as they are incompatible and can result
	      in internal errors.

	      Note: On x86 systems, -xpg is incompatible with -xregs=frameptr
	      because the gprof runtime library requires a valid frame pointer
	      to determine the return address of a profiled routine.  Note
	      also that compiling with -fast on x86 systems will invoke
	      -xregs=frameptr. Compile with the following instead:
	       -fast -xregs=no%frameptr -xpg

       -xport64[=v]
	      Use this option to help you port code to a 64-bit environment.
	      Specifically, this option warns against problems such as trunca‐
	      tion of types (including pointers), sign extension, and changes
	      to bit-packing that are common when you port code from a 32-bit
	      architecture to a 64-bit architecture.

	      This option has no effect unless compiling in 64-bit mode with
	      -m64.  (On a 64-bit Linux system, -m64 is the default.)

	      Values:

	      v must be one of the following values.

	      Value	     Meaning

	      no	     Generate no warnings related to the porting of
			     code from a 32 bit environment to a 64 bit envi‐
			     ronment.

	      implicit	     Generate warning only for implicit conversions.
			     Do not generate warnings when an explicit cast is
			     present.

	      full	     Generate all warnings related to the porting of
			     code from a 32 bit environment to a 64 bit envi‐
			     ronment. This includes warnings for truncation of
			     64-bit values, sign-extension to 64 bits under
			     ISO value-preserving rules, and changes to pack‐
			     ing of bitfields.

	      Defaults:

	      If you do not specify -xport64, the default is -xport64=no.  If
	      you specify -xport64, but do not specify a flag, the default is
	      -xport64=full.

	      See Also: -xarch, -m32/-m64

       -xprefetch[=a[,a]]
	      Enable and adjust prefetch instructions on those architectures
	      that support prefetch. You must compile with an optimization
	      level 3 or greater with this option.

	      a must be one of the following values.

	      Value	     Meaning

	      auto	     Enable automatic generation of prefetch instruc‐
			     tions.

	      no%auto	     Disable automatic generation

	      explicit	     Enable explicit prefetch macros

			     Explicit prefetching should only be used under
			     special circumstances that are supported by mea‐
			     surements.

	      no%explicit    Disable explicit prefectch macros.

	      latx:factor    (SPARC) You can only combine this flag with
			     -xprefetch=auto. Adjust the compiler's assumed
			     prefetch-to-load and prefetch-to-store latencies
			     by the specified factor. The factor must be a
			     positive floating-point or integer number.

	      yes	     Obsolete - do not use. Use
			     -xprefetch=auto,explicit instead.

	      no	     Obsolete - do not use. Use
			     -xprefetch=no%auto,no%explicit instead.

	      With -xprefetch, and -xprefetch=auto the compiler is free to
	      insert prefetch instructions into the code it generates. This
	      may result in a performance improvement on architectures that
	      support prefetch.

	      If you are running computationally intensive codes on large mul‐
	      tiprocessors, you might find it advantageous to use
	      -xprefetch=latx:factor. This option instructs the code generator
	      to adjust the default latency time between a prefetch and its
	      associated load or store by the specified factor.

	      The prefetch latency is the hardware delay between the execution
	      of a prefetch instruction and the time the data being prefetched
	      is available in the cache. The compiler assumes a prefetch
	      latency value when determining how far apart to place a prefetch
	      instruction and the load or store instruction that uses the
	      prefetched data.

	      Note -- the assumed latency between a prefetch and a load may
	      not be the same as the assumed latency between a prefetch and a
	      store.

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

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

	      To use the -xprefetch=latx:factor option, start with a factor
	      value near 1.0 and run performance tests against the applica‐
	      tion. 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 per‐
	      formance. 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.

	      Defaults:

	      The default is -xprefetch=auto,explicit.

	      If automatic prefetching is enabled, such as with -xprefetch or
	      -xprefetch=auto, but a latency factor is not specified, then
	      latx:1.0 is assumed.

	      Interactions:

	      This option accumulates instead of overrides.

	      The sun_prefetch.h header file provides the macros for specify‐
	      ing explicit prefetch instructions. The prefetches will be
	      approximately at the place in the executable that corresponds to
	      where the macros appear.

	      To use the explicit prefetch instructions, you must be on the
	      correct architecture, include sun_prefetch.h, and either exclude
	      -xprefetch from the compiler command or use -xprefetch,
	      -xprefetch=auto,explict, -xprefetch=explicit.

	      If you call the macros and include the sun_prefetch.h header
	      file, but pass -xprefetch=no%explicit, the explicit prefetches
	      will not appear in your executable.

	      The -xchip setting effects the determination of the assumed
	      latencies and therefore the result of a latx:factor setting.

	      The latx:factor suboption is valid only when automatic prefetch‐
	      ing is enabled. That is, latx:factor is ignored unless it is
	      used in conjunction with yes or auto.

	      Warnings:

	      Because the compiler tunes the prefetch mechanism for optimal
	      performance across a wide range of machines and applications,
	      you should only use the latx:factor suboption when the perfor‐
	      mance tests indicate there is a clear benefit. The assumed
	      prefetch latencies may change from release to release. There‐
	      fore, retesting the effect of the latency factor on performance
	      whenever switching to a different release is highly recommended.

       -xprefetch_auto_type=[a]
	      Where a is [no%]indirect_array_access.

	      Use this option to determine whether or not the compiler gener‐
	      ates indirect prefetches for the loops indicated by the option
	      -xprefetch_level in the same fashion the prefetches for direct
	      memory accesses are generated.

	      The prefix no% disables the option.

	      If you do not specify a setting for -xprefetch_auto_type, the
	      compiler sets it to -xprefetch_auto_type=no%indi‐
	      rect_array_access.

	      Options such as -xalias_level can affect the aggressiveness of
	      computing the indirect prefetch candidates and therefore the
	      aggressiveness of the automatic indirect prefetch insertion due
	      to better memory alias disambiguation information.

       -xprefetch_level=l
	      Controls the automatic insertion of prefetch instructions as
	      determined with -xprefetch=auto. The default is
	      -xprefetch_level=1 when you specify -xprefetch=auto.

	      l must be 1, 2, or 3.

	      Prefetch levels 2 and 3 may not be effective on older SPARC and
	      x86 platforms.

	      -xprefetch_level=1 enables automatic generation of prefetch
	      instructions.  -xprefetch_level=2 targets additional loops,
	      beyond those targeted at level 1 and -xprefetch=3 targets addi‐
	      tional loops beyond those targeted at level 2.

	      You must compile with optimization level 3 or greater and gener‐
	      ate code for a platform that supports prefetch.

       -xprofile=p
	      Collects data for a profile or use a profile to optimize.

	      p must be collect[:profdir], use[:profdir], or tcov[:profdir]

	      This option causes execution frequency data to be collected and
	      saved during execution, then the data can be used in subsequent
	      runs to improve performance. Profile collection is safe for mul‐
	      tithreaded applications.	That is, profiling a program that does
	      its own multitasking ( -mt ) produces accurate results. This
	      option is only valid when you specify -xO2 or greater level of
	      optimization.

	      If compilation and linking are performed in separate steps, the
	      same -xprofile option must appear on the compile as well as the
	      link step.  See the C++ User's Guide for a complete list of
	      options that must be specified at both compile time and link
	      time.

	      collect[:profdir]
		   Collects and saves execution frequency for later use by the
		   optimizer with -xprofile=use. The compiler generates code
		   to measure statement execution-frequency.

		   -xMerge -ztext -xprofile=collect should not be used
		   together.   While -xMerge forces statically initialized
		   data into read-only storage, -ztext prohibits position-
		   dependent symbol relocations in read-only storage, and
		   -xprofile=collect generates statically initialized, posi‐
		   tion-dependent symbol relocations in writable storage.

		   The profile directory name profdir, if specified, is the
		   pathname of the directory where profile data are to be
		   stored when a program or shared library containing the pro‐
		   filed object code is executed.  If the pathname is not
		   absolute, it is interpreted relative to the current working
		   directory when the program is compiled with the option
		   -xprofile=use:profdir.

		   If no profile directory name is specified with -xpro‐
		   file=collect:prof_dir or -xprofile=tcov:prof_dir, profile
		   data are stored at run time in a directory named pro‐
		   gram.profile where program is the basename of the profiled
		   process's main program.  In this case, the environment
		   variables SUN_PROFDATA and SUN_PROFDATA_DIR can be used to
		   control where the profile data are stored at run time.  If
		   set, the profile data are written to the directory given by
		   $SUN_PROFDATA_DIR/$SUN_PROFDATA.

		   If a profile directory name is specified at compilation
		   time, SUN_PROFDATA_DIR and SUN_PROFDATA have no effect at
		   run time.  These environment variables similarly control
		   the path and names of the profile data files written by
		   tcov, as described in the tcov(1) man page.

		   If these environment variables are not set, the profile
		   data is written to the directory profdir.profile in the
		   current directory, where profdir is the name of the exe‐
		   cutable or the name specified in the -xprofile=col‐
		   lect:profdir flag. -xprofile does not append .profile to
		   profdir if profdir already ends in .profile. If you run the
		   program several times, the execution frequency data accumu‐
		   lates in the profdir.profile directory; that is, output
		   from prior executions is not lost.

		   Example[1]:	to collect and use profile data in the direc‐
		   tory myprof.profile located in the same directory where the
		   program is built:

		   CC -xprofile=collect:myprof.profile -xO5 prog.cc -o prog
		     ./prog
		   CC -xprofile=use:myprof.profile -xO5 prog.cc -o prog

		   Example[2]:	to collect profile data in the directory
		   /bench/myprof.profile and later use the collected profile
		   data in a feedback compilation at optimization level -xO5:

		   CC -xprofile=collect:/bench/myprof.profile -xO5 prog.cc -o prog
		     ...run prog from multiple locations...
		   CC -xprofile=use:/bench/myprof.profile -xO5 prog.cc -o prog

		   If you are compiling and linking in separate steps, make
		   sure that any object files compiled with -xprofile=collect
		   are also linked with -xprofile=collect. For a complete list
		   of compiler options that must be specified at both compile
		   time and at link time, see the C User's Guide.

		   See also the ENVIRONMENT section of this man page below for
		   descriptions of environment variables that control asyn‐
		   chronous profile collections.

	      use[:profdir]
		   Uses execution frequency data collected from code compiled
		   with -xprofile=collect[:profdir] or -xpro‐
		   file=tcov[:profdir] to optimize for the work performed when
		   the profiled code was executed.  profdir is the pathname of
		   a directory containing profile data collected by running a
		   program that was compiled with -xprofile=collect[:profdir]
		   or -xprofile=tcov[:profdir].

		   To generate data that can be used by both tcov and -xpro‐
		   file=use[:profdir], the same profile directory must be
		   specified at compilation time, using the option -xpro‐
		   file=tcov[:profdir].	 To minimize confusion, specify
		   profdir as an absolute pathname.

		   The profdir is optional. If profdir is not specified, the
		   name of the executible binary is used. a.out is used if -o
		   is not specified. The compiler looks for profdir.pro‐
		   file/feedback, or a.out.profile/feedback without profdir
		   specified. For example:

		      CC -xprofile=collect -o myexe prog.c
		      CC -xprofile=use:myexe -xO5 -o myexe prog.c

		   The program is optimized by using the execution frequency
		   data previously generated and saved in the feedback files
		   written by a previous execution of the program compiled
		   with -xprofile=collect.

		   Except for the -xprofile option, the source files and other
		   compiler options must be exactly the same as those used for
		   the compilation that created the compiled program which in
		   turn generated the feedback file.  The same version of the
		   compiler must be used for both the collect build and the
		   use build as well.

		   If compiled with -xprofile=collect:profdir, the same pro‐
		   file directory name profdir must be used in the optimizing
		   compilation: -xprofile=use:profdir.

		   See also -xprofile_ircache for speeding up compilation
		   between collect and use phases.

	      tcov[:profdir]
		   Instrument object files for basic block coverage analysis
		   using tcov(1).

		   If the optional :profdir argument is specified, the com‐
		   piler will create a profile directory at the specified
		   location.  The data stored in the profile directory can be
		   used either by tcov(1) or by the compiler with -xpro‐
		   file=use:profdir .

		   If the optional :profdir argument is omitted, a profile
		   directory will be created when the profiled program is exe‐
		   cuted.  The data stored in the profile directory can only
		   be used by tcov(1).	The location of the profile directory
		   can be controlled using environment variables SUN_PROFDATA
		   and SUN_PROFDATA_DIR.  See ENVIRONMENT below.

		   If the location specified by :profdir is not an absolute
		   pathname, it is interpreted relative to the current working
		   directory when the program is compiled.

		   If :profdir is specified for any object file, the same
		   location must be specified for all object files in the same
		   program.  The directory whose location is specified by
		   :profdir must be accessible from all machines where the
		   profiled program is to be executed.	The profile directory
		   should not be deleted until its contents are no longer
		   needed, because data stored there by the compiler cannot be
		   restored except by recompilation.

		   Example 1: if object files for one or more programs are
		   compiled with -xprofile=tcov:/test/profdata, a directory
		   named /test/profdata.profile will be created by the com‐
		   piler and used to store data describing the profiled object
		   files.  The same directory will also be used at execution
		   time to store execution data associated with the profiled
		   object files.

		   Example 2: if a program named "myprog" is compiled with
		   -xprofile=tcov and executed in the directory /home/joe, the
		   directory /home/joe/myprog.profile will be created at run
		   time and used to store runtime profile data.

       -xprofile_ircache[=path]
	      Use -xprofile_ircache[=path] with -xprofile=collect|use to
	      improve compilation time during the use phase by reusing compi‐
	      lation data saved from the collect phase.

	      With large programs, compilation time in the use phase can
	      improve significantly because the intermediate data is saved.
	      Note that the saved data could increase disk space requirements
	      considerably.

	      When you use -xprofile_ircache[=path], path overrides the loca‐
	      tion where the cached files are saved. By default, these files
	      are saved in the same directory as the object file. Specifying a
	      path is useful when the collect and use phases happen in two
	      different directories.

	      Here's a typical sequence of commands:

	      example% CC -xO5 -xprofile=collect -xprofile_ircache t1.cc t2.cc
	      example% a.out	// run collects feedback data
	      example% CC -xO5 -xprofile=use -xprofile_ircache t1.cc t2.cc

       -xprofile_pathmap=collect_prefix:use_prefix
	      Use the -xprofile_pathmap option when you are also specifying
	      the -xprofile=use command. Use -xprofile_pathmap when both of
	      the following are true and the compiler is unable to find pro‐
	      file data for an object file that is compiled with -xpro‐
	      file=use.

	      o	 You are compiling the object file with -xprofile=use
		 in a directory that is different from the directory in which
		 the object file was previously compiled with -xprofile=col‐
		 lect.

	      o	 Your object files share a common basename in the
		 profile but are distinguished from each other by their loca‐
		 tion in different directories.

	      The collect-prefix is the prefix of the UNIX pathname of a
	      directory tree in which object files were compiled using -xpro‐
	      file=collect.

	      The use-prefix is the prefix of the UNIX pathname of a directory
	      tree in which object files are to be compiled using -xpro‐
	      file=use.

	      If you specify multiple instances of -xprofile_pathmap, the com‐
	      piler processes them in the order of their occurrence.  Each
	      use-prefix specified by an instance of -xprofile_pathmap is com‐
	      pared with the object file pathname until either a matching use-
	      prefix is identified or the last specified use-prefix is found
	      not to match the object file pathname.

       -xreduction
	      Analyzes loops for reduction in automatic parallelization. This
	      option is valid only if -xautopar is also specified. Otherwise
	      the compiler issues a warning.

	      When a reduction recognition is enabled, the compiler paral‐
	      lelizes reductions such as dot products, maximum and minimum
	      finding. These reductions yield different roundoffs from those
	      obtained by unparallelized code.

       -xregs=r[,r...]
	      Specify the usage of registers for the generated code.

	      r is a comma-separated list of one or more of the following sub‐
	      options: appl, float, frameptr.

	      Prefixing a suboption with no% disables that suboption.

	      Example: -xregs=appl,no%float

	      Note that -xregs suboptions are restricted to specific hardware
	      platforms.

	      appl (SPARC)
		       Allow the compiler to generate code using the applica‐
		       tion registers as scratch registers.  The application
		       registers are:

		       g2, g3, g4 (on 32-bit platforms)
		       g2, g3 (on 64-bit platforms)

		       It is strongly recommended that all system software and
		       libraries be compiled using -xregs=no%appl. System
		       software (including shared libraries) must preserve
		       these registers' values for the application. Their use
		       is intended to be controlled by the compilation system
		       and must be consistent throughout the application.

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

		       For more information on SPARC instruction sets, see
		       -xarch.

	      float (SPARC)
		       Allow the compiler to generate code by using the float‐
		       ing-point registers as scratch registers for integer
		       values. Use of floating-point values may use these reg‐
		       isters regardless of this option. To generate binary
		       code free of all references to floating point regis‐
		       ters, use -xregs=no%float and make sure your source
		       code does not in any way use floating point types.

	      frameptr (x86)
		       Allow the compiler to use the frame-pointer register
		       (%ebp on IA32, %rbp on x86 64-bit platforms) as a gen‐
		       eral-purpose register.

		       The default is -xregs=no%frameptr.

		       The C++ compiler ignores -xregs=frameptr unless excep‐
		       tions are  also disabled with -features=no%except.
		       Note also that -xregs=frameptr is part of -fast, but is
		       ignored by the C++ compiler unless -features=no%except
		       is also specified.

		       With -xregs=frameptr the compiler is free to use the
		       frame-pointer register to improve program performance.
		       However, some features of the debugger and performance
		       measurement tools may be limited. Stack tracing, debug‐
		       gers, and performance analyzers cannot report on func‐
		       tions compiled with -xregs=frameptr.

		       Also, C++ calls to Posix pthread_cancel() will fail
		       trying to find cleanup handlers.

		       Mixed C, Fortran, and C++ code should not be compiled
		       with -xregs=frameptr if a C++ function, called directly
		       or indirectly from a C or Fortran function, can throw
		       an exception.  If compiling such mixed source code with
		       -fast, add -xregs=no%frameptr after the -fast option on
		       the command line.

		       With more available registers on 64-bit platforms, com‐
		       piling with -xregs=frameptr has a better chance of
		       improving 32-bit code performance than 64-bit code.

		       Note: -xregs=frameptr is ignored and a warning is
		       issued by the compiler if you also specify -xpg.	 Also,
		       -xkeepframe overrides -xregs=frameptr.

	      The SPARC default is -xregs=appl,float.
	      The x86 default is -xregs=no%frameptr.
	      -xregs=frameptr is included in the expansion of -fast on x86.

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

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

       -xrestrict[=f]
	      Treats pointer-valued function parameters as restricted point‐
	      ers. f is %all, %none, %source or a comma-separated list of one
	      or more function names. This command-line option can be used on
	      its own, but is best used with optimization of -xO3 or greater.

	      Specifying -xrestrict=%source means that all functions defined
	      in the main source file, but not any header files or template
	      definition files, are restricted.

	      If you specify a function list with this option, pointer parame‐
	      ters in the specified functions are treated as restricted; if
	      you specify -xrestrict=%all, all pointer parameters in the
	      entire C++ file are treated as restricted.

	      The default is %none. Specifying -xrestrict is equivalent to
	      specifying -xrestrict=%source.

	      See Also: -xprefetch_auto_type, 'Restricted Pointers' in the C++
	      User's Guide

       -xs    Allows debugging by dbx without object files.

	      This option causes all the debug information to be copied into
	      the executable.  This has little impact on dbx performance or
	      the run-time performance of the program, but it does take more
	      disk space.

       -xsafe=mem
	      (SPARC platform) Allow the compiler to assume that no memory
	      protection violations occur.

	      This option allows the compiler to use the non-faulting load
	      instruction in the SPARC V9 architecture.

	      Warnings:

	      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.

	      Interactions:

	      This option takes effect only when used with optimization level
	      -xO5 and one of the following -xarch values: sparc, sparcvis,
	      sparcvis2, or sparcvis3 for both -m32 and -m64.

       -xspace
	      Does not allow optimizations that increase code size.

       -xtarget=t
	      Specifies the target system for instruction set and optimiza‐
	      tion.

	      t must be one of the folowing: native, native64, generic,
	      generic64 or system-name.

	      This option is a macro. Each specific value for -xtarget expands
	      into a specific set of values for the -xarch, -xchip, and
	      -xcache options. See the -dryrun explanation for details on how
	      to see the expansion of macro options such as -xtarget.

	      Note: The expansion of -xtarget for a specific host platform
	      might not expand to the same -xarch, -xchip, or -xcache settings
	      as -xtarget=native when compiling on that platform.

	      -xtarget=native is equivalent to -m32, -xarch=native,
	      -xchip=native, -xcache=native, to give best performance on the
	      32-bit host system.

	      -xtarget=native64 is equivalent to  -m64, -xarch=native64,
	      -xchip=native64, -xcache=native to give best performance on the
	      64-bit host system.

	      -xtarget=generic is equivalent to	 -m32, -xarch=generic,
	      -xchip=generic, -xcache=generic, to give the best performance
	      for generic architecture, chip and cache on most 32-bit systems.

	      -xtarget=generic64 is equivalent to  -m64, -xarch=generic64,
	      -xchip=generic64, -xcache=generic, to give the best performance
	      for generic architecture, chip and cache on most 64-bit systems.

	      On SPARC platforms:

	      Compiling for 64-bit Oracle Solaris software on 64-bit SPARC
	      architctures is indicated by the -m64 option. If you specify
	      -xtarget with a flag other than native64 or generic64, you must
	      also specify the -m64 option as follows:
	      -xtarget=ultra4 ... -m64
	      otherwise the compiler uses a 32-bit memory model.

	      Value	Meaning

	      platform-name
			Gets the best performance for the specified platform.
			The following are valid SPARC values for platform
			name:
			ultra, ultra2, ultra2i, ultra1/140, ultra1/170,
			ultra1/200, ultra2/1170, ultra2/1200, ultra2/1300,
			ultra2/2170, ultra2/2200, ultra2/2300, ultra2e,
			ultra2i, ultra3, ultra3cu, ultra3i, ultra4,
			ultra4plus, ultraT1, ultraT2, ultraT2plus, T3, T4,
			sparc64vi, sparc64vii, sparc64viiplus.

       On x86 platforms:

       Compiling for 64-bit Oracle Solaris software on 64-bit x86 64-bit plat‐
       forms is indicated by the -m64 option. If you specify -xtarget with a
       flag other than native64 or generic64, you must also specify the -m64
       option as follows:
       -xtarget=opteron ... -m64
       otherwise the compiler uses a 32-bit memory model.

	      Value	Meaning

	      processor_name
			Generate code for best performance on the following
			x86 processors:
			nehalem, barcelona, opteron, pentium, pentium_pro,
			pentium3, pentium4, penryn,
			sandybridge, westmere, woodcrest

	      For more information about platform and processor names, see the
	      C++ User's Guide.

	      The actual expansion of an -xtarget suboption might change and
	      improve with each compiler release.  Compile with -dryrun to see
	      the actual expansion as follows:
	      CC -dryrun -xtarget=ultra4 |& grep ###
	      ###     command line files and options (expanded):
	      ### -dryrun -xchip=ultra4 -xcache=64/32/4:8192/128/2 -xarch=sparcvis2

       -xthreadvar[=o]
	      Works in conjunction with the __thread declaration specifier to
	      take advantage of the compiler's thread-local storage facility.
	      After you declare the thread variables with the __thread speci‐
	      fier, use -xthreadvar to enable the use of thread-local storage
	      with position dependent code (non-PIC code) in dynamic (shared)
	      libraries. For more information on how to use __thread, see the
	      C++ User's Guide.

	      Values

	      o can be one of the following:

	      Value	     Meaning

	      [no%]dynamic   Compile variables for dynamic loading. Prefix no%
			     disables the option. Access to thread variables
			     is significantly faster when -xthread‐
			     var=no%dynamic but you cannot use the object file
			     within a dynamic library. That is, you can only
			     use the object file in an executable file.

	      Defaults

	      If you do not specify -xthreadvar, the default used by the com‐
	      piler depends upon whether or not position-independent code is
	      enabled. If position-independent code is enabled, the option is
	      set to -xthreadvar=dynamic. If position- independent code is
	      disabled, the option is set to -xthreadvar=no%dynamic.

	      If you specify -xthreadvar but do not specify any arguments, the
	      option is set to -xthreadvar=dynamic.

	      Interactions

	      Objects that use __thread must be compiled and linked with -mt.

	      Warnings

	      If there is non-position-independent code within a dynamic
	      library, you must specify -xthreadvar.

	      The linker cannot support the thread-variable equivalent of non-
	      PIC code in dynamic libraries. Non-PIC thread variables are sig‐
	      nificantly faster, and hence should be the default for executa‐
	      bles.

	      See Also

	      -xcode, -KPIC, -Kpic

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

       -xtrigraphs[={yes|no}]
	      Enables or disables recognition of trigraph sequences as defined
	      by the ISO/ANSI C standard.

	      -xtrigraphs=yes enables recognition of trigraph sequences in the
	      source code.

	      -xtrigraphs=no disables recognition of trigraph sequences in the
	      source code.

	      Defaults:

	      If the -xtrigraphs option is not specified, -xtrigraphs=yes is
	      assumed.

	      If only -xtrigraphs is specified -xtrigraphs=yes is assumed.

       -xunroll=n
	      Enables unrolling of loops where possible.

	      This option specifies whether or not the compiler optimizes
	      (unrolls) loops.

	      When n is 1, it is a suggestion to the compiler not to unroll
	      loops.

	      When n is an integer greater than 1, -xunroll=n causes the com‐
	      piler to unroll loops n times.

       -xustr={ascii_utf16_ushort|no}
	      This option enables compiler recognition of UTF-16 character
	      strings and literals. Since such strings and literals are not
	      yet part of any standard, this option enables recognition of
	      non-standard C++. Specify -xustr=ascii_utf16_ushort if you need
	      to support an internationalized application that uses ISO10646
	      UTF-16 characters.  In other words, use this option if your code
	      contains string characters that you want the compiler to convert
	      to UTF-16 characters in the object file.	Without this option,
	      the compiler neither produces nor recognizes sixteen-bit charac‐
	      ters. This option enables recognition of the U"ASCII_string"
	      string literals as an array of unsigned short int. This option
	      also enables recognition of character literals. For example:
	      unsigned short character = U'Z';

	      You can turn off compiler recognition of U"ASCII_string" string
	      literals by specifying -xustr=no. The rightmost instance of this
	      option on the command line overrides all previous instances.

	      The default is -xustr=no. If you specify -xustr without an argu‐
	      ment, the compiler won't accept it and instead issues a warning.
	      The default can change if the C or C++ standards define a mean‐
	      ing for the syntax.

	      It is not an error to specify -xustr=ascii_ustf16_ushort without
	      also specifying a U"ASCII_string" string literal.

	      Not all files have to be compiled with this option.

	      The following example shows a string literal in quotes that is
	      prepended by U.  It also shows a command line that specifies
	      -xustr.

	      example% cat file.cc
	      const unsigned short *foo = U"foo";
	      const unsigned short bar[] = U"bar";
	      const unsigned short *fun() { return foo; }
	      example% CC -xustr=ascii_utf16_ushort file.cc -c

	      An 8-bit character literal can be prepended with U to form a
	      16-bit UTF-16 character of type unsigned short. Examples:

	      const unsigned short x = U'x';
	      const unsigned short y = U'\x79';

       -xvector[=a]
	      Enables automatic generation of calls to the vector library
	      and/or the generation of the SIMD (Single Instruction Multiple
	      Data) instructions on x86 processors that support SIMD.  You
	      must use default rounding mode by specifying -fround=nearest
	      when you use this option.

	      The -xvector option requires optimization level -O3 or greater.
	      Compilation will not proceed if the optimization level is
	      unspecified or lower than -O3, and a message is issued.

	      a can have the following values (prefix no% disables a subop‐
	      tion):

	      [no%]lib
		   (SOLARIS Only) Enables the compiler to transform math
		   library calls within loops into single calls to the equiva‐
		   lent vector math routines when such transformations are
		   possible. This could result in a performance improvement
		   for loops with large loop counts.  Use no%lib to disable
		   this option.

	      [no%]simd
		   (x86 Only) Directs the compiler to use the native x86 SSE
		   SIMD instructions to improve performance of certain loops.
		   Streaming extensions are used on x86 by default at opti‐
		   mization level 3 and above where beneficial. Use no%simd to
		   disable this option.

		   The compiler will use SIMD only if streaming extensions
		   exist in the target architecture; that is, if target ISA is
		   at least SSE2. For example, you can specify -xtarget=wood‐
		   crest, -xarch=generic64, -xarch=sse2, -xarch=sse3, or -fast
		   on a modern platform to use it. If the target ISA has no
		   streaming extensions, the suboption will have no effect.

	      %none
		   Disable this option entirely.

	      yes  This option is deprecated, specify -xvector=lib instead.

	      no   This option is deprecated, specify -xvector=%none instead.

	      The default is -xvector=simd on x86 and -xvector=%none on SPARC
	      platforms.  If you specify -xvector without a suboption, the
	      compiler assumes -xvector=simd,lib on x86 Oracle Solaris, -xvec‐
	      tor=lib on SPARC Oracle Solaris, and -xvector=simd on Linux
	      platforms.

	      This option overrides previous instances so -xvector=%none
	      undoes a previously specified  -xvector=lib.

	      The compiler includes the libmvec	 libraries in the load step.

	      If you compile and link with separate commands, be sure to use
	      the same -xvector option in the linking CC command.

       -xvis[={yes|no}]
	      (SPARC) Compile with -xvis=yes when including the <vis.h> header
	      to generate VIS instructions, or when using assembler inline
	      code (.il) that uses VIS instructions.  The default is -xvis=no.
	      Specifying -xvis is equivalent to specifying -xvis=yes.

	      The VIS instruction set is an extension to the SPARC V9 instruc‐
	      tion set.	 Even though the UltraSPARC processors are 64-bit,
	      there are many cases, especially in multimedia applications,
	      when the data are limited to eight or 16 bits in size. The VIS
	      instructions can process four 16-bit data with one instruction
	      so they greatly improve the performance of applications that
	      handle new media such as imaging, linear algebra, signal pro‐
	      cessing, audio, video and networking.

       -xvpara
	      Issues warnings about potential parallel-programming related
	      problems that may cause incorrect results when using OpenMP. Use
	      with -xopenmp and OpenMP API directives.

	      The compiler issues warnings when it detects the following situ‐
	      ations:

	      o Loops are parallelized using MP directives with data dependen‐
	      cies between different loop iterations

	      o OpenMP data-sharing attributes-clauses are problematic. For
	      example, declaring a variable "shared" whose accesses in an
	      OpenMP parallel region may create a data race, or declaring a
	      variable "private" whose value in a parallel region is used
	      after the parallel region.

	      No warnings appear if all parallelization directives are pro‐
	      cessed without problems.

	      Example:
	      CC -xopenmp -xvpara any.cc

	      Note: Oracle Solaris Studio compilers support OpenMP 3.1 API
	      parallelization.	Consequently, the MP pragmas are deprecated.
	      See the OpenMP API User's Guide for information on migrating to
	      the OpenMP API.

       -xwe   Converts all warnings to errors by returning non-zero exit sta‐
	      tus.

       -Yc,path
	      Specifies a new path for the location of component c.

	      If the location of a component is specified, then the new path
	      name for the component is path/component_name. This option is
	      passed to ld.

	      Values

	      c must be one of the following values.

	      p	  Changes the default directory for cpp.

	      0	  Changes the default directory for ccfe.

	      a	  Changes the default directory for fbe.

	      2	  Changes the default directory for iropt.

	      c	  Changes the default directory for cg (SPARC).

	      O	  Changes the default directory for ipo.

	      k	  Changes the default directory for CClink.

	      l	  Changes the default directory for ld.

	      f	  Changes the default directory for c++filt.

	      m	  Changes the default directory for mcs.

	      u	  Changes the default directory for ube (x86).

	      h	  Changes the default directory for ir2hf (x86).

	      A	  Specifies a directory to search for all compiler components.
		  If a component is not found in path, the search reverts to
		  the directory where the compiler is installed.

	      P	  Adds path to the default library search path. This path will
		  be searched before the default library search paths.

	      S	  Changes the default directory for startup object files

	      Interactions

	      You can have multiple -Y options on a command line. If more than
	      one -Y option is applied to any one component, then the last
	      occurrence holds.

	      See also

	      Oracle Solaris Linker and Libraries Guide

       -z arg Link editor option.

	      -xMerge -ztext -xprofile=collect should not be used together.
	      While -xMerge forces statically initialized data into read-only
	      storage, -ztext prohibits position-dependent symbol relocations
	      in read-only storage, and -xprofile=collect generates statically
	      initialized, position-dependent symbol relocations in writable
	      storage.

	      For more information see the ld(1) man page and the Oracle
	      Solaris Linker and Libraries Guide.

   PRAGMAS
       The following .nf #pragma does_not_read_global_data #pragma
       does_not_write_global_data #pragma no_side_effect

       SPARC Only:

       Refer to the C++ User's Guide for more information on these pragmas.

ENVIRONMENT
       SUN_PROFDATA=profdir
		 If set, store profile data collected from a program compiled
		 with -xprofile=collect in a directory named profdir in the
		 current working directory at the time that the program is
		 executed.  If the optional argument :profdir was specified in
		 -xprofile=collect[:profdir] at compilation time,  SUN_PROF‐
		 DATA as no effect.

		 SUN_PROFDATA_DIR=dirname If set, store profile data collected
		 from a program compiled with -xprofile=collect in a directory
		 whose UNIX dirname is dirname.	 If dirname is not absolute,
		 it is interpreted relative to the current working directory
		 at the time that the program is executed.  If the optional
		 argument :profdir was specified in -xprofile=col‐
		 lect[:profdir] at compilation time, SUN_PROFDATA_DIR has no
		 effect.

       SUN_PROFDATA_REPLACE={objfile,program,all}
		 SUN_PROFDATA_REPLACE indicates the scope of profile data to
		 be reset when a changed version of an object file is detected
		 at runtime.  Use SUN_PROFDATA_REPLACE to ensure that profile
		 data are consistent with the profiled program within the
		 specified unit of program scope.

		 The values of SUN_PROFDATA_REPLACE and their meanings are as
		 follows:

		 objfile
		      reset profile data of changed object file

		 program
		      reset profile data of all object files in program con‐
		      taining changed object file

		 all  reset entire contents of profile directory if any object
		      file has changed

		 The default setting of SUN_PROFDATA_REPLACE is SUN_PROF‐
		 DATA_REPLACE=objfile .

		 Example:
		 % setenv SUN_PROFDATA_REPLACE program (csh)
		 $ export SUN_PROFDATA_REPLACE=program (ksh)

		 With this setting, when a program containing a changed object
		 file is executed, all object files in the program will have
		 their profile data reset.  Relevant options include -xOn and
		 -xipo=n.

       SUN_PROFDATA_ASYNC_INTERVAL=async_interval
		 Set this environment variable to enable asynchronous profile
		 collection.  In asynchronous profile collection, profile data
		 are collected from a running process at regular intervals
		 whose duration is specified in units of seconds.

		 SUN_PROFDATA_ASYNC_INTERVAL has no effect unless one of the
		 environment variables LD_AUDIT, LD_AUDIT_32, or LD_AUDIT_64
		 is set to /usr/lib/{,64}/libxprof_audit.so.1.

		 Asynchronous profile collection requires an MT-safe, mmap
		 based memory allocator, such as libumem(3) with mmap-based
		 allocation specified by setting UMEM_OPTIONS to backend=mmap.

		 Example: to enable asynchronous profile collection from a 64
		 bit process at 1 minute intervals,specify the following envi‐
		 ronment variables:

		 $ env LD_AUDIT_64=/usr/lib/64/libxprof_audit.so.1 \
		 SUN_PROFDATA_ASYNC_INTERVAL=60 UMEM_OPTIONS=backend=mmap \
		 64-bit-program [program-args]

       SUN_PROFDATA_ASYNC_VERBOSE=verbose
		 If set nonzero, enables verbose messages from asynchronous
		 collector to stderr.  SUN_PROFDATA_ASYNC_VERBOSE has no
		 effect unless asynchronous profile collection is enabled.

FILES
       file.a		   Static library
       file.C		   Input file
       file.cc		   Input file
       file.c++		   Input file
       file.cpp		   Input file
       file.cxx		   Input file
       file.o		   Object file
       file.so		   Dynamic (shared) library
       a.out		   Linked output
       xprof_fini.o	   Initialization and finalization handlers for pro‐
			   grams compiled with -xprofile=collect

SEE ALSO
       analyzer(1), as(1), c++filt(1), cc(1), csh(1), dbx(1), gprof(1), ld(1),
       more(1), nm(1), prof(1), tcov(1)

       C++ User's Guide,
       C++ Migration Guide,
       The C++ Programming Language, Third Edition, Bjarne Stroustrup, Addi‐
       son-Wesley 1997
       The C Programming Language, B. W. Kernighan and D. M. Ritchie, Pren‐
       tice-Hall 1988
       Oracle Solaris Linker and Libraries Guide
       International Standard (ISO/IEC FDIS 14882), Programming Languages —
       C++

NOTES
       errno

       Certain floating-point math library routines return error status in the
       errno variable (defined in errno.h).  With compiler options -fast,
       -xbuiltin, -xlibmieee, -xlibmil, -xlibmopt the compiler is free to
       replace calls to floating point functions with equivalent optimized
       code that does not set the errno variable.  Further, -fast also defines
       the macro __MATHERR_ERRNO_DONTCARE,  which allows the compiler to
       assume that math functions need not set errno.  As a result, user code
       that relies on the value of errno or a floating-point exception being
       raised after a floating point function call could produce inconsistent
       results.

       One way around this problem is to avoid compiling such codes with these
       options, such as -fast.

       However, if -fast optimization is required and the code depends on the
       value of errno being set properly or an appropriate floating-point
       exception being raised after floating-point library calls, you should
       compile with the options

	 -xbuiltin=none -U__MATHERR_ERRNO_DONTCARE \
	 -xnolibmopt  -xnolibmil

       following -fast on the command line to inhibit the compiler from opti‐
       mizing out such library calls and to to ensure that calls to math func‐
       tions set errno as documented.

4th Berkeley Distribution	 December 2011				 CC(1)
[top]

List of man pages available for SunOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net