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

개요

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

cc(1)

cc(1)                            User Commands                           cc(1)



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 available 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 website:


        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 technologies and other topics.


       For  the  complete description of all new features and functionality 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 defini‐
       tion,  and  should  be  used only to specify the instruction set of the
       target processor.


       The ILP32 model specifies that C-language int, long, and  pointer  data
       types  are  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 compiling  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  fea‐
       tures.


       With  this  release,  the  default  instruction  set and the meaning 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  com‐
       piler  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. Running binary
       objects compiled by Oracle Developer Studio compilers 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 operating systems. Take
       note that the C compiler recognizes by default some of  the  constructs
       of  the  2011  ISO/IEC C standard. 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 compilation
       process incorporates a preprocessor, compiler,  code  generator,  opti‐
       mizer,  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 prepro‐
       cessed, compiled, optimized, instrumented for profiling, assembled, and
       link  edited.  Although the preprocessor can be used as a macro proces‐
       sor, this is not recommended, 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  appro‐
       priate 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  sub‐
       stituted 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 profiling, 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 automatically include the file setup.il.


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


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


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


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


       System administrators may create system-wide default files  in  Studio-
       install-path/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 produced by options  -#,  -###,
       and -dryrun.


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


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


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


         demo% cat /project/defaults/cc.defaults
         -fast -I/project/src/hdrs -L/project/libs -llibproj -xvpara
         demo% setenv SPRO_DEFAULTS_PATH /project/defaults
         demo% cc -c -I/local/hdrs -L/local/libs -lliblocal tst.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  prob‐
       lems.


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

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


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


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


       See ld(1) for linker options.


       In 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 brack‐
       ets ( [] ) are optional. Curly brackets enclose a bar-separated list of
       literal items to be chosen, as in {yes | no | maybe }. The  first  item
       in  a  list  usually  indicates the default value when the flag appears
       without a value.


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


       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 asser‐
           tions 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 speci‐
           fied 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 speci‐
           fied, 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 availability of the _Restrict key‐
           word:



             __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 -xmema‐
           lign=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 platforms.


       -E

           Runs  the  source  file through the preprocessor only and sends the
           output to stdout. The preprocessor is built directly into the  com‐
           piler,  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 messages.


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


       -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 con‐
           sists 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  suppres‐
           sion 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  function  argument  and  return
                        types.


           full         Error  messages are printed in full verbose form show‐
                        ing 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  speci‐
           fied 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 exam‐
           ple %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 fea‐
           tures  are  added.  Code  that compiles using -errwarn=%all without
           error may not compile without error in the next release of the com‐
           piler.

           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 previously
                        specified by this option with tag or %all from causing
                        cc  to exit with a fatal status when issued as a warn‐
                        ing message.


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


           %none        Prevents any warning messages from causing cc to  exit
                        with  a fatal status should any warning tag be issued.
                        This is the default.




       -fast

           This option is a macro that you can effectively use as  a  starting
           point for tuning an executable for maximum runtime 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  speci‐
           fied  at  both compile time and at link time, see the Oracle Devel‐
           oper 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 compilation machine. In such
           cases, follow -fast with the appropriate -xtarget option. For exam‐
           ple:


             % 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  command  line.
           Therefore,  you can override any of the expanded options by follow‐
           ing -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 pro‐
           gram 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, prema‐
           ture program termination, or unexpected SIGFPE signals.

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



       -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 conforms by
           default to the behavior specified by the ISO/IEC 9899:1999 C  stan‐
           dard. 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 pro‐
               gram will fail to write to a string literal under  the  default
               compilation mode just as if you had specified -xstrconst on the
               command line.


           [no%]extensions

               Allows/disallows zero-sized struct/union declarations and  void
               function with return statements returning a value to work.


           extinl

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


           [no%]extinl

               Generates extern inline functions as static functions.



           [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 duplicate strings
               are not removed.

               -features=mergestrings  is only effective when -features=const‐
               strings 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 oper‐
               ator,  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 other‐
               wise not allowed. The default is no%zla.


           %none

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


           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 propagate excep‐
           tions. You might need to enable this option when compiling  C  code
           that needs to interoperate properly with exception handlers written
           in C++ using any of their gcc compatibility modes. For more  infor‐
           mation, see -std=v in Oracle Developer
                           Studio 12.6: C++ User's Guide.

           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 dou‐
                        ble.


           any          Floating point expressions are evaluated depending  on
                        the combination of the types of the variables and con‐
                        stants 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 platforms  that  do  not  support  fused  multiply-add
           instructions.  When  the  minimum  architecture  is  not used, then
           -fma=fused has no affect.

           Fused multiply-add instructions eliminate the intermediate rounding
           step  between the multiply and add. Consequently, programs may pro‐
           duce different results when compiled with -fma=fused although  pre‐
           cision 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 ten‐
           tative 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  traditional  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  float‐
           ing-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  perfor‐
           mance of some programs.

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

           On SPARC systems, this option is effective only if used  when  com‐
           piling 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 float‐
           ing-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). -fpre‐
           cision is ignored on SPARC platforms.


       -fround=r

           Sets the IEEE 754 rounding mode that is established at runtime dur‐
           ing 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-nega‐
           tive-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 ini‐
           tial value (round-to-nearest by default).

           This option is effective only if used when compiling the main  pro‐
           gram.

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



       -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. Otherwise, the  enum
           type will be signed or unsigned as appropriate based on the enumer‐
           ator values.



       -fsimple[=n]

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

           The compiler defaults to -fsimple=0. Specifying -fsimple is equiva‐
           lent 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 following:

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


                   o      Computations  producing no visible result other than
                          potential floating- point exceptions 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 particular, a floating-point computa‐
                          tion cannot be replaced by one that produces differ‐
                          ent 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  -xvec‐
               tor=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 opti‐
               mizer 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 execution 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 Devel‐
           oper Studio website: oracle.com/technetwork/server-storage/develop‐
           erstudio/


       -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 evalu‐
           ating them in double precision. Use the -fsingle flag when specify‐
           ing  -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 vari‐
           able,  or  when  the expression is cast to a shorter floating-point
           type, rather than leaving the value in the register. Due to  round‐
           offs and truncation, the results may be different from those gener‐
           ated 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  simultaneously 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 common.



           [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 over‐
                               flow.


           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 example. The [no%] form of the option
           by  itself  does  not explicitly cause a particular trap to be dis‐
           abled.

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

           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  repre‐
           sented  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 exe‐
           cutable. 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  depen‐
           dency  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 com‐
           piled for 64-bit SPARC architectures must also be compiled with  an
           explicit  -xcode  value  as  documented  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 Per‐
           formance Analyzer analyzer(1).

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

           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 Per‐
           formance 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 com‐
           piling  your program. Use the er_src(1) command to display the mes‐
           sages, 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  prop‐
           erly  for  debugging.  Note that compiling the module that contains
           the function main with the  -g  option  is  usually  necessary  for
           debugging.

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

           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 parame‐
                        ter  information  that  is  considered  crucial during
                        post-mortem debugging.


           -g2          Same as -g.


           -g3          Produce additional debugging information,  which  cur‐
                        rently  consists only of macro definition information.
                        This added information 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                 -xcom‐
           press_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 dif‐
           ferent 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 executable file,
           it copies the intrinsic name from the library file  into  the  exe‐
           cutable,  into  a  list  of needed shared library files. Every exe‐
           cutable 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 follow‐
                      ing order:

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


                   2.     The  compiler  and system standard directories, usu‐
                          ally /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  directory  that
                          contains  the file which contains the include state‐
                          ment itself.


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


                   3.     The compiler and system standard  directories,  usu‐
                          ally /usr/include.



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


               o      The  compiler  never  searches  the  current  directory,
                      unless the directory is listed explicitly in a -I direc‐
                      tive. 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  directories,  usu‐
                          ally /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 compiler does not
                          search the -I directories that appear before -I-).


                   2.     The compiler and system standard  directories,  usu‐
                          ally /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 (/). Directories 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 settings.


       -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 preproces‐
           sor directive.

           The  first directory the compiler searches for filename is the cur‐
           rent 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 com‐
           pile 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  source‐
           file.


       -library=sunperf

           Link   with   the  Oracle  Developer  Studio  supplied  performance
           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 sufficient 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 -xmema‐
           lign=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 -xmema‐
           lign=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 paral‐
           lelization API) includes -mt=yes automatically.

           Use this option consistently. If you compile and link one  transla‐
           tion unit with -mt, you must compile and link all units of the pro‐
           gram 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 inappro‐
           priate for programs that rely on all variables being  automatically
           considered  volatile. Typical programs that might have this assump‐
           tion 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. file‐
           name  cannot  be the same as sourcefile since cc does not overwrite
           the source file.

           filename must have an appropriate suffix. When used with -c,  file‐
           name  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 corre‐
           sponding files suffixed .i. The output will not contain any prepro‐
           cessing 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 compiler 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  assign‐
           ments to formal parameters.


       -Qoption           phase
                   option[,option...]

           Passes option to the compilation phase.

           To  pass  multiple  options, specify them in order as a comma-sepa‐
           rated list. Options that are passed to components with -Qoption can
           be  reordered.  Options  that the driver recognizes are kept in the
           correct order. Do not use -Qoption  for  options  that  the  driver
           already recognizes.

           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 sup‐
           presses this information.


       -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  output  object
           file.  This option is passed to ld(1). This option cannot be speci‐
           fied with -g.



       -shared

           Produces a shared object  rather  than  a  dynamically-linked  exe‐
           cutable.  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 com‐
           piled for 64-bit SPARC architectures must also be compiled with  an
           explicit  -xcode  value  as  documented  under  the  description of
           -xcode.

           For more information, see the -G option.



       -staticlib=[no%]sunperf

           When used with -library=sunperf, -staticlib=sunperf will link stat‐
           ically  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 spec‐
           ified,  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  process.  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 execution.

           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 compiler command
           line when linking. The option is also accepted at compile-time  but
           is  ignored unless an executable binary is generated. Using -trace‐
           back with -G to create a shared library is an error.



           %none or none

               Disables traceback.


           common

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


           signals_list

               Specifies a comma-separated list  of  names  of  signals  which
               should  generate  a  stack  trace, in lower case. The following
               signals (those that cause the generation of a core file) can be
               caught: sigquit, sigill, sigtrap, sigabrt, sigemt, sigfpe, sig‐
               bus, sigsegv, sigsys, sigxcpu, 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 performance.


       -Uname

           Causes  any definition of name to be undefined. This option removes
           any initial definition of the preprocessor 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  information  on  the
           standard error output.


       -v

           Causes  the  compiler to perform more and stricter semantic 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 immediately preceding backslash (\) character;
           the backslash is removed from the resulting argument.) All -W argu‐
           ments are passed after the regular command-line arguments.

           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 optimizer


           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  over‐
           ride 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 compatibility exten‐
               sions. The compiler issues errors  and  warnings  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  dif‐
               ferent  semantics for the same construct, the compiler uses the
               ISO C interpretation. If the -Xa option is used in  conjunction
               with  the  -xtransition  option,  the  compiler issues warnings
               about the different semantics.


           t (transition) (Obsolete)

               The -Xt option will be removed in a future release. It is  rec‐
               ommended  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 com‐
               piler uses the K&R C interpretation. If you use the -Xt  option
               in  conjunction  with  the  -xtransition  option,  the compiler
               issues warnings about the different semantics.


           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 constructs 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  cre‐
           ation 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  capa‐
           bility.

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

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

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

           For more information refer to the SF1_SUNW_ADDR32 software capabil‐
           ities 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 compiler assumes
               that memory references that involve different C basic types  do
               not alias each other. The compiler also assumes that references
               to all other types can alias each other as well as any C  basic
               type.  The  compiler  assumes  that references using char * can
               alias any other type.


           weak

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

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

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


           layout

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

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


           strict

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

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

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


           std

               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 derefer‐
               encing of pointers that are found in the 1999 ISO  C  standard.
               Programs  that properly use this rule will be very portable and
               should see good performance gains under optimization.


           strong

               The same restrictions apply as at the std level, but  addition‐
               ally,  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-ana‐
           lyzer(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, -xan‐
           notate=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  architecture by
           allowing only the specified set of instructions. This  option  does
           not guarantee use of any target-specific instructions. However, use
           of this option can affect the portability of a binary program.  See
           the Notes and Warnings sections at the end of this entry.

           Note: 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 compati‐
           bility with previous 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 platforms and  -xarch=sparcvis2  on
                        SPARC platforms.


           native       Compile for good performance on this system.

                        The  compiler  chooses the appropriate setting 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 exten‐
               sions. This option enables the compiler to  generate  code  for
               good performance on the V9 ISA.


           sparcvis

               Compile for the SPARC-V9 ISA plus VIS.

               Compile for SPARC-V9 plus the Visual Instruction Set (VIS) ver‐
               sion 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 extensions, including  the
               Visual  Instruction  Set  (VIS) version 1.0, the UltraSPARC-III
               extensions, including the Visual Instruction Set (VIS)  version
               2.0,  the  fused  multiply-add  instructions,  and  the  Visual
               Instruction Set (VIS) version 3.0


           sparcfmaf

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

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

               Note  that  you  must  use -xarch=sparcfmaf in conjunction with
               -fma=fused and some optimization level to get the  compiler  to
               attempt  to find opportunities to use the multiply-add instruc‐
               tions 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 extensions, 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 extensions, 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 extensions, 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 sub‐
               set of the VIS 3.0 instructions a subset of the SPARC T3 exten‐
               sions,  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 extensions, including the
               Visual Instruction Set (VIS) version  1.0,  the  UltraSPARC-III
               extensions,  including 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 SPARCACE 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 extensions, including the
               Visual Instruction Set (VIS) version  1.0,  the  UltraSPARC-III
               extensions,  including 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 extensions, including  the
               Visual  Instruction  Set  (VIS) version 1.0, the UltraSPARC-III
               extensions, including 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 SPARCACE 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 extensions, including  the
               Visual  Instruction  Set  (VIS) version 1.0, the UltraSPARC-III
               extensions, including the Visual Instruction Set (VIS)  version
               2.0, the SPARC64 VI extensions for floating-point multiply-add,
               and the SPARC64 VII extensions for integer multiply-add.


           v9

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


           v9a

               Is equivalent to -m64 -xarch=sparcvis and is provided for  com‐
               patibility with earlier releases.


           v9b

               Is equivalent to -m64 -xarch=sparcvis2 and is provided for com‐
               patibility 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 instructions are available in many of these instruc‐
           tion 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  instruc‐
               tions.



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


           aes

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


           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  instruc‐
               tions.



           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 extension: 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 system 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 architectures
           (SSE, SSE2, SSE3, SSSE3, and so on) refer to the Intel-64 and IA-32
           Intel Architecture Software Developer's Manual.

           Defaults:

           If -xarch=isa is not specified, the defaults are: -xarch=generic on
           SPARC platforms -xarch=generic on x86/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 appropriate choice
           can provide good performance of the  executable  on  the  specified
           architecture.  An  inappropriate  choice,  however, might result in
           serious degradation of performance or in in a binary  program  that
           is not executable on all intended target platforms.


       -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  compatible
           standard  interface  and  the  Linux  bundled library conforms to a
           standard interface, the need for the -xatomic option will be redun‐
           dant.


       -xautopar

           Turns  on automatic loop parallelization. Analyzes loops for inter-
           iteration data dependence and does loop restructuring. If optimiza‐
           tion 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 prag‐
           mas.  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 information.

           If  you  compile  and  link in separate steps, specify -xautopar 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 performance. 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  argu‐
           ment,  the  default  is -xbuiltin=%all and the compiler substitutes
           intrinsics or inlines standard library functions much more  aggres‐
           sively.

           Compiling with -fast adds -xbuiltin=%all.

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


       -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 Lan‐
           guage - C).

           o can be a comma separated list comprised of the following:



           [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 particular 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 sup‐
           plied by the -xtarget option.

           The -xcache values are:


           generic

               Define the cache properties for good performance on most  plat‐
               forms. 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  migra‐
           tion  of  code  from  systems  where  the  char  type is defined as
           unsigned. Unless you are migrating from such a system, do  not  use
           this option. Only code that relies on the sign of a char type needs
           to be rewritten to explicitly specify signed or unsigned.  You  can
           substitute one of the following 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 rou‐
                       tines.


           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  rou‐
                       tines.


           u           Equivalent to unsigned.


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

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

           If  you use -xchar, be particularly careful when you compare a char
           against a predefined system macro because the value  in  the  macro
           may  be signed. This is most common for any routine that returns an
           error code which is accessed through a macro. Error codes are typi‐
           cally  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 com‐
           pilers 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-con‐
                      stant in low-to-high byte order.


           high       Place the characters of a multi-character character-con‐
                      stant in high-to-low byte order.


           default    Place the characters of a multi-character character-con‐
                      stant  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 multi‐
           threaded 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  over‐
               flow 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 SIGSEGV). The signal thus raised is said to be
               associated with the error.

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

               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 set‐
               ting the stack pointer to an  invalid  but  potentially  mapped
               address (see _stack_grow(3C)).

               The  optional  action, if specified, must be one of the follow‐
               ing:



               :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 corruption of the stack due
                   to  stack  overflow.  It  can  be  disabled  by  specifying
                   -xcheck=no%stkovf.


               :diagnose

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

                   If a memory access violation is diagnosed as a stack  over‐
                   flow 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  instruction  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  han‐
                   dler normally associated with the error.


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

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

               -xcheck=stkovf is supported only on Oracle Solaris.  The C run‐
               time  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, espe‐
               cially 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 tar‐
               get application 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 sup‐
           plied by the -xtarget option.

           This option specifies timing properties by  specifying  the  target
           processor.

           Some effects are:


               o      The ordering of instructions, that is, scheduling


               o      The way the compiler uses branches


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

           The -xchip values for SPARC platforms are:



           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 envi‐
               ronment.


           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  abso‐
               lute  addresses.  Code  +  data  + bss size is limited to 2**32
               bytes.


           abs44

               This is the default for 64-bit systems. Generates 44-bit  abso‐
               lute  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  sec‐
           tion  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 con‐
           tain source characters from one of these locales.

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



       -xcompress={[no%]debug}

           Compresses  debug sections using the format specified by the -xcom‐
           press_format option if supported by the underlying  Operating  Sys‐
           tem. 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 specifies 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 compression, using
                       the GNU section compression format.


           On Oracle Solaris, when compilation  involves  linking,  the  debug
           sections  are  compressed  using  the  ld  option -z  compress-sec‐
           tions=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-sec‐
           tions. For more information, see the objcopy(1g) man page.

           The option is ignored with a warning when Operating System  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 information.


       -xdebuginfo=a[,a...]

           Control how much debugging and observability information  is  emit‐
           ted.

           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 disables that suboption. The
           default is -xdebuginfo=%none. Specifying -xdebuginfo without a sub-
           option is forbidden.



           %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 informa‐
               tion 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 definitions of tagtypes.


           [no%]decl

               Emit information for function and variable declarations, 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 template 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  backtracking 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 -xdebuginfo 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  set‐
           ting 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 dependency analy‐
           sis is done at compile time.

           Dependency  analysis may help on single-processor systems. However,
           if you try -xdepend on single-processor  systems,  you  should  not
           also  specify  -xautopar  ,  otherwise 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  information  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 -xdumpmacros option is in effect until the end of the  file  or
           until it is overridden by the dumpmacros or end_dumpmacros pragma.

           Values:

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



           [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  direc‐
               tives.


           [no%]sys

               Print  all  macros  defines, undefines, and use information 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,  -xdump‐
               macros=%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 -xdump‐
           macros=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  functions  and
           variables by the linker.

           This  option  instructs the compiler to place functions and/or data
           variables  into  separate  section  fragments,  which  enables  the
           linker,  using directions in a mapfile specified by the linker's -M
           option, to reorder these sections to optimize 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 performance requires
           the following operations:


               1.     Compiling and linking with -xF.


               2.     Following the instructions in the Performance
                                        Analyzer  manual regarding how to gen‐
                      erate a mapfile for functions or following the  instruc‐
                      tions in the Linker and Libraries
                                        Guide regarding how to generate a map‐
                      file 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% disables the sub‐
           option.



           [no%]func

               Fragment functions into separate sections.


           [no%]gbldata

               Fragment global data (variables  with  external  linkage)  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  vari‐
           ables.

           Globalization is a technique needed by fix and continue functional‐
           ity 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 information that
           helps tools associate profiled load and store instructions with the
           data-types  and  structure  members  (in  conjunction with symbolic
           information produced with -g) to which they  refer.  It  associates
           profile  data  with  the  data space of the target, rather than the
           instruction space, and provides insight into behavior that  is  not
           easily obtained from only instruction profiling.

           You can compile a specified set of object files with -xhwcprof how‐
           ever, -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 profiling,  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 com‐
           piler is to attempt to automatically inline all  functions  in  the
           source files.

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

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


               o      The source for the function is in the  file  being  com‐
                      piled  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  com‐
           piler 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  inlin‐
           ing 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 representa‐
               tion) as possible inline candidates.

               Under no circumstances will a function larger than this be con‐
               sidered 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  func‐
               tion, use -xinline_report=2 to report detailed inlining message
               and follow the suggestion in the inlining message.


           max_function_inst[:n]

               Allow functions to increase due to automatic inlining by up  to
               n pseudo instructions (counted in compiler's internal represen‐
               tation).


           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  profil‐
               ing  feedback  (-xprofile)  in order to consider 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  combination  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 performing automatic  recursive  inlin‐
               ing.

               When  interactions  between  max_recursive_inst  and max_recur‐
               sive_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 parameters con‐
               trol the degree of inlining of small recursive 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  -xin‐
           line_param=default.

           The list of values and options accumulate from left  to  right.  So
           for           a           specification           of          -xin‐
           line_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  accumulate  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 output 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 parame‐
                        ters 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  call‐
                        site 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 call‐
           sites that are not inlined might not be accurate.


       -xinstrument=[no%]datarace]

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

           You can then use the Performance Analzyer to run  the  instrumented
           program  with  collect  -r  races  to  create a data-race-detection
           experiment. You can run the instrumented  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 argument.

           If you compile and link in seperate steps, you must  specify  -xin‐
           strument=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 compile command. However, whole-program opti‐
           mizations performed 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 perform optimizations across
           files. However, this additional information does not become part of
           the  final  executable binary file. Any increase in the size of the
           executable program is due  to  the  additional  optimizations  per‐
           formed.  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.

           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 interprocedural aliasing
           analysis as well as optimization of memory allocation and layout to
           improve cache performance.

           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 single 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 opti‐
           mizations 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 version 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  compila‐
           tion  may generate warnings about undefined symbols, but the inter‐
           procedural optimizations 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 optimiza‐
           tions as it works with the set of object files in  the  link  step.
           The  compiler  makes the following two assumptions for any function
           (or subroutine) foo() defined in this set of object files:


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


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


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

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

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

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

           See also: -xjobs and -xipo_archive


       -xipo_archive[=a]

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

           a is one of the following:



           writeback

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

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


           readonly

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

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

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


           none

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


           It is illegal to specify -xipo_archive without a flag.


       -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 initial pass and optimizing only at link time. Optimiza‐
           tion 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 including -xipo to perform optimiza‐
           tion,  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  __unopti‐
           mized_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-car‐
           ried  dependences  on  array references that it finds in a loop for
           purposes of optimization. This enables a compiler to perform  vari‐
           ous  loop  optimizations  such as microvectorization, distribution,
           software pipelining, etc., which would not be  otherwise  possible.
           It  is  used  in  cases where the user knows either that the depen‐
           dences do not matter or that they never occur in practice.

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

           The following values for p are interpreted as follows:



           loop        Ignore assumed loop-carried vector dependences.


           loop_any    Ignore all loop-carried vector dependences.


           back        Ignore  assumed  backward  loop-carried  vector  depen‐
                       dences.


           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 overhead among spawned jobs. Also, using a very high num‐
           ber 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. Mul‐
           tiple  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 process 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 variables.  The  no%
           prefix allows the compiler to potentially remove the definitions.

           The default is no%funcs,no%vars. Specifying -xkeep_unref is equiva‐
           lent   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 functions.

           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 -xkeep‐
           frame=%none.

           If specified on the command line  without  a  value,  the  compiler
           assumes -xkeepframe=%all.

           This option is accumulative and can appear on the command line mul‐
           tiple 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 functions, 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 con‐
                        formance with the C90 standard.


           c99          Specify runtime library behavior of libc be in confor‐
                        mance with the C99 standard.


           c11          Equivalent  to  c99.  The  runtime library behavior of
                        libc for c99 and c11 are identical.


           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 faster and safer shared
           libraries because the implementation 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 scop‐
               ing 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  symbolic  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 -xld‐
           scope=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  com‐
           mand  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 ver‐
           sions of the function.

           Library  functions  declared with the __hidden or __symbolic speci‐
           fiers 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 excep‐
           tional 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 -xinline 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 information.


       -xlibmopt[={%none,archive,shared}]

           Controls whether the compiler uses a library of optimized math rou‐
           tines  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 specified.)


           archive

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


           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 command line is not significant.

           The optimized math library includes selected math routines 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 compiler selects rou‐
           tines 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 opti‐
           mized  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 setting 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  link‐
           ing  with the optimized math library when -fast is used, add -xlib‐
           mopt=%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  opti‐
           mizations on relocatable object files.

           The  post-optimizer performs a number of advanced performance opti‐
           mizations 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  opti‐
                        mizations, at link time.


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


           Specifying   -xlinkopt   without   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  compiler  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 compile with
           -xlinkopt.

           You must use -xlinkopt on at least some of the compilation commands
           for  -xlinkopt  to  be useful at link time. The optimizer can still
           perform some limited optimizations 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 com‐
           mand 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 fol‐
           lows:



             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  stan‐
           dard 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 exam‐
           ple:



             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 dependencies:


             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 informa‐
           tion derived from the -o output  filename,  if  specified,  or  the
           input  source  filename,  replacing (or adding) the filename suffix
           with .d . If you specify -xMD and -xMF, the preprocessor writes all
           makefile  dependency  information  to the file specified with -xMF.
           Compiling with -xMD               -xMF or -xMD  -o   filename  with
           more  than  one  source file is not allowed and generates an error.
           The dependency file is overwritten if it already exists.


       -xMF           filename

           Use this option to specify a file for the makefile- dependency out‐
           put.  There  is no way to specify individual filenames for multiple
           input files with -xMF on one  command  line.  Compiling  with  -xMD
           -xMF  or  -xMMD  -xMF with more than one source file is not allowed
           and generates an error. The dependency file is  overwritten  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 functionality as -xM1, but  compila‐
           tion  continues.  -xMMD  generates an output file for the makefile-
           dependency information derived from  the  -o  output  filename,  if
           specified,  or the input source filename, replacing (or adding) the
           filename suffix with .d . If you specify -xMF,  the  compiler  uses
           the  filename  you  provide  instead.  Compiling with -xMMD -xMF or
           -xMMD -o  filename with more than one source file  is  not  allowed
           and  generates  an  error. The dependency file is overwritten if it
           already exists.


       -xMerge

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

           -xMerge, -ztext, and -xprofile=collect should not be used together.
           While -xMerge forces statically  initialized  data  into  read-only
           storage,  -ztext prohibits position-dependent symbol relocations in
           read-only storage, and -xprofile=collect generates statically  ini‐
           tialized,  position-dependent  symbol relocations in writable stor‐
           age.


       -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  assumptions  the
           compiler makes about the alignment of data. By controlling the code
           generated for potentially misaligned memory accesses  and  by  con‐
           trolling  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  mis‐
           aligned data accesses. There must be a value for both a (alignment)
           and b (behavior). a specifies the maximum assumed memory  alignment
           and b specifies the behavior for misaligned memory accesses.

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

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

           If  actual  data  alignment  at  runtime is less than the specified
           alignment, the misaligned access attempt (a memory read  or  write)
           generates  a  trap.  The  two possible responses to the trap are as
           follows:


               o      The OS converts the trap to a SIGBUS signal. If the pro‐
                      gram does not catch the signal, the program 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 normally.

           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 compiler options that must  be  speci‐
           fied  at  both compile time and at link time, see the Oracle Devel‐
           oper 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 platforms 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 -xmodel 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 your‐
           self.


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


       -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 pro‐
           gram is compiled, the better runtime performance obtained. However,
           higher optimization levels may result in increased compilation time
           and larger executable files.

           There are five levels that you can use with -xOn. The actual  opti‐
           mizations  performed  by the compiler at each level may change with
           each compiler release. They are only summarized here.

           If the optimizer runs out of memory, it attempts  to  proceed  over
           again  at  a  lower  level of optimization, resuming compilation of
           subsequent routines at the original level.

           Values:



           -xO1         Do only the basic local optimizations.


           -xO2         Do basic local and  global  optimization.  This  level
                        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  com‐
                        bined 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 feed‐
                        back. 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 opti‐
           mization 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 optimization level.

           If you use -g and the optimization level is -xO3 or lower, the com‐
           piler  provides  best-effort  symbolic information with almost full
           optimization. Tail-call optimization and back-end inlining are dis‐
           abled.

           If  you  use  -g  and the optimization level is -xO4 or higher, the
           compiler provides best-effort symbolic information with full  opti‐
           mization.

           Debugging  with  -g  does  not suppress -xOn, but -xOn limits -g in
           certain ways. For example,  the  optimization  options  reduce  the
           utility of debugging so that you cannot display variables from dbx,
           but you can still use the dbx  where  command  to  get  a  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 different  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 optimization level
               under -xopenmp=parallel is -xO3. The compiler raises the  opti‐
               mization 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 accord‐
               ingly, 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  macros.  This  is  the  default when
               -xopenmp is not specified.


           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  program.  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 pro‐
           cessor 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,  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 information.

           Nested parallelism is disabled by default. To enable nested  paral‐
           lelism,  you  must set the OMP_NESTED environment 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++ appli‐
           cation program interface (API) for building multithreaded  applica‐
           tions, 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 functions. This option does
           not produce any object or executable 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 platform. 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  deter‐
           mine page size of the target platform.

           The  -xpagesize  option  has no effect unless you use it at compile
           time and at link time. For a complete list of compiler options that
           must  be  specified  at both compile time and at link time, see the
           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  setting  the
           LD_PRELOAD  environment  variable  to mpss.so.1 with the equivalent
           options, or running the Oracle Solaris command  ppgsz(1)  with  the
           equivalent  options  before  running  the  program.  See the Oracle
           Solaris man pages for details.

           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  page‐
           size, 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 function. 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-spe‐
           cific  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 -xpch‐
           stop options in combination with the #pragma hdrstop directive.

           Use the -xpch  option  to  create  a  precompiled-header  file  and
           improve  your  compilation  time.  The  precompiled-header  file is
           designed to reduce compile time for applications whose source files
           share  a  common  set of include files containing a large amount of
           source code. A precompiled header works by  collecting  information
           about  a  sequence  of  header files from one source file, and then
           using that information when recompiling that source file, and  when
           compiling  other  source files that have the same sequence of head‐
           ers.

           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 deter‐
           mines  which include file is the last one. Use one of the following
           two flags to determine which method the compiler uses to  automati‐
           cally generate a precompiled header:



           -xpch=auto

               The  contents  of  the  precompiled-header file is based on the
               longest viable prefix (see the following section for an  expla‐
               nation  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 specifying  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  suffix  .cpch.
           When  you  specify  pch_filename, you can add the suffix or let the
           compiler add it for you. For example, if you specify cc  -xpch=col‐
           lect: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 fol‐
           lowing 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 precom‐
                      piled-header file is the same as the compiler that  cre‐
                      ated  the  precompiled-header file. A precompiled-header
                      file created by one version 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  contents  of  the
                      included  headers  that  were specified when the precom‐
                      piled 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 direc‐
                      tory in which the precompiled-header file was created.


               o      The   initial  sequence  of  pre-processing  directives,
                      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  direc‐
           tives  are  not  recognized by the compiler as tokens. This initial
           sequence of tokens is known as the viable prefix. In  other  words,
           the  viable  prefix  is  the top portion of the source file that is
           common to all source files. The compiler uses this viable prefix as
           the basis for creating a precompiled-header file and thereby deter‐
           mining which header files from the source are pre-compiled.

           The viable prefix that the compiler finds during the current compi‐
           lation must match the viable prefix that it used to create the pre‐
           compiled-header file. In other words, the  viable  prefix  must  be
           interpreted  consistently  by  the  compiler  across all the source
           files that use the same precompiled-header file.

           The viable prefix consists of any of  the  following  pre-processor
           directives:


               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 prefix automat‐
           ically when  you  specify  -xpch=auto  or  -xpch=autofirst  and  is
           defined as follows. For -xpch=collect or -xpch=use, the viable pre‐
           fix 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 generates a warn‐
           ing and disables the automatic  creation  of  a  precompiled-header
           file.  Also, if you specify both the #pragma hdrstop and the -xpch‐
           stop option, then the compiler uses the earlier  of  the  two  stop
           points to terminate the viable prefix.

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

           A header file is precompileable when it is interpreted consistently
           across different source files. Specifically, 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 decla‐
           ration 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 constraints 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-gener‐
           ated 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 com‐
           piler, 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  specify‐
           ing  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, gen‐
           erates a warning and disables the automatic generation of the  pre‐
           compiled-header file.

           A  #pragma  hdrstop  before the first include file under -xpch=aut‐
           ofirst or -xpch=auto disables the automatic generation of the  pre‐
           compiled-header file.

           See also: -xpchstop


       -xpchstop=[file|<include>]

           file  is  the last include file to be considered in creating a pre‐
           compiled-header file. Using -xpchstop on the command line is equiv‐
           alent 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  tun‐
           ing 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 pcsample(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 collected 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 incompatible  and  can  result  in
           internal errors.


       -xprefetch[=val[,val]]

           Enables  prefetch  instructions on those architectures that support
           prefetch. You must compile with optimization  level  3  or  greater
           with this option.

           val must be one of the following:



           auto

               Enable automatic generation of prefetch instructions.


           no%auto

               Disable automatic generation.


           explicit

               Enable explicit prefetch macros.

               Explicit  prefetching should only be used under special circum‐
               stances that are supported by measurements.


           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 execu‐
               tion of a prefetch instruction and  the  time  the  data  being
               prefetched is available in the cache.

               The  compiler assumes a prefetch latency value when determining
               how far apart to place a prefetch instruction and the  load  or
               store instruction that uses the prefetched data.

               Note: the assumed latency between a prefetch and a load may not
               be the same as the assumed latency between  a  prefetch  and  a
               store.

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

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

               To  use  the  latx:factor  suboption, start with a factor value
               near 1.0 and run performance  tests  against  the  application.
               Then  increase  or decrease the factor, as appropriate, and run
               the performance tests again. Continue adjusting the factor  and
               running the performance tests until you achieve optimum 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  applica‐
           tions  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 prefetches for direct mem‐
           ory accesses are generated.

           If you do not specify a setting for -xprefetch_auto_type, the  com‐
           piler 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  inser‐
           tion of prefetch instructions as determined 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   prefetch
           instructions.   -xprefetch_level=2  enables  additional  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  -xanno‐
           tate.

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


       -xprofile=p

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

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

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

           If  compilation  and  linking  are performed in separate steps, the
           same -xprofile option must appear on the compile  as  well  as  the
           link step. See the 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 initialized data into
               read-only storage, -ztext prohibits  position-dependent  symbol
               relocations  in read-only storage, and -xprofile=collect gener‐
               ates statically initialized, position-dependent symbol  reloca‐
               tions in writable storage.

               The  profile directory name profdir, if specified, is the path‐
               name of the directory where profile data are to be stored  when
               a program or shared library containing 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=col‐
               lect: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  variables  SUN_PROFDATA  and
               SUN_PROFDATA_DIR  can be used to control where the profile data
               are stored at runtime. If set, the profile data are written  to
               the directory given by $SUN_PROFDATA_DIR/$SUN_PROFDATA.

               If  a  profile directory name is specified at compilation time,
               SUN_PROFDATA_DIR and SUN_PROFDATA have no  effect  at  runtime.
               These  environment  variables  similarly  control  the path and
               names of the profile data files written by tcov,  as  described
               in the tcov(1) man page.

               If these environment variables are not set, the profile data is
               written to the directory profdir.profile in the current  direc‐
               tory,  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 .pro‐
               file. If you run the program several times, the execution  fre‐
               quency  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 directory 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 optimization 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 variables 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 exe‐
               cuted.  profdir  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 -xpro‐
               file=use[:profdir], the same profile directory must  be  speci‐
               fied   at   compilation   time,   using   the   option   -xpro‐
               file=tcov[:profdir]. To minimize confusion, specify profdir  as
               an absolute pathname.

               The  profdir is optional. If profdir is not specified, the name
               of the executible binary is used. a.out is used if  -o  is  not
               specified.  The compiler looks for profdir.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 frequency  data
               previously generated and saved in the feedback files written by
               a previous  execution  of  the  program  compiled  with  -xpro‐
               file=collect.

               Except  for  the  -xprofile  option, the source files and other
               compiler options must be exactly the same as those used for the
               compilation  that  created  the  compiled program which in turn
               generated the feedback file. The same version of  the  compiler
               must  be  used  for both the collect build and the use build as
               well.

               If compiled with -xprofile=collect:profdir,  the  same  profile
               directory  name profdir must be used in the optimizing compila‐
               tion: -xprofile=use:profdir.

               See also -xprofile_ircache for speeding up compilation  between
               collect and use phases.


           tcov[:profdir]

               Instrument object files for basic block coverage analysis using
               tcov(1).

               If the optional :profdir argument is  specified,  the  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 profile direc‐
               tory 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  con‐
               trolled  using environment variables SUN_PROFDATA and SUN_PROF‐
               DATA_DIR. See ENVIRONMENT below.

               If the location specified by :profdir is not  absolute,  it  is
               interpreted  relative to the current working directory when the
               program is compiled.

               If :profdir is specified for any object file, the same location
               must be specified for all object files in the same program. The
               directory whose location  is  specified  by  :profdir  must  be
               accessible  from  all machines where the profiled program is to
               be executed. The profile directory should not be deleted  until
               its contents are no longer needed, because data stored there by
               the compiler cannot be restored except by recompilation.

               Example 1: If object files for one or more  programs  are  com‐
               piled  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  execu‐
               tion data associated with the profiled object files.

               Example  2: If a program named "myprog" is compiled with -xpro‐
               file=tcov and executed in the directory /home/joe,  the  direc‐
               tory  /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 compila‐
           tion 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 use‐
           ful  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 specify‐
           ing  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 directories.

           The collect-prefix is the prefix of the UNIX pathname of  a  direc‐
           tory  tree in which object files were compiled using -xprofile=col‐
           lect.

           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 com‐
           piler processes them in the order of their  occurrence.  Each  use-
           prefix  specified  by  an instance of -xprofile_pathmap is compared
           with the object file pathname until either a matching use-prefix is
           identified  or  the last specified use-prefix is found not to match
           the object file pathname.


       -xreduction

           Analyzes loops for reduction  in  automatic  parallelization.  This
           option  is valid only if -xautopar is also specified. Otherwise the
           compiler issues a warning.

           When a reduction recognition is enabled, the compiler  parallelizes
           reductions such as dot products, maximum and minimum finding. These
           reductions yield different roundoffs from those obtained by  unpar‐
           allelized code.


       -xregs=r[,r...]

           Specify the usage of registers for the generated code.

           r  is a comma-separated list of one or more of the following subop‐
           tions: 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 application reg‐
               isters as scratch registers. The application registers are  g2,
               g3,  and  g4 on 32-bit platforms) and g2 and g3 on 64-bit plat‐
               forms.

               It  is  strongly  recommended  that  all  system  software  and
               libraries  be  compiled  using  -xregs=no%appl. System software
               (including shared libraries)  must  preserve  these  registers'
               values  for  the  application. Their use is intended to be con‐
               trolled by  the  compilation  system  and  must  be  consistent
               throughout the application.

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

               For more information on SPARC instruction sets, see -xarch.


           float (SPARC)

               Allow the compiler to generate code by using the 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 com‐
               pilers will attempt to diagnose 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 regis‐
               ter.

               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 performance. 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 compiled with
               -xregs=frameptr if a C++ function,  called  directly  or  indi‐
               rectly 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 expan‐
           sion 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 regis‐
           ter 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 com‐
           piled 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  parame‐
           ters in the specified functions are treated as restricted; if -xre‐
           strict=%all is specified, all pointer parameters in  the  entire  C
           file are treated as restricted.

           The default is %none. Specifying -xrestrict is equivalent to speci‐
           fying -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 exe‐
           cutable.

           -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 pro‐
           gram.

           When the compile command forces linking (that is, -c is not  speci‐
           fied)  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 sec‐
           tion 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 protection vio‐
           lations 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 violation occurs,  you  should
           use  this  option  only  for  programs  in which such faults cannot
           occur. Because few  programs  incur  memory-based  traps,  you  can
           safely  use  this  option for most programs. Do not use this option
           for programs that explicitly depend on memory-based traps to handle
           exceptional conditions.

           This  option  takes  effect  only when used with optimization level
           -xO5 and one of the following -xarch values: sparc, sparcvis, spar‐
           cvis2, 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_analy‐
           sis=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 boundary, 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  afore‐
           mentioned 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  precision.  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  -fea‐
           tures=[no%]conststrings instead.

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


       -xtarget=t

           Specifies the target system for the instruction set  and  optimiza‐
           tion.

           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 -xtar‐
           get=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 indicated 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 fol‐
           lows:


             -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  -xtar‐
           get=native when compiling on that system.

           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  (Obso‐
               lete), 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  arguments,  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 signifi‐
           cantly 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 command 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  optimizations  that
           slightly  reduce  performance  for a single process 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 com‐
           piler 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 inter‐
           nationalized application that uses ISO10646 UTF-16 string literals.
           In other words, use this option if your code contains string liter‐
           als 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 argu‐
           ment, the compiler won't accept it and instead  issues  a  warning.
           The  default  can change if the C or C++ standards define a 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 fol‐
           lowing 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 Instruction Multiple Data)  instruc‐
           tions  on processors that support SIMD. You must use default round‐
           ing mode by specifying -fround=nearest when you use this option.

           The -xvector option requires optimization level  -xO3  or  greater.
           The  option  is silently ignored if the optimization level is lower
           than -xO3.

           a is the equivalent of the following. Prefix no% disables a  subop‐
           tion.



           [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  val‐
               ues    under    -xarch=sparcace,     -xarch=sparcaceplus    and
               -xarch=sparcace2, -xvector=simd  is  in  effect  unless  -xvec‐
               tor=none  or  -xvector=no%simd  has been specified. In addition
               -xO4 or greater is required for -xvector=simd, otherwise -xvec‐
               tor=simd is ignored.

               For  all  other  -xarch values, directs the compiler to use the
               Visual Instruction Set [VIS1, VIS2, ViS3, etc.]  SIMD  instruc‐
               tions  to  improve  the performance of certain loops. Basically
               with explicit -xvector=simd option, the compiler  will  perform
               loop  transformation enabling the generation of special vector‐
               ized 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  extensions  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 Ora‐
           cle 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 Oracle 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 instructions. The default is -xvis=no. Specify‐
           ing -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 processors are 64-bit,
           there are many cases, especially in multimedia  applications,  when
           the  data are limited to eight or 16 bits in size. The VIS instruc‐
           tions can process four 16-bit data with  one  instruction  so  they
           greatly  improve  the  performance  of applications that handle new
           media such as imaging, linear algebra,  signal  processing,  audio,
           video and networking.


       -xvpara

           Issues  warnings about potential parallel-programming related prob‐
           lems that may cause incorrect results when using OpenMP.  Use  with
           -xopenmp and OpenMP API directives.

           The  compiler  issues warnings when it detects the following situa‐
           tions:


               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  component  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 direc‐
           tory 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 opti‐
       mizing out such library calls and to to ensure that calls to math func‐
       tions set errno as documented.

   New Shared Libraries
       For  Solaris  release  10,  new  shared  libraries libxprof.so.1, libx‐
       prof_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 Ora‐
       cle 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 manpage 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 spec‐
       ified, 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 interpreted by
           lint as though its value had been placed on the command line, imme‐
           diately 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 direc‐
           tory, 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 compiled with
           -xprofile=collect in a directory named profdir in the current work‐
           ing  directory  at  the  time  that the program is executed. If the
           optional  argument  :profdir  was   specified   in   -xprofile=col‐
           lect[:profdir] at compilation time, SUN_PROFDATA as no effect.


       SUN_PROFDATA_DIR=dirname

           If  set,  store profile data collected from a program compiled with
           -xprofile=collect in a directory whose UNIX dirname is dirname.  If
           dirname  is not absolute, it is interpreted relative to the current
           working directory at the time that the program is executed. If  the
           optional   argument   :profdir   was  specified  in  -xprofile=col‐
           lect[:profdir] at compilation time, SUN_PROFDATA_DIR has no effect.


       SUN_PROFDATA_REPLACE={objfile,program,all}

           The value of the environment  variable  SUN_PROFDATA_REPLACE  indi‐
           cates  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  fol‐
           lows:


           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_PROF‐
           DATA_REPLACE=objfile .

           Example:



             % setenv SUN_PROFDATA_REPLACE program (csh)
             $ export SUN_PROFDATA_REPLACE=program (ksh)


           With this setting, when a program containing a changed object  file
           is  executed,  all object files in the program will have their pro‐
           file data reset. Relevant options include -xOn and -xipo=n.


       SUN_PROFDATA_ASYNC_INTERVAL=async_interval

           Set this environment variable to enable asynchronous  profile  col‐
           lection.  In asynchronous profile collection, profile data are col‐
           lected 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 envi‐
           ronment 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  following  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 asynchronous collec‐
           tor 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 interfer‐
           ence with profile collection by application threads that  have  not
           terminated  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 pro‐
       gram 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 diagnosis


       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 pro‐
                           grams 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), sun‐
       studio(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



Studio 12.6                        May 2017                              cc(1)
맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.
RSS ATOM XHTML 5 CSS3