cc(1) 맨 페이지 - 윈디하나의 솔라나라

개요

섹션
맨페이지이름
검색(S)

cc

Name
     cc - C compiler

Synopsis
     cc   [-#] [-###] [-Aname[(tokens)]] [-ansi]
          [-B[static|dy- namic]] [-C] [-c] [-D] [-d[y|n]] [-dalign]
          [-E] [-errfmt[=[no%]error]] [-errhdr[=h]]
          [-erroff[=t[,t...]]] [-errshort[=i]] [-errtags=a]
          [-errwarn[=xtarget[,t...]]] [-fast] [-fcommon] [-fd] [-features=[a]] [-fexceptions] [-fno-exceptions]
          [-flags] [-flteval[={any|2}]] [-fma[={none|fused}]]
          [-fnonstd] [-fno-strict-aliasing] [-fno-common] [-fnoshort-enums] [-fns=[no|yes]] [-fopenmp] [-fprecision=p]
          [-fround=r] [-fshort-enums] [-fsimple[=n]] [-fsingle] [-fstore] [-fstrict-aliasing]
          [-ftrap[=t[,t...]]] [-fvisibility=v] [-G] [-g] [-g[n]] [-gz[=cmp-type]] [-H] [-hname]
          [-I[-|dir]] [-i] [-include] [-KPIC] [-Kpic] [-keeptmp]
          [-Ldir] [-lname] [-library=sunperf] [-m32|-m64] [-mc]
          [-misalign] [-misalign2] [-mr[,string]] [-mt] [-native]
          [-nofstore][-O] [-On] [-ofilename] [-P] [-p]
          [-pedantic{[yes=|no]}] [-preserve_argvalues[=int|none]]
          [-Qoption phase [,option...]] [-Q[y|n]] [-qp]
          [-Rdir[:dir...]] [-S] [-s] [-shared] [-staticlib=[no%]sunperf]
          [-std=value] [-temp=path] [-traceback[=list]] [-Uname]
          [-V] [-v] [-Wc,arg] [-w] [-X[c|a|t|s]] [-Xlinker arg]
          [-xaddr32[={yes|no}]] [-xalias_level[=a]]
          [-xannotate] [-xarch=a] [-xatomic=a]
          [-xautopar] [-xbuiltin[=a]] [-xCC]
          [-xc99[=o]] [-xcache=c] [-xchar[=o]]
          [-xchar_byte_order[=o]] [-xcheck=n] [-xchip=c]
          [-xcode=v] [-xcsi] [-xcompress={[no%]debug}] [-xcompress_format=cmp-type] [-xdebugformat=dwarf]
          [-xdebuginfo=a[,a...]] [-xdepend[={yes|no}]]
          [-xdryrun] [-xdumpmacros[=v[,v...]]] [-xe] [-xF[=v]]
          [-xglobalize[={yes|no}]] [-xhelp=f]
          [-xhwcprof[={enable|disable}]] [-xinline=[v[,v...]]]
          [-xinline_param=a[,a[,a]...]] [-xinline_report[=n]]
          [-xinstrument=[no%]datarace] [-xipo[=n]]
          [-xipo_archive[=a]] [-xipo_build=[yes|no]]
          [-xivdep[=p]] [-xjobs={n|auto}]
          [-xkeep_unref[={[no%]funcs,[no%]vars}]]
          [-xkeepframe[=p]] [-xlang=language] [-xldscope=[v]]
          [-xlibmieee] [-xlibmil] [-xlibmopt]
          [-xlinkopt[=level]] [-xloopinfo] [-xM] [-xM1] [-xMD]
          [-xMF] [-xMMD] [-xMerge] [-xmaxopt[=v]] [-xmemalign=ab]
          [-xmodel=[a]] [-xnolib] [-xnolibmil] [-xnolibmopt]
          [-xnorunpath] [-xOn] [-xopenmp[=i]] [-xP]
          [-xpagesize=n] [-xpagesize_heap=n] [-xpagesize_stack=n]
          [-xpatchpadding[={fix|patch|size}]] [-xpec] [-xpch=v]
          [-xpchstop] [-xpentium] [-xpg] [-xprefetch[=val[,val]]]
          [-xprefetch_auto_type=[a] [-xprefetch_level=l]
          [-xprevise={yes|no}] [-xprofile=p] [-xprofile_ircache[=path]]
          [-xprofile_pathmap=collect_prefix:use_prefix]
          [-xreduction] [-xregs=r[,r...]] [-xrestrict[=f]]
          [-xs[={yes|no}]] [-xsafe=mem] [-xsecure_code_analysis{=[yes|no]]
          [-xsegment_align=n] [-xsfpconst]
          [-xspace] [-xstrconst] [-xtarget=t] [-xtemp=path]
          [-xthreadvar[=o] [-xthroughput[={yes|no}]] [-xtime]
          [-xtransition] [-xtrigraphs[=[yes|no]]
          [-xunboundsym={yes|no}] [-xunroll=n]
          [-xustr={ascii_utf16_ushort|no}] [-xvector[=a]] [-xvis]
          [-xvpara] [-Yc,dir] [-YA,dir] [-YI,dir] [-YP,dir]
          [-YS,dir] [-Zll]

Description
     Oracle Developer Studio 12.6 C Compiler version 5.14.


     This man page details the options or flags that  are  avail-
     able  for the C compiler in the Oracle Developer Studio 12.6
     release.


     Complete documentation for this release is available on  the
     Oracle  Technical Network (OTN) Oracle Developer Studio web-
     site:


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


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


     For the complete description of all new features  and  func-
     tionality  in  the  Oracle  Developer  Studio suite, see the
     What's New in the Oracle
               Developer Studio
               12.6
               Release.


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

  Compiling for 64-bit Platforms
     Use the -m32 and -m64 options to specify the data type model
     of the target compilation, ILP32 or LP64 respectively.

     The -xarch option no longer carries an  implicit  data  type
     model  definition,  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  each 32-bits wide. The LP64 model
     specifies that long and pointer data types are each  64-bits
     wide  and  int is 32-bits wide. The Oracle Solaris and Linux
     OS also support large files and large arrays under the  LP64
     data type model.

  Special x86 Notes
     There are some important issues to be aware of when  compil-
     ing for x86 Oracle Solaris platforms.


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


     With this release, the default instruction set and the mean-
     ing  of  -xarch=generic  has changed to sse2. Now, compiling
     without specifying a target platform option  results  in  an
     sse2  binary  incompatible with older Pentium III or earlier
     systems.


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


     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
     Since the release of Oracle  Solaris  10,  the  linker  will
     automatically  check  the  compatibility  of  binary objects
     against the runtime hardware platform.


     Program binaries compiled and built using specialized -xarch
     hardware  flags  are  verified by the OS 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.

     On Linux, however, there is no such verification check. Run-
     ning binary objects compiled by Oracle Developer Studio com-
     pilers on older hardware platforms could result  in  runtime
     failures; on Linux it is the user's responsibility to deploy
     these binaries on suitable hardware platforms.


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

  Overview of the C Compiler
     The cc (1) manual page describes the ISO C compiler  options
     that are SVID compliant under current Oracle Solaris operat-
     ing systems. Take note that the  C  compiler  recognizes  by
     default  some  of the constructs of the 2011 ISO/IEC C stan-
     dard. Specifically, the supported features are  detailed  in
     the Oracle Developer Studio
                 12.6:
                 C User's Guide. Use the -std flag to  limit  the
     compiler to a specific version of the ISO/IEC C standard.


     cc is the interface to the C compilation system. The  compi-
     lation  process  incorporates a preprocessor, compiler, code
     generator,  optimizer,  assembler,  and  link   editor.   cc
     processes the supplied options and then executes the various
     components with the proper  arguments.  cc  accepts  several
     types of files as arguments.


     Files with .c suffix are taken to be C source files and  may
     be  preprocessed, compiled, optimized, instrumented for pro-
     filing, assembled, and link edited. Although the  preproces-
     sor  can  be  used  as a macro processor, this is not recom-
     mended, as its output is geared toward that which  would  be
     acceptable  as  input to a valid C compiler. The compilation
     process may be stopped after the completion of any  pass  if
     the appropriate options are supplied.


     If the compilation process runs through the assembler,  then
     an  object file is produced in the current working directory
     with .o suffix substituted for .c. However, the .o  file  is
     normally  deleted  if  a  single C file is compiled and then
     immediately link edited.


     Files with .s suffix are taken to be assembly source  files;
     they may be assembled and link edited.

     Files with .S suffix are taken to be assembly source  files;
     they may be assembled and link edited. Such files are passed
     to the preprocessor (/usr/ccs/lib/cpp  on  Oracle  Solaris),
     and then to the assembler.


     Files with an .i are  taken  to  be  preprocessed  C  source
     files, and may be compiled, optimized, instrumented for pro-
     filing, assembled, and link edited. Files whose names do not
     end in .c, .s, .S or .i are passed to the link editor, which
     produces a  dynamically  linked  executable  whose  name  by
     default is a.out.


     See option -Yc, dir to change the default  directories  used
     for finding libraries. dir is a colon-separated path list.


     The default library search order can be seen  by  using  the
     -###  or  -xdryrun option and examining the -Y option of the
     ld invocation.

  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 automat-
     ically 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  directories 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  direc-
     tories  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/lib/compilers/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 pro-
     duced by options -#, -###, and -dryrun.


     Options specified by the user on the command line will  usu-
     ally override options read from the defaults file. For exam-
     ple, if the defaults file specifies compiling with -xO4  and
     the  user  specifies  -xO2 on the command 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 preprocessor 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.c




     The compiler command is now equivalent to:


       cc -fast -xvpara -c -I/local/hdrs -L/local/libs -lliblocal \
              tst.c -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 problems.


     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 general, processing of the compiler options is from  left
     to  right, permitting selective overriding of macro options.
     This rule does not apply to linker or preprocessor options.


     In the syntax of the command-line options,  items  shown  in
     square  brackets ( [] ) 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 indi-
     cates the default value when  the  flag  appears  without  a
     value.


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


     The following options are interpreted by cc:


     -#
         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  actually execute it. Also shows how command options
         would expand.


     -Aname[(tokens)]
         Associate name as a predicate with the specified  tokens
         as if by a #assert preprocessing directive.



           Preassertions:system(unix)
                     machine(sparc) (SPARC)
                     machine(i386) (x86)
                     cpu(sparc) (SPARC)
                     cpu(i386) (x86)


         The above are not predefined in -pedantic mode.

         If -A is followed by a dash  (-)  only,  it  causes  all
         predefined  macros (other than those that begin with __)
         and predefined assertions to be forgotten.


     -ansi
         Equivalent to -std=c89.


     -B [static|dynamic]
         Specifies whether bindings of libraries for linking  are
         static  or  dynamic,  indicating  whether  libraries are
         non-shared     or     shared,      respectively.      -B
         dynamic  causes  the link editor to look for files named
         libx.so and then for files named libx.a when  given  the
         -lx option. -B               static causes the link edi-
         tor to look only for files named libx.a. This option may
         be  specified  multiple  times  on the command line as a
         toggle.

         This option and its argument are passed to ld.


     -C
         Prevents the  C  preprocessor  from  removing  comments,
         other than those on preprocessing directive lines.

     -c
         Compile and produce a  .o  file  for  each  source  file
         without linking. You can explicitly name a single object
         file by using the -o option. When the compiler  produces
         object code for each or 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.


     -Dname[(arg[,arg])]             [=expansion]
         Define a macro with optional arguments as if  the  macro
         is  defined  by a #define preprocessing directive. If no
         =expansion is specified, the compiler assumes =1.



           Predefinitions:unix
                       sparc (SPARC)
                       sun


         The above are not predefined in -pedantic mode.

         These predefinitions are valid in all modes:



           __BUILTIN_VA_ARG_INCR
           __SUNPRO_C=0x5140
           __SVR4 (Oracle Solaris)
           __SVR4__ (Oracle Solaris)
           __svr4__ (Oracle Solaris)
           __db4 (Oracle Solaris)
           __SunOS_5_10 (Oracle Solaris)
           __SunOS_5_11 (Oracle Solaris)
           __SunOS_RELEASE (Oracle Solaris)
           __amd64 (x86 -m64)
           __gnu__linux (linux)
           __i386 (x86)
           __i386__ (x86 -m32)
           __linux (linux)
           __linux__ (linux)
           __sparc (SPARC)
           __sparcv8 (SPARC)
           __sparcv9 (SPARC -m64)
           __sun (Oracle Solaris)
           __unix
           __`uname -s`_`uname -r | tr . _`
           __x86_64 (x86 -m64)
           linux (x86, linux)
           _LP64 (-m64)
           __LP64__ (-m64)

         A hex value 0xRRrrmm  representing  the  Oracle  Solaris
         release,  where  RR.rr  is  the  output  of  the sysinfo
         (SI_RELEASE) system call, or of the  uname  -r  command,
         with  leading zeros added when needed. The mm digits are
         reserved for possible future "micro" releases.  All  the
         digits are decimal. Example for Oracle Solaris 11, which
         is SunOS 5.11: __SunOS_RELEASE, has the value,  0x051100
         .  The  value  of  __SunOS_RELEASE  for  an older Oracle
         Solaris release is always less  than  the  value  for  a
         later release. Example of use:


           #if __SunOS_RELEASE >= 0x051100 // Solaris 11 or later.

         The following is predefined with  any  -std  flag  value
         when  -pedantic is not specified to indicate the availa-
         bility of the _Restrict keyword:



           __RESTRICT


         The compiler also predefines the  following  object-like
         macro to indicate the pragma will be recognized:


           __PRAGMA_REDEFINE_EXTNAME




     -d [y|n]
         Allow or disallow dynamic linking.

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

         This option and its argument are passed to ld.

         Note: 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
         -xmemalign=8s  instead.  For a complete list of obsolete
         options and flags, see the Oracle Developer Studio
                         12.6:
                         C User's Guide. Ignored on x64/x86 plat-
         forms.


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


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



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


         no%error
             Do not add the prefix "error:"  to  any  error  mes-
             sages.


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


     -errhdr [=h]
         Use this option to limit the warnings from header  files
         to  the group of header files indicated by the following
         flags:


         %all
                      Check all used header files.


         %none
                      Check none of the header files.

         %user
                      Default. Checks all the user header  files.
                      Does  not check system include files, those
                      in  /usr/include  and  its  subdirectories.
                      Does not check system header files supplied
                      by the compiler.




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

         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.

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

         Only warning messages from the C compiler that display a
         tag  when  the -errtags option is used can be suppressed
         with the -erroff option. You can achieve  finer  control
         over   error   message   suppression  by  using  #pragma
         error_messages.


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

         i can be one of the following:



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


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


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


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

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


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

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


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

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

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

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

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

         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  message specified by tag is issued
                      only as a warning message. Has no effect if
                      tag  is  not  issued.  Use  this  option to
                      revert a warning message  that  was  previ-
                      ously  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 warn-
                      ing 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.

     -fast
         This option is a macro that you can effectively use as a
         starting point for tuning an executable for maximum run-
         time performance. The expansion of -fast can change from
         one  release  of  the  compiler to the next and includes
         options that are target platform specific. Use the -# or
         the  -xdryrun options to examine the expansion of -fast,
         and incorporate the appropriate options  of  -fast  into
         the ongoing process of tuning the executable.

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

         The -fast option impacts the value  of  errno.  See  the
         NOTES  section  at  the  end  of  this man page for more
         information.

         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 Oracle Developer Studio
                         12.6:
                         C User's Guide.

         The -fast option is unsuitable  for  programs  that  are
         intended  to run on a different target than the compila-
         tion machine. In  such  cases,  follow  -fast  with  the
         appropriate -xtarget option. For example:


           % cc -fast -xtarget=generic

         For C modules depending on exception handling  specified
         by SUID, follow -fast by -xnolibmil -xbuiltin=%default


           % cc -fast -xnolibmil -xbuiltin=%default

         The -fast option acts like a macro expansion on the com-
         mand  line.  Therefore,  you  can  override  any  of the
         expanded options by following  -fast  with  the  desired
         option.

         If you  combine  -fast  with  other  options,  the  last
         specification applies.

         These options are turned on for -fast:


           -fma=fused (SPARC, x86)
           -fns (SPARC, x86)
           -fsimple=2 (SPARC, x86)
           -fsingle (SPARC, x86)
           -nofstore (x86)
           -xalias_level=basic (SPARC, x86)
           -xbuiltin=%all (SPARC, x86)
           -xdepend (SPARC, x86)
           -xlibmil (SPARC, x86)
           -xlibmopt (SPARC, x86)
           -xmemalign=8s (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. For
         details on the options set  by  -fast,  see  the  Oracle
         Developer Studio
                         12.6:
                         C User's Guide.

         To determine the expansion of -fast on a running system,
         execute the command:


           cc -fast -xdryrun |& grep ###

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

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

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



     -fcommon
          Reverses -fno-common if specified on the  command  line
         after -fno-common.

     -fd
         Reports K&R function declarations and definitions.


     -features=[a]
         The compiler's treatment of extern inline functions con-
         forms  by  default  to  the  behavior  specified  by the
         ISO/IEC 9899:1999 C standard.  Compile  new  codes  with
         -features=no%extinl  to  obtain  the  same  treatment of
         extern inline functions as provided by versions 5.5,  or
         older, of the C and C++ compilers.

         Old C and C++ objects (pre C/C++ 5.6) can be linked with
         new C and C++ objects with no change of behavior for the
         old objects. To get standard  conforming  behavior,  old
         code must be recompiled using the current compiler.

         The following table lists the  possible  values  for  a.
         Prefix no% disables a suboption.



         [no%]conststrings
             Enables or disables the placement of string literals
             in     read-only     memory.    The    default    is
             -features=conststrings which replaces the deprecated
             -xstrconst  option. Note that your program will fail
             to write to a string literal under the default  com-
             pilation   mode   just   as  if  you  had  specified
             -xstrconst on the command line.


         [no%]extensions
             Allows/disallows  zero-sized  struct/union  declara-
             tions  and  void  function  with  return  statements
             returning a value to work.


         extinl
             Generates extern inline functions  as  global  func-
             tions.  This is the default, which conforms with the
             1999 C standard.


         [no%]extinl
             Generates extern inline functions  as  static  func-
             tions.

         [no%]gcc_enums
             The type of an enum will be a  signed  type  if  and
             only  if  at  least  one  enumerator  has a negative
             value. Otherwise the enum will be an unsigned  type.
             Normally  that  means enums will be of type unsigned
             int. However, if  the  value  is  too  large  to  be
             represented  as  a  signed or unsigned int, then the
             type of the enum will be  signed  or  unsigned  long
             long  for  -m32, or signed or unsigned long for-m64.
             The default is  no%gcc_enums  where  an  enum  is  a
             signed int.



         [no%]iddollar
             Allow a dollar symbol ($) as a noninitial identifier
             character. The default is no%iddollar.


         [no%]mergestrings
             (SPARC) Causes the compiler to put  string  literals
             and  other  suitable  const or read-only data into a
             special section  of  the  binary  where  the  linker
             removes duplicate strings.

             The default is -features=no%mergestrings, and dupli-
             cate strings are not removed.

             -features=mergestrings  is   only   effective   when
             -features=conststrings is also in effect.


         [no%]typeof
             Enables/disables recognition of the typeof operator.
             The typeof operator returns the type of its argument
             (either an expression or a type).  It  is  specified
             syntactically  like  the  sizeof  operator,  but  it
             behaves  semantically  like  a  type  defined   with
             typedef.  Accordingly,  it  can  be  used anywhere a
             typedef can be used. For example, it can be used  in
             a  declaration,  a  cast,  or  inside of a sizeof or
             typeof. The default is -features=typeof.


         [no%]zla
             Allow an array to be declared  with  a  size  of  0,
             which  is  otherwise  not  allowed.  The  default is
             no%zla.

         %none
             The option -features=%none is deprecated and  should
             be  replaced by -features=no% followed by the subop-
             tion.


         Examples:


           typeof(int) i;/* declares variable "i" to be type int*/
           typeof(i+10) j;/* declares variable "j" to be type int,
                     the type of the expression */

           i = sizeof(typeof(j)); /* sizeof returns the size of
                     the type associated with variable "j" */

           int a[10];
           typeof(a) b;/* declares variable "b" to be array of
           size 10 */


         The typeof operator can be especially  useful  in  macro
         definitions,  where  arguments may be of arbitrary type.
         For example:

           #define SWAP(a,b)
                    { typeof(a) temp; temp = a; a = b; b = temp; }




     -fexceptions, -fno-exceptions
         Generates (does not generate) extra code needed to  pro-
         pagate  exceptions. You might need to enable this option
         when compiling C code that needs to  interoperate  prop-
         erly with exception handlers written in C++ using any of
         their gcc compatibility modes. For more information, see
         -std=v in Oracle Developer

         The -fexceptions/-fno-exceptions flags are not available
         on x86 with the -m32 option.



     -flags
         Same as  -xhelp=flags.  Prints  a  one-line  summary  of
         available options.

     -flteval[={any|2}]
         (Obsolete) The -flteval flag is obsolete and  should  no
         longer be used.

         (x86) Use this option  to  control  how  floating  point
         expressions are evaluated.



         2
                      Floating point expressions are evaluated as
                      long double.


         any
                      Floating point  expressions  are  evaluated
                      depending  on  the combination of the types
                      of the variables and constants that make up
                      an expression.


         -flteval=2 can no longer be used with any -xarch  value.
         Specifying -flteval=2 will result in a error message.

         For more information, see `Precision of  Floating  Point
         Evaluators' in appendix E of the Oracle Developer Studio
                         12.6:
                         C User's Guide.


     -fma[={none|fused}]
         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 architecture requirement is -xarch=sparcfmaf
         on  SPARC  and  -xarch=avx2  on  x86  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  plat-
         forms  that  do  not support fused multiply-add instruc-
         tions. When the minimum architecture is not  used,  then
         -fma=fused has no affect.

         Fused multiply-add instructions eliminate the intermedi-
         ate  rounding  step between the multiply and add. Conse-
         quently, programs may  produce  different  results  when
         compiled with -fma=fused although precision will tend to
         increase rather than decrease.


     -fnonstd
         Macro for -fns and -ftrap=common.



     -fno-common
         Places tentative definitions in .bss instead of .common.

         Tentative  definition  are  file   scope   uninitialized
         declarations without extern. Examples:


           int i;
           long *lp;

         Variables placed in .common are  resolved  to  a  single
         object  by  the linker. Variables placed in .bss must be
         unique.  So multiple tentative definitions can  lead  to
         linker errors about multiply defined symbols.




     -fnoshort-enums
         Cancels out all -fshort-enums flags that appear  earlier
         on  the cc command line. Whichever option (-fshort-enums
         or -fnoshort-enums) occurs  last  on  the  command  line
         takes effect.




     -fno-strict-aliasing
         -fno-strict-aliasing  is equivalent to -xalias_level=any



     -fns[=[no|yes]]
         For SPARC, selects the SPARC nonstandard  floating-point
         mode.

         For x86,  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  tradi-
         tional x86 floating-point operations that do not utilize
         the SSE or SSE2 instruction set.

         The default, -fns=no, is standard floating-point mode.

         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.

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

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

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


     -fopenmp
         Same as -xopenmp=parallel.


     -fprecision=p
         (x86) Initializes the rounding precision  mode  bits  in
         the  Floating-point  Control  Word to p, which is one of
         single (24 bits), double  (53  bits),  or  extended  (64
         bits)    respectively.    The   default   floating-point
         rounding-precision mode is extended.

         Note that on x86,  only  the  precision,  not  exponent,
         range  is  affected  by  the  setting  of floating-point
         rounding precision mode.

         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=r
         Sets the IEEE 754 rounding mode that is  established  at
         runtime during the program initialization.

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

         The default is -fround=nearest.

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

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

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

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



     -fshort-enums
         Sets the type of an enum to that of  the  smallest  type
         capable  of  holding  all  of  the  enumerator values. A
         signed type is used if and only if at least one  of  the
         enumerators  has  a  negative  value.  An enum with this
         option in effect  could  become  of  type  signed  char,
         unsigned  char,  signed  short or unsigned short. Other-
         wise, the enum  type  will  be  signed  or  unsigned  as
         appropriate based on the enumerator values.



     -fsimple[=n]
         Allows the optimizer  to  make  simplifying  assumptions
         concerning floating-point arithmetic.

         The compiler defaults to -fsimple=0. Specifying -fsimple
         is equivalent to -fsimple=1.

         If n is present, it must be 0, 1, or 2.
         -fsimple=0
             Permits no simplifying assumptions. Preserves strict
             IEEE 754 conformance.


         -fsimple=1
             Allows conservative simplifications.  The  resulting
             code does not strictly conform to IEEE 754.

             With -fsimple=1, the optimizer can assume  the  fol-
             lowing:

                 o    The  IEEE  754  default   rounding/trapping
                      modes do not change after process initiali-
                      zation.


                 o    Computations producing  no  visible  result
                      other than potential floating- point excep-
                      tions may be deleted


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

                      With  -fsimple=1,  the  optimizer  is   not
                      allowed   to  optimize  completely  without
                      regard to roundoff or exceptions.  In  par-
                      ticular,  a floating-point computation can-
                      not be replaced by one that  produces  dif-
                      ferent  results  with  rounding  modes held
                      constant at runtime.



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

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

             -fsimple=2  allows  fp-transformations   which   may
             introduce fp exceptions.


         See also: Techniques for Optimizing  Applications:  High
         Performance
                       Computing 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 Developer Studio website:
         oracle.com/technetwork/server-storage/developerstudio/


     -fsingle
         (-Xt and -Xs modes only) By default -Xs and  -Xt  follow
         the K&R C rules for float expressions, by promoting them
         to double and evaluating them in double  precision.  Use
         the  -fsingle  flag  when specifying -Xs or -Xt to cause
         the compiler to evaluate  float  expressions  as  single
         precision.


     -fstore
         (x86) Causes the compiler to  convert  the  value  of  a
         floating-point expression or function to the type on the
         left-hand side of an assignment, when that expression or
         function  is assigned to a variable, or when the expres-
         sion is cast to a shorter  floating-point  type,  rather
         than leaving the value in the register. Due to roundoffs
         and truncation, the results may be different from  those
         generated  from  the register value. This is the default
         mode. To turn off this option, use the -nofstore option.



     -fstrict-aliasing
         -fstrict-aliasing is equivalent to -xalias_level=strict



     -ftrap[=t[,t...]           ]
         Sets the IEEE 745 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  simultane-
         ously  enable traps and install a SIGFPE handler. If you
         specify more than  one  value,  the  list  is  processed
         sequentially from left to right.

         Use prefix no% to remove a suboption from %all  or  com-
         mon.



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


         The default is -ftrap=%none.

         Note that the [no%] form of the option 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  exam-
         ple.  The  [no%]  form  of the option by itself does not
         explicitly cause a particular trap to be disabled.

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

         If you compile one routine with  -ftrap=t,  compile  all
         routines  of  the program with the same -ftrap=t option;
         otherwise, you 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;




     -fvisibility=v
         The -fvisibility=v option is equivalent to the -xldscope
         option as follows:


         -fvisibility=default
                                   -fvisibility=default       is
                                   equivalent to -xldscope=global


         -fvisibility=internal
                                   -fvisibility=internal       is
                                   equivalent to -xldsdope=hidden


         -fvisibility=protected
                                   -fvisibility=protected      is
                                   equivalent       to
                                   -xldscope=symbolic


         -fvisibility=hidden
                                   -fvisibility=hidden       is
                                   equivalent to -xldscope=hidden





     -G
         Produce a shared object rather than a dynamically linked
         executable.  This  option  is passed to ld and cannot be
         used with the -dn option.

         When you use the -G option, the compiler does  not  pass
         any  default  -l  options  to ld. If you want the shared
         library to have a dependency on another shared  library,
         you  must  pass  the  necessary -l option on the command
         line.

         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 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  docu-
         mented under the description of -xcode.

         For more information, see the -G option.


     -g
         See -g[n].


     -g[n]
         Produce additional symbol table information  for  dbx(1)
         and the Performance Analyzer analyzer(1).

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

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

         Compile with the -g option to use the full  capabilities
         of  the  Performance  Analyzer.  While  some performance
         analysis features do not require -g,  you  must  compile
         with  -g  to  view annotated source, some function level
         information, and compiler commentary messages.  See  the
         analyzer(1) man page and the Performance
                       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.

         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 but
         is  linked  with  -g  will  not be prepared properly for
         debugging. Note that compiling the module that  contains
         the  function  main with the -g option is usually neces-
         sary for debugging.

         -g is implemented as a macro  that  expands  to  various
         other,  more primitive, options. See -xdebuginfo for the
         details of the expansions.

         Values:
         -g
                      Produce standard debugging information.


         -gnone
                      Do not produce any  debugging  information.
                      This is the default.


         -g1
                      Produce file and line  number  as  well  as
                      simple  parameter  information that is con-
                      sidered crucial during  post-mortem  debug-
                      ging.


         -g2
                      Same as -g.


         -g3
                      Produce additional  debugging  information,
                      which  currently  consists  only  of  macro
                      definition information. This added informa-
                      tion  can result in an increase in the size
                      of the debug information in  the  resulting
                      .o  and  executable  when compared to using
                      only -g.





     -gz[=cmp-type]
         Equivalent      of      specifying      -xcompress=debug
         -xcompress_format=cmp-type.

         -gz with no suboption is equivalent to -gz=zlib.



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


     -h           name
         Assigns a name to a shared dynamic library;  allows  you
         to keep different versions of a library.

         In general, the name after -h should be the same as  the
         file  name  given in the -o option. The space between -h
         and name is optional.

         The linker assigns the specified name to the library and
         records  the  name  in the library file as the intrinsic
         name of the library. If there is  no  -h   name  option,
         then no intrinsic name is recorded in the library file.

         When the runtime linker loads the library into  an  exe-
         cutable  file,  it  copies  the  intrinsic name from the
         library file into the executable, into a list of  needed
         shared  library files. Every executable has such a list.
         If there is no intrinsic name of a shared library,  then
         the  linker  copies  the path of the shared library file
         instead.


     -I[-|dir]
         -Idir adds dir to  the  list  of  directories  that  are
         searched  for  #include files. -I values accumulate from
         left to right.


             o    For include statements  of  the  form  #include
                  <foo.h>,  the  preprocessor  searches  for  the
                  header file in the following order:

                 1.   The directories named with the  -I  option,
                      if any.


                 2.   The compiler  and  system  standard  direc-
                      tories, usually /usr/include.




             o    For include statements  of  the  form  #include
                  "foo.h",  the compiler searches the directories
                  in the following order:

                 1.   The current directory (that is, the  direc-
                      tory  that contains the file which contains
                      the include statement itself.


                 2.   The directories named with -I  options,  if
                      any.


                 3.   The compiler  and  system  standard  direc-
                      tories, usually /usr/include.



         -I-  changes  the  include-file  search  rules  to   the

         following:


             o    The compiler never searches the current  direc-
                  tory, unless the directory is listed explicitly
                  in a -I directive. This effect applies even for
                  include   statements   of   the  form  #include
                  "foo.h".


             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 compiler  and  system  standard  direc-
                      tories, usually /usr/include.




             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- (that is, the com-
                      piler does not search  the  -I  directories
                      that appear before -I-).


                 2.   The compiler  and  system  standard  direc-
                      tories, usually /usr/include.



         Only the first -I- option on the command line  works  as
         described above.

         -Idir looks in dir, prior to usr/include,  for  included
         files  whose  names  do not begin with slash (/). Direc-
         tories for multiple -I options are searched in the order
         specified.

         Warnings:

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

     -i
         Ignores the LD_LIBRARY_PATH and LD_LIBRARY_PATH_64  set-
         tings.


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


     -KPIC
         (SPARC) (Obsolete) You should not use this  option.  Use
         -xcode=pic32  instead.  For  a complete list of obsolete
         options and flags, see the Oracle Developer Studio
                         12.6:
                         C User's Guide.

         (x86) -KPIC is identical to -Kpic on x86 architectures.


     -Kpic
         (SPARC) (Obsolete) You should not use this  option.  Use
         -xcode=pic13  instead.  For  a complete list of obsolete
         options and flags, see the Oracle Developer Studio
                         12.6:
                         C User's Guide.

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


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

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

         Warnings:

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


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


     -library=sunperf
         Link with the Oracle Developer Studio  supplied  perfor-
         mance libraries.


     -m32|-m64
         Specifies the data type 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.

         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 Oracle Developer Studio
                         12.6:
                         C User's Guide.

         Note that in previous compiler releases, the  data  type
         model,  ILP32  or LP64, was implied by the choice of the
         instruction set  with  -xarch.  Starting  with  the  Sun

         Studio 12 compilers, this is no longer the case. On most
         platforms, just adding -m64 to the command line is  suf-
         ficient to create 64-bit objects.

         -m64 is the default, except on Oracle Solaris 10 and  11
         where -m32 is the default.

         See also: -xarch.


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


     -misalign
         (SPARC) (Obsolete) You should not use this  option.  Use
         the -xmemalign=1i option instead. For a complete list of
         obsolete options and flags, see the Oracle
                         Developer Studio
                         12.6:
                         C User's Guide.


     -misalign2
         (SPARC) (Obsolete) You should not use this  option.  Use
         the -xmemalign=2i option instead. For a complete list of
         obsolete options and flags, see the Oracle
                         Developer Studio
                         12.6:
                         C User's Guide.


     -mr[,string]
         -mr removes all strings from the .comment section of  an
         object   file.   When   you   use   the  -mr  flag,  mcs
         -d is invoked.

         -mr,string removes all strings from the .comment section
         and inserts string in the .comment section of the object
         file. If string contains embedded  blanks,  it  must  be
         enclosed  in  quotation  marks.  If  string is null, the
         .comment section will be empty. When you use this  flag,
         mcs -d -a is invoked.


     -mt[={yes|no}]
         Use this option to compile and link multithreaded code.

         This option passes -D_REENTRANT to the preprocessor.

         -mt=yes is the default behavior of the compiler. -mt  is
         equivalent  to  -mt=yes. If this behavior is not desired
         use the option -mt=no.

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

         Use this option consistently. If you  compile  and  link
         one translation unit with -mt, you must compile and link
         all units of the program with -mt.

         To determine which  system  support  libraries  will  be
         linked by default, compile with the -dryrun option.

         See also: -xnolib


     -native
         This option is a synonym for -xtarget=native.


     -nofstore
         (x86) Cancel -fstore on command  line.  Cancels  forcing
         expressions  to  have  the  precision of the destination
         variable as invoked by -fstore.

         -nofstore is invoked by -fast.  The  normal  default  is
         -fstore.


     -O
         Use default optimization level -xO3. However,  -xO3  may
         be inappropriate for programs that rely on all variables
         being automatically considered  volatile.  Typical  pro-
         grams 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.


     -On
         The same as -xOn.


     -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 specifies the target .so library file. This option
         and its argument are passed to ld.


     -P
         Preprocesses only the  named  C  files  and  leaves  the
         result  in  corresponding  files suffixed .i. The output
         will not  contain  any  preprocessing  line  directives,
         unlike -E.


     -p
         (Obsolete) See -xpg.


     -pedantic{=[yes|no]}
         Strict conformance  with  errors/warnings  for  non-ANSI
         constructs.  The  -std flag can be used to specify which
         ANSI standard is in effect. The -Xc, -Xa, -Xt, -Xs,  and
         -xc99 flags cannot be specified with the -pedantic flag.
         Doing so will result in an error  being  issued  by  the
         compiler.

         The option -pedantic is equivalent to pedantic=yes.

         -pedantic=no is the default when no -pedantic option  is
         specified.


     -preserve_argvalues[=simple|none|complete]
         (x86) Saves copies of register-based function  arguments
         in the stack.

         When none is specified  or  if  the  -preserve_argvalues
         option  is  not  specified on the command line, the com-
         piler behaves as usual.

         When simple is specified, up to  six  integer  arguments
         are saved.

         When complete is specified, the values of  all  function
         arguments  in the stack trace are visible to the user in
         the proper order.

         The values are not updated during the function  lifetime
         on assignments to formal parameters.

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

         To pass multiple options, specify them  in  order  as  a
         comma-separated  list.  Options  that are passed to com-
         ponents 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  recog-
         nizes.

         The following table shows the possible values for  phase
         and the corresponding argument for -Wc,arg



           Qoption
           phase     W<c>
           =====     ====
           fbe       a    Assembler: (fbe), (gas)
           cg        c    C code generator: (cg)(SPARC)
           driver    d    cc driver (1)
           ld        l    Link editor (ld)
           mcs       m    mcs
           ipo       O    (Capital letter `O') Interprocedural optimizer
           postopt   o    Postoptimizer
           cpp       p    Preprocessor (cpp)
           ube       u    C code generator (ube), (x86)
           acomp     0    (The number zero) Compiler acomp
           iropt     2    Optimizer: (iropt)
           previse   3    Static error checking: (previse)

         See also: -Wc,arg


     -Q[y|n]
         Emits or does not emit identification information to the
         output  file.  If  y is used, identification information
         about each invoked compilation tool will be added to the
         output  files (the default behavior). This can be useful
         for software administration. -Qn suppresses this  infor-
         mation.


     -qp
         Same as -p.


     -Rdir[:dir...]
         A colon-separated list of directories  used  to  specify
         library  search  directories  to  the runtime linker. If
         present and not null,  it  is  recorded  in  the  output
         object file and passed to the runtime linker.

         If both LD_RUN_PATH and the -R option are specified, the
         -R option takes precedence.


     -S
         Compiles, but does not assemble or link edit the named C
         files.   The   assembler-language   output  is  left  in
         corresponding files suffixed .s.


     -s
         Removes all symbolic debugging information from the out-
         put  object  file.  This option is passed to ld(1). This
         option cannot be specified with -g.



     -shared
         Produces a shared  object  rather  than  a  dynamically-
         linked  executable. This option is passed to ld (as -G),
         and cannot be used with the -dm option.

         When you use the -shared  option,  the  compiler  passes
         default  -l  options  to  ld, which are the same options
         that would be passed if you created an executable.

         If you are creating a shared object  by  specifying  the
         -shared  option  along  with other compiler options that
         are specified at both compile time and link  time,  make
         sure that that those options are also specified 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  docu-
         mented under the description of -xcode.

         For more information, see the -G option.



     -staticlib=[no%]sunperf
         When used with -library=sunperf, -staticlib=sunperf will
         link  statically  with the Sun performance libraries. By
         default  and  when  -library=no%sunperf  is   specified,
         -library=sunperf  results  in dynamic linking of the Sun
         performance libraries.

         For compatibility with  CC,  %all  and  %none  are  also
         accepted values for -staticlib, where %all is equivalent
         to sunperf and %none is equivalent to no%sunperf.


     -std=value
         C language standard selection flag.

         value is required and defined as one of the following:



         c89
                                          Equivalent to c90.



         c90
                                          C  source   language
                                          accepted   is   that
                                          defined by  the  ISO
                                          C90 standard.



         c99
                                          C  source   language
                                          accepted   is   that
                                          defined by  the  ISO
                                          C99 standard.


         c11
                                          C  source   language
                                          accepted   is   that
                                          defined by  the  ISO
                                          C11 standard.



         gnu89
                                          Equivalent to gnu90.


         gnu90
                                          Allow for extensions
                                          with ISO C90.


         gnu99
                                          Allow for extensions
                                          with ISO C99.


         gnu11
                                          Allow for extensions
                                          with ISO C11.

         -std=iso9899:1990
                                          Equivalent        to
                                          -std=c90.


         -std=iso9899:199409
                                          Equivalent        to
                                          -std=c90.


         -std=c9x
                                          Equivalent        to
                                          -std=c99.


         -std=iso9899:1999
                                          Equivalent        to
                                          -std=c99.


         -std=iso9899:199x
                                          Equivalent        to
                                          -std=c99.


         -std=c1x
                                          Equivalent        to
                                          -std=c11.


         -std=iso9899:2011
                                          Equivalent        to
                                          -std=c11.


         -std=gnu9x
                                          Equivalent        to
                                          -std=gnu99.


         -std=gnu1x
                                          Equivalent        to
                                          -std=gnu11.



         -std defaults to c11.

         The  macro  __STRICT_ANSI__  is  predefined   when   the
         -std=c89,  -std=c90,  -std=c99,  or  -std=c11  option is
         used. Some header files may use this macro  to  restrict
         the declaration of functions and definition of macros to
         those defined by the ISO C standard.

         When any of the flags -Xc, -Xa, -Xt, or -xtransition are
         specified,  the  -std  default  is not in effect and the
         compiler  defaults  to  -xc99=all,no_lib.  When  -Xs  is
         specified,  the  -std  default  is not in effect and the
         compiler defaults to -xc99=none. When  -xc99  is  speci-
         fied, the -std default is not in effect and the compiler
         is as specified by the -xc99 flag.

         The -Xc, -Xa, -Xt, -Xs, and -xc99 flags cannot  be  used
         if  the  -std  flag  has  been  specified. Doing so will
         result in an error being issued by the compiler.

         If you compile and link in separate steps you  must  use
         the same values for -std flag in both steps.


     -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 pro-
         cess. The compiler gives precedence to the value set  by
         -temp over the value of TMPDIR.

         See also: -keeptmp


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

         The -traceback option causes the executable to  issue  a
         stack  trace  to  stderr, dump core, and exit if certain
         signals  are  generated  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  com-
         piler  command  line  when  linking.  The option is also
         accepted at compile-time but is ignored unless  an  exe-
         cutable 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  genera-
             tion of a core file) can be caught: sigquit, sigill,
             sigtrap, sigabrt, sigemt, sigfpe,  sigbus,  sigsegv,
             sigsys, sigxcpu, and sigxfsz.

             Any of these can be preceeded with  no%  to  disable
             catching 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.

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


           % limit coredumpsize 0

         The -traceback option has no effect on  runtime  perfor-
         mance.


     -Uname
         Causes any definition of  name  to  be  undefined.  This
         option  removes any initial definition of the preproces-
         sor symbol name created by -D on the same  command  line
         including those placed by the command-line driver.

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

         If the same name is specified for both -D and  -U,  name
         is not defined, regardless of the order of the options.


     -V
         Causes each invoked tool to print its  version  informa-
         tion on the standard error output.


     -v
         Causes the compiler to perform more and stricter  seman-
         tic  checks,  and  to enable certain lint-like checks on
         the named C files.

     -Wc,arg
         Passes the argument arg to  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  immedi-
         ately  preceding  backslash (\) character; the backslash
         is removed from the resulting argument.)  All  -W  argu-
         ments  are  passed  after the regular command-line argu-
         ments.

         c can be one of the following:



         a
                      Assembler: (fbe), (gas)


         c
                      C code generator: (cg)(SPARC)


         d
                      cc driver (1)


         l
                      Link editor (ld)


         m
                      mcs


         O
                      (Capital letter `O') Interprocedural optim-
                      izer


         o
                      Postoptimizer


         p
                      Preprocessor (cpp)


         u
                      C code generator (ube), (x86)


         0
                      (The number zero) Compiler (acomp)


         2
                      Optimizer: (iropt)


         3
                      Static error checking: (previse)


         (1) Note: You cannot use -Wd  to  pass  the  cc  options
         listed in this man page to the C compiler.

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

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


     -w
         Suppress compiler warning messages.

         The option is equivalent to the option -erroff=%all.


     -X[c|a|t|s]
          (Obsolete) The -Xc,  -Xa,  -Xt,  -Xs  options  will  be
         removed in a future release.

         The -Xc, -Xa, -Xt, and -Xs flags cannot be used  if  the
         -std or -xlang flag has been specified.

         When not using the -std flag,  the  -X  options  specify
         varying degrees of compliance to the 1990 and 1999 ISO C
         standard. The value of -xc99 affects  which  version  of
         the ISO C standard the -X option applies.



         c (conformance)
             Strictly conformant ISO C, without K&R C compatibil-
             ity extensions. The compiler issues errors and warn-
             ings for programs that use non-ISO C constructs.

             (Obsolete) The -Xc  option  will  be  removed  in  a
             future  release.  Use  the -std flag to choose the C
             language dialect, and then use -pedantic in place of
             -Xc to specify strict conformance.


         a
             ISO C plus  K&R  C  compatibility  extensions,  with
             semantic  changes required by ISO C. Where K&R C and
             ISO C specify different semantics for the same  con-
             struct,  the compiler uses the ISO C interpretation.
             If the -Xa option is used in  conjunction  with  the
             -xtransition  option,  the  compiler issues warnings
             about the different semantics.

         t (transition) (Obsolete)
             The -Xt option will be removed in a future  release.
             It  is  recommended that C code that requires -Xt to
             build and compile correctly be migrated  to  conform
             with at least the C99 dialect of the ISO C standard,
             that is, compilable with -std=c99.

             This option uses ISO  C  plus  K&R  C  compatibility
             extensions  without semantic changes required by ISO
             C. Where K&R C and ISO C specify different semantics
             for  the same construct, the compiler uses the K&R C
             interpretation. If you use the -Xt  option  in  con-
             junction  with the -xtransition option, the compiler
             issues warnings about the different semantics.


         s (K&R C) (Obsolete)
             The -Xs option will  require  the  -E  in  a  future
             release. It is recommended that C code that requires
             -Xs to build and compile correctly  be  migrated  to
             conform  with  at least the C99 dialect of the ISO C
             standard, that is, compilable with -std=c99.

             The compiler tries to warn about all  language  con-
             structs  that have differing behavior between Oracle
             Developer Studio ISO C and the K&R C.


         All warning messages about  differing  behavior  can  be
         eliminated  through appropriate coding; for example, use
         of casts can eliminate  the  integral  promotion  change
         warnings.


     -Xlinker           arg
         Passes arg to linker, ld(1).


     -xaddr32[={yes|no}]
         (x86/x64) 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 limita-
         tion 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 com-
         piled 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   capabilities  definition,  described  in  the
         Linker and Libraries Guide.


     -xalias_level[=a]
         a must be one of:any, basic, weak, layout, strict,  std,
         strong. Use this flag to place the indicated alias level
         into effect for the whole  translation  unit.  In  other
         words,  the  alias level you select is applied to all of
         the memory references in the translation unit. If you do
         not   supply   -xalias_level,   the   compiler   assumes
         -xalias_level=any. If you supply -xalias_level without a
         value, the compiler assumes -xalias_level=layout.



         any
             The compiler assumes that all memory references  can
             alias  at  this  level. There is no type-based alias
             anaylysis.


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


         weak
             If you use the -xalias_level=weak option,  the  com-
             piler  assumes  that any structure pointer can point
             to any structure type. Any structure or  union  type
             that contains a reference to any type that is either
             referenced in an expression in the source being com-
             piled or is referenced from outside the source being
             compiled, must be declared prior to  the  expression
             in the source being compiled.

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

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


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

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


         strict
             The compiler assumes that  memory  references,  that
             involve  types  such  as structs or unions, that are
             the same when  tags  are  removed,  can  alias  each
             other.  Conversely, the compiler assumes that memory
             references involving types that  are  not  the  same
             even after tags are removed do not alias each other.
             However, any structure or union type that contains a
             reference  to  any  type  that is part of any object
             referenced in an expression in the source being com-
             piled,  or  is  referenced  from  outside the source
             being  compiled,  must  be  declared  prior  to  the
             expression in the source being compiled.

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

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


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


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


         See also: -xprefetch_auto_type



     -xannotate[={yes|no}]
         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 on Oracle  Solaris  is  -xannotate=yes.  The
         default on Linux is -xannotate=no. 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.


     -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 archi-
         tecture by allowing only the specified set  of  instruc-
         tions.  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: Use  the  -m64  or  -m32  option  to  specify  the
         intended  data  type model, LP64 (64-bits) or ILP32 (32-
         bits) respectively. The -xarch flag no longer  indicates
         the  data type model, except for compatibility with pre-
         vious releases, as indicated below.

         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.

         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 for all platforms:
         generic
                      This option uses the instruction set common
                      to most processors. This is the default and
                      is equivalent to -xarch=sse2 on  x86  plat-
                      forms  and  -xarch=sparcvis2 on SPARC plat-
                      forms.


         native
                      Compile for good performance on  this  sys-
                      tem.

                      The compiler chooses the  appropriate  set-
                      ting for the current system processor it is
                      running on.


         Values specific to SPARC platforms:



         sparc
             Compile for the SPARC-V9 ISA.

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


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


         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)
             version  1.0, the UltraSPARC-III extensions, includ-
             ing 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)
             version  1.0, the UltraSPARC-III extensions, includ-
             ing 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  conjunc-
             tion  with -fma=fused and some optimization level to
             get the compiler to attempt to find opportunities to
             use the multiply-add instructions automatically.


         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.


         sparc4b
             Compile for the SPARC4B 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 SPARC64 VI
             extensions  for  floating-point  multiply-add,   the
             SPARC64 VII extensions for integer multiply-add, and
             the PAUSE and CBCOND instructions from the SPARC  T4
             extensions.

         sparc4c
             Compile for the SPARC4C 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 SPARC64 VI
             extensions  for  floating-point  multiply-add,   the
             SPARC64 VII extensions for integer multiply-add, the
             VIS3B subset of the VIS 3.0 instructions a subset of
             the  SPARC T3 extensions, called the VIS3B subset of
             VIS 3.0, and the PAUSE and CBCOND instructions  from
             the SPARC T4 extensions.


         sparc5
             Compile for the SPARC5 version of the SPARC-V9 ISA.

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


         sparcace
             Compile for the sparcace  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)
             version  1.0, the UltraSPARC-III extensions, includ-
             ing the Visual Instruction Set  (VIS)  version  2.0,
             the   SPARC64   VI   extensions  for  floating-point
             multiply-add, the SPARC64 VII extensions for integer
             multiply-add, and the SPARC64 X extensions for SPAR-
             CACE floating-point.


         sparcaceplus
             Compile for the sparcaceplus 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)
             version  1.0, the UltraSPARC-III extensions, includ-
             ing the Visual Instruction Set  (VIS)  version  2.0,
             the   SPARC64   VI   extensions  for  floating-point
             multiply-add, the SPARC64 VII extensions for integer
             multiply-add,  the SPARC64 X extensions for SPARCACE
             floating-point, and the SPARC64  X+  extensions  for
             SPARCACE floating-point.



         sparcace2
             Compile for the sparcace2 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)
             version  1.0, the UltraSPARC-III extensions, includ-
             ing the Visual Instruction Set  (VIS)  version  2.0,
             the   SPARC64   VI   extensions  for  floating-point
             multiply-add, the SPARC64 VII extensions for integer
             multiply-add,  the SPARC64 X extensions for SPARCACE
             floating-point, the SPARC64 X+ extensions for  SPAR-
             CACE  floating-point, and the SPARC64 XII extensions
             for SPARCACE floating-point.



         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)
             version  1.0, the UltraSPARC-III extensions, includ-
             ing 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
             data type model need only use -m64.


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

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


         Notes:

         Object binary files (.o) compiled with  generic,  sparc,
         sparcvis2,  sparcvis3,  sparcfmaf,  and  sparcima can be
         linked and can execute together but can only  run  on  a
         processor supporting all the instruction sets linked.

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

         Values specific to x86 platforms:




         avx512
             May use 386,  MMX,  Pentium_pro,  SSE,  SSE2,  SSE3,
             SSSE3,   SSE4.1,   SSE4.2,   AES,   PCLMULQDQ,  AVX,
             FSGSBASE, RDRND,  F16C,  AVX2,  BMI1,  BMI2,  LZCNT,
             INVPCID,  FMA,  ADX, RDSEED, PREFETCHW, PREFETCHWT1,
             AVX512F, AVX512CDI, AVX512VLI, AVX512BW and AVX512DQ
             instructions.



         avx2_i
             May use 386,  MMX,  Pentium_pro,  SSE,  SSE2,  SSE3,
             SSSE3,   SSE4.1,   SSE4.2,   AES,   PCLMULQDQ,  AVX,
             FSGSBASE, RDRND,  F16C,  AVX2,  BMI1,  BMI2,  LZCNT,
             INVPCID, FMA, ADX, RDSEED, PREFETCHW and PREFETCHWT1
             instructions.


         avx2
             May use 386,  MMX,  Pentium_pro,  SSE,  SSE2,  SSE3,
             SSSE3,   SSE4.1,   SSE4.2,   AES,   PCLMULQDQ,  AVX,
             FSGSBASE, RDRND,  F16C,  AVX2,  BMI1,  BMI2,  LZCNT,
             INVPCID, and FMA instructions.

         avx_i
             May use 386,  pentium_pro,  MMX,  SSE,  SSE2,  SSE3,
             SSSE3,  SSE4.1,  SSE4.2,  AES,  PCLMULQDQ, FSGSBASE,
             RDRND, and F16C instructions.


         avx
             May use 386,  pentium_pro,  MMX,  SSE,  SSE2,  SSE3,
             SSSE3,  SSE4.1,  SSE4.2, AES, and PCLMULQDQ instruc-
             tions.


         aes
             May use 386,  MMX,  Pentium_pro,  SSE,  SSE2,  SSE3,
             SSSE3,  SSE4.1,  SSE4.2, AES, and PCLMULQDQ instruc-
             tions.


         sse4_2
             May use 386,  MMX,  Pentium_pro,  SSE,  SSE2,  SSE3,
             SSSE3, SSE4.1, and SSE4.2 instructions.


         sse4_1
             May use 386,  MMX,  Pentium_pro,  SSE,  SSE2,  SSE3,
             SSSE3, and SSE4.1 instructions.


         ssse3
             May use 386, MMX, Pentium_pro, SSE, SSE2, SSE3,  and
             SSSE3 instructions.


         sse3
             May use 386, MMX, Pentium_pro, SSE, SSE2,  and  SSE3
             instructions.



         sse2
             May  use  386,  MMX,  Pentium_pro,  SSE,  and   SSE2
             instructions.



         sse
              Obsolete.  Use -xarch=generic instead.

         ssea
             May use 386, MMX, Pentium_pro, SEE, and  AMD  exten-
             sion:  3DNow!, 3DNow! extension instructions for AMD
             processors.


         pentium_pro
              Obsolete.  Use -xarch=generic instead.



         generic
             Uses the instruction set common to most processor.


         native
             Uses the instructions available on the current  sys-
             tem processor the compiler is running on.


         Notes:

         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  archi-
         tectures  (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/x64 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=T3 expands to -xarch=sparcvis3   -
         xchip=T3   -xcache=8/16/4:6144/64/24.  In  the following
         command  -xarch=sparc4  overrides  the  -xarch=sparcvis3
         that is set by the expansion of -xtarget=T3.

           example% cc -xtarget=T3 -xarch=sparc4 foo.c

         Warnings:

         If this option is used with optimization, the  appropri-
         ate  choice  can provide good performance of the execut-
         able on the  specified  architecture.  An  inappropriate
         choice,  however, might result in serious degradation of
         performance or in in a binary program that is  not  exe-
         cutable on all intended target platforms.


     -xatomic=a
         Specify which atomics support runtime library is linked.

         a must be one of the following:



         studio
                   Link with the libstatomic library bundled with
                   Oracle Developer Studio.


         gcc
                   Link with the libatomic library in /usr/lib.


         none
                   Do not link with any atomics support library.


         The option -xatomic=none is  the  default  when  neither
         -latomic nor -xatomic is specified.

         -latomic   will   be   automatically    translated    to
         -xatomic=studio.

         An explicit -xatomic option should override the presence
         of -latomic regardless of the order on the command line.
         A warning message will be  emitted  if  the  setting  of
         -xatomic is conflict with -latomic.

         When the Oracle Solaris operating system includes a com-
         patible standard interface and the Linux bundled library
         conforms to a  standard  interface,  the  need  for  the
         -xatomic option will be redundant.


     -xautopar
         Turns on automatic loop parallelization. Analyzes  loops
         for  inter-iteration  data dependence and does loop res-
         tructuring. If optimization is not at  -xO3  or  higher,
         optimization is raised to -xO3 and a warning is issued.

         Note that -xautopar does not enable the  recognition  of
         OpenMP  pragmas.  To  enable  the  recognition of OpenMP
         pragmas, use the -xopenmp compiler option.

         Use the OMP_NUM_THREADS environment variable to  specify
         the  number  of  threads  to  use when running a program
         automatically parallelized  by  the  -xautopar  compiler
         option.  If  OMP_NUM_THREADS  is  not  set,  the default
         number of threads used is a multiple of  the  number  of
         cores  per  socket  (that is, cores per processor chip),
         which is less than or equal to the total number of cores
         or  32,  whichever  is less. You can specify a different
         number  of  threads  by  setting   the   OMP_NUM_THREADS
         environment  variable.  For best performance, the number
         of threads used should not exceed the number of hardware
         threads   (or   virtual  processors)  available  on  the
         machine. On Oracle Solaris systems, this number  can  be
         determined  by  using  the  psrinfo(1M) command. See the
         Oracle Developer Studio
                         12.6:
                         OpenMP API User's Guide for more  infor-
         mation.

         If you compile and link in separate steps, specify -xau-
         topar  in  both  the compilation step and the link step.
         When used with the link step, the -xautopar option  will
         link   with   the   OpenMP   runtime   support  library,
         libmtsk.so.



     -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  functions  where  profitable for perfor-
         mance. See the er_src(1) man page to learn how  to  read
         compiler  commentary output to determine 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  intrin-
         sics  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  inter-
         pose   on  global  functions  may  result  in  undefined
         behavior.


     -xCC
         When you specify -std=c89  , c90, gnu89, or  gnu99   and
         -xCC,  the  compiler  accepts the C++-style comments. In
         particular, the "//" can be used to indicate  the  start
         of a comment.


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

         o can be a comma separated list comprised of the follow-
         ing:



         [no_]lib
             (Oracle Solaris) Enable the 1999 C standard  library
             semantics of routines that appeared in both the 1990
             and 1999 C standard. no_lib limits semantics to  the
             1990 C standard. This flag has no effect on linux.


         all
             Turn  on  recognition  of  supported  C99   language
             features  and  enable  the  1999  C standard library
             semantics of routines that appear in both  the  1990
             and 1999 C standard.

         none
             Turn off recognition of C99 language  features,  and
             do  not enable the 1999 C standard library semantics
             of routines that appeared in both the 1990 and  1999
             C standard.


         If you do not specify -xc99, the  compiler  defaults  to
         -xc99=all,no_lib.

         If you specify -xc99 without any values, the  option  is
         set to -xc99=all.

         The -xc99 flag cannot be used if the -std or -xlang flag
         has been specified.


     -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 par-
         ticular cache property is used.

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

         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. You can sub-
         stitute one of the following values for 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.


         s
                     Equivalent to signed.


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


         u
                     Equivalent to unsigned.


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

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

         If you use -xchar, be particularly careful when you com-
         pare  a  char  against a predefined system macro because
         the value in the macro may be signed. This is most  com-
         mon  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 Oracle 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 that  it  does  not  depend  on
         whether  type  char  is  signed or unsigned. The sign of
         type char varies among compilers and operating systems.

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


         low
                    Place the  characters  of  a  multi-character
                    character-constant in low-to-high byte order.


         high
                    Place the  characters  of  a  multi-character
                    character-constant in high-to-low byte order.


         default
                    Place the  characters  of  a  multi-character
                    character-constant  in an order determined by
                    the compilation mode -X[a|c|s|t].




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

         n must be one of the following values.



         %all
             Perform all -xcheck checks.


         %none
             Do not perform any of the -xcheck checks.


         stkovf[action]
             Generate code to detect  stack  overflow  errors  at
             runtime, optionally specifying an action to be taken
             when a stack overflow error is detected.

             A stack overflow error occurs when a thread's  stack
             pointer  is  set beyond the thread's allocated stack
             bounds. The error may not be detected if the new top
             of stack address is writable.

             A stack overflow  error  is  detected  if  a  memory
             access  violation  occurs  as a direct result of the
             error, raising an associated  signal  (usually  SIG-
             SEGV).  The signal thus raised is said to be associ-
             ated with the error.

             An undetected stack overflow  error  may  result  in
             silent  data corruption. Preventing undetected stack
             overflow errors requires compiler and  runtime  sup-
             port.

             If -xcheck=stkovf[action] is specified, the compiler
             generates  code  to  detect stack overflow errors in
             cases involving stack frames larger than the  system
             page size. The code includes a library call to force
             a memory access violation  instead  of  setting  the
             stack  pointer  to an invalid but potentially mapped
             address (see _stack_grow(3C)).

             The optional action, if specified, must  be  one  of
             the following:



             :detect
                 If action is :detect, a detected stack  overflow
                 error is handled by executing the signal handler
                 normally associated with the error.

                 On  SPARC  Solaris,   -xcheck=stkovf:detect   is
                 enabled by default. This prevents silent corrup-
                 tion of the stack due to stack overflow. It  can
                 be disabled by specifying -xcheck=no%stkovf.


             :diagnose
                 If action is :diagnose, a detected  stack  over-
                 flow error is handled by catching the associated
                 signal and calling stack_violation(3C) to  diag-
                 nose  the error. This is the default behavior if
                 no action is specified.

                 If a memory access violation is diagnosed  as  a
                 stack  overflow  error, the following message is
                 printed to stderr:

                 ERROR: stack overflow detected:  pc=<inst_addr>,
                 sp=<sp_addr>
                 where <inst_addr> is the address of the instruc-
                 tion where the error was detected, and <sp_addr>
                 is the value of the stack pointer  at  the  time
                 that  the error was detected. After checking for
                 stack overflow and printing the above message if
                 appropriate,   control   passes  to  the  signal
                 handler normally associated with the error.


             -xcheck=stkovf:detect adds a stack bounds  check  on
             entry to routines with stack frames larger than sys-
             tem page size (see  _stack_grow(3C)).  The  relative
             cost of the additional bounds check should be negli-
             gible in most applications.

             -xcheck=stkovf:diagnose adds a system call to thread
             creation  (see sigaltstack(2)). The relative cost of
             the additional system call depends on how frequently
             the application creates and destroys new threads.

             -xcheck=stkovf is supported only on Oracle  Solaris.
             The  C  runtime  library  on  Linux does not support
             stack overflow                     detection.


         no%stkovf
             Turns off stack-overflow checking.


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

             Exercise caution when using  -xcheck  with  a  large
             amount  of local data, such as arrays with more than
             10,000  elements.  This  can  cause  the  compiler's
             internal  representation  of  the  program to become
             very large when  that  local  date  is  initialized,
             which can result in significantly longer compilation
             times, especially when  combined  with  optimization
             levels greater than -02.


         no%init_local
             Do not initialize local variables.

         noreturn
             Inform the compiler to add code to cause  a  runtime
             error  if  a routine which has been described as "do
             not return" returns.

             A routine can be described as "do not return" by any
             of the following:


                 o    __attribute__ ((noreturn))


                 o    #pragma does_not_return


                 o    using the C11 qualifier _Noreturn

             Undefined behaviour will result if a routine returns
             after   being   described   as  not  returning.  The
             -xcheck=noreturn flag tells the compiler to  add  an
             illegal  instruction  after every call to a function
             marked as does not return to force the target appli-
             cation to abort if that function returns.


         If you do not specify -xcheck, the compiler defaults  to
         -xcheck=%none  and  if  you  specify -xcheck without any
         arguments, the compiler defaults to -xcheck=%all, unless
         you  are on an Oracle Solaris system for SPARC, in which
         case, the compiler will default to -xcheck=stkovf:detect
         for both cases.

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


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

         c must be one of the values listed below.

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

         This option specifies timing  properties  by  specifying
         the target processor.

         Some effects are:

             o    The ordering of instructions, that is, schedul-
                  ing


             o    The way the compiler uses branches


             o    The instructions to use in cases where semanti-
                  cally equivalent alternatives are available

         The -xchip values for SPARC platforms are:



         generic
             Set the parameters for  the  best  performance  over
             most  SPARC  platform  architectures.  This  is  the
             default.


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


         sparc64vi (Obsolete)
             Optimize for the SPARC64 VI processor.


         sparc64vii (Obsolete)
             Optimize for the SPARC64 VII processor.


         sparc64viiplus
             Optimize for the SPARC64 VII plus processor.


         sparc64x
             Optimize for the SPARC64 X processor.


         sparc64xplus
             Optimize for the SPARC64 X+ processor.



         sparc64xii
             Optimize for the SPARC64 XII processor.

         ultraT1 (Obsolete)
             Optimize for the UltraSPARC T1 processor.


         ultraT2 (Obsolete)
             Optimize for the UltraSPARC T2 processor.


         ultraT2plus (Obsolete)
             Optimize for the UltraSPARC T2+ processor.


         T3 (Obsolete)
             Optimize for the SPARC T3 processor.


         T4
             Optimize for the SPARC T4 processor.


         T5
             Optimize for the SPARC T5 processor.


         T7
             Optimize for the SPARC T7 processor.



         T8
             Optimize for the SPARC T8 processor.



         M5
             Optimize for the SPARC M5 processor.


         M6
             Optimize for the SPARC M6 processor.


         M7
             Optimize for the SPARC M7 processor.

         M8
               Optimize for the SPARC M8 processor.


         The -xchip values for x86 platforms are:


         generic
             Optimize for most x86 platforms.


         native
             Optimize for this host processor.


         core2
             Optimize for the Intel Core2 processor.


         nehalem
             Optimize for the Intel Nehalem processor.



         penryn
             Optimize for the Intel Penryn processor.


         pentium
              Obsolete.  Use -xchip=generic instead.


         pentium_pro
              Obsolete.  Use -xchip=generic instead.


         pentium3
              Obsolete.  Use -xchip=generic instead.


         pentium4
             Optimize for the Intel Pentium 4 style processor.


         sandybridge
             Optimize for the Intel Sandy Bridge processor.

         ivybridge
             Optimize for the Intel Ivy Bridge processor.


         haswell
             Optimize for the Intel Haswell processor.


         westmere
             Optimize for the Intel Westmere processor.


         amdfam10
             Obsolete. Use -xchip=generic instead.


         broadwell
             Optimize for the Intel Broadwell processor.



         skylake
             Optimize for the Intel Skylake processor.





     -xcode=v
         (SPARC) Specify 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   xarch=v9                 -
         xcode=abs32 or -m64 -xcode=abs44 will not work.

         The values for -xcode are:



         abs32
             This is the default for  32-bit  systems.  Generates
             32-bit absolute addresses. Code + data + bss size is
             limited to 2**32 bytes.

         abs44
             This is the default for  64-bit  systems.  Generates
             44-bit absolute addresses. Code + data + bss size is
             limited to 2**44 bytes.  Available  only  on  64-bit
             architectures.


         abs64
             Generates 64-bit absolute addresses. Available  only
             on 64-bit architectures.


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


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


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

         When building  shared  dynamic  libraries,  the  default
         -xcode  value  of  abs44  (not abs32) will not work with
         64-bit   architectures.    Specify    -xcode=pic13    or
         -xcode=pic32 instead.

         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  to  look  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 exceeds
                  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.



     -xcsi
         This option allows the C compiler to accept source  code
         written  in  locales  that  do  not conform to the ISO C
         source  character  code  requirements.   These   locales
         include ja_JP.PCK.

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

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



     -xcompress={[no%]debug}
         Compresses debug sections using the format specified  by
         the  -xcompress_format option if supported by the under-
         lying Operating System. A sub-option  is  required.  The
         option  is  ignored with a warning when Operating System
         support is unavailable.


     -xcompress_format=cmp-type
         When -xcompress=debug is in effect, this options  speci-
         fies how the debug section is to be compressed.

         The following values for cmp-type are recognized:
         none
                     No compression of the debug section is done.


         zlib
                     Compresses  the  debug  section  using  ZLIB
                     compression.


         zlib-gnu
                     Compresses the section using  ZLIB  compres-
                     sion, using the GNU section compression for-
                     mat.


         On Oracle Solaris, when  compilation  involves  linking,
         the debug sections are compressed using the ld option -z
         compress-sections=cmp-type. For  more  information,  see
         the ld(1) man page.

         On Oracle Solaris, when  compiling  to  an  object  file
         (.o),   the   debug   sections   are   compressed  using
         elfcompress -t cmp-type. For more information,  see  the
         elfcompress(1) man page.

         On Linux, the objcopy command is used to compress  debug
         sections  of each .o file using theobjcopy             -
         -compress-debug-sections. For more information, see  the
         objcopy(1g) man page.

         The option is ignored with a warning when Operating Sys-
         tem support is unavailable.



     -xdebugformat=dwarf
         -xdebugformat=dwarf  generates   debugging   information
         using  the  dwarf  standard format. This is the default.
         The option is obsolete.

         See also the  dwarfdump (1)  man page for more  informa-
         tion.


     -xdebuginfo=a[,a...]
         Control how much debugging and observability information
         is emitted.

         The  term  tagtype  refers  to  tagged  types:  structs,
         unions, enums, and classes.

         The following list  contains  the  possible  values  for
         suboptions a. The prefix no% applied to a suboption dis-
         ables that suboption. The default is  -xdebuginfo=%none.

         Specifying  -xdebuginfo  without a sub-option is forbid-
         den.



         %none
             No debugging information is generated. This  is  the
             default.


         [no%]line
             Emit line number and file information.


         [no%]param
             Emit location list info for  parameters.  Emit  full
             type  information  for  scalar  values (for example,
             int, char *) and type names but not full definitions
             of tagtypes.


         [no%]variable
             Emit location list information for lexically  global
             and  local  variables,  including  file and function
             statics but excluding  class  statics  and  externs.
             Emit full type information for scalar values such as
             int and char * and type names but not  full  defini-
             tions of tagtypes.


         [no%]decl
             Emit information for function and variable  declara-
             tions,  member functions, and static data members in
             class declarations.


         [no%]tagtype
             Emit full type definitions  of  tagtypes  referenced
             from  param  and  variable datasets, as well as tem-
             plate definitions.


         [no%]macro
             Emit macro information.


         [no%]codetag
             Emit DWARF codetags (also known as  Stabs  N_PATCH).

             This  is  information regarding bitfields, structure
             copy, and spills used by RTC and discover.


         [no%]hwcprof
             Generate information critical  to  hardware  counter
             profiling.  This  information  includes  ldst_map, a
             mapping from ld/st instructions to the symbol  table
             entry  being  referenced, and branch_target table of
             branch-target addresses used to  verify  that  back-
             tracking   did   not   cross  a  branch-target.  See
             -xhwcprof for more information.

             Note: ldst_map  requires  the  presence  of  tagtype
             information.  The driver will issue an error if this
             requirement is not met.


         These are macros which expand to combinations of -xdebu-
         ginfo and other options as follows:


           -g = -g2

           -gnone =
                   -xdebuginfo=%none
                   -xglobalize=no
                   -xpatchpadding=fix
                   -xkeep_unref=no%funcs,no%vars

           -g1 =
                   -xdebuginfo=line,param,codetag
                   -xglobalize=no
                   -xpatchpadding=fix
                   -xkeep_unref=no%funcs,no%vars

           -g2 =
                   -xdebuginfo=line,param,decl,variable,tagtype,codetag
                   -xglobalize=yes
                   -xpatchpadding=fix
                   -xkeep_unref=funcs,vars

           -g3 =

                   -xdebuginfo=line,param,decl,variable,tagtype,codetag,macro
                   -xglobalize=yes
                   -xpatchpadding=fix
                   -xkeep_unref=funcs,vars

     -xdepend[=[yes|no]]
         Analyzes loops for inter-iteration data dependencies and
         performs 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 compiler sets the option
         to -xdepend=yes which means the compiler analyzes  loops
         for data dependencies.

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

         Dependency analysis may help  on  single-processor  sys-
         tems.  However,  if you try -xdepend on single-processor
         systems, you should not also specify -xautopar ,  other-
         wise  the  -xdepend  optimization  is done for multiple-
         processor systems.

         See also: -xprefetch_auto_type


     -xdryrun
         This option is a macro for -###.


     -xdumpmacros[=value[,value...]]
         Use this option when you want  to  see  how  macros  are
         behaving  in your program. This option provides informa-
         tion such as macro defines, undefines, and instances  of
         usage.  It prints output to the standard error (stderr),
         based on the order macros are processed. The  -xdumpmac-
         ros  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.



         [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 conditional
             directives.


         [no%]sys
             Print all macros defines, undefines, and use  infor-
             mation for macros in system header files.


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


         %none
             Do not print any macro information.


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

         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 -xdumpmacros, it defaults to -xdumpmacros=%none.


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


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

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

         Reordering functions and variables for  optimal  perfor-
         mance 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 follow-
                  ing  the  instructions  in   the   Linker   and
                  Libraries
                                    Guide regarding how  to  gen-
                  erate 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.


         v can be one of the following values.  Prefix  no%  dis-
         ables the suboption.



         [no%]func
             Fragment functions into separate sections.


         [no%]gbldata
             Fragment global data (variables with external  link-
             age) into separate sections.


         %all
             Fragment functions and global data.


         %none
             Fragment nothing.


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

         See also: analyzer(1), ld(1)


     -xglobalize[={yes|no}]
         Control globalization of  function-level  or  file-level
         static variables.

         Globalization is a technique needed by fix and  continue
         functionality  in the debugger whereby function-level or
         file-level static symbols are promoted to globals  while
         a  prefix is added to the name to keep identically named
         symbols distinct.

         The default is -xglobalize=no. Specifying -xglobalize is
         equivalent to specifying -xglobalize=yes.

         Interactions:

         See -xpatchpadding.

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



     -xhelp=gccflags
         Displays a summary of addtional gcc  flags  accepted  by
         Studio that is not shown by the -xhelp=flags.



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

         When -xhwcprof is enabled, the compiler generates infor-
         mation  that  helps  tools  associate  profiled load and
         store instructions with  the  data-types  and  structure
         members  (in  conjunction with symbolic information pro-
         duced with -g) to which they refer. It  associates  pro-
         file 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 instruc-
         tion profiling.

         You can compile a specified set  of  object  files  with
         -xhwcprof however, -xhwcprof is most useful when applied
         to all object files in the  appli`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 Developer Studio compilers.

         -xhwcprof uses -xdebuginfo to automatically  enable  the
         minimum  amount of debugging information it needs, so -g
         is not required.

         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.

         -xhwcprof is implemented as  a  macro  that  expands  to
         various other, more primitive, options as follows:



           -xhwcprof
                   -xdebuginfo=hwcprof,tagtype,line

           -xhwcprof=enable
                   -xdebuginfo=hwcprof,tagtype,line
           -xhwcprof=disable
                   -xdebuginfo=no%hwcprof,no%tagtype,no%line


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


           example% cc -c -O -xhwcprof -g -xdebugformat=dwarf example.c

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


     -xinline[=v[,v]...]
         v can be [{%auto,func_name,no%func_name}].

         -xinline tries to inline only those functions  specified
         in  the  list.  The list is comprised of either a comma-
         separated list of function names, or a  comma  separated
         list  of no%func_name values, or the value %auto. If you
         specify %nofunc_name, the compiler is not to inline  the
         named function. If you specify %auto, the compiler is to
         attempt to automatically inline  all  functions  in  the
         source files.

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

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

         A function is inlined if any of the following apply:


             o    Optimization is set at -xO3 or higher.


             o    Inlining the funciton is judged to  be  profit-
                  able and safe.


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

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

         See also: -xldscope.


     -xinline_param=a[,a[,a]...]
         Use this option to manually change the  heuristics  used
         by  the  compiler for deciding when to inline a function
         call.

         This option only has an effect at  -O3  or  higher.  The
         following  sub-options  have  an  effect  only at -O4 or
         higher when automatic inlining is on.

         In the  following  sub-options  n  must  be  a  positive
         integer; a can be one of the following:



         default
             Set the values  of  all  the  sub-options  to  their
             default values.


         max_inst_hard[:n]
             Automatic inlining only considers functions  smaller
             than  n  pseudo  instructions (counted in compiler's
             internal representation) as possible  inline  candi-
             dates.

             Under no circumstances will a function  larger  than
             this be considered for inlining.

         max_inst_soft[:n]
             Set  inlined  function's  size  limit  to  n  pseudo
             instructions   (counted   in   compiler's   internal
             representation).

             Functions of greater size than this may sometimes be
             inlined.

             When interacting with max_inst_hard,  the  value  of
             max_inst_soft should be equal to or smaller than the
             value  of  max_inst_hard,  i.e,   max_inst_soft   <=
             max_inst_hard.

             In general, the compiler's  automatic  inliner  only
             inlines   calls  whose  called  function's  size  is
             smaller than the value  of  max_inst_soft.  In  some
             cases  a  function  may  be inlined when its size is
             larger than the value of max_inst_soft  but  smaller
             than that of max_inst_hard. An example of this would
             be if the parameters passed  into  a  function  were
             constants.

             When  deciding  whether  to  change  the  value   of
             max_inst_hard  or  max_inst_soft  for  inlining  one
             specific   call   site   to    a    function,    use
             -xinline_report=2  to  report detailed inlining mes-
             sage and follow the suggestion in the inlining  mes-
             sage.


         max_function_inst[:n]
             Allow functions to increase due to automatic  inlin-
             ing  by  up  to  n  pseudo  instructions (counted in
             compiler's internal representation).


         max_growth[:n]
             The automatic inliner is  allowed  to  increase  the
             size  of  the  program by up to n% where the size is
             measured in pseudo instructions.


         min_counter[:n]
             The minimum call site frequency counter as  measured
             by  profiling  feedback (-xprofile) in order to con-
             sider a function for automatic inlining.

             This option is valid only when  the  application  is
             compiled with profiling feedback (-xprofile=use).

         level[:n]
             Use  this  sub-option  to  control  the  degree   of
             automatic  inlining  that  is  applied. The compiler
             will inline more functions with higher settings  for
             -xinline_param=level.

             n must be one of 1, 2, or 3.

             The default value of n is 2 when this option is  not
             specified,  or when the options is specified without
             :n.

             Specify the level of automatic inline



               level:1    basic inlining
               level:2    medium inlining (default)
               level:3    aggressive inlining


             The level decides the specified values for the  com-
             bination of the following inlining parameters:



               max_growth
               + max_function_inst
               + max_inst
               + max_inst_call


             When level = 1, all  the  parameters  are  half  the
             values  of  the  default.  When  level  = 2, all the
             parameters are the default value. When  level  =  3,
             all  the  parameters  are  double  the values of the
             default.


         max_recursive_depth[:n]
             When a function  calls  itself  either  directly  or
             indirectly,  it  is  said  to  be making a recursive
             call.

             This  sub-option  allows  a  recursive  call  to  be
             automatically inlined up to n levels.


         max_recursive_inst[:n]
             Specifies the maximum number of pseudo  instructions
             (counted  in compiler's internal representation) the
             caller of a recursive function can grow to  by  per-
             forming automatic recursive inlining.

             When  interactions  between  max_recursive_inst  and
             max_recursive_depth  occur, recursive function calls
             will be inlined until either the max_recursive_depth
             number  of recursive calls, or until the size of the
             function     being     inlined     into      exceeds
             max_recursive_inst. The settings of these two param-
             eters control the degree of inlining of small recur-
             sive functions.


         If -xinline_param=default  is  specified,  the  compiler
         will  set  all  the  values  of  the  sub-opitons to the
         default values.

         If  the  option  is  not  specified,  the   default   is
         -xinline_param=default.

         The list of values and options accumulate from  left  to
         right.      So      for      a      specification     of
         -xinline_param=max_inst_hard:30,..,max_inst_hard:50, the
         value max_inst_hard:50 will be passed to the compiler.

         If multiple -xinline_param options are specified on  the
         command  line,  the list of sub-options likewise accumu-
         late from left to right. For example, the effect of



           -xinline_param=max_inst_hard:50,min_counter:70 ...
              -xinline_param=max_growth:100,max_inst_hard:100


         will be the same as that of

         -xinline_param=max_inst_hard:100,min_counter:70,max_growth:100


     -xinline_report[=n]
         This option generates a report written to standard  out-
         put  on  the  inlining of functions by the compiler. The
         type of report depends on the value of n, which must  be
         0, 1, or 2.



         0
                      No report is generated.

         1
                      A  summary  report  of  default  values  of
                      inlining parameters is generated.


         2
                      A detailed report of inlining  messages  is
                      generated,   showing  which  callsites  are
                      inlined and which are  not,  with  a  short
                      reason for not inlining a callsite. In some
                      cases, this report will  include  suggested
                      values  for -xinline_param that can be used
                      to inline a callsite that is not inlined.


         When -xinline_report is not specified, the default value
         for  n  is  0. When -xinline_report is specified without
         =n, the default value is 1.

         When -xlinkopt is present, the inlining  messages  about
         the  callsites  that  are not inlined might not be accu-
         rate.


     -xinstrument=[no%]datarace]
         Specify this option to compile and instrument your  pro-
         gram  for  analysis  by  the  Thread  Analyzer. For more
         information on  the  Thread  Analyzer,  see  tha(1)  for
         details.

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

         You can specify  -xinstrument=no%datarace  to  turn  off
         preparation of source code for the thread analyzer. This
         is the default.

         It is illegal to specify -xinstrument without  an  argu-
         ment.

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

         This option also sets -g.

         Interactions:
         -xinstrument cannot be used together with -xlinkopt.


     -xipo[=n]
         The compiler performs partial-program  optimizations  by
         invoking  an  interprocedural analysis pass. It performs
         optimizations across all object files in the link  step,
         and  is not limited to just the source files on the com-
         pile command. However, whole-program optimizations  per-
         formed  with  -xipo  do not include assembly (.s) source
         files.

         You must specify -xipo both 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 Oracle Developer
                         Studio
                         12.6:
                         C User's Guide.

         Analysis and optimization is limited to the object files
         compiled with -xipo, and does not extend to object files
         or libraries. -xipo  is  multiphased,  so  you  need  to
         specify  -xipo  for each step if you compile and link in
         separate steps.

         The -xipo option generates significantly  larger  object
         files  due  to the additional information needed to per-
         form optimizations across  files.  However,  this  addi-
         tional  information  does  not  become part of the final
         executable binary file. Any increase in the size of  the
         executable  program  is  due to the additional optimiza-
         tions performed. The object files created in the  compi-
         lation  steps  have additional analysis information com-
         piled within them to permit crossfile  optimizations  to
         take place at the link step.

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

         With -xipo=1, the compiler performs inlining across  all
         source  files.  At -xipo=2, the compiler performs inter-
         procedural aliasing analysis as well as optimization  of
         memory  allocation  and  layout to improve cache perfor-
         mance.

         Here are some important considerations for -xipo:


             o    It requires an optimization level of  at  least
                  -xO4.

             o    Objects that are compiled without -xipo can  be
                  linked  freely  with  objects that are compiled
                  with -xipo.

         In this example, compilation and linking occur in a sin-
         gle step:


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


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



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


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

         If you have .o files compiled with the -xipo option from
         different  compiler  versions,  mixing  these  files can
         result in failure with an error message about  "IR  ver-
         sion  mismatch".  When  using  the -xipo option, all the
         files should be compiled with the same  version  of  the
         compiler.

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



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


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

         When Not To Use -xipo=2 Interprocedural Analysis:

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


             1.   foo() is not called explicitly by another  rou-
                  tine 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 assump-
         tion (2) is not true.

         As an example, consider interposing on the function mal-
         loc()  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.

         See also: -xjobs and -xipo_archive


     -xipo_archive[=a]
         The -xipo_archive option enables the compiler to  optim-
         ize  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  compilation
             are replaced with an optimized version.

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


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

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

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


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

         It is illegal to specify -xipo_archive without a flag.


     -xipo_build=[yes|no]
         Building -xipo without -xipo_build involves  two  passes
         through  the  compiler -- once when producing the object
         files, and then again later at link time when performing
         the cross file optimization. Setting -xipo_build reduces
         compile time by avoiding optimizations during  the  ini-
         tial pass and optimizing only at link time. Optimization
         is not needed for the object files,  as  with  -xipo  it
         will  be  performed  at link time. If unoptimized object
         files built with -xipo_build are linked without  includ-
         ing  -xipo to perform optimization, the application will
         fail to link with an unresolved symbol error.

         Examples:

         The following example performs a fast build of .o files,
         followed by crossfile optimization at link time:



           % cc -O -xipo -xipo_build -o code1.o -c code1.c
           % cc -O -xipo -xipo_build -o code2.o -c code2.c
           % cc -O -xipo -o a.out code1.o code2.o


         The -xipo_build will turn off -O when  creating  the  .o
         files, to build these quickly. Full -O optimization will
         be performed at link time as  part  of  -xipo  crossfile
         optimization.

         The following example links without using -xipo.



           % cc -O -o a.out code1.o code2.o


         If  either  code1.o  or  code2.o  were  generated   with
         -xipo_build,  the  result  will  be  a link-time failure
         indicating  the  symbol   __unoptimized_object_file   is
         unresolved.

         When building .o files separately, the default  behavior
         is  -xipo_build=no.  However,  when  the  executable  or
         library is built in a single  pass  from  source  files,
         -xipo_build will be implicitly enabled. For example:

           % cc -fast -xipo a.c b.c c.c


         will implicitly enable  -xipo_build=yes  for  the  first
         passes  that  generate  a.o,  b.o,  and c.o. Include the
         option -xipo_build=no to disable this behavior.


     -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 perform various loop optimizations
         such as microvectorization, distribution, software pipe-
         lining,  etc., which would not be otherwise 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  depen-
                     dences.


         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|auto}
         Compile with multiple processes. If  this  flag  is  not
         specified, the default behavior is -xjobs=auto.

         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  number  of  available  processors  can
         degrade  performance  because of context switching over-
         head among spawned jobs. Also, using a very high  number
         can  exhaust the limits of system resources such as swap
         space.

         When  -xjobs=auto  is  specified,  the   compiler   will
         automatically  choose the appropriate number of parallel
         jobs.

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

         If -xjobs is not  specified,  the  default  behavior  is
         -xjobs=auto.  This  can be overridden by adding -xjobs=n
         to the command line. Multiple instances of -xjobs on the
         command  line  override  each  other until the rightmost
         instance is reached.

         Examples:

         The following  example  links  with  up  to  3  parallel
         processes for -xipo:



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


         The following example links serially with a single  pro-
         cess for -xipo:



           % cc -xipo -xO4 -xjobs=1 t1.o t2.o t3.o


         The  following  example  links  in  parallel,  with  the
         compiler choosing the number of jobs for -xipo:



           % cc -xipo -xO4  t1.o t2.o t3.o


         Note that this is exactly  the  same  behavior  as  when
         explicitly specifying -xjobs=auto:


           % cc -xipo -xO4 -xjobs=auto t1.o t2.o t3.o




     -xkeep_unref[={[no%]funcs,             [no%]vars}]
         Keep definitions of  unreferenced  functions  and  vari-
         ables. The no% prefix allows the compiler to potentially
         remove the definitions.

         The default is no%funcs,no%vars. Specifying -xkeep_unref
         is  equivalent  to  specifying  -xkeep_unref=funcs,vars,
         meaning that -keep_unref keeps everything.


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

         Specifying %all  prohibits  stack-related  optimizations
         for  all the code. Specifying %none allows 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  com-
         mand line multiple times. For example,


           -xkeepframe=%all -xkeepframe=no%func1

         indicates that the stack frame should be  kept  for  all
         functions  except  func1.  Also,  -xkeepframe  overrides
         -xregs=frameptr. For example,

           -xkeepframe=%all -xregs=frameptr

         indicates that the stack should be kept  for  all  func-
         tions,  but  the optimizations for -xregs=frameptr would
         not be done.


     -xlang=language
         (Oracle Solaris) The -xlang flag can be used to override
         the default libc behavior as specified by the -std flag.
         language must be one of the following:



         c89
                      Specify runtime library behavior of libc to
                      be in conformance with the C90 standard.


         c99
                      Specify runtime library behavior of libc be
                      in conformance with the C99 standard.


         c11
                      Equivalent  to  c99.  The  runtime  library
                      behavior of libc for c99 and c11 are ident-
                      ical.


         When -xlang is not specified, it defaults to the  ISO  C
         runtime  library behavior as the -std flag. For example,
         for  -std=c11,  -xlang  defaults  to   -xlang=c11,   for
         -std=gnu89  -xlang defaults to -std=c89.

         The -Xc, -Xa, -Xt, -Xs, and -xc99 flags cannot  be  used
         if -xlang has been specified. Doing so will result in an
         error being issued by the compiler.

         If you compile and link in separate steps you  must  use
         the same values for -xlang in both steps.

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



         C++
             Use the CC command. See CC(1) for details.


         Fortran 95 (or Fortran 90)
             Use the f95 command. See f95(1) for details.

         Fortran 77
             Use f95 -xlang=f77. See f95(1) for details.


         C
             Use the cc command.


         This flag is available only on  Oracle  Solaris  and  is
         silently ignored on Linux.


     -xldscope={v}
         Changes the default linker scoping for the definition of
         extern  symbols. Changing the default can result in fas-
         ter and safer shared libraries because  the  implementa-
         tion will be better hidden.

         v must be one of the following:



         global
             Global  linker  scoping  is  the  least  restrictive
             linker scoping. All references to the symbol bind to
             the definition in  the  first  dynamic  module  that
             defines  the  symbol.  This  linker  scoping  is the
             current linker scoping for extern symbols.


         symbolic
             Symbolic linker scoping and is more restrictive than
             global  linker scoping. All references to the symbol
             from within the dynamic module being linked bind  to
             the symbol defined within the module. Outside of the
             module, the symbol appears as though it were global.
             This linker scoping corresponds to the linker option
             -Bsymbolic.


         hidden
             Hidden linker scoping is more restrictive than  sym-
             bolic  and  global  linker  scoping.  All references
             within a dynamic module bind to a definition  within
             that  module. The symbol will not be visible outside
             of the module.


         If you do not specify -xldscope,  the  compiler  assumes
         -xldscope=global.  It  is not legal to specify -xldscope
         without any arguments. The compiler issues an  error  if
         you  specify  -xldscope  without  an  argument. Multiple
         instances of this option on the  command  line  override
         each other until the rightmost instance is reached.

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

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


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

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

         Library functions declared with the __hidden  or  __sym-
         bolic  specifiers  can be generated inline when building
         the library. They are not supposed to be  overridden  by
         clients. For more information, see chapter 2 "C-Compiler
         Implementation  Specific  Information"  in  the   Oracle
         Developer Studio
                         12.6:
                         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
         Forces IEEE 754 style return values for math routines in
         exceptional  cases.  In such cases, no exception message
         will be printed, and errno should not be relied on.

     -xlibmil
         Inlines some library routines for faster execution. This
         option  selects the appropriate assembly language inline
         templates for the floating-point option and platform for
         your  system.  -xlibmil inlines a function regardless of
         any specification of the function as part of  the  -xin-
         line flag.

         However, these substitutions can cause  the  setting  of
         errno  to  become unreliable. If your program depends on
         the value of errno, avoid this  option.  See  the  NOTES
         section  at  the  end of this man page for more informa-
         tion.


     -xlibmopt[={%none,archive,shared}]
         Controls whether the compiler uses a library  of  optim-
         ized math routines or the standard system math routines.
         The possible argument values are:



         %none
             Do not link with the optimized math  library.  (This
             is  the  default  when no -xlibmopt option is speci-
             fied.)


         archive
              Link with the  optimized  math  library  in  static
             archive form. (This is the default when -xlibmopt is
             specified with no argument.)


         shared
             (Oracle  Solaris)  Link  with  the  optimized   math
             library in shared object form.


         The rightmost instance of this  option  on  the  command
         line overrides all previous instances. The order of this
         option relative to other libraries specified on the com-
         mand line is not significant.

         The optimized math library includes selected  math  rou-
         tines  normally  found  in  libm. The optimized routines
         typically run faster than their libm  counterparts.  The
         results may be slightly different from those produced by
         the libm routines, although in most  cases  they  differ
         only  in  the  least  significant  bit.  When the static
         archive form of the optimized library is used, the  com-
         piler  selects  routines  that  are  optimized  for  the
         instruction set indicated by the -xarch value  specified
         when  linking.  When the shared object form is used, the
         most appropriate routines are selected at runtime  based
         on  the  instruction  set  supported by the system being
         used.

         NOTE: The shared object form is available only on Oracle
         Solaris.

         The routines in the optimized math library depend on the
         default  round-to-nearest  floating point rounding mode.
         If you use the optimized math library, you  must  ensure
         that  round-to-nearest  mode  is  in  effect when any of
         these routines is called. These  routines  also  do  not
         modify  errno.  Do  not  link  with  the  optimized math
         library if your program depends on math  functions  set-
         ting  errno  in  response  to  error conditions. See the
         NOTES section at the end  of  this  man  page  for  more
         information.

         Interactions:

         -xlibmopt=archive is implied by  the  -fast  option.  To
         disable  linking  with  the  optimized math library when
         -fast is used, add -xlibmopt=%none  following  -fast  on
         the command line:


           example% cc -fast -xlibmopt=%none ...

         See also:

         -fast




     -xlinkopt[=level]
         (Oracle  Solaris)  Instructs  the  compiler  to  perform
         link-time optimizations on relocatable object files.

         The post-optimizer performs a number of advanced perfor-
         mance  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 post-optimizer is  disabled.  (This  is
                      the default.)


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


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


         Specifying -xlinkopt without the 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 you use it to compile
         the whole program, and with profile feedback.

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



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


         For a complete list of compiler  options  that  must  be
         specified at both compile time and at link time, see the
         Oracle
                         Developer Studio
                         12.6:
                         C User's Guide.

         Note that the level parameter is only used when the com-
         piler  is  linking.  In  the  example  above,  the post-
         optimization level used is  2  even  though  the  object
         binaries were compiled with an implied level of 1.

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

         You must use -xlinkopt on at least some of the  compila-
         tion  commands  for -xlinkopt to be useful at link time.

         The optimizer can still perform some  limited  optimiza-
         tions on object binaries not compiled with -xlinkopt.

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

         The link-time post-optimizer is most effective when  you
         use  it with runtime 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  applications  where
         optimal  placement  of  code  performed at link time can
         reduce instruction cache misses. Typically,  this  would
         be compiled as follows:



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


         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 excutable by
         including debugging information.

         Interactions:

         -xlinkopt cannot be used together with -xinstrument.


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

     -xM1
         Same as -xM except that -xM1 is  not  supported  in  -Xs
         mode  nor does -xM1 report dependencies for /usr/include
         header files. For example:



           example% more hello.c
           #include <stdio.h>
           main()
           {
               (void) printf ("hello\n");
           }
           example% cc -xM hello.c
           hello.o: hello.c
           hello.o: /usr/include/stdio.h


         Compiling with -xM1 does not report header  file  depen-
         dencies:


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




     -xMD
         Generates makefile dependencies like -xM but compilation
         continues.   -xMD  generates  an  output  file  for  the
         makefile-dependency information derived from the -o out-
         put   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 multiple input files with -xMF on one com-
         mand  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 overwrit-
         ten if it already exists.

         This option cannot be used with -xM or -xM1.


     -xMMD
         Use  this  option  to  generate  makefile   dependencies
         excluding  system  header  files. This is the same func-
         tionality as -xM1, but compilation continues. -xMMD gen-
         erates an output file for the makefile-dependency infor-
         mation derived from the -o output  filename,  if  speci-
         fied,  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 gen-
         erates an error. The dependency file is  overwritten  if
         it already exists.


     -xMerge
         Directs cc to merge the data segment with the text  seg-
         ment.  Data  initialized  in the object file produced by
         this compilation is read-only and (unless linked with ld
         -N) is shared between processes.

         -xMerge, -ztext, and  -xprofile=collect  should  not  be
         used  together. While -xMerge forces statically initial-
         ized  data  into  read-only  storage,  -ztext  prohibits
         position-dependent   symbol   relocations  in  read-only
         storage, and -xprofile=collect generates statically ini-
         tialized, position-dependent symbol relocations in writ-
         able storage.


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

         If you specify both -xO and -xmaxopt,  the  optimization
         level set with -xO must not exceed the -xmaxopt value.


     -xmemalign=ab
         (SPARC) Use the -xmemalign option to control the assump-
         tions 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  speci-
         fies  the  maximum assumed memory alignment and b speci-
         fies the behavior for misaligned memory accesses.

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

         For memory accesses where the alignment cannot be deter-
         mined  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 pro-
                  gram aborts. Even if the  program  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  succeeded  nor-
                  mally.

         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
                      Equivalent to specifying i when a=1, 2,  or
                      4, and s when a=8 or 16.


         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  com-
         piler  options  that  must  be specified at both compile
         time and at link time, see the Oracle Developer Studio
                         12.6:
                         C User's Guide.

         Defaults:

         The  default  for  64-bit  SPARC  programs   (-m64)   is
         -xmemalign=8s.

         The  default  for  32-bit  SPARC  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 plat-
         forms and should only be specified for  the  compilation
         of such objects.

         This option is invalid when specified with -m32.

         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 -xmo-
         del on the command-line.

         If you do not  specify  -xmodel,  the  compiler  assumes
         -xmodel=small. Specifying -xmodel without an argument is
         an error.

         It is not necessary to  compile  all  translation  units
         with  this  option. You can compile select files as long
         as you ensure the object you  are  accessing  is  within
         reach.

         Be aware that not all Linux system  support  the  medium
         model.


     -xnolib
         Does not link any libraries by default; that is,  no  -l
         options  are  passed  to the linker ld. Normally, the cc
         driver passes -lc to ld.

         When you use -xnolib,  you  must  pass  all  -l  options
         explicitly yourself.


     -xnolibmil
         Does not inline math library  routines.  Use  -xnolibmil
         after the -fast option, as follows:

           cc -fast -xnolibmil ...



     -xnolibmopt
         (Obsolete). Use -xlibmopt=%none instead. See -xlibmopt.

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

           example% cc -fast -xnolibmopt ...



     -xnorunpath
         Do not build a runtime search path for shared  libraries
         into the executable.

         Normally cc does not pass any -R  path  to  the  linker.
         There  are  a  few  options  that do pass -R path to the
         linker  such  as  -library=sunperf  and  -xopenmp.   The
         -xnorunpath option can be used to prevent this.

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


     -xOn
         Specifies optimization level (n).  (Note  the  uppercase
         letter O, followed by a digit 1, 2, 3, 4, or 5)

         Generally, the higher the  level  of  optimization  with
         which  a program is compiled, the better runtime perfor-
         mance obtained. However, higher optimization levels  may
         result  in increased compilation time and larger execut-
         able 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  ori-
         ginal level.

         Values:



         -xO1
                      Do only the basic local optimizations.


         -xO2
                      Do basic  local  and  global  optimization.
                      This level usually gives minimum code size.


         -xO3
                      Adds global optimizations at  the  function
                      level,  and automatic inlining of functions
                      whose body is smaller than the overhead  of
                      calling  the  function.  In  general,  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. Optimization at this  level
                      is more likely to improve performance if it
                      is  done   with   profile   feedback.   See
                      -xprofile=collect|use.


         The default is no optimization. However,  this  is  only
         possible if you do not specify an optimization level. If
         you specify an optimization level, there  is  no  option
         for turning optimization off.

         If you are  trying  to  avoid  setting  an  optimization
         level, be sure not to specify any option that implies an
         optimization level. For example, -fast is a macro option
         that  sets  optimization at -xO5. All other options that
         imply an optimization level give a warning message  that
         optimization  has  been  set.  The  only  way to compile
         without any optimization is to delete all  options  from
         the  command line or make file that specify an optimiza-
         tion level.

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

         If you use -g 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  lim-
         its  -g  in  certain ways. For example, the optimization
         options reduce the utility of debugging so that you can-
         not  display  variables  from dbx, but you can still use
         the dbx where command to get a symbolic  traceback.  For
         more information, see Debugging a Program With  dbx.

         If you specify both -xO and -xmaxopt,  the  optimization
         level set with -xO must not exceed the -xmaxopt value.

         See also:

         -xldscope, -fast, -xprofile=p,  csh(1) man page

         Performance Analyzer discusses the effects of  the  dif-
         ferent levels of optimization on the Analyzer's data.


     -xopenmp[={parallel|noopt|none}]
         Enable explicit parallelization with OpenMP directives.

         The following details the -xopenmp values:



         parallel
             Enables recognition of OpenMP pragmas. The optimiza-
             tion level under -xopenmp=parallel is -xO3. The com-
             piler raises  the  optimization  level  to  -xO3  if
             necessary and issues a warning.

             This  flag  also  defines  the  preprocessor   macro
             _OPENMP.  The  _OPENMP  macro is defined to have the
             decimal value yyyymm where yyyy and mm are the  year
             and  month designations of the version of the OpenMP
             API that the implementation supports. Refer  to  the
             Oracle Developer Studio
                                   12.6:
                                   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 -xO3. If you explicitly  set  the  optimization
             lower     than     -xO3,     as     in    cc    -xO2
             -xopenmp=noopt, the compiler issues an error. If you
             do   not   specify   an   optimization   level  with
             -xopenmp=noopt, the OpenMP pragmas  are  recognized,
             the  program  is  parallelized  accordingly,  but no
             optimization is done. This  flag  also  defines  the
             preprocessor macro _OPENMP.


         none
             Does not enable the recognition of  OpenMP  pragmas,
             makes  no  change  to the optimization level of your
             program, and does not define any  preprocessor  mac-
             ros. This is the default when -xopenmp is not speci-
             fied.


         If you specify -xopenmp, but do not specify a value, the
         compiler   assumes  -xopenmp=parallel.  If  you  do  not
         specify  -xopenmp   at   all,   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  a  future
         release.  You  can  avoid warning messages by explicitly
         specifying an appropriate optimization level.

         Use the OMP_NUM_THREADS environment variable to  specify
         the number of threads to use when running an OpenMP pro-
         gram. If OMP_NUM_THREADS is not set, the default  number
         of threads used is a multiple of the number of cores per
         socket (that is, cores per  processor  chip),  which  is
         less  than  or equal to the total number of cores or 32,
         whichever is less. You can specify a different number of
         threads by setting the OMP_NUM_THREADS environment vari-
         able, or by  calling  the  omp_set_num_threads()  OpenMP
         runtime  routine,  or by using the num_threads clause on
         the parallel region directive. For best performance, the
         number  of  threads  used  to  execute a parallel region
         should not exceed the number  of  hardware  threads  (or
         virtual  processors) available on the machine. On Oracle
         Solaris systems, this number can be determined by  using
         the  psrinfo(1M)  command. On Linux systems, this number
         can be determined by inspecting the file  /proc/cpuinfo.
         See the Oracle Developer Studio
                         12.6:
                         OpenMP API User's Guide for more  infor-
         mation.

         Nested parallelism is disabled  by  default.  To  enable
         nested parallelism, you must set the OMP_NESTED environ-
         ment variable to TRUE. See the Oracle Developer Studio
                         12.6:
                         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.
         When used with the link step, the -xopenmp  option  will
         link   with   the   OpenMP   runtime   support  library,
         libmtsk.so.

         For up-to-date functionality and performance, make  sure
         that  the  latest  patch  of the OpenMP runtime library,
         libmtsk.so, is installed on the system.

         For more information about the OpenMP Fortran 95, C, and
         C++  application  program  interface  (API) for building
         multithreaded applications,  see  the  Oracle  Developer
         Studio
                         12.6:
                         OpenMP API User's Guide.

         For information that is specific to the C implementation
         of OpenMP, see the Oracle Developer Studio
                         12.6:
                         C User's Guide.


     -xP
         Performs only syntax and semantic checking on the source
         file  in  order  to print prototypes for all K&R C func-
         tions. This option does not produce any object  or  exe-
         cutable code.


     -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  plat-
         form.  If  you  do  not  specify  a  valid pagesize, the
         request is silently ignored at runtime.

         Use the pagesize(1) Oracle Solaris command to  determine
         the  number  of  bytes  in  a page. The operating system
         offers no guarantee that the page size request  will  be
         honored.  However,  appropriate segment alignment can be
         used  to  increase  the  likelihood  of  obtaining   the
         requested  page  size. See the -xsegment_align option on
         how to set the segment alignment. You can use pmap(1) or
         meminfo(2)  to  determine  page size of the target plat-
         form.

         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 Oracle Developer Studio
                         12.6:
                         C User's Guide.

         If you specify -xpagesize=default, the 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  set-
         ting  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.

         The libhugetlbfs library is required for  -xpagesize  to
         work  on  Linux.  See the Linux libhugetlbfs(7) man page
         for more information.


     -xpagesize_heap=n
         Set the page size in memory for the heap.

         The n value is the same as for -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 runtime.

         See -xpagesize for details.


     -xpagesize_stack=n
         Set the page size in memory for the stack.

         The n value is the same as described for -xpagesize.

         You must specify  a  valid  page  size  for  the  Oracle
         Solaris  operating system on the target platform. If you
         do not specify a valid pagesize, the request is silently
         ignored at runtime.

         See -xpagesize for details.


     -xpatchpadding[={fix|patch|size}]
         Reserve an area of memory before the start of each func-
         tion. If fix is specified, the compiler will reserve the
         amount of space required by fix and  continue.  This  is
         the  default.  If either patch or no value is specified,
         the compiler will reserve  a  platform-specific  default
         value.  A value of -xpatchpadding=0 will reserve 0 bytes
         of space. The maximum value for size on x86 is 127 bytes
         and on SPARC is 2048 bytes.


     -xpch=v
         This compiler option  activates  the  precompiled-header
         feature. v can be auto, autofirst, collect:pch_filename,
         or use:pch_filename. You  can  take  advantage  of  this
         feature  through the -xpch and -xpchstop options in com-
         bination 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.

         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 precompiled-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 sec-
             tion 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
             contains  only  the first header found in the source
             file.


         If you decide to  create  your  precompiled-header  file
         manually, you must start by first using -xpch and speci-
         fying 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.c:


           cc -xpch=collect:myheader a.cc

         A valid precompiled-header filename always has the  suf-
         fix  .cpch.  When  you specify pch_filename, you can add
         the suffix or let the compiler add it for you. For exam-
         ple,  if  you  specify  cc  -xpch=collect:foo  a.c,  the
         precompiled-header file is called foo.cpch.

         If the compiler cannot use the precompiled-header  file,
         under -xpch=auto and -xpch=autofirst, it will generate a
         new precompiled-header file. If the compiler cannot  use
         the  precompiled-header  file under -xpch=use, a warning
         is issued and the compilation is  done  using  the  real
         headers.

         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.c bar.c foobar.c

         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:


             o    The compiler that you are using to  access  the
                  precompiled-header file is the same as the com-
                  piler that created the precompiled-header file.
                  A  precompiled-header  file created by one ver-
                  sion of the  compiler  may  not  be  usable  by
                  another version of the compiler.


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


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


             o    The contents of the included headers  that  you
                  specify with -xpch=use is identical to the con-
                  tents of the included headers that were  speci-
                  fied when the precompiled header was created.


             o    The current directory (that is,  the  directory
                  in  which  the  compilation  is  occurring  and
                  attempting to use  a  given  precompiled-header
                  file) is the same as the directory in which the
                  precompiled-header file was created.


             o    The initial sequence of  pre-processing  direc-
                  tives,  including  #include  directives, in the
                  file you specified with -xpch=collect  are  the
                  same   as   the   sequence   of  pre-processing
                  directives  in  the  files  you  specify   with
                  -xpch=use.

         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 com-
         piler  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  con-
         sistently 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:


             o    #include


             o    #if/ifdef/ifndef/else/elif/endif


             o    #define/undef


             o    #ident


             o    #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 pre-
         fix   automatically   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.

             o    The first declaration/definition statement


             o    The first #line directive


             o    A #pragma hdrstop directive


             o    After the named include  file  if  you  specify
                  -xpch=auto and -xpchstop


             o    The  first  include   file   if   you   specify
                  -xpch=autofirst

         Note: An end point within a conditional  statement  gen-
         erates  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 com-
         piler uses the earlier of the two stop  points  to  ter-
         minate the viable prefix.

         Within the viable prefix of  each  file  that  shares  a
         precompiled-header  file, each corresponding #define and
         #undef directive must reference the same symbol (in  the
         case  of  #define,  each  one  must  reference  the same
         value). Their order of  appearance  within  each  viable
         prefix  must  be  the  same  as well. Each corresponding
         pragma must also be the same  and  appear  in  the  same
         order across all the files sharing a precompiled header.

         A header file is precompileable when it  is  interpreted
         consistently  across  different  source  files. Specifi-
         cally, when it contains only complete declarations. 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
         declaration 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 */

         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  con-
         straints is undefined.


             o    The header  file  must  not  use  __DATE__  and
                  __TIME__.


             o    The  header  file  must  not  contain   #pragma
                  hdrstop.

         When the  compiler  creates  a  precompiled-header  file
         automatically, 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 performed under a lock so  that  it  works  properly
         under dmake.

         If  you  need  to  force   the   compiler   to   rebuild
         automatically-generated  precompiled-header  files,  you
         can clear the  precompiled-header  file  cache-directory
         with  the  CCadmin tool. See the CCadmin(1) man page for
         more information.

         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:


           %.o : %.cc shared.cpch
           $(cc) -xpch=use:shared -xpchstop=foo.h -c $<
           default : a.out
           foo.o + shared.cpch : foo.c
           $(cc) -xpch=collect:shared -xpchstop=foo.h foo.c -c
           a.out : foo.o bar.o foobar.o
           $(c) 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 precompiled-header
         file.

         For -xpch=auto or -xpch=autofirst, you do  not  have  to
         create any additional make rules in your makefiles.

         Warnings:

         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> generates an error.

         If you specify -xpch=autofirst or you specify -xpch=auto
         without -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  generation of the precompiled-
         header file.

         A #pragma hdrstop before the first  include  file  under
         -xpch=autofirst  or  -xpch=auto  disables  the automatic
         generation of the precompiled-header file.

         See also: -xpchstop


     -xpchstop=[file|<include>]
         file is the last include file to be considered in creat-
         ing  a  precompiled-header  file. Using -xpchstop on the
         command line is equivalent to placing a  hdrstop  pragma
         (see the Oracle Developer Studio
                         12.6:
                         C  User's   Guide)   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 including <include>. This flag overrides the
         default  -xpch=auto  behavior  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. 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.


     -xpentium
          Obsolete.  Use -xchip=generic instead.


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

         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 Oracle
         Solaris platforms include approximate  user  CPU  times.
         These  times are derived from PC sample data (see pcsam-
         ple(2)) for routines in the main executable and routines
         in  shared  libraries specified as linker arguments when
         the  executable  is  linked.  Other   shared   libraries
         (libraries    opened   after   process   startup   using
         dlopen(3C)) 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).

         Current Oracle Solaris releases do  not  include  system
         libraries  compiled  with -p. As a result, profiles col-
         lected  on  current  Oracle  Solaris  platforms  do  not
         include call counts for system library routines.

         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

         If you specify -xpg  at  compile  time,  you  must  also
         specify it at link time. See the Oracle Developer
                         Studio
                         12.6:
                         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 incompa-
         tible and can result in internal errors.


     -xprefetch[=val[,val]]
         Enables prefetch  instructions  on  those  architectures
         that  support  prefetch. You must compile with optimiza-
         tion level 3 or greater with this option.

         val must be one of the following:



         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  spe-
             cial  circumstances  that  are supported by measure-
             ments.


         no%explicit
             Disable explicit prefetch macros.


         latx:factor
             (SPARC)  You  can  only  combine  this  option  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
             number of the form n.n.

             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  performance across a wide range of machines
             and applications. This  tuning  may  not  always  be
             optimal.  For  memory-intensive  applications, espe-
             cially applications intended to run  on  large  mul-
             tiprocessors,  you may be able to obtain better per-
             formance 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 one.

             To use the latx:factor suboption, start with a  fac-
             tor value near 1.0 and run performance tests against
             the application. Then increase or decrease the  fac-
             tor,  as  appropriate, and run the performance tests
             again. Continue adjusting the factor and running the
             performance  tests until you achieve optimum perfor-
             mance. 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.


         yes
             (Obsolete) Do not use. Use  -xprefetch=auto,explicit
             instead.


         no
             (Obsolete)       Do       not        use.       Use
             -xprefetch=no%auto,no%explicit instead.


         Defaults:

         If you do not specify -xprefetch,  the  default  is  now
         -xprefetch=auto,explicit,  not  -xprefetch=yes.  If  you
         specify  -xprefetch  without  a  value,   it   is   also
         equivalent   to  -xprefetch=auto,explicit.  This  change
         adversely affects  applications  that  have  essentially
         non-linear   memory  access  patterns.  To  disable  the
         change, specify -xprefetch=no%auto,no%explicit.

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


     -xprefetch_auto_type=[a]
         a is [no%]indirect_array_access.

         Use this option to determine whether or not the compiler
         generates indirect prefetches for the loops indicated by
         the option -xprefetch_level in the same fashion the pre-
         fetches for direct memory accesses are generated.

         If    you    do    not    specify    a    setting    for
         -xprefetch_auto_type,    the   compiler   sets   it   to
         -xprefetch_auto_type=no%indirect_array_access.

         Options such as -xdepend, -xrestrict, and  -xalias_level
         can  affect the aggressiveness of computing the indirect
         prefetch candidates and therefore the aggressiveness  of
         the  automatic indirect prefetch insertion due to better
         memory alias disambiguation information.


     -xprefetch_level=l
         Use  this  option  to  control  the  aggressiveness   of
         automatic  insertion  of prefetch instructions as deter-
         mined with -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  pre-
         fetch  instructions.  -xprefetch_level=2  enables  addi-
         tional  generation  beyond  level  1  and   -xprefetch=3
         enables additional generation beyond level 2.

         You must compile with optimization level  3  or  greater
         and generate code for a platform that supports prefetch.

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


     -xprevise={yes|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  -xprevise=yes  and  linking  in  a
         separate  step,  include  -xprevise=yes also on the link
         step.

         The default is -xprevise=no.

         On Linux, -xprevise=yes needs to be specified along with
         -xannotate.

         See the Oracle Developer Studio Code Analyzer documenta-
         tion for further information.


     -xprofile=p
         Collects data for a profile or use a profile  to  optim-
         ize.

         p   must   be   collect[:profdir],   use[:profdir],   or
         tcov[:profdir]

         This option causes execution frequency data to  be  col-
         lected  and saved during execution, then the data can be
         used in subsequent runs to improve performance.  Profile
         collection  is safe for multithreaded applications. That
         is, profiling a program that does its own multitasking (
         -mt  )  produces  accurate  results. This option is only
         valid when you specify -xO2 or greater level of  optimi-
         zation.

         If compilation and linking  are  performed  in  separate
         steps, the same -xprofile option must appear on the com-
         pile as well as the link step. See the Oracle  Developer
         Studio
                         12.6:
                         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, and -xprofile=collect should not be
             used  together. While -xMerge forces statically ini-
             tialized data into read-only storage, -ztext  prohi-
             bits  position-dependent symbol relocations in read-
             only storage, and -xprofile=collect generates stati-
             cally initialized, position-dependent symbol reloca-
             tions 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  con-
             taining the profiled 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
             -xprofile=collect:prof_dir                        or
             -xprofile=tcov:prof_dir, profile data are stored  at
             runtime  in  a directory named program.profile where
             program is the basename of  the  profiled  process's
             main  program.  In  this case, the environment vari-
             ables 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 compila-
             tion time, SUN_PROFDATA_DIR and SUN_PROFDATA have no
             effect at runtime. These environment variables simi-
             larly 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 pro-
             file    data    is    written   to   the   directory
             profdir.profile  in  the  current  directory,  where
             profdir  is  the  name of the executable or the name
             specified  in  the  -xprofile=collect: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
             accumulates in the profdir.profile  directory;  that
             is, output from prior executions is not lost.

             Example[1]: to collect and use profile data  in  the
             directory  myprof.profile located in the same direc-
             tory where the program is built:

               cc -xprofile=collect:myprof.profile -xO5 prog.c -o prog
                 ./prog
               cc -xprofile=use:myprof.profile -xO5 prog.c -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  optimiza-
             tion level -xO5:



               cc -xprofile=collect:/bench/myprof.profile -xO5 prog.c -o prog
                 ...run prog from multiple locations...
               cc -xprofile=use:/bench/myprof.profile -xO5 prog.c -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.

             See also the ENVIRONMENT VARIABLES section  of  this
             man page below for descriptions of environment vari-
             ables that control asynchronous profile collections.


         use[:profdir]
             Uses execution frequency data  collected  from  code
             compiled    with    -xprofile=collect[:profdir]   or
             -xprofile=tcov[:profdir] to optimize  for  the  work
             performed when the profiled code was executed. prof-
             dir is the pathname of a directory  containing  pro-
             file  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
             -xprofile=use[:profdir],  the same profile directory
             must be specified at  compilation  time,  using  the
             option  -xprofile=tcov[:profdir]. To minimize confu-
             sion, specify profdir as an absolute pathname.

             The profdir is optional. If profdir  is  not  speci-
             fied,  the  name  of  the executible binary is used.
             a.out is used if -o is not specified.  The  compiler
             looks      for      profdir.profile/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 fre-
             quency  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 feed-
             back 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
             profile  directory  name profdir must be used in the
             optimizing compilation: -xprofile=use:profdir.

             See also -xprofile_ircache for speeding up  compila-
             tion 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
             compiler  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 -xprofile=use:profdir.

             If the optional :profdir argument is omitted, a pro-
             file  directory  will  be  created when the profiled
             program is executed. 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  abso-
             lute,  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  exe-
             cuted.  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  compiler  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 runtime and used to store runtime
             profile data.




     -xprofile_ircache[=path]
         (SPARC)      Use      -xprofile_ircache[=path]      with
         -xprofile=collect|use to improve compilation time during
         the use phase by reusing compilation data saved from the
         collect phase.

         With large programs, compilation time in the  use  phase
         can  improve significantly because the intermediate data
         is saved. Note that the saved data could  increase  disk
         space requirements considerably.

         When you use  -xprofile_ircache[=path],  path  overrides
         the  location  where  the  cached  files  are  saved. By
         default, these files are saved in the same directory  as
         the  object  file.  Specifying a path is useful when the
         collect and use phases happen in  two  different  direc-
         tories.

         Here's a typical sequence of commands:

           example% cc -xO5 -xprofile=collect -xprofile_ircache t1.c t2.c
           example% a.out     // run collects feedback data
           example% cc -xO5 -xprofile=use -xprofile_ircache t1.c t2.c



     -xprofile_pathmap=collect_prefix:use_prefix
         (SPARC) 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 profile data for an
         object file that is compiled with -xprofile=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=collect.


             o    Your object files share a  common  basename  in
                  the  profile  but  are  distinguished from each
                  other by their  location  in  different  direc-
                  tories.

         The collect-prefix is the prefix of the UNIX pathname of
         a  directory  tree  in  which object files were compiled
         using -xprofile=collect.

         The use-prefix is the prefix of the UNIX pathname  of  a
         directory  tree in which object files are to be compiled
         using -xprofile=use.

         If you specify multiple instances of  -xprofile_pathmap,
         the  compiler  processes  them  in  the  order  of their
         occurrence. Each use-prefix specified by an instance  of
         -xprofile_pathmap is compared with the object file path-
         name 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  paralleliza-
         tion.  This  option  is  valid only if -xautopar is also
         specified. Otherwise the compiler issues a warning.

         When a reduction recognition is  enabled,  the  compiler
         parallelizes  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  fol-
         lowing suboptions: 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 appli-
             cation  registers as scratch registers. The applica-
             tion registers are g2, g3, and g4  on  32-bit  plat-
             forms) and g2 and g3 on 64-bit platforms.

             It is strongly recommended that all system  software
             and libraries be compiled using -xregs=no%appl. Sys-
             tem  software  (including  shared  libraries)   must
             preserve  these  registers'  values for the applica-
             tion. 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 con-
             flict 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
             floating-point  registers  as  scratch registers for
             integer values. Floating-point values may use  these
             registers  regardless  of  this  option. To generate
             binary code free of all references to floating point
             registers,  use  -xregs=no%float  and make sure your
             source code does not in any way use  floating  point
             types.


         float (X86)
             Allow the compiler to generate  code  by  using  the
             floating-point   registers   as  scratch  registers.
             Floating-point  values  may  use   these   registers
             regardless  of  this option. To generate binary code
             free of all references to floating point  registers,
             use  -xregs=no%float  and make sure your source code
             does not in any way use floating point types. During
             code  generation the compilers will attempt to diag-
             nose code that results in the use of floating point,
             simd, or x87 instructions.


         frameptr (x86)
             Allow the compiler to use the frame-pointer register
             (%ebp  on  IA32,  %rbp on x86 64-bit platforms) as a
             general-purpose register.

             The default is -xregs=no%frameptr.

             The  C++  compiler  ignores  -xregs=frameptr  unless
             exceptions      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 perfor-
             mance. However, some features of  the  debugger  and
             performance  measurement tools may be limited. Stack
             tracing, debuggers, and performance analyzers cannot
             report on functions 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  com-
             piled 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,
             compiling  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,float. -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 registers in order to safely  link
         with that library.


     -xrestrict[=f]
         Treats pointer-valued function parameters as  restricted
         pointers.  f is %all, %none 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.

         If a  function  list  is  specified  with  this  option,
         pointer   parameters  in  the  specified  functions  are
         treated as restricted; if -xrestrict=%all is  specified,
         all  pointer parameters in the entire C file are treated
         as restricted.

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

         See also: `Restricted Pointers' in the Oracle  Developer
         Studio
                         12.6:
                         C User's Guide.


     -xs[={yes|no}]
         (Oracle Solaris)  Link  debug  information  from  object
         files into executable.

         -xs  is  the  same   as   -xs=yes.   The   default   for
         -xdebugformat=dwarf is the same as -xs=yes.

         This option controls the trade-off  of  executable  size
         versus  the  need  to  retain  object  files in order to
         debug. For dwarf, use  -xs=no  to  keep  the  executable
         small but depend on the object files. For stabs, use -xs
         or -xs=yes to avoid dependence on the  object  files  at
         the  cost of a larger executable. This option has almost
         no effect on dbx performance or the runtime  performance
         of the program.

         When the compile command forces linking (that is, -c  is
         not  specified)  there will be no object file(s) and the
         debug information must be placed in the  executable.  In
         this   case,  -xs=no  (implicit  or  explicit)  will  be
         ignored.

         The feature is implemented by having the compiler adjust
         the  section  flags  and/or  section names in the object
         file that it emits, which then tells the linker what  to
         do  for  that  object  file's  debug  information. It is
         therefore a compiler option, not a linker option. It  is
         possible  to  have  an executable with some object files
         compiled -xs=yes and others compiled -xs=no.

         Linux compilers accept but ignore -xs.  Linux  compilers
         do not accept -xs={yes|no}.


     -xsafe=mem
         (SPARC) Allow the compiler to assume that no memory pro-
         tection violations occur.

         This option allows the compiler to use the  non-faulting
         load instruction in 64-bit SPARC architecture.

         Because non-faulting loads do not cause a  trap  when  a
         fault  such as address misalignment or segmentation vio-
         lation occurs, you should use this option only for  pro-
         grams  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.

         This option takes effect only when used  with  optimiza-
         tion  level -xO5 and one of the following -xarch values:
         sparc, sparcvis, sparcvis2, or sparcvis3 for  both  -m32
         and -m64.


     -xsecure_code_analysis{=[yes|no]}
         Enable or disable compiler secure code analysis to  find
         and display possible memory safety violations at compile
         time. Secure code analysis runs  in  parallel  with  the
         compilation  process and may result in increased compile
         time.

         If -xsecure_code_analysis is not specified or if  it  is
         specified  without  a  yes|no  argument,  the default is
         -xsecure_code_analysis=yes.

         Use -xsecure_code_analysis=no  to  disable  secure  code
         analysis.


     -xsegment_align=n
         (Oracle  Solaris)  This  option  causes  the  driver  to
         include  a special mapfile on the link line. The mapfile
         aligns the text, data, and bss  segments  to  the  value
         specified  by  n.  When  using  very  large pages, it is
         important that the heap and stack segments  are  aligned
         on  an  appropriate  boundary. If these segments are not
         aligned, small pages will be used up to the  next  boun-
         dary,  which  could cause a performance degradation. The
         mapfile ensures that the  segments  are  aligned  on  an
         appropriate boundary.

         The n value must be one of the following:

         SPARC: The following values are valid:  8K,  64K,  512K,
         2M, 4M, 32M, 256M, 1G, and none.

         x86: The following values are valid: 4K, 8K, 64K,  512K,
         2M, 4M, 32M, 256M, 1G, and none.

         The default for both SPARC and x86 is none.

         Recommended usage is as follows:


           SPARC 32-bit compilation: -xsegment_align=64K
           SPARC 64-bit compilation: -xsegment_align=4M

           x86 32-bit compilation: -xsegment_align=8K
           x86 64-bit compilation: -xsegment_align=4M

         The driver will include  the  appropriate  mapfile.  For
         example,  if  the user specifies -xsegment_align=4M, the
         driver           adds            -M          install-
         directory/lib/compilers/mapfiles/map.4M.align   to   the
         link line, where install-directory is  the  installation
         directory.  The  aforementioned  segments  will  then be
         aligned on a 4M boundary.


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

     -xspace
         Does no optimizations that increase code size. Does  not
         parallelize  loops  if  it increases code size. Example:
         Does not unroll loops.


     -xstrconst
         This option may be deprecated in a future  release.  Use
         -features=[no%]conststrings instead.

         The -xstrconst option inserts string literals  into  the
         read-only  data  section  of the text segment instead of
         the default data  segment.  Duplicate  strings  will  be
         eliminated  and the remaining copy shared amongst refer-
         ences in the code.


     -xtarget=t
         Specifies the target system for the instruction set  and
         optimization.

         t must be one of: native, generic, or system-name.

         Each specific value for -xtarget expands into a specific
         set    of   values   for   the   -xarch,   -xchip,   and
         -xcache options. Use the -xdryrun  option  to  determine
         the expansion of -xtarget=native on a running system.

         For example, -xtarget=T3 is equivalent to  -xchip=T3   -
         xcache=8/16/4:6144/64/24  -xarch=sparcvis3.



           cc -dryrun -xtarget=T3 |& grep ###
           ###     command line files and options (expanded):
           ### -dryrun -xchip=T3 -xcache=8/16/4:6144/64/24 -xarch=sparcvis3


         The data type model, either 32-bit or 64-bit,  is  indi-
         cated  by  the  -m32|-m64  option. To specify the 64-bit
         data type model, use the -m64 option as follows:


           -xtarget=<value> ... -m64

         To specify the 32-bit data  type  model,  use  the  -m32
         option as follows:


           -xtarget=<value> ... -m32

         See also the -m32|-m64 option for a  discussion  of  the
         default data type model.

         The expansion of -xtarget for  a  specific  host  system
         might  not expand to the same -xarch, -xchip, or -xcache
         settings as -xtarget=native when compiling on that  sys-
         tem.

         The following values for t are valid on all systems:


         native
             Equivalent to


               —xarch=native —xchip=native —xcache=native

             to give best performance on the host system.


         generic
             Equivalent to


               —xarch=generic —xchip=generic —xcache=generic

             to give best performance on most  systems.  This  is
             the default.


         system-name
             Get the best performance for the specified system.

             Select a system name from the following  lists  that
             represents the actual system you are targeting.

             Valid SPARC system names are: sparc64vi  (Obsolete),
             sparc64vii   (Obsolete),  sparc64viiplus,  sparc64x,
             sparc64xplus,   sparc64xii,   ultraT1    (Obsolete),
             ultraT2  (Obsolete), ultraT2plus, T3 (Obsolete), T4,
             T5, T7, M5, M6, and M7.

             Valid  x86  system  names  are:  skylake,   haswell,
             ivybridge,  nehalem,  barcelona  (Obsolete), pentium
             (Obsolete),   pentium_pro    (Obsolete),    pentium3
             (Obsolete), pentium4, penryn, sandybridge, westmere,
             woodcrest, and broadwell.

     -xtemp=path
         Equivalent to -temp=path.


     -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 specifier, 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 Oracle Developer Studio
                         12.6:
                         C User's Guide.

         o must be the following:



         [no%]dynamic
             Compile variables for dynamic  loading.  Prefix  no%
             disables  the  option. Access to thread variables is
             significantly faster when -xthreadvar=no%dynamic but
             you  cannot  use  the  object  file within a dynamic
             library. That is, you can only use the  object  file
             in an executable file.


         If you do not specify -xthreadvar, the default  used  by
         the  compiler  depends  upon  whether  or  not position-
         independent code  is  enabled.  If  position-independent
         code    is    enabled,    the    option    is   set   to
         -xthreadvar=dynamic.  If  position-independent  code  is
         disabled, the option is set to -xthreadvar=no%dynamic.

         If you specify -xthreadvar but do not specify any  argu-
         ments, the option is set to -xthreadvar=dynamic.

         If  there  is  non-position-independent  code  within  a
         dynamic library, you must specify -xthreadvar.

         The linker cannot support the thread-variable equivalent
         of  non-PIC  code  in  dynamic libraries. Non-PIC thread
         variables are significantly faster, and hence should  be
         the default for executables.

         If  there  is  non-position-independent  code  within  a
         dynamic library, you must specify -xthreadvar.

         Using thread variables on different versions  of  Oracle

         Solaris  software requires different options on the com-
         mand line.

         See also: -xcode, -KPIC, -Kpic


     -xthroughput[={yes|no}]
         The -xthroughput option  tells  the  compiler  that  the
         application   will  be  run  in  situations  where  many
         processes are simultaneously running on the system.

         If -xthroughput=yes, the compiler will  favor  optimiza-
         tions that slightly reduce performance for a single pro-
         cess while improving the amount of work achieved by  all
         the processes on the system. As an example, the compiler
         might choose to be less aggressive in prefetching  data.
         Such a choice would reduce the memory bandwidth consumed
         by the process, and as such the process may run  slower,
         but  it  would  also  leave  more memory bandwidth to be
         shared among other processes.

         The default is -xthroughput=no.


     -xtime
         Reports the time and resources used by each compilation.


     -xtransition(obsolete)
         Issues warnings for differences between K&R C and ISO C.
         The  -xtransition  option issues messages in conjunction
         with the -Xa and -Xt  options.  You  can  eliminate  all
         warning   messages   about  differing  behavior  through
         appropriate coding.  The  -xtransition  option  will  be
         removed in a future release.


     -xtrigraphs[=[yes|no]]
         Enables or disables recognition of trigraph sequences as
         defined by the ISO 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=no is assumed.

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


     -xunboundsym={yes|no}
         Specify  whether  the  program  contains  references  to
         dynamically bound symbols.

         -xunboundsym=yes means the program  contains  references
         dynamically bound symbols.

         -xunboundsym=no  means  the  program  does  not  contain
         references to dynamically bound symbols.

         The default is -xunboundsym=no.


     -xunroll=n
         Specifies  whether  or  not   the   compiler   optimizes
         (unrolls)  loops.  n is a positive integer. When n is 1,
         it is a command and the compiler unrolls no loops.  When
         n  is  greater than 1, -xunroll=n allows the compiler to
         unroll loops n times.


     -xustr={ascii_utf16_ushort|no}
         Specify -xustr=ascii_utf16_ushort if you need to support
         an  internationalized  application  that  uses  ISO10646
         UTF-16 string literals. In other words, use this  option
         if  your code contains string literals that you want the
         compiler to convert to  UTF-16  strings  in  the  object
         file. Without this option, the compiler neither produces
         nor recognizes sixteen-bit  character  string  literals.
         This  option  enables recognition of the U"ASCII_string"
         string literals as an array of unsigned short int. Since
         such  strings  are  not  yet  part of any standard, this
         option enables recognition of non-standard C.

         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  argument,  the  compiler won't accept it and instead
         issues a warning. The default can change if the C or C++
         standards define a meaning for the syntax.

         It is not an error to specify -xustr=ascii_ustf16_ushort
         without   also   specifying   a  U"ASCII_string"  string
         literal.

         When specifying the flag -xustr=ascii_utf16_ushort,  one
         of  the  following  options must also be specified: -Xc,
         -Xa, -Xt, -Xs,  -xc99,  -std=c99,  -std=c89,   -std=c90,
         -std=gnu89, -std=gnu90, -std=gnu99 or -ansi.

         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.c
           const unsigned short *foo = U"foo";
           const unsigned short bar[] = U"bar";
           const unsigned short *fun() { return
           example% cc -xustr=ascii_utf16_ushort file.c -c




     -xvector[=a]
         Enables automatic generation  of  calls  to  the  vector
         library  or  the generation of the SIMD (Single Instruc-
         tion Multiple Data) instructions on processors that sup-
         port  SIMD. You must use default rounding mode by speci-
         fying -fround=nearest when you use this option.

         The -xvector option requires optimization level -xO3  or
         greater. The option is silently ignored if the optimiza-
         tion level is lower than -xO3.

         a is the equivalent of the following.  Prefix  no%  dis-
         ables a suboption.



         [no%]lib
             (Oracle Solaris) Enables the compiler  to  transform
             math library calls within loops into single calls to
             the  equivalent  vector  math  routines  when   such
             transformations are possible. This could result in a
             performance improvement for loops  with  large  loop
             counts. Use no%lib to disable this option.


         [no%]simd
             (SPARC)  For  -xarch=sparcace,   -xarch=sparcaceplus
             and  -xarch=sparcace2,  directs  the compiler to use
             floating point and  integral  SIMD  instructions  to
             improve  the  performance of certain loops. Contrary
             to that of  the  other  SPARC  -xarch  values  under
             -xarch=sparcace,        -xarch=sparcaceplus      and
             -xarch=sparcace2, -xvector=simd is in effect  unless
             -xvector=none  or  -xvector=no%simd  has been speci-
             fied. In addition -xO4 or greater  is  required  for
             -xvector=simd, otherwise -xvector=simd is ignored.

             For all other -xarch values, directs the compiler to
             use  the  Visual  Instruction Set [VIS1, VIS2, ViS3,
             etc.] SIMD instructions to improve  the  performance
             of    certain   loops.   Basically   with   explicit
             -xvector=simd option, the compiler will perform loop
             transformation  enabling  the  generation of special
             vectorized SIMD instructions to reduce the number of
             loop  iterations.  In  addition  to the optimization
             level requirement  noted  below,  the  -xvector=simd
             option  is  effective  only  if -xarch=sparcvis3 and
             above.


         [no%]simd
             (x86) 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  optimization  level  3  and above where
             beneficial. Use no%simd to disable this option.

             The compiler will use SIMD only if streaming  exten-
             sions  exist in the target architecture; that is, if
             target ISA is at least SSE2. For  example,  you  can
             specify      -xtarget=woodcrest,     -xarch=generic,
             -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
             Disables this option entirely.


         yes
             This  option  is  deprecated,  specify  -xvector=lib
             instead.

         no
             This option is  deprecated,  specify  -xvector=%none
             instead.


         On x86, the default  is  -xvector=simd.  On  SPARC,  the
         default   is  -xvector=simd  under  -xarch=sparcace,   -
         xarch=sparcaceplus    and     --xarch=sparcace2,     and
         -xvector=%none  on  other  SPARC  -xarch  values. If you
         specify  -xvector  without  a  suboption,  the  compiler
         assumes   -xvector=simd,lib   on   x86  Oracle  Solaris,
         -xvector=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.

         Note: -xvector=%none should be used when compiling  Ora-
         cle Solaris kernel code for x86 platforms.

         If you compile and link with separate commands, be  sure
         to use the same option for both compilation and linking.


     -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 instruc-
         tions.  The  default  is  -xvis=no.  Specifying -xvis is
         equivalent to specifying -xvis=yes.

         The VIS[tm] instruction set is an extension to the SPARC
         V9  instruction  set. Even though the UltraSPARC proces-
         sors 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  pro-
         cess  four  16-bit  data  with  one  instruction so they
         greatly improve the  performance  of  applications  that
         handle new media such as imaging, linear algebra, signal
         processing, audio, video and networking.


     -xvpara
         Issues  warnings  about  potential  parallel-programming
         related  problems  that may cause incorrect results when
         using OpenMP. Use with -xopenmp and  OpenMP  API  direc-
         tives.

         The compiler issues warnings when it detects the follow-
         ing situations:


             o    Loops are parallelized using MP directives when
                  there  are  data dependencies 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  cause  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
         processed without problems.

         Example:

           cc -xopenmp -xvpara any.c



     -Yc, dir
         Specifies a new directory dir for the location  of  com-
         ponent  c.  c  can  consist  of  any  of  the characters
         representing tools listed under the -W option.

         If the location of a tool is being specified,  then  the
         new  path  name  for  the tool will be dir/tool. If more
         than one -Y option is applied to any one item, then  the
         last occurrence holds.


     -YA, dir
         Specifies a directory dir to  search  for  all  compiler
         components.  If  a  component  is  not found in dir, the
         search reverts to the directory where  the  compiler  is
         installed.


     -YI, dir
         Changes default directory searched for include files.


     -YP, dir
         Changes default directory for finding libraries files.

     -YS, dir
         Changes default directory for startup object files.




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

  NOTES
  errno
     Certain floating-point math  library  routines  will  return
     error  status  in  the  errno variable (defined in errno.h).
     With options -fast , -xbuiltin,  -xlibmieee,  -xlibmil,  and
     -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 -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 \
       -xlibmopt=%none  -xnolibmil




     following -fast on the command line to inhibit the  compiler
     from optimizing out such library calls and to to ensure that
     calls to math functions set errno as documented.

  New Shared Libraries
     For Solaris release 10, new shared libraries  libxprof.so.1,
     libxprof_audit.so.1,  and  libtdf.so.1  must be installed in
     order to use the -xprofile option. These libraries are  pre-
     installed on the latest Oracle Solaris releases.

  FLT_ROUNDS
     The implementation of FLT_ROUNDS supplied with Studio C  for
     SPARC  Linux  behaves  as  specified  in  the C standard. It
     returns the appropriate value for the current rounding mode.
     It  does not always return the value 1 specified in the man-
     page that describes the functions defined in the standard  C
     header <fenv.h>.

  Predefined Identifier __STDC__
     On Oracle Solaris, the predefined  macro  __STDC__  has  the
     value  0  when  one  of  the  flags -Xt, -Xa or -std without
     -pedantic flag has been specified, and 1 when either the -Xc
     or  -pedantic  flag  has  been  specified.  __STDC__  is not
     defined for -Xs.


     On Linux, __STDC__ has the value 1.

  PRAGMAS
     The following #pragmas are  recognized  by  the  compilation
     system:

       #pragma align
       #pragma c99
       #pragma does_not_read_global_data
       #pragma does_not_return
       #pragma does_not_write_global_data
       #pragma error_messages
       #pragma fini
       #pragma hdrstop
       #pragma ident
       #pragma init
       #pragma [no_]inline
       #pragma [no_]warn_missing_parameter
       #pragma int_to_unsigned
       #pragma opt
       #pragma pack
       #pragma rarely_called
       #pragma redefine_extname
       #pragma returns_new_memory
       #pragma struct_align
       #pragma unknown_control_flow
       #pragma weak

       #pragma does_not_read_global_data
       #pragma does_not_write_global_data
       #pragma no_side_effect



     See also the Oracle Developer Studio
                 12.6:

                 OpenMP API User's Guide for a list of  supported
     OpenMP 2.5 directives.


     SPARC Only:

       #pragma nomemorydepend
       #pragma no_side_effect
       #pragma pipeloop
       #pragma unroll



     Refer to the Oracle Developer Studio
                 12.6:
                 C User's Guide for  more  information  on  these
     pragmas.

Environment Variables
     The following is a list of environment  variables  that  you
     can set along with a brief description of their function.

     LINT_OPTIONS
         A default set of options to lint. LINT_OPTIONS is inter-
         preted  by  lint  as though its value had been placed on
         the command line, immediately following the name used to
         invoke lint, as in:

           lint $LINT_OPTIONS ... other-arguments ...



     TMPDIR
         cc normally creates temporary  files  in  the  directory
         tmp.  You  may  specify another directory by setting the
         environment variable TMPDIR to  your  chosen  directory.
         (If  TMPDIR  isn't  a  valid directory, then cc will use
         tmp). The -xtemp option has precedence over  the  TMPDIR
         environment variable.


     SUNPRO_SB_INIT_FILE_NAME
         (Obsolete) The source browser functionality is no longer
         supported.


     SUN_PROFDATA=profdir
         If set, store profile data collected from a program com-
         piled  with -xprofile=collect in a directory named prof-
         dir in the current working directory at  the  time  that
         the program is executed. If the optional argument :prof-
         dir was specified in -xprofile=collect[:profdir] at com-
         pilation time, SUN_PROFDATA as no effect.


     SUN_PROFDATA_DIR=dirname
         If set, store profile data collected from a program com-
         piled  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=collect[:profdir]   at    compilation    time,
         SUN_PROFDATA_DIR has no effect.


     SUN_PROFDATA_REPLACE={objfile,program,all}
         The    value     of     the     environment     variable
         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  pro-
         gram 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
             containing 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_PROFDATA_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(3LIB) 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 fol-
         lowing environment 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  asynchro-
         nous collector to stderr. SUN_PROFDATA_ASYNC_VERBOSE has
         no effect  unless  asynchronous  profile  collection  is
         enabled.


     SUN_PROFDATA_CLEANUP_AFTER_EXIT=[0|1]
         If set to 1, enables  profiler  to  clean  up  its  data
         structures  between  the  time  that  the  process calls
         exit() and the time that process exit  is  complete.  If
         set  to  0, avoids destructive interference with profile
         collection by application threads  that  have  not  ter-
         minated   before   the  application  calls  exit().  See
         exit(3C)   for   details.   The   default   setting   is
         SUN_PROFDATA_CLEANUP_AFTER_EXIT=0.

     Refer to Oracle Developer Studio
               12.6:
               OpenMP API User's Guide for information about  the
     following  environment  variables  that  can  be  set for an
     OpenMP program or a program  automatically  parallelized  by
     the -xautopar option:

         o    OMP_SCHEDULE


         o    OMP_NUM_THREADS


         o    OMP_DYNAMIC


         o    OMP_PROC_BIND


         o    OMP_PLACES


         o    OMP_NESTED


         o    OMP_STACKSIZE


         o    OMP_WAIT_POLICY


         o    OMP_MAX_ACTIVE_LEVELS


         o    OMP_THREAD_LIMIT


         o    OMP_CANCELLATION


         o    OMP_DISPLAY_ENV


         o    PARALLEL


         o    SUNW_MP_WARN


         o    SUNW_MP_THR_IDLE

         o    SUNW_MP_PROCBIND


         o    SUNW_MP_MAX_POOL_THREADS


         o    SUNW_MP_MAX_NESTED_LEVELS


         o    STACKSIZE


         o    SUNW_MP_GUIDED_WEIGHT


         o    SUNW_MP_WAIT_POLICY

Files
     a.out
                         executable output file


     bb_link.o
                         tcov support


     file.a
                         library of object files


     file.c
                         C source file


     file.d
                         tcov(1) test coverage input file


     file.i
                         C source file after preprocessing


     file.il
                         inline(1) expansion file


     file.o
                         object file


     file.profile
                         The directory for data used by -xprofile


     file.s
                         assembler source file


     file.so
                         dynamic library

     file.tcov
                         output from tcov(1)


     acomp
                         compiler front end


     cc
                         compiler command line driver


     cg
                         code generator (SPARC)


     crt1.o
                         runtime startup code


     crti.o
                         runtime startup code


     crtn.o
                         runtime startup code


     fbe
                         assembler


     gcrt1.o
                         startup for profiling with gprof(1)


     gmon.out
                         default profile file for -xpg


     ipo
                         Interprocedural optimizer (SPARC)


     iropt
                         global optimizer



     libm.so
                         system math library


     libmmheap.so.1
                         memory allocator  for  Studio  compilers
                         and runtimes


     libmtsk_db.so.1
                         debugging support library for  -xautopar
                         and -xopenmp


     libmtsk.so.1
                         runtime  library   for   -xautopar   and
                         -xopenmp

     libmvec.so.1
                         system vector math library



     libredblack.so
                         bids support



     libstkovf.so.1
                         runtime library for stack overflow diag-
                         nosis


     libsunmath.so.1
                         system math library extensions


     libsunperf.so
                         Sun Performance library


     libtdf.so.1
                         file access library for -xprofile


     libxprof_audit.so.1
                         linker audit library for -xprofile


     libxprof.so.1
                         runtime library for -xprofile


     llib-lm
                         system math lint library


     llib-lm.ln
                         system math lint library


     llib-lsunmath
                         System math extensions lint library


     llib-lsunmath.ln
                         System math extensions lint library



     mcrt1.o
                         start-up for profiling with prof(1)  and
                         intro(3)


     misalign.o
                         misalign data support (SPARC)


     mon.out
                         default profile file for -p


     postopt
                         postoptimizer (SPARC)

     ssbd
                         Static  synchronization  bug   detection
                         (Oracle Solaris Operating Environment)


     stack_grow.o
                         stack overflow checking (SPARC)


     SunWS_cache
                         The directory used to  store  data  when
                         the -xpch option is used.


     ube
                         optimizer, code generator (x86)


     ube_ipa
                         Interprocedural analyzer (x86)


     values-xa.o
                         -Xa support


     values-xc.o
                         -Xc support


     values-xpg4.o
                         xpg4 support


     values-xpg6.o
                         SUSv3 support


     values-xs.o
                         -Xs support


     values-xt.o
                         -Xt support


     xprof_fini.o
                         Initialization and finalization handlers
                         for      programs      compiled     with
                         -xprofile=collect

See Also
     analyzer(1), as(1),  c89(1),  c99(1),  cflow(1),  cscope(1),
     ctags(1),  ctrace(1),  dbx(1),  er_src(1), indent(1), ld(1),
     lint(1),  prof(1),  sunstudio(1),  version(1),  psrinfo(1M),
     tmpnam(3C), inline(4)


     Oracle Developer Studio
               12.6:
               C User's Guide

     Oracle Developer Studio
               12.6:
               OpenMP API User's Guide


     The ISO/IEC 9899-1990 Programming Language - C standard


     The ISO/IEC 9899-1999 Programming Language - C standard
맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.
RSS ATOM XHTML 1.0 CSS3