cc




SYNOPSIS
       cc [-newc] [flag ...] file ...
       cc -oldc [flag ...] file ...
       cc -migrate [flag ...] file ...

   Default Flags:
       cc -newc -assume aligned_objects -cpp -call_shared -double
       -fprm n -fptm n -g0 -I/usr/include  -inline  manual  -mem­
       ber_alignment  -no_fp_reorder -no_misalign -O1 -oldcomment
       -p0 -no_pg -preempt_symbol  -signed  -arch  generic  -std0
       -tune generic -writable_strings

DESCRIPTION
                                  Note
       This  manpage  is outdated.  It is being retained only for
       the purpose of documenting the -oldc and  -migrate  flags.
       These  flags were provided in previous versions of DIGITAL
       UNIX to support the transition  to  the  new  C  compiler.
       That  transition  is  now complete and we do not encourage
       the continued use of these flags.

       This manpage will not be updated to reflect changes to the
       system C compiler. It should only be referenced to gain an
       understanding of the effects of -oldc and  -migrate.   For
       documentation on the system C compiler, see cc(1).

       The  cc  command  invokes  the  C compiler.  The -newc and
       -oldc  flags  invoke  different  compiler  implementations
       (where  the  implementation  invoked  by -newc is upwardly
       compatible with that invoked by -oldc).  The  "newc"  com­
       piler  offers  improved optimization, additional features,
       and greater compatibility with Digital compilers  provided
       on other platforms.  The "newc" compiler implementation is
       the default.

       You can access the "newc" compiler with either  the  -newc
       flag  or  the  -migrate  flag;  however, the default flags
       associated with these two flags are different:

       - The default flags associated with  the  -newc  flag  are
         similar  to the defaults associated with the -oldc flag.

       - The default flags associated with the -migrate flag  are
         the   same  as  those  previously  associated  with  the
         -migrate flag in the compilation  environment  for  ver­
         sions  of the DEC OSF/1 operating system preceding DIGI­
         TAL UNIX Version 4.0.

       can continue to use the compiler in the same way that they
       did previously (that is, the same  command  line  accesses
       the same compiler with the same defaults).

       The  cc command can accept any of the following file argu­
       ments:

       - Arguments whose names end with .c are assumed  to  be  C
         source programs. They are compiled, and each object pro­
         gram is left in a file whose name consists of  the  last
         component of the source with .o substituted for .c.  The
         .o file is deleted only when a single source program  is
         compiled and loaded all at once.

       - Arguments whose names end with .s are assumed to be sym­
         bolic  assembly  language  source  programs.   They  are
         assembled, producing a .o file.

       - Arguments  whose  names  end with .i are assumed to be C
         source files after being processed by the  C  preproces­
         sor.

       - Arguments  whose names do not end with .c, .s, or .i are
         assumed to be either C-compatible  object  files,  typi­
         cally  produced by an earlier cc run, or libraries of C-
         compatible routines.

       When you use the -oldc flag, the compiler accepts the fol­
       lowing additional file arguments:

       - Arguments  whose  names  end  with  .c are compiled into
         ucode object files when -oldc's highest level  of  opti­
         mization  is  specified  (-O3  flag)  or when only ucode
         object files are to be produced (-j  flag).   The  ucode
         object file is left in a file whose name consists of the
         last component of the source with .u substituted for .c.

       - Arguments  whose  names  end with .B, .O, .S, and .M are
         assumed to be binary ucode, produced by the  front  end,
         optimizer, ucode object file splitter, and ucode merger,
         respectively.  Arguments whose names  end  with  .U  are
         assumed to be symbolic ucode.  Arguments whose names end
         with .G are assumed  to  be  binary  assembly  language,
         which is produced by the code generator and the symbolic
         to binary assembler.  These files primarily aid in  com­
         piler development and are not generally used.

       - Files  that  are  assumed  to  be binary ucode, symbolic

       The cc command can  accept  flags  that  are  specific  to
       either  the  cc  command or the ld command (linker).  When
       the compiler recognizes  position-sensitive  linker  flags
       (-L,  -all,  -exclude,  -exported_symbol,  -hidden,  -hid­
       den_symbol, -kl, -l, -none, -non_hidden, and -no_archive),
       it  maintains  their  relative order for the linker.  This
       reference page describes the flags that  are  specific  to
       the cc command.  See ld(1) for a description of the linker
       flags.

       All of the input files, plus the results of  the  compila­
       tions,  are  loaded  in the order given to produce an exe­
       cutable program with the default name a.out.  The compiler
       can produce object files in extended COFF format (the nor­
       mal result).  It can also produce object files in symbolic
       assembly  language  format  when invoked with the -S flag.
       When invoked with the -oldc  flag,  it  can  also  produce
       binary  assembly  language code, binary ucode, or symbolic
       ucode.

       When the compiler is invoked, it  defines  C  preprocessor
       macros  that  identify the language of the input files and
       the environments in which the code can run.  You can  ref­
       erence  these  macros in #ifdef statements to isolate code
       that applies to a particular language or environment.  The
       preprocessor  macros  are  listed  in the following table.
       Note that the type of standards you apply and the type  of
       source file determine which macros are defined.
       -------------------------------------------------------------------------
       Macro                              Source File Type   -std Flag
       -------------------------------------------------------------------------
       __DECC (-newc and -migrate only)   .c
       LANGUAGE_C                         .c                 -std0
       __LANGUAGE_C__                     .c                 -std0, -std, -std1
       unix                               .c, .s             -std0
       __unix__                           .c, .s             -std0, -std, -std1
       __osf__                            .c, .s             -std0, -std, -std1
       __alpha                            .c, .s             -std0, -std, -std1
       __arch64__                         .c, .s             -std0, -std, -std1
       __digital__                        .c, .s             -std0, -std, -std1
       SYSTYPE_BSD                        .c, .s             -std0
       _SYSTYPE_BSD                       .c, .s             -std0, -std, -std1
       LANGUAGE_ASSEMBLY                  .s                 -std0, -std, -std1
       __LANGUAGE_ASSEMBLY__              .s                 -std0, -std, -std1
       -------------------------------------------------------------------------

       You  can explicitly define macros with the -D flag to con­
       trol which functions are declared in header files  and  to
       obtain  standards conformance checking.  See for a list of

       While the -D flag controls which functions are declared in
       header  files,  the  -stdn  flags control how strictly the
       declarations conform to the ANSI C standard.   For  strict
       ISO  C  and  ANSI C conformance, the compiler command line
       must include the -std1 flag.

       The following environment variables  can  affect  compiler
       operation:

       LANG
           Provides a default value for locale variables that are
           not set.   If  any  of  these  variables  contains  an
           invalid  setting, the compiler behaves as if none were
           set.

       LC_ALL
           If set to a non-empty string, this variable  overrides
           values in all locale variables, including LANG.

       LC_CTYPE
           Determines   the  locale  for  the  interpretation  of
           sequences of bytes of text  data  as  characters  (for
           example,  single-  as opposed to multi-byte characters
           in arguments and input files).

       LC_MESSAGES
           Determines the locale used for diagnostic messages.

       NLSPATH
           Determines the locale of message catalogs for the pro­
           cessing of LC_MESSAGES.

       TMPDIR
           Provides  a pathname that overrides the default direc­
           tory for temporary files, if any.

       For more information on these environment  variables,  see
       i18n_intro(5) and l10n_intro(5).

       To facilitate setting default compiler flags, you can cre­
       ate an optional configuration file named comp.config or an
       environment variable named DEC_CC:

       - The  comp.config  file  allows  system administrators to
         establish a set of compilation flags that are applied to
         compilations on a system-wide basis.  The compiler flags
         in comp.config must be specified on a single  line,  and

       - The DEC_CC environment variable allows DEC  C  users  to
         establish a set of compilation flags that are applied to
         subsequent compilation on a per-user basis.

         The DEC_CC environment variable can contain two distinct
         sets of compilation flags separated by a single vertical
         bar (|).  The flags before the vertical bar are known as
         prologue  flags  and the flags after the bar are know as
         epilogue flags.

         The DEC_CC environment variable can begin or end with  a
         vertical  bar,  or  have  no vertical bar at all.  If no
         vertical bar is present, the flags are treated  as  pro­
         logue  flags  by  default.  Any vertical bar found after
         the first vertical bar is treated as  whitespace  and  a
         warning is issued.

       Compiler flags are processed in the following order during
       a compilation:

        1.  comp.config flags

        2.  DEC_CC prologue flags

        3.  command line flags

        4.  DEC_CC epilogue flags

       If -v is specified on the command line,  the  contents  of
       DEC_CC and comp.config, if present, are displayed.

FLAGS
       Flags  described in this section are divided into the fol­
       lowing categories:

       - Compiler selection flags

       - Overall compiler behavior flags

       - C preprocessor flags

       - Linker or loader flags

       - Optimization flags

       - Feedback-directed optimization flags

       - Code portability flags

       - Data alignment flags

       - Data volatility flags

       - C language flags

       - Rounding-mode flags (IEEE floating-point)

       - Stack-handling and pointer-handling flags

       - IEEE floating-point support flags

       - Ucode generation flags (enabled by -oldc)

       - Compiler development flags (not generally used)

   Compiler Selection Flags
       -newc
           Invokes the new implementation of the C compiler, with
           defaults  that  make it compatible with the -oldc com­
           piler.  This is the default.

       -migrate
           Invokes the new implementation of the C compiler,  but
           with  a  slightly  different set of compiler flags and
           default optimizations.  These flags and  optimizations
           provide  backward compatibility for applications rely­
           ing on the -migrate flag provided in  previous  imple­
           mentations of the cc command.

       -oldc
           Invokes the older, ucode-based implementation of the C
           compiler.

   Overall Compiler Behavior Flags
       -arch option
           Specifies which version of the Alpha  architecture  to
           generate  instructions  for.    All  Alpha  processors
           implement a core set  of  instructions  and,  in  some
           cases, the following extensions: BWX (byte/word-manip­
           ulation extension), MVI  (multimedia  extension),  FIX
           (square  root  and  floating-point extension), and CIX
           (count extension).  (The Alpha Architecture  Reference

       generic
           Generate instructions that  are  appropriate  for  all
           Alpha processors.  This option is the default.

       host
           Generate  instructions for the processor that the com­
           piler is running on (for example, EV6 instructions  on
           an EV6 processor).

       ev4,ev5
           Generate  instructions  for  the EV4 processor (21064,
           20164A, 21066, and  21068  chips)  and  EV5  processor
           (some  21164  chips).  (Note that chip number 21164 is
           used for both EV5 and EV56 processors.)

           Applications compiled with this option will not  incur
           any emulation overhead on any Alpha processor.

       ev56
           Generate  instructions for EV56 processors (some 21164
           chips).

           This option permits the compiler to generate  any  EV4
           instruction,  plus  any  instructions contained in the
           BWX extension.

           Applications compiled with this option may incur  emu­
           lation overhead on EV4 and EV5 processors.

       ev6 Generate   instructions   for  EV6  processors  (21264
           chips).

           This option permits the compiler to generate  any  EV6
           instruction,  plus  any  instructions contained in the
           following extensions: BWX, MVI, FIX, and CIX.

           Applications compiled with this option may incur  emu­
           lation  overhead  on EV4, EV5, EV56, and PCA56 proces­
           sors.

       pca56
           Generate instructions for  PCA56  processors  (21164PC
           chips).

           This  option  permits the compiler to generate any EV4
           instruction, plus any instructions  contained  in  the
           BWX and MVI extensions.

           Applications  compiled with this option may incur emu­
           and continuing with subsequent versions, the operating
           system  kernel  includes an instruction emulator. This
           capability allows any Alpha chip to execute  and  pro­
           duce correct results from Alpha instructions - even if
           the some of the instructions are  not  implemented  on
           the  chip.   Applications  using emulated instructions
           will run correctly, but may incur  significant  emula­
           tion overhead at run time.

           The  psrinfo -v command can be used to determine which
           type of processor is installed on any given Alpha sys­
           tem.

       -c  Suppresses  the  loading  phase of the compilation and
           forces the creation of an object file.

       -edit[0-9]
           When syntactic or semantic errors are detected by  the
           compiler's  front  end,  invokes the editor defined by
           the environment variable EDITOR (or vi  if  EDITOR  is
           undefined).   Two  files  are  opened for editing: the
           error message file, which indicates  the  location  of
           the  error,  and  the source file.  When you exit from
           the editor, the compilation is restarted.

           The n argument specifies the number of times a  compi­
           lation  can  be interrupted in this way.  If no number
           is specified, the compile-edit-compile  cycle  repeats
           indefinitely  until  all  errors  are  corrected.  The
           -edit0 flag turns off  this  feature.   To  abort  the
           cycle,  you  must press Ctrl-C while the process is in
           the compilation phase (that is, while it is not in the
           editor).

           When compiling on a character-based terminal, the com­
           pile job has to be in the foreground for this flag  to
           take  effect.   When  compiling on a workstation, this
           flag takes effect whether it is in the  foreground  or
           background.

       -[no]error_limit nn
           Sets a limit on the number of errors that the compiler
           will flag.  The default is 30.

       -FIfilename
           Specifies a file that is to  be  included  before  the
           first  line  in  a  source  file is actually compiled.
           This enables users to develope include files  contain­
           ing  sets  of pragmas that control a particular aspect
           of a compilation (for example, optimizations or  diag­
           nostics).

       -msg_actiontype msg_list
           Provides users with the ability to control  the  diag­
           nostic  messages  issued by the compiler.  The message
           output can be tuned in groups (based on message  level
           or  message  group) or individually (based on the mes­
           sage ID strings enclosed in parentheses at the end  of
           message text strings).

           The  -msg_actiontype  flag  has eight different forms,
           each resulting in a different action that changes  the
           status, severity, or frequency that will be applied to
           the messages identified by the msg_list argument.  The
           following message-control flags are supported:

       -msg_enable
         Enable a specific message or group of messages.

       -msg_disable
         Disable  a  specific message or group of messages. (Note
         that messages with error or  fatal  severity  cannot  be
         disabled; only warning and informational messages can be
         disabled.)

       -msg_always
         Always emit the  messages  identified  by  the  msg_list
         argument.

       -msg_once
         Emit the identified messages only once.

       -msg_fatal
         Change the identified messages to be fatal, compilation-
         ending errors.

       -msg_warn
         Change the identified messages to  be  warnings.   (Note
         that error- or fatal-severity messages cannot be changed
         to warning-severity messages.)

       -msg_inform
         Change the identified messages to be informational  mes­
         sages.   (Note  that  error-  or fatal-severity messages
         cannot be changed to informational-severity messages.)

       -msg_error
         Change the identified messages  to  be  error  messages.
         (Note  that fatal-severity messages cannot be changed to
         error-severity messages.)

         sage groups, or message IDs.  Enabling a  message  level
         also  enables  all  lower  levels, and disabling a level
         also disables all higher levels.  For example, disabling
         level  3  messages  disables  levels  3 - 6.  Operations
         other than enabling or disabling apply only to the spec­
         ified (or default) level, not to lower levels.

         The following message levels and message groups are sup­
         ported:

         Message Levels:

       level0
         Very important messages that  are  enabled  by  default.
         Level 0 messages cannot be disabled as a class (level0),
         but individual level 0 messages can be disabled if  they
         are   warning-   or   informational-severity   messages.
         (Error- or fatal-severity messages cannot be  disabled.)

         Messages at this level correspond to messages covered by
         pragma nostandard.   These  include  all  messages  that
         should be displayed for code in header files.

       level1
         Important messages, but less important than level 0 mes­
         sages.  These messages are not displayed if pragma  nos­
         tandard  is  active.  Level 1 is the default for DIGITAL
         UNIX releases prior to V4.0E.

       level2
         Moderately important messages. Level 2  is  the  default
         for the DIGITAL UNIX V4.0E and later versions.

       level3
         Less  important  messages. (The -w0 flag enables level 3
         messages.)

       level4
         Useful messages associated with the -check and -portable
         flags.

       level5
         Less  useful -check and -portable messages than the mes­
         sages associated with level 4. (The -check flag  enables
         level 5 messages.)

       level6
         All  messages,  including all messages not in any of the
         lower levels.   Disabling  level  6  messages  does  not
         affect  the  lower-level  messages;  it affects only the

       alignment
         Messages reporting unusual or  inefficient  data  align­
         ment.

       c_to_cxx
         Messages  reporting  the use of C features that would be
         invalid or have a different meaning if compiled by a C++
         compiler.

       check
         Messages reporting code or practices that, although cor­
         rect and perhaps portable, are sometimes considered ill-
         advised  because  they  can  be  confusing or fragile to
         maintain (for example, assignment as the test expression
         in an if statement).

       defunct
         Messages  reporting  the  use of obsolete features, fea­
         tures that were commonly accepted by early  C  compilers
         but were subsequently removed from the language.

       noansi
         Messages reporting the use of non-ANSI C features.

       obsolescent
         Messages reporting the use of features that are valid in
         ANSI C, but which are  identified  in  the  standard  as
         being obsolescent and likely to be removed from the lan­
         guage in a future version of the standard.

       overflow
         Messages reporting assignments  and/or  casts  that  may
         cause overflow or other loss of data significance.

       performance
         Messages  reporting  code that might result in poor run-
         time performance.

       portable
         Messages reporting the use  of  language  extensions  or
         other  constructs  that  might  not be portable to other
         compilers or platforms.

       preprocessor
         Messages reporting questionable or non-portable  use  of
         preprocessing constructs.

       guestcode
         Messages reporting questionable coding practices.  Simi­
         lar to check, but messages in this group are more likely
         to  indicate  a programming error, not just a non-robust

       unused
         Messages reporting expressions, declarations,  and  code
         paths that are not used.

       -nestlevel=n
           Sets  the  nesting-level limit for include files.  The
           default is 50.

       -machine_code
           Includes the generated machine  code  in  the  listing
           file.   By  default,  machine  code is not listed.  To
           produce  the  listing  file,  you  must  also  specify
           -source_listing.

           [The  -machine_code flag is not available when you use
           the -oldc flag.]

       -noobject
           Suppresses creation of an object file. By default,  an
           object  module  file  is created with the same name as
           that of the first source file of  a  compilation  unit
           and with the .o file extension.

           Use the -noobject flag when you need only a listing of
           a program or when you want the  compiler  to  check  a
           source file for errors.

           [The  -noobject flag is not available when you use the
           -oldc flag.]

       -o output
           Names the final output file output.

       -protect_headers keyword
           Ensures that the compiler's assumptions about  pointer
           sizes and data alignments are not in conflict with the
           default values that were in  effect  when  the  system
           libraries were created.

           The keywords for the -protect_headers flag are as fol­
           lows:

       all Enables the protect  headers  feature.   This  is  the
           default if the file being compiled is a C source file.

       none
           Disables the protect headers  feature.   This  is  the
           default  if  the file being compiled is a non-C source
           the compiler's default behavior in effect.

           If  more  than  one such switch appears on the command
           line, only the last one is applied.  See protect_head­
           ers_setup(8) for details.

           [The  -protect_headers  flag is not available when you
           use the -oldc flag.]

       -S  Compiles the specified source files and generates sym­
           bolic  assembly language output in corresponding files
           suffixed with .s.

       -show keyword[,keyword,...]
           Specifies one or more items  to  be  included  in  the
           listing file.  When specifying multiple keywords, sep­
           arate them by commas and no intervening blanks. To use
           any  of  the -show keywords, you must also specify the
           -source_listing option.

           The keywords for the -show flag are as follows:

       none
           Turns off all show options.

       all Turns on all show options.

       [no]expansion
           Places final macro expansions in the program  listing.
           When  you specify expansion, the number printed in the
           margin indicates the maximum depth of macro  substitu­
           tions that occur on each line.

       [no]header
           Produces header lines at the top of each page of list­
           ing.

       [no]include
           Places contents of header files in program listing.

       [no]source
           Places source program statements in program listing.

       [no]statistics
           Places compile-time performance statistics in the pro­
           gram listing.

           If  you  specify  -source_listing  but  do not specify

           [The -show flag is not  available  when  you  use  the
           -oldc flag.]

       -source_listing
           Produces  a  source program listing file with the same
           name as the source file and with a  .lis  file  exten­
           sion.  You  must specify this qualifier to get a list­
           ing. The default is to not produce a listing file.

           [The rce_listing flag is not available  when  you  use
           the -oldc flag.]

       -v  Prints  the compiler passes as they execute with their
           arguments and their  input  and  output  files.   Also
           prints  resource  usage in the C-shell time format. If
           specified more than once, the passes are  printed  but
           not executed.

           When  specified  with  -newc  or -migrate, the -v flag
           also  directs  the  compiler  to  display  the  macros
           defined at the start of the compilation.

       -V  Prints  the  version  of the compiler driver and, when
           the -oldc flag  is  specified,  the  versions  of  all
           passes in the same format as the what command.

       -verbose
           Produces  longer  error and warning messages. Messages
           in this form may give the user more  hints  about  why
           the compilation failed.

       -w[n]
           Controls  the  display  of  messages  as  well  as the
           actions that occur as a result of the  messages.   The
           value of n can be one of the following:

       0   Displays  all  levels  of compiler messages (warnings,
           errors, fatals, and, when -newc or -migrate is  speci­
           fied, informational messages).

       1   Suppresses  warning  messages.   The -w1 flag displays
           error and fatal messages and, when -newc  or  -migrate
           is  specified,  informational messages.  Specifying -w
           is the equivalent of specifying -w1.

       2   If the compiler encounters an error that  generates  a
           warning-level  diagnostic  message,  the compiler dis­
           plays the message and then aborts.


           If  no  -w flag is specified (the default), only warn­
           ing, error, and fatal messages are displayed.

       -warnprotos
           Causes the compiler to produce warning messages when a
           function  is  called  that is not declared with a full
           prototype.  This checking is more strict than required
           by ANSI C.

   C Preprocessor Flags
       -C  Passes  all  comments  directly  to  the preprocessor,
           except comments on preprocessor directive lines.

       -[no_]cpp
           Determines whether to call the C macro preprocessor on
           C and assembly source files before compiling.

           -cpp is the default.

       -Dname[=def]
           Defines the name as if with a #define statement. If no
           definition is given, the name is defined as 1.

       -E  Runs only the C macro preprocessor on  the  files  and
           sends the result to the standard output device.

       -I[dir]
           Specifies  a  search path for header files whose names
           do not indicate a specific directory  path  (that  is,
           whose names do not begin with a /).  The actual search
           path depends upon the form of the  #include  directive
           used for the file:

       - If  the  #include  "filename"  form  of the directive is
         used, the C macro preprocessor  searches  for  the  file
         first  in  the directory in which it found the file that
         contains the directive, then in the  search  path  indi­
         cated by the -I flag, and finally in the standard direc­
         tory, /usr/include.

       - If the #include <filename>  form  of  the  directive  is
         used,  the  preprocessor  searches for the file first in
         the search path indicated by the -I flag,  and  then  in
         the standard directory, /usr/include.

         search path.  If no dir is specified in any instance  of
         the   -I[dir]  flag,  the  C  macro  preprocessor  never
         searches  the  standard  directory,  /usr/include,   for
         header files.

         The  -nocurrent_include  flag can also modify the search
         path.

       -M  Requests a  dependency  list.   This  flag  is  passed
           directly to the preprocessor.  See cpp(1) for details.

       -MD Requests a  dependency  file.   This  flag  is  passed
           directly  to  the  preprocessor  and linker.  For more
           information, see cpp(1) and ld(1).

       -nocurrent_include
           Controls the search order for header files.  This flag
           is  passed  directly  to  the  preprocessor.  For more
           information, see cpp(1).

       -oldcomment
           Directs the preprocessor to delete comments (replacing
           them  with  nothing  at all).  This allows traditional
           token concatenation.

           This is the default in -std0 mode.  In -std and  -std1
           mode, the default is to replace comments with a single
           space.

       -P  Runs only the C preprocessor and puts the  result  for
           each  .c or .s source file in a corresponding .i file.
           The .i file has  no  #line_number  preprocessor  macro
           lines in it.

       -proto[is]
           Extracts  prototype  declarations for function defini­
           tions and puts them in a .H suffixed file.  The subop­
           tion  i includes identifiers in the prototype, and the
           suboption s generates prototypes for static  functions
           as well.

       -Q  Directs  the  preprocessor  to  use  single  quotes in
           __FILE__ expansions  instead  of  double  quotes.  See
           cpp(1) for details.

       -Uname
           Removes any definition of name, where name is either a
           symbol previously  defined  with  the  -D  flag  or  a
           reserved  symbol  that  is predefined by the compiler.
           If no name is specified, the -U flag is ignored.   (To
           display  a  list  of  predefined symbols, enter the cc
           Produces a dynamic executable file that uses shareable
           objects  during  run  time.  This  is the default. The
           loader uses shareable  objects  to  resolve  undefined
           symbols. The run-time loader (/sbin/loader) is invoked
           to bring in all  required  shareable  objects  and  to
           resolve  any  symbols  that  remained undefined during
           static link time.

       -compress
           Passes the -compress flag to the compilation phase (if
           the -c flag is present) or passes the -compress_r flag
           to ld (if the -r flag is present).  Use of  this  flag
           causes  the  output object file to be produced in com­
           pressed object file format, resulting  in  a  substan­
           tially smaller object file.

       -cord
           Runs  the procedure rearranger, cord, on the resulting
           file after  linking.  The  rearrangement  is  done  to
           reduce  the  cache conflicts associated with accessing
           the program's text.  The output of cord is left in the
           file  specified  by  the  -o  output  flag or a.out by
           default.  At least one -feedback file must  be  speci­
           fied.   See  prof(1) for information on creating feed­
           back files.

       -exact_version
           Used  in  conjunction  with  -call_shared  to  request
           strict dependency testing for the executable file pro­
           duced. Executable files built in this  manner  can  be
           executed  only   if the shared libraries that they use
           were not modified after the executable was built.

       -expect_unresolved pattern
           Causes any unresolved symbols matching pattern  to  be
           ignored.   Such  symbols are not displayed and are not
           treated as errors or  warnings.  You  can  enter  this
           option multiple times on a command line.  The patterns
           use shell wildcard characters (?, *, [, ]).  The wild­
           card  characters  must  be  properly quoted to prevent
           them from being expanded by the shell. For more infor­
           mation, see sh(1).

       -fini symbol
           Makes  the  procedure represented by the symbol into a
           termination routine. A termination routine is  a  rou­
           tine  that  is  called without an argument when either
           the file that contains the routine is unloaded or  the
           program that contains the routine exits.

       -init symbol
           the file that contains the routine is  loaded  or  the
           program that contains the routine is started.

       -input_to_ld filename
           Directs  the linker to read the contents of file file­
           name as if the contents had been supplied  on  the  ld
           command line.

           Inside  file filename, lines ending with \ are treated
           as continuation lines, and lines starting with  #  are
           treated as comment lines and ignored.  The -v flag can
           be used to display the expansion of files specified in
           a  -input  file. The files can be nested up to 20 lev­
           els.

       -no_archive
           Prevents the linker from using  archive  libraries  to
           resolve symbols. This flag is used in conjunction with
           -call_shared. The -no_archive flag is position  sensi­
           tive;  it  affects only those flags and variables that
           follow it on the command line. This flag can  also  be
           used more than once on the command line.

       -non_shared
           Directs  the  linker  to  produce a static executable.
           The output object created by the linker will  not  use
           any shared objects during execution.

       -shared
           Produce  dynamic  shareable  objects.  The loader will
           produce a shareable object that other dynamic executa­
           bles can use at run time.

           The following options are used with -shared:

       -check_registry location_file
           Checks  the  location of this shared object's segments
           and make sure they  stay  out  of  the  way  of  other
           object's  segments  in  the  location_file.   Multiple
           instances of this option are allowed.

       -rpath path
           Creates an rpath record containing the specified  path
           string.   The path string is a colon-separated list of
           directories that is meaningful only when  creating  an
           executable  with  shared  linkage.   If an item in the
           path supplied to -rpath is of  the  form  $VARNAME  or
           ${VARNAME}, the linker interprets it as an environment
           variable.

           record to search for shared libraries at run time.

       -set_version version-string
           Establishes  the  version  identifier (or identifiers)
           associated with a shared library.  The string version-
           string  is  either  a  single  version identifier or a
           colon-separated  list  of  version  identifiers.    No
           restrictions  are placed on the names of version iden­
           tifiers; however, it is highly recommended  that  UNIX
           directory naming conventions be followed.

           If  a  shared  library  is built with this option, any
           executable built against it will record  a  dependency
           on  the  specified  version  or,  if a list of version
           identifiers is specified, the rightmost version speci­
           fied in the list.  If a shared library is built with a
           list of version identifiers, the loader will allow any
           executable to run that has a shared library dependency
           on any of the listed versions.

       -soname shared_object_name
           Sets DT_SONAME for a shared object. The name can be  a
           single  component  name  (for example, libc.a), a full
           pathname (starting with a slash), or a relative  path­
           name  (containing a slash). The default DT_SONAME used
           for shared objects is the filename  component  of  the
           output  file name.  Specify the output file name using
           the -o  option as described previously.

       -update_registry location_file
           Registers the location of this  shared  object's  seg­
           ments  and makes sure they stay out of the way of oth­
           ers in the location_file.  Location_file is updated if
           it is writable.

       -pthread
           Directs  the  linker  to use the threadsafe version of
           any library specified with the -l  flag  when  linking
           programs.   This flag also tells the linker to include
           the POSIX 1003.1c-conformant DECthreads interfaces  in
           libpthread when linking the program.

       -taso
           Directs  the linker to load the executable file in the
           lower 31-bit addressable virtual address range. The -T
           and  -D  flags  to  the  ld  command can also be used,
           respectively, to ensure that the text  and  data  seg­
           ments addresses are loaded into low memory.

           The  -taso  flag,  however,  in  addition  to  setting
           loader. If you specify -taso and also specify text and
           data segment addresses with -T and -D, those addresses
           override  the  -taso default addresses. The -taso flag
           can be  helpful  when  porting  programs  that  assume
           address values can be stored in 32-bit variables (that
           is, programs that assume that pointers  are  the  same
           length as int variables).

       -threads
           Directs  the  linker  to use the threadsafe version of
           any library specified with the -l  flag  when  linking
           programs.   This flag also tells the linker to include
           the POSIX 1003.4a Draft 4 conformant DECthreads inter­
           faces.   It  is  supported only for compatibility with
           earlier releases of Digital UNIX.  New designs  should
           use the -pthread flag.

   Optimization Flags
       -[no]ansi_alias
           Directs  the  compiler  to  assume the ANSI C aliasing
           rules, and  thus  allows  the  optimizer  to  be  more
           aggressive  in  its  optimizations.  The -noansi_alias
           flag turns off ANSI C aliasing rules.

           The aliasing rules are explained in Section 3.3, para­
           graphs  20 and 25 of the ANSI C Standard, reprinted as
           follows:

           "An object shall have its stored value  accessed  only
           by an lvalue that has one of the following types:

       - The declared type of the object,

       - A qualified version of the declared type of the object,

       - A type that is the signed or unsigned type corresponding
         to the declared type of the object,

       - A type that is the signed or unsigned type corresponding
         to  a  qualified  version  of  the  declared type of the
         object,

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

         signed  and qualified versions of an otherwise same type
         are considered to be the same type), then assuming  ANSI
         C  aliasing rules allows the compiler to generate better
         optimized code.

         If your program does access the same data through point­
         ers  of  a different type (for example, by a "pointer to
         int" and a "pointer to float"), you must not  allow  the
         compiler  to  assume ANSI C aliasing rules because these
         rules can result in the generation of incorrect code.

         The default is to assume no ANSI C aliasing  rules  when
         compiling  with  the  -vaxc,  -std,  or  -std0 flag. The
         default is -ansi_alias when  compiling  with  the  -std1
         flag.

         The  -noansi_alias flag turns off ANSI C aliasing rules.

         The -[no]ansi_alias flag is not available when  you  use
         the -oldc flag.

       -[no_]ansi_args
           Tells the compiler whether the source code follows all
           ANSI rules about arguments, that is, whether the  type
           of  an  argument  matches the type of the parameter in
           the called function or whether a function prototype is
           present  so the compiler can automatically perform the
           expected type conversion.

           Specifying -no_ansi_args means that the argument  type
           may  not match the expected parameter type.  This flag
           is important, for example, when the  caller  passes  a
           parameter  of type long and the called routine expects
           an int.  The -no_ansi_args flag forces the compiler to
           generate  argument  cleaning code to convert the argu­
           ment to the appropriate type.  Except when  the  -std1
           flag  is specified, -no_ansi_args is the default. Note
           that it is safe to specify -ansi_args if you use ANSI-
           style function prototypes at all call sites.

           Specifying  -ansi_args  means that your code meets the
           ANSI C requirements, so no special  argument  cleaning
           code  is generated.  This is a performance gain.  When
           -std1 is specified, -ansi_args is the default.

           [The -[no_]ansi_args flag is not  available  when  you
           use the -oldc flag.]

       -assume array_parameter_restricted_pointers
           Specifies the assumption that all array parameters are
           restricted.  In the following code, for example,  only

           extern int foo(char * a, char b[]);

           When  this flag is specified, both a and b are treated
           as restricted pointers.

       -assume [no]math_errno
           Controls the compiler's assumption about  a  program's
           dependence  on  the  setting  of errno by math library
           routines:

       - By default (-assume math_errno),  the  compiler  assumes
         that  the program might interrogate errno after any call
         to a math libarry routine that  is  capable  of  setting
         errno.  The definition of the ANSI C math library allows
         programs to depend on this behavior, which unfortunately
         restricts  optimization  because  this  causes most math
         functions to be treated as having side effects.

       - Specifying -assume nomath_errno instructs  the  compiler
         to assume that the program does not look at the value of
         errno after calls to math  functions.   This  assumption
         allows  the  compiler to reorder or combine computations
         to improve the performance of those math functions  that
         it  recognizes  as  intrinsic  functions.   In practice,
         robust floating-point code seldom  relies  on  errno  to
         detect  domain  or range errors, so -assume nomath_errno
         can often be safely used to improve performance.

         [The -assume [no]math_errno flag is not  available  when
         you use the -oldc flag.]

       -assume parameter_restricted_pointers
           Specifies  the  assumption that all pointer parameters
           are restricted.

       -assume [no]restricted_pointers
           Specifies  the  assumption  that  all   pointers   are
           restricted.

           The  -assume  norestricted_pointers  flag disables the
           __restrict keyword from all pointers.  This  can  help
           detect  inappropriate  use of __restrict.  If the code
           works correctly at high optimization  with  __restrict
           turned off, but breaks with it turned on, it is likely
           that the  compiler  encountered  a  pointer  that  was
           restricted  in  error.   Restricted  pointers  are  an
           assertion by the programmer to aid  optimization;  the
           compiler cannot detect erroneous assertions.
           tor (&) are being applied outside the current compila­
           tion unit to extern variables that are declared inside
           the current compilation unit.  Making  this  assertion
           allows the compiler to perform better optimizations.

           This  flag  is  often  suitable  for use with the -ifo
           flag, which presents a group of source  files  to  the
           compiler as a single compilation unit.

       -fast
           Provides  a  single method for turning on a collection
           of optimizations for increased performance.

           Note that the -fast flag can produce different results
           for  floating-point  arithmetic  and  math  functions,
           although most programs are not sensitive to these dif­
           ferences.

           The  -fast  flag  defines the following compiler flags
           and symbols to improve run-time performance.  You  can
           adjust the optimizations by specifying the negation of
           any given flag.

       -ansi_alias
           Directs the compiler to assume  the  ANSI  C  aliasing
           rules,  and  thus  allows  the  optimizer  to  be more
           aggressive in its optimizations.

           See the description of this  flag  elsewhere  in  this
           reference  page  for  more  detailed information about
           this operation.

       -ansi_args
           Tells the compiler that the source  code  follows  all
           ANSI  rules about arguments; that is, whether the type
           of an argument matches the type of  the  parameter  in
           the  called  function, or whether a function prototype
           is present so the compiler can  automatically  perform
           the expected type conversion.

           See  the  description  of  this flag elsewhere in this
           reference page for  more  detailed  information  about
           this operation.

       -assume nomath_errno
           Allows the compiler to reorder or combine computations
           to improve the performance  of  those  math  functions
           that it recognizes as intrinsic functions.

           See  the  description  of  this flag elsewhere in this

       -assume trusted_short_alignment
           Specifies that any short accessed through a pointer is
           naturally aligned.  This generates the  fastest  code,
           but  can silently generate the wrong results if any of
           the short objects cross a quadword boundary.

           See the description of this  flag  elsewhere  in  this
           reference  page  for  more  detailed information about
           this operation.

       -D_INTRINSICS
           Declares certain functions to be  intrinsic.   When  a
           function  is intrinsic, the compiler is free to gener­
           ate faster code that provides the same function behav­
           ior (but may not actually call the function).

       -D_INLINE_INTRINSICS
           Directs  the  compiler to inline some of the intrinsic
           functions, avoiding the overhead of a function call.

       -D_FASTMATH
           Causes the /usr/include/math.h file  to  redefine  the
           names  of certain common math routines, including sqrt
           and exp, so that faster  but  slightly  less  accurate
           functions are used. The fast math routines do not sup­
           port IEEE exceptional behavior.

       -float
           Tells the compiler that it is not necessary to promote
           expressions of type float to type double.

           See  the  description  of  this flag elsewhere in this
           reference page for  more  detailed  information  about
           this operation.

       -fp_reorder
           Allows  floating-point operations to be reordered dur­
           ing optimization.

           See the description of this  flag  elsewhere  in  this
           reference  page  for  more  detailed information about
           this operation.

       -ifo
           Performs inter-file optimizations.

           See the description of this  flag  elsewhere  in  this
           reference  page  for  more  detailed information about
           this operation.

       -intrinsics
           See  the  description  of  this flag elsewhere in this
           reference page for  more  detailed  information  about
           this operation.

       -O3 or -O4
           The  -newc  and -oldc flags set the optimization level
           to -O3.

           The -migrate flag sets the optimization level to  -O4.

           See  the  description of these flags elsewhere in this
           reference page for  more  detailed  information  about
           this operation.

       -readonly_strings
           Makes  string  literals read-only for improved perfor­
           mance.

           See the description of this  flag  elsewhere  in  this
           reference  page  for  more  detailed information about
           this operation.

       -feedback file
           Specifies the name of a  feedback  file  (produced  by
           prof  after  running  a pixie version of the program).
           The feedback file contains information that  the  com­
           piler can use when performing optimizations.

           You  can also use a feedback file as input to the cord
           utility, using -feedback and the -cord flags  to  link
           the program.

       -[no_]fp_reorder
           Specifies  whether  certain  code transformations that
           affect floating-point operations  are  allowed.  These
           changes  can  affect  the  accuracy  of  the program's
           results.

           The -no_fp_reorder flag, the default, directs the com­
           piler  to  use  only certain scalar rules for calcula­
           tions. This setting can  prevent  some  optimizations.
           The  -fp_reorder  flag  frees  the compiler to reorder
           floating-point operations based on  algebraic  identi­
           ties  (inverses, associativity, and distribution). For
           instance, this allows  the  compiler  to  move  divide
           operations  outside  of  loops, thus improving perfor­
           mance.

           If you specify -fp_reorder and the  compiler  reorders
           code  to  improve  performance, the results can differ
           rate than those gained by the default.

       -G num
           Specifies  the  maximum size, in bytes, of a data item
           that is to be put in one of the small  data  sections.
           Data  items in the small data sections are more likely
           to be candidates for global pointer  optimizations  by
           link-time  optimizations.  The  num argument is inter­
           preted as a decimal number. The default value for  num
           is  8  bytes.  This value cannot be changed when using
           the -newc or -migrate flag.

       -ifo
           Provide improved  optimization  (inter-file  optimiza­
           tion)  and code generation across file boundaries that
           would not be possible if the files were compiled sepa­
           rately.

           When  you specify -ifo on the command line in conjunc­
           tion with a series of file  specifications,  the  com­
           piler  does  not  concatenate  each  of  the specified
           source files.  Instead, each  file  is  treated  sepa­
           rately  for  purposes of parsing, except that the com­
           piler will issue diagnostics about conflicting  exter­
           nal  declarations  and function definitions that occur
           in different files. For purposes of  code  generation,
           the  compiler treats the files as one application. The
           default is to not provide inter-file optimization.

           [The -ifo flag is not available when you use the -oldc
           flag.]

       -[no_]inline keyword
           Specifies whether to provide inline expansion of func­
           tions.  The  -no_inline  flag  disables  the  inlining
           optimization  that  would  otherwise  be  performed by
           default  under  the  following  compiler  optimization
           -O[n] flags:

       - When -O2, -O3, or -O4 is specified under -newc

       - When -O4 or -O5 is specified under -migrate

       - When -O3 is specified under -oldc

         When  choosing calls to expand inline, the compiler also
         considers the function size, how often the call is  exe­
         cuted,  how  many  registers  the  inline expansion will
         require, and other factors.

       none
           No  inlining  is  done, even if requested by a #pragma
           inline preprocessor directive.  This  is  the  default
           when compiling with the -O0 optimization level.

       manual
           Inlines only those function calls explicitly requested
           for inlining by a #pragma inline  directive.  This  is
           the  default  when  compiling  with the -O1 flag under
           -newc.

       size
           Inlines all of the function calls in the manual  cate­
           gory,  plus  any  additional  calls  that the compiler
           determines would improve run-time performance  without
           significantly  increasing  the  size  of  the program.
           This is the default when compiling with the -O2 or -O3
           flag  under  -newc,  or the -O, -O4, or -O5 flag under
           -migrate.

       speed
           Inlines all of the function calls in the manual  cate­
           gory,  plus  any  additional  calls  that the compiler
           determines would improve  run-time  performance,  even
           where  it  may  significantly increase the size of the
           program.

       all Inlines every call that can  be  inlined  while  still
           generating  correct code. Recursive routines, however,
           will not cause an infinite loop at compile time.

           For optimization level 0 (-O0), the  -inline  flag  is
           ignored and no inlining is done.  The #pragma noinline
           preprocessor directive can also  prevent  inlining  of
           any function.

           [The  -inline  flag  is not available when you use the
           -oldc flag.]

       -[no_]intrinsics
           Controls whether the compiler recognizes certain func­
           tions as intrinsic functions - even if the appropriate
           header file is not included and the function names are
           not  specified in a pragma intrinsic directive. Recog­
           nition is based on the function name and the call sig­
           nature (arguments and return types).

           When  the compiler identifies a function as an intrin­
           version of that function - given an optimization level
           (-On) that enables the  intrinsic  treatment  of  that
           particular function.

           The  optimization level determines which functions can
           be treated as intrinsics:

       -O0 or -O1

         No intrinsic functions.  The  -intrinsics  flag  has  no
         effect at this optimization level.

       -O2 (or -O)

         Memory  and string functions: alloca, bcopy, bzero, mem­
         cpy, memmove, memset, strcpy, strlen

         Math functions: abs, fabs, labs,  atan,  atan2,  atan2f,
         atand,  atand2,  atanf,  ceil,  ceilf,  cos, cosd, cosf,
         floor, floorf, sin, sind, sinf.

       -O3

         fprintf, printf, snprintf, sprintf

       -fast (due to its supplying -assume nomath_errno and -O3)

         acos, acosf, asin, asinf, cosh, coshf, exp,  expf,  log,
         log10, log10f, logf, log2, pow, powf, sqrt, sqrtf, sinh,
         sinhf, tan, tand, tanf, tanh.

         The effects of the various optimization levels are cumu­
         lative;  for  example, -fast causes the functions at the
         -02 (or -O) and -O3 optimization levels to be treated as
         intrinsics  -  in  addition  to  the  intrinsic function
         treatment that is triggered by -fast itself.

         The -intrinsics flag is in effect by default.   To  dis­
         able  the  default, specify the -no_intrinsics flag.  To
         disable the intrinsic treatment of individual functions,
         specify  the  function names in a pragma function direc­
         tive in either your source code  or  a  file  associated
         with a -FI flag ("file include" flag).

       -mp Enables the compiler to process parallel decomposition
           pragmas (directives) in C source code.  It also  trig­
           gers  the  link  phase  to  link  with the appropriate
           thread and compiler support libraries that are  needed
           to run the generated multiprocessor code.
           or  without -mp.  With -mp, the pragmas cause the pro­
           gram to run in several  concurrent  threads  that  may
           execute  in  a significantly shorter elapsed time on a
           DIGITAL UNIX multiprocessor system.  Without -mp,  the
           compiler  will ignore the pragmas and the program will
           run sequentially as a normal C program.

           [The -ifo flag is not available when you use the -oldc
           flag.]

       -O[n]
           Determines  the  level  of optimization. The following
           table lists the types of  optimizations  that  can  be
           performed.   The  default  optimization  level is -O1.
           Note, however, that different optimizations  are  per­
           formed  at each level, depending on whether you invoke
           the compiler with the -newc, -oldc, or -migrate  flag.
           ------------------------------------------------------
           -newc     -oldc     -migrate   Optimization
           ------------------------------------------------------

           -O0       -O0       -O0        None
           -O1       -O1       -O1        Local    optimizations
                                          and   recognition   of
                                          common subexpressions.
           -O1       -O2, -O   -O2, -O    Global   optimization,
                                          including code motion,
                                          strength reduction and
                                          test      replacement,
                                          split lifetime  analy­
                                          sis, and code schedul­
                                          ing.
           -O2, -O   -O2, -O   -O3        Additional      global
                                          optimizations     that
                                          improve speed (at  the
                                          cost   of  extra  code
                                          size), such as integer
                                          multiplication     and
                                          division     expansion
                                          (using  shifts),  loop
                                          unrolling,  and   code
                                          replication  to elimi­
                                          nate branches.
           -O2, -O   -O3       -O4        Inline  expansion   of
                                          static procedures.
           -O3       -O3       -O4        Inline   expansion  of
                                          global procedures.

                                          ysis, vectorization of
                                          some  loops  on  8-bit
                                          and 16-bit data  (char
                                          and short), and inser­
                                          tion of  NOP  instruc­
                                          tions    to    improve
                                          scheduling.
           ------------------------------------------------------

           To determine whether using  -O4  with  -newc  benefits
           your  program,  you  should  compare program execution
           times for the same program compiled at levels -O3  and
           -O4.

           If  you  are  using the -O (or -O2) optimization level
           when compiling code that will never end up in a shared
           library, you should consider changing to the -O3 level
           because it provides additional compiler optimizations.
           (The -O3 level may inhibit the ability to preempt sym­
           bols, so it should not be used for shared  libraries.)

       -Olimit num
           Specifies the maximum size, in basic blocks, of a rou­
           tine that will be optimized by the  global  optimizer.
           If  a  routine  has  more  than  this  number of basic
           blocks, it will not be optimized and a message will be
           printed.  A  flag specifying that the global optimizer
           is to be run (-O2 or -O3) must also be specified.  The
           num  is  assumed  to  be a decimal number. The default
           value for num is 500 basic blocks.

           [The -Olimit flag is not available with the  -newc  or
           -migrate flags.]

       -om Performs  code  optimization  after linking, including
           nop (no operation) removal, .lita removal, and reallo­
           cation of common symbols. This flag also positions the
           $gp register so that the maximum number  of  addresses
           fall  in  the  $gp-accessible window.  The -om flag is
           supported  only  for  programs   compiled   with   the
           -non_shared  flag. The following options can be passed
           directly to -om by using the -WL compiler flag:

       -WL,-om_compress_lita
           Removes unused .lita entries after  optimization,  and
           then compresses the .lita section.

       -WL,-om_dead_code
           Removes dead code (unreachable instructions) generated
           after applying optimizations. The .lita section is not
           "common" symbol whose size is less than  or  equal  to
           num  will be allocated close to each other.  This flag
           can be used to improve the probability that the symbol
           can be accessed directly from the $gp register.  (Nor­
           mally,  om  tries  to  collect  all  "common"  symbols
           together,  not  just  symbols  that conform to certain
           size constraints.)

       -WL,-om_ireorg_feedback,file
           Uses the pixie-produced information in file.Counts and
           file.Addrs  to  reorganize  the instructions to reduce
           cache thrashing.

       -WL,-om_no_inst_sched
           Turns off instruction scheduling.

       -WL,-om_no_align_labels
           Turns off alignment of labels. Normally, the -om  flag
           will  quadword  align  the  targets of all branches to
           improve loop performance.

       -WL,-om_split_procedures
           Splits frequently accessed  routines  into  "hot"  and
           "cold"  code  segments,  and  stores these segments in
           different parts of the image.  The  hot  segments  are
           the  most  frequently  executed  parts of the code, as
           determined by feedback data produced by a  representa­
           tive  run of the program.  The hot segments are stored
           near other parts of the program that are also executed
           frequently.  In this way, the most frequently executed
           parts of the program are compacted in a way that makes
           them  more  likely to fit into the cache.  This speeds
           up the execution time of that code.

           For  additional  information  on  om,  send  email  to
           wrl-techreports@decwrl.dec.com, specifying help on the
           subject line.  Then, follow the  instructions  in  the
           reply you receive to obtain report number 94/1.

       -preempt_module
           Supports   symbol  preemption  on  a  module-by-module
           basis. During optimization, inlining is performed only
           on functions within a single compilation unit. This is
           the default in the following cases:

       - At optimization levels -O3 and -O4 when -newc is used

       - At optimization levels -O4 and -O5 when -migrate is used

         flags  are  specified  on  the  command line: -c, -r, or
         -shared.

         In all other cases, -preempt_symbol is the default.

       -preempt_symbol
           Preserves full symbol preemption;  that  is,  supports
           symbol preemption on a symbol-by-symbol basis within a
           module as well as between modules.   During  optimiza­
           tion,  if inlining is requested, only static functions
           are eligible.

           The default taken for a compilation  is  either  -pre­
           empt_symbol  or  -preempt_module.  See the description
           of the -preempt_module flag for details on the  condi­
           tions  that  determine  which  option  is taken as the
           default.

       -speculate all
           Specifies that speculation may occur anywhere  in  the
           executable image.

           A  conditionally-executed  operation  is speculated by
           beginning the operation's execution prior  to  testing
           the condition that guards the use of the value of that
           operation.  If execution  reaches  the  conditionally-
           executed use of the operation's value, then that value
           will be available for  immediate  use.   If  execution
           does  not  reach the conditionally executed use of the
           operation's value,  then  the  speculatively  computed
           value is ignored.

           If any module in a program is compiled with -speculate
           all, all exceptions throughout the entire program  are
           dismissed  on  the  assumption  that  the execution is
           caused by  an  unsuccessful  speculative  instruction.
           (Note,  though,  that  floating-pointing  instructions
           specifying software completion [/S]  are  still  given
           normal  exception  handling.)  Code  compiled with the
           -speculate all flag  cannot  use  any  form  of  local
           exception  handling  nor  be  linked with any routines
           that do.  As a result, you should use  the  -speculate
           all  flag only in programs that are known to be error-
           free and that do not depend on  fault  and  trap  han­
           dling.  If code compiled speculatively incurs a lot of
           exceptions, it may result in  an  overall  performance
           loss.   If  this  is so, you should discontinue use of
           this feature.

           [The -speculate all flag is not available when you use
           in the source module that is being compiled.

           A module compiled with  -speculate  by_routine  cannot
           use  any  form of local exception handling, but can be
           linked with other modules that do. The run-time system
           checks each exception to see if it occurred in a spec­
           ulative routine.  It dismisses  exceptions  from  rou­
           tines  that  are  speculatively  executed, but signals
           exceptions from other routines.  (Note,  though,  that
           floating-pointing   instructions  specifying  software
           completion [/S] are still given normal exception  han­
           dling.)   As  a  result, you should use the -speculate
           by_routine flag only for modules that are known to  be
           error-free  and  that  do not depend on fault and trap
           handling.  If code compiled speculatively incurs a lot
           of exceptions, it may result in an overall performance
           loss.  If this is so, you should  discontinue  use  of
           this feature.

           The  -speculate by_routine flag yields somewhat slower
           execution than the -speculate all flag, but  does  not
           restrict trap and fault handling in other modules with
           which it is linked.

           [The -speculate by_routine flag is not available  when
           you use the -oldc flag.]

       -tune option
           Selects  processor-specific  instruction  tuning for a
           specific implementation  of  the  Alpha  architecture.
           Tuning  for  a  specific  implementation  can  provide
           improvements in run-time performance.

           Regardless of the setting of the -tune flag, the  gen­
           erated  code  will  run correctly on all Alpha proces­
           sors.  Note that code tuned for a specific target  may
           run  more  slowly  on another target than generically-
           tuned code.

           The option keyword can be one of the following:

       generic
           Selects instruction tuning that is appropriate for all
           Alpha processors. This option is the default.

       host
           Selects instruction tuning that is appropriate for the
           processor on which the code is being compiled.

       ev4 Selects instruction  tuning  for  the  21064,  21064A,
           number 21164 is used for both  EV5  and  EV56  proces­
           sors.)

       ev6 Selects instruction tuning for the 21264 chip.

       -unroll n
           Controls  loop unrolling done by the optimizer at lev­
           els -O2 and above  for  -newc.  Specifying  -unroll  n
           unrolls  loop  bodies  n  times.  Specifying -unroll 0
           means  the  optimizer  uses  its  own  default  unroll
           amount.  Specifying -unroll 1 means no unrolling.  The
           default is -unroll 0.

           [The -unroll flag is not available when  you  use  the
           -oldc flag.]

   Feedback-directed Optimization Flags
       -prof_gen
           Generates  an executable image that has profiling code
           added to it.  Using this flag is equivalent to running
           the  pixie(5) command on an existing image, except the
           resulting image will not have  the  .pixie  extension.
           See  also  the  descriptions of the -prof_use_om_feed­
           back, -prof_dir, and -pids flags.

       -prof_use_feedback
           Uses profiling feedback  to  improve  runtime  perfor­
           mance.   Using  this  flag  is equivalent to using the
           prof(1) command to produce a feedback file,  and  then
           using  the  cc -feedback command to recompile the pro­
           gram.

           To use the -prof_use_feedback flag, first compile your
           program with the -prof_gen and -gen_feedback flags and
           then run the program to generate the needed  profiling
           data.

       -prof_use_om_feedback
           Uses  profiling  feedback  to  rearrange the resulting
           image to reduce cache conflicts of the  program  text.
           This  flag  uses  the  -om  postlink optimizer, and is
           equivalent to using  the  -om  -WL,-om_ireorg_feedback
           flags.  If the -pids flag is also specified, this flag
           merges the .Counts performance data files   using  the
           prof -pixie -merge command.

           To  use  the -prof_use_om_feedback flag, first compile

       -prof_dir
           Specifies a location to which the profiling data files
           (.Counts and .Addrs) are written.  Use  this  flag  in
           conjunction   with   the   -prof_gen   flag   and  the
           -prof_use_feedback or  -prof_use_om_feedback  flag  to
           specify  a location for the profiling data files.   If
           you do not specify this flag, the profiling files  are
           written to the current directory.

           Specifying  the  -prof_dir flag also enables the -pids
           flag.

       -[no_]pids
           [Disables] or enables the addition of  the  process-id
           to  the  filename  of  the  basic  block  counts  file
           (.Counts).  This  facilitates  collecting  information
           from  multiple  invocations  of the pixie output file.
           Unless the -prof_dir flag is specified, the default is
           -no_pids.

   Source-code Debugging Flags
       -g[n]
           Determines the production of symbol table information.
           When no value is specified for n,  the  compiler  pro­
           duces  symbol  table  information  for  full  symbolic
           debugging and suppresses optimizations that limit full
           symbolic debugging (same as -g2).

           The value of n can be one of the following:

       0   Produces  only  enough  symbol  table  information for
           linking. Names and addresses of external symbols,  and
           the  addresses and basic layout of the stack-frame are
           available. Profiling tools  work,  but  the  names  of
           local  procedures, source lines, and source file names
           are  not  available.  The  debugger  allows  procedure
           traceback  and  all  instruction-level commands.  How­
           ever, line-oriented commands do not work.   No  symbol
           types  are available, and the names of stack-frame and
           static variables are not available.  All optimizations
           are supported.

       1   Produces  limited  symbol table information. Profiling
           and debugging tools provide line numbers, source  file
           names,  and the names of local procedures, when appro­
           priate. Line-oriented  debugging  commands  work,  but
           symbol  types  and  the names of stack-frame variables
           optimizations are supported.

       2   Produces  symbol  table  information for full symbolic
           debugging and  suppress  some  optimizations.   Symbol
           types  and  stack-frame variables names are available.
           Optimization is suppressed (-g2 implies -O0).

       3   Produces symbol table information for fully  optimized
           code.   This  level  of  debugging  supplies  the same
           information as -g2, but it also  allows  all  compiler
           optimizations.   As  a result, some of the correlation
           is lost between the source  code  and  the  executable
           program.

   Program Profiling Flags
       -gen_feedback
           Generates accurate profile information to be used with
           -feedback optimizations, as follows:

       1.
         Compile the source code with the -gen_feedback flag.

       2.
         Run pixie on the executable file.

       3.
         Execute the pixie version of  the  program  to  generate
         execution statistics on the program.

       4.
         Use  prof  to  create a feedback file from the execution
         statistics.

       5.
         Recompile the program with the -feedback flag and either
         the -O2 or -O3 flag (for -newc) or the -O2, -O3, -O4, or
         -O5 flag (for -migrate).   This  provides  the  compiler
         with  execution information that the compiler can use to
         improve certain optimizations.

         [The -gen_feedback flag is not available  when  you  use
         the -oldc flag.]

       -p[n]
           Determines  the  level  of profiling. The -p flag pre­
           pares for profiling by periodically sampling the value
           time startup routine (mcrt0.o) and the level 1 profil­
           ing library (libprof1.a) is searched. When you use the
           -p flag together with either the -pthread flag or  the
           -threads  flag,  the profiling library libprof1_r.a is
           used.

           When profiling begins, the startup routine calls  mon­
           startup   (see   monitor(3))  and  produces,  in  file
           mon.out, execution-profiling data  for  use  with  the
           postprocessor prof(1).

           The value n can be one of the following:

       0   Do not permit any profiling.  This is the default.  If
           linking occurs, the standard run-time startup  routine
           (crt0.o)   is   used,  and  no  profiling  library  is
           searched.

       1   Same as -p.

       -[no_]pg
           Turns gprof profiling on or  off  when  compiling  and
           linking the file immediately following this flag.  The
           gprof profiler produces a call graph showing the  exe­
           cution of a C program.

           When  this  flag  is  turned on, the standard run-time
           startup routine is replaced by  the  gcrt0.o  routine.
           Programs  that  are  linked with the -pg flag and then
           run will produce, in file  gmon.out,  a  dynamic  call
           graph and profile.  You then run gprof on the gmon.out
           file to display the output.  When you use the -pg flag
           together with either the -pthread flag or the -threads
           flag, the profiling library libprof1_r.a is used.

           For more information, see the gprof(1) reference page.

   Code Portability Flags
       -accept option1[,option2,...]
           Overcomes the problem of DEC C's relaxed ANSI mode
           (-std,  the  default option) accepting many VAX C key­
           words that are not accepted in K&R mode.  Without this
           option,  a user program will stop compiling if it con­
           tains a variable with the same name as one of the  VAX
           C keywords.  The following options are available:

         names of  variables  in  programs  being  compiled.   If
         vaxc_keywords  is specified, the compiler will recognize
         the VAX C keywords no matter  what  standard  option  is
         specified.

       [no]restrict_keyword
         Cause  the  compiler  to  recognize the restrict keyword
         (C9X standard) no matter what standard  mode  is  speci­
         fied.

       -check
           Performs  compile-time  code checking. With this flag,
           the compiler checks for code that exhibits nonportable
           behavior,   represents   a  possible  unintended  code
           sequence, or possibly affects operation of the program
           because of a quiet change in the ANSI C Standard. Some
           of these checks  have  traditionally  been  associated
           with  the  lint  utility.   This flag is available for
           -newc and -migrate only.

       -isoc94
           Causes the macro __STDC_VERSION__ to be passed to  the
           preprocessor  and  enables  recognition of the digraph
           forms of various operators.   Note  that  the  -isoc94
           flag has no influence on -stdn flags and vice versa.

       -ms Directs  the compiler to interpret source code accord­
           ing to certain language rules followed by the  C  com­
           piler  provided with the Microsoft Visual C++ compiler
           product.  Compatibility with  this  implementation  is
           not  complete;  however,  the  compiler recognizes the
           following extensions and responds to them by  relaxing
           a  standard behavior and, in most instances, suppress­
           ing a diagnostic message:

       - Allow a  declaration  of  an  unnamed  structure  within
         another structure.  You can reference all members of the
         inner structure as members of the named outer structure.
         This  is  similar  to the C++ treatment of nested unions
         lacking a name, but  extended  to  both  structures  and
         unions.  For example:

            struct {
               struct {
                  int a;
                  int b;
               };  /*No name here */
               int c;
            }d;   /* d.a, d.b, and d.c are valid member names. */
            typedef int typedefname;
            typedef int typedefname;

       - Allow typedef declarations that are redeclared to a com­
         patible type.  For example:

            typedef enum {a,b,c} typedefname;
            typedef enum {d,e,f} typedefname;

       - Allow declaration of a structure with a trailing  incom­
         plete  array.   This  is  useful if you are dealing with
         counted arrays, where the first element of the structure
         is  used to hold a count of the array elements, the sec­
         ond element is an array of data, and  the  structure  is
         always   allocated  dynamically.   The  sizeof  operator
         treats the incomplete array as having a length of  zero.
         For example:

            struct {
               int a;
               int b[];
            }s;

       - Allow a static function declaration in block scope (that
         is, inside another function).  For example:

            f() {
                static int a(int b);
            }

       - Allow & to  produce  an  lvalue  expression  in  certain
         cases.  For example:

            int *a, *b;
               f() {
                   &*a=b;
            }

       - Allow  integers  and  pointers  to be compared without a
         cast.  For example:

            int *a,b;
            f() {
            if (a==b)
               b=1;
            }

         a pointer to char can be assigned to a pointer to signed
         char, assuming that the -signed flag is in effect:

            signed char *a;

       - Suppress  warning messages for declarations that contain
         two semicolons; that is, allow completely empty declara­
         tions at file scope.  For example:

            int a;;

       - Suppress  warning messages for declarations that contain
         a variable name but no type.  For example:

            b;

       - Ignore any extra comma at the end of the last enumerator
         in an enumeration declaration.  For example:

            enum E {a, b, c,};  /* Ignore the comma after "c". */

       - Allow  typedef  declarations  that have a type specifier
         but no identifier name  declaring  the  new  type.   For
         example:

            typedef struct { int a; };

       - Suppress  warning  messages  when  one  of the following
         unsupported Microsoft pragmas is encountered:

            #pragma code_seg
            #pragma optimize
            #pragma warning

              The -stdn flag  and  the  -ms  flags  are  mutually
              exclusive.  When both of these flags are specified,
              the last one seen by the driver program  is  placed
              in  effect.   (When  -ms  is in effect, -std is the
              default.)

       -portable
           Directs the compiler to issue diagnostics for any non­
           portable coding that it encounters.

       -SD[directory]
           Suppresses certain  warning-  and  informational-level
           diagnostic  messages that are inappropriate for system
           header files. The suppressed messages relate  to  non-
           portable  constructs  in  header files whose pathnames
           are prefixed by string directory.

           The default is -SD/usr/include.

           Specifying -SD without a directory string cancels  the
           effect  of  any previous -SD flags on the command line
           (including the  default,  -SD/usr/include).   It  also
           disables the -protect_headers feature's suppression of
           diagnostic   messages   by    defining    the    macro
           __DECC_EMPTY_SD_OPTION.  (The -protect-headers feature
           provides   message    suppression    in    the    file
           __DECC_include_prologue.h.)

       -std[n]
           Directs the compiler to issue warnings when it encoun­
           ters language constructs that are not standard in  the
           language.  The default is -std.

           The following values are accepted:

       -std
           Enforces  the  ANSI C standard, but allows some common
           programming practices disallowed by the standard.  The
           -std  flag causes the macro __STDC__=0 to be passed to
           the preprocessor.

       -std0
           Enforces the K & R  programming  style,  with  certain
           ANSI  extensions  in areas where the K & R behavior is
           undefined or ambiguous.  In  general,  -std0  compiles
           most   pre-ANSI   C  programs  and  produces  expected
           results. The -std0 flag causes the __STDC__  macro  to
           be undefined.

       -std1
           Strictly enforces the ANSI C standard and all its pro­
           hibitions (such as those that apply to the handling of
           void  types, the definition of lvalues in expressions,
           the mixing of integrals and pointers, and the  modifi­
           cation  of  rvalues).   This  flag  does not, however,
           restrict the name space defined by  the  DIGITAL  UNIX
           implementation  to only reserved names as specified by
           ANSI C.

           The -std1 flag  causes  the  macro  __STDC__=1  to  be

           None  of  the  -std* flags restrict or expand the name
           space defined by the DIGITAL UNIX implementation  (for
           example,  items  declared in system header files).  To
           restrict the name space so that only ANSI  C  reserved
           names  are  made  visible from the system header files
           listed in the ANSI C standard, use the  _ANSI_C_SOURCE
           macro.   For details on _ANSI_C_SOURCE and other stan­
           dard macros, see standards(5).

       -vaxc
           Places the compiler in VAX C compatibility  mode.   In
           addition  to supporting the ANSI C language, this mode
           of compilation also supports VAX C extensions that are
           incompatible  with the ANSI C standard and that change
           the language semantics. This mode provides compatibil­
           ity  for  programs  that depend on old VAX C behavior.
           This flag is not available  when  you  use  the  -oldc
           flag.

   Data Alignment Flags
       -assume [no]aligned_objects
           Controls  the alignment assumptions for code generated
           for indirect load and store instructions.

           The -assume aligned_objects flag causes  the  compiler
           to  assume  that  a  dereferenced  object's  alignment
           matches or exceeds  the  alignment  indicated  by  the
           pointer  to the object.  On Alpha systems, dereferenc­
           ing a  pointer  to  a  longword-  or  quadword-aligned
           object  is more efficient than dereferencing a pointer
           to a byte- or word-aligned object. Therefore, when the
           compiler  assumes  that a pointer object of an aligned
           pointer type does point to an aligned object,  it  can
           generate  better  code  for  pointer  dereferences  of
           aligned pointer types.

           The -assume noaligned_objects flag causes the compiler
           to  generate longer code sequences to perform indirect
           load and store operations in order to  avoid  hardware
           alignment  faults  for  arbitrarily aligned addresses.
           Although the -assume noaligned_objects flag may gener­
           ate  less efficient code than -assume aligned_objects,
           by avoiding hardware alignment faults, it  speeds  the
           execution of programs that reference unaligned data.

           The  -assume  aligned_objects flag is the default. The

       - A pointer of type short points to objects  that  are  at
         least short-aligned.

       - A  pointer  of  type  int  points to objects that are at
         least int-aligned.

       - A pointer of type struct points to objects that have  an
         alignment  of  struct  (that  is,  the  alignment of the
         strictest member alignment, or  byte  alignment  if  you
         have specified #pragma nomember_alignment for struct).

         If  your  module breaks one of these rules, you must use
         the -assume noaligned_objects flag to compile  the  mod­
         ule;  otherwise,  your  program may get alignment faults
         during execution, which will degrade performance.

         The     -assume     aligned_objects     and      -assume
         noaligned_objects  flags can be used in the same cc com­
         mand, allowing you to turn  this  flag  on  and  off  as
         needed by individual source files.

         The      -assume     aligned_objects     and     -assume
         noaligned_objects are not available  when  you  use  the
         -oldc  flag.   However,  the -misalign flag is a synonym
         for -assume noaligned_objects and the -no_misalign  flag
         is a synonym for -assume aligned_objects.

       -assume [no]trusted_short_alignment
           Controls  the  compiler's assumptions about the align­
           ment of short types accessed through a pointer.

           Specifying -assume  trusted_short_alignment  indicates
           that  the  compiler  should  assume any short accessed
           through a pointer is naturally aligned.   This  gener­
           ates  the  fastest code, but can silently generate the
           wrong results if any of  the  short  objects  cross  a
           quadword boundary.  This is the behavior when -oldc is
           specified.

           Specifying -assume notrusted_short_alignment tells the
           compiler  that  short  objects  may  not  be naturally
           aligned.  The compiler generates slightly larger  (and
           slower)  code  that  will  give  the  correct  result,
           regardless of the actual alignment of the data.   This
           is the default when -newc or -migrate is specified.

           Note  that  -assume notrusted_short_alignment does not
           override the __unaligned type qualifier, the -misalign

       -[no_]misalign
           Controls the alignment assumptions for code  generated
           for indirect load and store instructions.

           The   -misalign   flag   is   a  synonym  for  -assume
           noaligned_objects and the -no_misalign flag is a  syn­
           onym   for   -assume   aligned_objects.   The  -assume
           [no]aligned_objects flag is discussed earlier in  this
           reference page.

       -[no]member_alignment
           Directs the compiler to byte-align data structure mem­
           bers (with the exception of bit-field members).

           By default, data structure members are aligned on nat­
           ural  boundaries (that is, on the next boundary appro­
           priate to the type of the member) instead of the  next
           byte.  For  example, an int variable member is aligned
           on the next longword boundary, and  a  short  variable
           member is aligned on the next word boundary.

           Any  use  of  the  #pragma  member_alignment,  #pragma
           nomember_alignment, or #pragma pack directives  within
           the  source  code overrides the setting established by
           this flag.

           The use of the -nomember_alignment flag can cause con­
           flicts  between  the compiler's assumptions about data
           layouts and the default values  that  were  in  effect
           when  the  system  libraries  were  created.  See pro­
           tect_headers_setup(8) for details on how to avoid this
           conflict.

           [The  -[no]member_alignment flag is not available when
           you use the -oldc flag.]

       -Zp[n]
           Aligns structure members based on the integer n, where
           n can be 1, 2, 4, or 8. This flag specifies packing so
           that each structure member after the first  is  stored
           on  n-byte  boundaries.  When you specify the -Zp flag
           without an n value, structure members  are  packed  on
           1-byte boundaries.

           The  use  of the -Zpn flag (where n!=8) can cause con­
           flicts between the compiler's assumptions  about  data
           layouts  and  the  default  values that were in effect
           when the system  libraries  were  created.   See  pro­
           tect_headers_setup(8) for details on how to avoid this
           conflict.
           Affects the generation  of  code  for  assignments  to
           objects that are less than or equal to 16 bits in size
           (for instance char, short) that have been declared  as
           volatile.   The  generated code includes a load-locked
           instruction for the enclosing longword or quadword, an
           insertion of the new value of the object, and a store-
           conditional instruction for the enclosing longword  or
           quadword.   By  using this locked instruction sequence
           for byte and word stores,  the  -strong_volatile  flag
           allows  byte and word access of data at byte granular­
           ity.  This means that assignments to adjacent volatile
           small  objects by different threads in a multithreaded
           program will not cause one of the objects  to  receive
           an incorrect value.

           [The  -strong_volatile  flag is not available when you
           use the -oldc flag.]

       -weak_volatile
           Affects the generation  of  code  for  assignments  to
           objects that are less than or equal to 16 bits in size
           (for instance char, short) that have been declared  as
           volatile.   The  generated code includes a read of the
           enclosing longword or quadword, an  insertion  of  the
           new  value of the object, and a store of the enclosing
           longword or quadword.

           The  -weak_volatile  flag  does  not  generate  locked
           instructions  for  this sequence.  This allows byte or
           word access  to  memory-like  I/O  devices  for  which
           larger  accesses  will  not  cause  read or write side
           effects.  Because the sequence does not access byte or
           word  data  independently directly in memory (that is,
           ensure byte granularity), adjacent volatile  data  can
           be  corrupted when such byte or word accesses are per­
           formed in a multithreaded  environment  (for  example,
           two  volatile shorts stored in a longword and accessed
           asynchronously).

           [The -weak_volatile flag is not available when you use
           the -oldc flag.]

   C Language Flags
       -double
           Promotes expressions of type float to double.  This is
           the default when -std0 is used.

       -float

       -float_const
           Causes the C front end to inspect  the  floating-point
           value and treat the value as a float if it can be rep­
           resented as a single precision value.  By default, all
           floating-point  constants are treated as double preci­
           sion.

           To ensure that this change has no impact on  standards
           conformance,  the  -float_const  flag is disabled when
           -std1 (strict ANSI mode) is also specified on the com­
           pile  command  line.   When this situation occurs, the
           compiler issues a warning message indicating that  the
           -float_const flag is being ignored.

       -readonly_strings
           Causes  all  string  literals to be read-only. This is
           the default.

           This flag overrides -writable_strings. If you  attempt
           to write to a string literal when -readonly_strings is
           specified, you might experience unpredictable results,
           such as a segmentation fault.

       -signed
           Causes  all  char declarations to have the same repre­
           sentation and range of values as signed char  declara­
           tions.   This is used to override a previous -unsigned
           flag.  This is the default.

       -unsigned
           Causes all char declarations to have the  same  repre­
           sentation  and range of values as unsigned char decla­
           rations.

       -varargs
           Prints warnings for all lines  that  may  require  the
           varargs.h macros.

       -volatile
           Causes all variables to be treated as volatile.

       -writable_strings
           Causes  all  string  literals to be writable.  This is
           the default.

           This flag overrides -readonly_strings.

           Specifies chopped rounding mode (round toward zero).

       -fprm d
           Dynamically sets rounding mode for IEEE floating-point
           instructions.  The dynamic rounding mode is determined
           from the contents of the floating-point control regis­
           ter  and can be changed or read at execution time by a
           call to write_rnd(3) or read_rnd(3).  If  you  specify
           -fprm   d,   the  IEEE  floating-point  rounding  mode
           defaults to round to nearest.

       -fprm n
           Specifies normal  rounding  mode  (unbiased  round  to
           nearest).  This is the default.

       -fprm m
           Specifies round toward minus infinity mode.

   Stack-handling and Pointer-handling Flags
       -trapuv
           Forces  all  uninitialized  stack variables to be ini­
           tialized with 0xfff58005fff58005. When this  value  is
           used  as a floating-point variable, it is treated as a
           floating-point NaN and causes a  floating-point  trap.
           When  it is used as a pointer, an address or segmenta­
           tion violation usually occurs.

           For programs compiled without the -trapuv switch,  the
           debugger  stops only on executable statements in which
           the value of a specified variable changes.   With  the
           -trapuv switch, the debugger stops on these statements
           and also stops on  all  local  variable  declarations.
           (The  debugger  treats the local variable declarations
           as assignment statements  because  the  variables  are
           initialized by the compiler.)

       -xtaso
           Controls pointer size allocation by directing the com­
           piler to respond to the #pragma  pointer_size  prepro­
           cessor  directives.  This  flag  allows you to specify
           32-bit pointers when  used  in  conjunction  with  the
           pragma pointer_size directive. To use 32-bit pointers,
           you must place pragmas where appropriate in your  pro­
           gram.  Images built with this flag must be linked with
           the -xtaso or -taso flag in order  to  run  correctly.
           See  the Programmer's Guide for information on #pragma
           pointer_size.

           default.   You can still use 64-bit pointers, but only
           by the use of pragmas.

           The use of the -xtaso_short flag can  cause  conflicts
           between the compiler's assumptions about pointer sizes
           and data layouts and the default values that  were  in
           effect  when  the  system  libraries were created. See
           protect_headers_setup(8) for details on how  to  avoid
           this conflict.

       -framepointer
           Makes  all procedures in the source file use $fp (reg­
           ister 15) as the frame pointer.

   IEEE Floating-point Support Flags
       -fptm n
           Generates instructions that do not  trigger  floating-
           point underflow or inexact trapping modes.  Any float­
           ing point overflow, divide-by-zero, or invalid  opera­
           tion will unconditionally generate a trap.  -fptm n is
           the default.

       -fptm u
           Generates traps on floating-point underflow as well as
           overflow, divide-by-zero, and invalid operation.

       -ieee
           Ensure  support  of  all portable features of the IEEE
           Standard   for   Binary   Floating-Point    Arithmetic
           (ANSI/IEEE  Std  754-1985), including the treatment of
           denormalized numbers, NaNs,  and  infinities  and  the
           handling  of  error  cases.   This  flag also sets the
           _IEEE_FP C preprocessor macro.

           If your program must use IEEE signaling features  that
           are  not  portable  across  different IEEE implementa­
           tions, see the ieee(3) reference page for a discussion
           of how to access them under the DIGITAL UNIX operating
           system.

       -scope_safe
           Ensures that any trap (such  as  floating-point  over­
           flow) is reported to have occurred in the procedure or
           guarded scope that caused the trap.  Any  trap  occur­
           ring  outside  that  scope  is  not  reported  to have
           occurred in the procedure or guarded scope,  with  the
           exception of well-defined trapb instructions following
           jsr instructions.
           ucode  object  file output in corresponding files suf­
           fixed with .u.  This flag is not  available  with  the
           -newc and -migrate flags.

       -k  Passes flags that start with a -k to the ucode loader.
           This flag is used to specify ucode libraries (with -kl
           filename) and other ucode loader flags.

       -ko output
           Names  the  output file created by the ucode loader as
           output.  This file is not removed.  If  this  file  is
           compiled, the object file is left in a file whose name
           consists of output with the suffix changed to  .o.  If
           output  has no suffix, a .o suffix is appended to out­
           put.  This flag is not available with  the  -newc  and
           -migrate flags.

   Compiler Development Flags (Not Generally Used)
       -Hc Halts  compiling after the pass specified by the char­
           acter c, producing an intermediate file for  the  next
           pass.   The c character can be one of the following: [
           fjusmoca ].  It selects the compiler pass in the  same
           way  as the -t flag.  If this flag is used, the symbol
           table file produced and used by the  passes  is  given
           the name of the last component of the source file with
           the suffix changed to  .T,  and  the  file  is  always
           retained after the compilation is halted.

       -K  Directs  the  compiler  to  give recognizable names to
           intermediate files and retain them for debugging  pur­
           poses.  Each file is given the name of the last compo­
           nent of the source file, replacing its suffix with the
           conventional suffix for the type of file (for example,
           .B file for binary ucode produced by the  front  end).
           These  intermediate files are never removed, even when
           a pass encounters a fatal error. When ucode linking is
           performed  and the -K flag is specified, the base name
           of the files created after the ucode link is u.out  by
           default.  If -ko output is specified, the base name of
           the object file, if it exists, is output.   If  output
           includes  a suffix, the suffix is not included as part
           of the base name.

       -Wc[c...],arg1[,arg2...]
           Passes the argument, or arguments (argi), to the  com­
           piler  pass, or passes (c[c...]). Each c character can
           be one of the following: [ pfjusdqmocablyz  ].  The  c
           selects  the  compiler  pass in the same way as the -t

       startup routine, or standard library. These arguments  are
       processed  from  left to right, so their order is signifi­
       cant. When the -B flag is encountered,  the  selection  of
       names  takes place using the last -h and -t flags.  There­
       fore, the -B flag is always required when using -h or  -t.
       Sets  of these flags can be used to select any combination
       of names.

       All -B flags must be preceded by -p flags.   The  -p  flag
       provides  the location of startup routines and the profil­
       ing library.

       Use the -t [hpfjusmocablyzrntLCD] suboptions to select the
       names.   The  names  selected  are those designated by the
       characters following the -t flag, according to the follow­
       ing  table.  Note that the -newc and -migrate flags accept
       the same set of suboptions.

       -------------------------------------------------------
       -oldc Name   -newc Name   Character
       -------------------------------------------------------

       include                   h (see note following table)
       cfe          gemc_cc      p, f
       ujoin                     j
       uld                       u
       usplit                    s
       umerge                    m
       uopt                      o
       ugen                      c
       as0          as0          a
       as1          as1          b
       ld           ld           l
       ftoc                      y
       cord         cord         z
       [m]crt0.o    [m]crt0.o    r
       libprof1.a   libprof1.a   n
       btou, utob                t
       om           om           L
       pixie        pixie        C
       prof         prof         D
       -------------------------------------------------------

       If the character h is in the -t argument, a  directory  is
       added  to  the list of directories to be used in searching
       for header files.  The name of this directory has the form
       $COMP_TARGET_ROOT/usr/include/string. This directory is to
       contain the header files for the  string  release  of  the
       compiler.  The standard directory is still searched.

           normally found.

       -Bstring
           Append string to all names specified by the  -t  flag.
           If no -t flag has been processed before the -B, the -t
           flag is assumed to be hpfjusmocablyzrntL.   This  list
           designates all names.

           If  no  -t  argument has been processed before the -B,
           then a -Bstring is passed to the loader  to  use  with
           its -lx arguments.

       Invoking the compiler with a name of the form ccstring has
       the same effect as using a -Bstring flag  on  the  command
       line.

EXAMPLES
       1.
         cc helloworld.c

         Compiles  the  file  helloworld.c  using  the compiler's
         defaults.  Because no output file is named in  the  com­
         mand  line,  the result of the compilation is written to
         the executable file named a.out.

       2.
         cc -newc -v helloworld.c
         /usr/lib/cmplrs/cc/gemc_cc  -D__LANGUAGE_C__  -D__unix__
         -D__osf__ -D__alpha -D_S YSTYPE_BSD -D_LONGLONG -D__dig­
         ital__ -D__arch64__  -I/usr/include  -v  -preempt_module
         -intrinsics   -g0  -O2  -std  -noansi_alias  -o  hello.o
         hello.c

         These macros are in effect at the start of the
         ----------------------------------------------
         compilation.
         ------------

         -D__DECC -D__osf__  -D__arch64__  -D__PRAGMA_ENVIRONMENT
         -D_LONGLONG -D__digital__ -D__X_FLOAT -D__DATE__="Jan 28
         1998"    -D__DECC_MODE_RELAXED     -D__DECC_VER=50760700
         -D_SYSTYPE_BSD   -D__ALPHA   -D__IEEE_FLOAT   -D__unix__
         -D__TIME__="15:23:28"       -D__Alpha_AXP       -D__INI­
         TIAL_POINTER_SIZE=0     -D__STDC__=0    -D__LANGUAGE_C__
         -D__alpha /usr/lib/cmplrs/cc/gemc_cc:
         0.00u 0.02s 0:00  16%  0+9k  0+8io  0pf+0w  9stk+1032mem
         /usr/lib/cmplrs/cc/ld      -g0      -O1     -call_shared
         /usr/lib/cmplrs/cc/crt0.o          hello.o           -lc
         /usr/lib/cmplrs/cc/ld:
         0.01u 0.02s 0:00 17% 0+8k 0+15io 0pf+0w 8stk+1224mem
         pass, and its arguments, as it executes.

ERRORS
       The  diagnostics  produced  by cc are intended to be self-
       explanatory.  Occasional messages may be produced  by  the
       assembler or loader.

FILES
       file.c    Input file

       file.o    Object file

       a.out     Loaded output

       err.english.cc
                 Compiler error messages in English

       /tmp/ctm? Temporary

       /usr/lib/cmplrs/cc/comp.config
                 Compiler configuration file (optional)

       /usr/lib/cmplrs/cc/cfe
                 C front end

       /usr/lib/cmplrs/cc/cpp
                 C macro preprocessor

       /usr/lib/cmplrs/cc/gemc_cc
                 DEC C compiler

       /usr/lib/cmplrs/cc/ujoin
                 Binary ucode and symbol table joiner

       /usr/bin/uld
                 Ucode loader

       /usr/lib/cmplrs/cc/usplit
                 Binary ucode and symbol table splitter

       /usr/lib/cmplrs/cc/umerge
                 Procedure integrator

       /usr/lib/cmplrs/cc/uopt
                 Optional global ucode optimizer

       /usr/lib/cmplrs/cc/om
                 Post-link optimizer

       /usr/lib/cmplrs/cc/ugen

       /usr/lib/cmplrs/cc/as1
                 Binary  assembly  language assembler and reorga­
                 nizer

       /usr/lib/cmplrs/cc/crt0.o
                 Run-time startup

       /usr/lib/cmplrs/cc/mcrt0.o
                 Startup for prof profiling

       /usr/lib/cmplrs/cc/gcrt0.o
                 Startup for gprof profiling

       /usr/ccs/lib/libc.a
                 Standard library, see intro(3)

       /usr/lib/cmplrs/cc/libprof1.a
                 Level 1 profiling library

       /usr/lib/cmplrs/cc/libprof1_r.a
                 Reentrant level 1  profiling  library  for  code
                 compiled with -pthread or -threads

       /usr/include
                 Standard directory for header files

       /usr/lib/cmplrs/cc/ftoc
                 Interface between prof and cord

       /usr/lib/cmplrs/cc/cord
                 Procedure-rearranger

       /usr/bin/btou
                 Binary to symbolic ucode translator

       /usr/bin/utob
                 Symbolic to binary ucode translator

       mon.out   File produced for analysis by prof

       gmon.out  File produced for analysis by gprof

RELATED INFORMATION
       ANSI X3.159-1989

       B.  W. Kernighan and D. M. Ritchie, The C Programming Lan­
       guage

       B. W. Kernighan, Programming in C -- a tutorial
       Programmer's Guide

       Assembly Language Programmer's Guide

       DEC C Language Reference Manual

       as(1), atom(1), cc(1), c89(1), cord(1),  dbx(1),  ftoc(1),
       gprof(1), hiprof(5), ieee(3), ladebug(1), ld(1), ld(1old),
       monitor(3), pixie(5),  prof(1),  protect_headers_setup(8),
       standards(5), third(5), what(1) delim off