cc man page on OSF1

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

cc(1)									 cc(1)

NAME
       cc - C compiler

SYNOPSIS
       cc [option...] file... [option...]

   Default Options:
       cc -std	-arch generic  -assume aligned_objects	-noansi_alias  -assume
       math_errno  -call_shared	 -cpp  -error_limit 30	-float	 -nofp_reorder
       -fprm  n	  -fptm	 n  -g0	  -I/usr/include   -inline manual  -intrinsics
       -member_alignment  -nomisalign  -nestlevel=50  -newc  -O1   -p0	 -nopg
       -preempt_symbol	-SD/usr/include -signed	 -tune generic	-weak_volatile
       -writable_strings

OPTIONS
       Options described in this section are divided into the following	 cate‐
       gories.	 The  default  options	for each category, if any, are listed:
       Compiler Selection Options

	      Default: -newc
	      Language Mode Options

	      Default: -std
	      Overall Compiler Behavior Options

	      Defaults: -arch generic, -error_limit 30,
	      -nestlevel=50
	      Compiler Diagnostic Controls Options

	      Default: -SD/usr/include
	      C Preprocessor Options

	      Defaults: -cpp, -I/usr/include
	      Options that Affect the Linker or Loader

	      Default: -call_shared
	      Optimization Options

	      Defaults: -noansi_alias, -assume math_errno,
	      -float, -nofp_reorder, -inline manual, -intrinsics,
	      -O1, -preempt_symbol, -tune generic
	      Feedback-directed Optimization Options

	      Default: None
	      Source-code Debugging Options

	      Default: -g0
	      Program Profiling Options

	      Defaults: -p0, -nopg
	      Data Alignment Options

	      Defaults: -assume aligned_objects, -member_alignment
	      -nomisalign
	      Data Volatility Options

	      Default: -weak_volatile
	      C Language Options

	      Defaults: -signed, -writable_strings
	      Stack-handling and Pointer-handling Options

	      Default: None
	      IEEE Floating-point Support Options

	      Defaults: -fprm n, -fptm n
	      Compiler Development Options (Not Generally Used)

	      Default: None

   Compiler Selection Options
       Invokes the compiler with the default option settings shown in the SYN‐
       OPSIS section.  This option is provided to turn off -migrate, and it is
       the default.  Invokes the compiler with a set of optimization  settings
       that  are  slightly  different  from those associated with -newc. These
       settings are consistent with the cc -migrate settings for  versions  of
       the  DEC OSF/1 operating system that preceded DIGITAL UNIX Version 4.0.
       This option is provided for backwards compatibility only, and  its  use
       is strongly discouraged.

   Language Mode Options
       The  language  mode  options are mutually exclusive. When more than one
       such option appears on the command line, the last one listed will  take
       effect.	 The default is -std.  Selects the relaxed ANSI language mode.
       This is the default. Accepts standard ANSI C89 and  C99	features,  but
       allows some common programming practices disallowed by the standards.

	      This  option  does  not  restrict the Tru64 UNIX name space (for
	      example, the names defined in system header files).  To restrict
	      that  name  space	 so  that only ANSI reserved names are visible
	      from the ANSI header files, use the  _ANSI_C_SOURCE  macro.  See
	      standards(5) for more details.

	      This  option sets the macro __STDC_VERSION__ to 199901L, and the
	      macro __STDC__ to 0.  Selects the K & R language mode.  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 C89 programs and produces
	      expected results.	 The -std0 option leaves the  macros  __STDC__
	      and  __STDC_VERSION__  undefined.	  Selects  the strict ANSI C89
	      language mode. Strictly enforces the ANSI C89 standard  and  all
	      its  prohibitions	 (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 modification of rvalues).

	      This  option  does  not  restrict the Tru64 UNIX name space (for
	      example, the names defined in system header files). To  restrict
	      that  name  space	 so  that only ANSI reserved names are visible
	      from the ANSI header files, use the  _ANSI_C_SOURCE  macro.  See
	      standards(5) for more details.

	      This  option  sets  the macro __STDC__ to 1 and leaves the macro
	      __STDC_VERSION__ undefined. Note that this option	 also  affects
	      linker-defined symbols.  See ld(1) for more information.

	      This option, combined with -O3 or higher, turns on ANSI aliasing
	      rules (-ansi_alias option).  Selects the strict  ANSI  C99  lan‐
	      guage  mode. Strictly enforces the ANSI C99 standard and all its
	      prohibitions.

	      This option does not restrict the Tru64  UNIX  name  space  (for
	      example,	the names defined in system header files). To restrict
	      that name space so that only ANSI	 reserved  names  are  visible
	      from  the	 ANSI  header files, use the _ANSI_C_SOURCE macro. See
	      standards(5) for more details.

	      This option sets the macro __STDC_VERSION__ to 199901L, and  the
	      macro __STDC__ to 1.  Enables additional features from Amendment
	      1 to the ANSI C89 standard.

	      This option sets the macro __STDC_VERSION__ to  199409L  in  all
	      language modes except for the following:

	      -c99  (__STDC_VERSION__ is set to 199901L)
	      -vaxc  (__STDC_VERSION__ is not set)

	      This  option  has	 no effect on the macro __STDC__.  Selects the
	      Microsoft language mode, which provides some compatibility  with
	      the  Microsoft Visual C compiler.	 Although this option does not
	      provide full compatibility, it can be useful as a	 porting  aid.
	      It  provides  the	 following extensions. Except for these exten‐
	      sions, the -ms option is equivalent to -std. Thread Local	 Stor‐
	      age  (TLS) and structured exception handling are always enabled.
	      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.  */
	      Allow duplicate typedef declarations. For example:

	      typedef  int typedefname; typedef int typedefname; Allow typedef
	      declarations that are redeclared to a compatible type. For exam‐
	      ple:

	      typedef  enum {a,b,c} typedefname; typedef enum {d,e,f} typedef‐
	      name; 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 second 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 expres‐
	      sion in certain cases. For example:

	      int *a, *b;
		 f() {
		     &*a=b; } Allow integers and pointers to be compared with‐
	      out a cast.  For example:

	      int *a,b; f() { if (a==b)
		 b=1;  } Treat the char type as either signed char or unsigned
	      char, depending of the default in effect. For example, a pointer
	      to  char	can  be assigned to a pointer to signed char, assuming
	      that the -signed option 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;

	      This is assigned type int.  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 identi‐
	      fier 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

	      Selects  the  K  & R language mode. This option is equivalent to
	      -std0.  Selects the K & R language mode. This option is  equiva‐
	      lent to -std0.  Selects the VAX C language mode. This is similar
	      to -std (relaxed ANSI mode) but extends the  language  semantics
	      in  ways	that  are  incompatible with ANSI C. It provides close
	      compatibility with the vaxc compiler.

   Overall Compiler Behavior Options
       Causes the compiler to recognize	 additional  keywords.	The  following
       options	are available: The default compilation mode on OpenVMS systems
       includes recognition of the following keywords that are	not  available
       on Tru64 UNIX except in -vaxc mode: _align, globaldef, globalref, glob‐
       alvalue, noshare, readonly,  variant_struct,  and  variant_union.  This
       option  causes  these keywords to be recognized. It may help in porting
       applications from OpenVMS systems.  Cause the compiler to recognize the
       restrict	 keyword (from the C9X review draft).  Specifies which version
       of the Alpha architecture to generate instructions for. All Alpha  pro‐
       cessors	implement  a  core set of instructions and, in some cases, the
       following extensions: BWX (byte/word-manipulation extension), MVI (mul‐
       timedia	extension), FIX (square root and floating-point convert exten‐
       sion), and CIX (count extension).  (The	Alpha  Architecture  Reference
       Manual describes the extensions in detail.)

	      The  option  specified  by  the  -arch  option  determines which
	      instructions the compiler can  generate:	Generate  instructions
	      that  are	 appropriate  for all Alpha processors. This option is
	      the default.  Generate instructions for the processor  that  the
	      compiler	is running on (for example, EV6 instructions on an EV6
	      processor).  Generate instructions for the EV4 processor (21064,
	      21064A,  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 emula‐
	      tion overhead on any Alpha processor.  Generate instructions for
	      EV56 processors (some 21164 chips).

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

	      Applications compiled with this option may incur emulation over‐
	      head  on	EV4 and EV5 processors.	 Generate instructions for EV6
	      processors (21264 chips).

	      This option permits the compiler to generate  any	 EV6  instruc‐
	      tion,  plus  any	instructions contained in the following exten‐
	      sions: BWX, MVI, and FIX.

	      Applications compiled with this option may incur emulation over‐
	      head on EV4, EV5, EV56, and PCA56 processors.  Generate instruc‐
	      tions for EV67 processors (21264A chips).

	      This option is the same as the ev6 option except	that  it  also
	      permits  the  compiler to generate any instructions contained in
	      the CIX extension.

	      If your application uses CIX instructions, it may	 incur	emula‐
	      tion  overhead on all processors that are older than EV67.  Gen‐
	      erate instructions for PCA56 processors (21164PC chips).

	      This option permits the compiler to generate  any	 EV4  instruc‐
	      tion,  plus any instructions contained in the BWX and MVI exten‐
	      sions.

	      Applications compiled with this option may incur emulation over‐
	      head on EV4, EV5, and EV56 processors.

	      A program compiled with any of the options will run on any Alpha
	      processor.  Beginning with DIGITAL UNIX V4.0 and continuing with
	      subsequent  versions,  the  operating  system kernel includes an
	      instruction emulator. This capability allows any Alpha  chip  to
	      execute	and   produce  correct	results	 from  Alpha  instruc‐
	      tions--even if the some of the instructions are not  implemented
	      on  the  chip. Applications using emulated instructions will run
	      correctly, but may incur significant emulation overhead  at  run
	      time.

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

	      Note the following differences between the -arch evx  and	 -tune
	      evx options (where x designates a specific processor): -arch evx
	      implies -tune evx, but -tune  evx	 does  not  imply  -arch  evx.
	      -arch  evx can generate unguarded evx-specific instructions.  If
	      you run that application on a pre-evx processor, those  instruc‐
	      tions  may  get emulated (and emulated instructions can be up to
	      1000 times slower than actual instructions).  -tune evx can gen‐
	      erate  evx-specific  instructions,  but  those are always amask-
	      guarded. That expands the code size but avoids instruction  emu‐
	      lation.	If  you	 want  the best performance possible on an evx
	      processor and are not concerned  about  performance  on  earlier
	      processors,  the	best  choice would be -arch evx (which implies
	      -tune evx).  If you want good performance on  an	evx  processor
	      but  also want the application to run reasonably fast on earlier
	      processors, the best choice would probably be -tune  evx.	  Sup‐
	      presses the loading phase of the compilation and forces the cre‐
	      ation of an object file.	Generates runtime code	to  check  the
	      values  of  array	 subscripts (and equivalent pointer arithmetic
	      involving pointers produced by converting an  array  name	 to  a
	      pointer)	to  verify  that the resulting address lies within the
	      range for which the C standard requires  well-defined  behavior.
	      The  exact source code constructs that trigger these checks, and
	      the values used for a given bounds  check,  are  not  simple  to
	      describe.	 In  some  cases  the  checks  will  trap on a partial
	      address computation even though the final result of the computa‐
	      tion is within bounds. A failed bounds check at runtime produces
	      a Trace/BPT trap, which may be caught  by	 signal(SIGTRAP,  han‐
	      dler). See the Programmer's Guide for more details.

	      The  -nocheck_bounds  option  (the default) disables the runtime
	      checking of array bounds.	 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	 unde‐
	      fined).  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  compilation  can
	      be  interrupted in this way. If no number is specified, the com‐
	      pile-edit-compile cycle repeats indefinitely  until  all	errors
	      are  corrected.	The  -edit0  option 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 compile job
	      has to be in the foreground for this option to take effect. When
	      compiling	 on a workstation, this option takes effect whether it
	      is in the foreground or background.  Sets a limit on the	number
	      of  error-level  diagnostics  that  the  compiler will emit. The
	      default is 30.  Specifies a file that is to be  included	before
	      the  first  line	in  a  source  file is actually compiled. This
	      enables users to develop include files containing sets of	 prag‐
	      mas that control a particular aspect of a compilation (for exam‐
	      ple, optimizations or diagnostics).  Controls the size of shared
	      data  in	memory	that  can  be  safely  accessed from different
	      threads. The possible size values are byte, longword, and	 quad‐
	      word.

	      Specifying  byte allows single bytes to be accessed from differ‐
	      ent threads sharing data in memory without corrupting  surround‐
	      ing bytes. This option will slow runtime performance.

	      Specifying longword allows naturally aligned 4-byte longwords to
	      be accessed safely from different threads sharing data  in  mem‐
	      ory.   Accessing	data  items  of	 3 bytes or less, or unaligned
	      data, may result in data items  written  from  multiple  threads
	      being inconsistently updated.

	      Specifying quadword allows naturally aligned 8-byte quadwords to
	      be accessed safely from different threads sharing data  in  mem‐
	      ory.   Accessing	data  items  of	 7 bytes or less, or unaligned
	      data, may result in data items  written  from  multiple  threads
	      being  inconsistently  updated.  This  is the default.  Sets the
	      nesting-level limit  for	include	 files.	 The  default  is  50.
	      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.  Suppresses cre‐
	      ation 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 file extension.

	      Use the -noobject option when you need only a listing of a  pro‐
	      gram  or	when  you want the compiler to check a source file for
	      errors.  Names the final output file output.  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 option are as follows:
	      Enables the protect headers feature. This is the default if  the
	      file  being  compiled  is a C source file.  Disables the protect
	      headers feature. This is the default if the file being  compiled
	      is  a  non-C source file.	 Cancels any previous -protect_headers
	      options and places the compiler's default behavior in effect.

	      If more than one -protect_headers option appears on the  command
	      line, only the last one is applied. See protect_headers_setup(8)
	      for details.  Compiles the specified source files and  generates
	      symbolic	assembly  language  output in corresponding files suf‐
	      fixed with Specifies one or more items to	 be  included  in  the
	      listing  file.  When specifying multiple keywords, separate 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 option are as follows: Turns off all
	      show options.  Turns on all  show	 options.   Produces  a	 brief
	      macro and symbol table map in the program listing, omitting most
	      macros and symbols that are  unreferenced.  Attributes  such  as
	      line  number of declaration, size, alignment, storage class, and
	      type are shown for each symbol.  Adds a list of line numbers  to
	      each  identifier	produced  by the brief or symbol show options,
	      identifying the listing lines that contain  references  to  that
	      identifier.  If  neither	brief  nor  symbol  is	specified, the
	      default is brief. Listing line numbers are the  sequential  num‐
	      bers  that  span included files, and appear just before the text
	      of each source line in the source	 listing.   When  appropriate,
	      the line number designating a reference to a symbol is annotated
	      with one or more suffixes indicating the way in which the symbol
	      was used on that line, as follows:

	      = Assigned or initialized
	      & Address taken
	      () Function called
	      * Simple dereference
	      -> Member dereference
	      [] Subscripted (that is, using [] syntax)
	      b Invoked as a builtin function
	      Places  final  macro expansions in the program listing. When you
	      specify expansion, the number printed in	the  margin  indicates
	      the  maximum  depth  of  macro  substitutions that occur on each
	      line. Expansion is not shown for	lines  that  are  preprocessor
	      directives.   Produces  header  lines at the top of each page of
	      listing.	Places contents of header files	 in  program  listing.
	      Places  source  program  statements  in program listing.	Places
	      compile-time performance	statistics  in	the  program  listing.
	      Same  as	[no]brief, except that unreferenced macros and symbols
	      are not suppressed.

	      If you specify -source_listing but do  not  specify  -show  key‐
	      words,  the compiler includes header lines and source statements
	      in the program listing (-show header,source).  Produces a source
	      program  listing	file with the same name as the source file and
	      with a file extension. You must specify this qualifier to get  a
	      listing.	 The default is to not produce a listing file.	Prints
	      the compilation phases as they execute with their arguments  and
	      their  input  and	 output files. Prints resource usage in the C-
	      shell time format. Prints the macros defined at the start of the
	      compilation.  Prints the version of the compiler driver.

   Compiler Diagnostic Controls Options
       Performs	 compile-time  code  checking.	With this option, the compiler
       checks for code that exhibits nonportable behavior, represents a possi‐
       ble unintended code sequence, or possibly affects operation of the pro‐
       gram because of a quiet change in the ANSI C Standard.  Some  of	 these
       checks have traditionally been associated with the lint utility.

	      The  -check  option  is equivalent to -msg_enable level5. The cc
	      driver converts -check into -msg_enable level5  (the  -v	option
	      notifies	you  of	 this transformation).	Causes the compiler to
	      dump, to stdout, all messages enabled by any  given  cc  command
	      line.  The  compiler  then  exits,  without doing a compilation.
	      Provides users with the ability to control the  diagnostic  mes‐
	      sages issued by the compiler. The message output can be tuned in
	      groups (based on message level or message group) or individually
	      (based  on the message ID strings enclosed in parentheses at the
	      end of message text strings).

	      The -msg_actiontype  option  has	eight  different  forms,  each
	      resulting	 in a different action that changes the status, sever‐
	      ity, or frequency that will be applied to the  messages  identi‐
	      fied  by	the  msg_list  argument. The following message-control
	      options are supported: Enable a specific	message	 or  group  of
	      messages.	  Disable  a  specific	message	 or group of messages.
	      (Note that messages with error or fatal severity cannot be  dis‐
	      abled; only warning and informational messages can be disabled.)
	      Always emit the messages identified by  the  msg_list  argument.
	      Emit  the	 identified messages only once.	 Change the identified
	      messages to be fatal,  compilation-ending	 errors.   Change  the
	      identified  messages to be warnings. (Note that error- or fatal-
	      severity messages cannot be  changed  to	warning-severity  mes‐
	      sages.)  Change the identified messages to be informational mes‐
	      sages. (Note that error- or fatal-severity  messages  cannot  be
	      changed to informational-severity messages.)  Change the identi‐
	      fied messages to be error messages.  (Note  that	fatal-severity
	      messages cannot be changed to error-severity messages.)

	      The  msg_list argument to the -msg_actiontype option is a comma-
	      separated list of one or more message levels, message 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
	      specified (or default) level, not to lower levels.

	      The following message levels and message groups are supported:

	      Message  Levels:	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.  Important messages, but less impor‐
	      tant than level 0 messages. These messages are not displayed  if
	      pragma  nostandard is active. Level 1 is the default for DIGITAL
	      UNIX releases prior to V4.0E.   Moderately  important  messages.
	      Level  2	is the default for DIGITAL UNIX V4.0E and later (Tru64
	      UNIX) versions.	Less  important	 messages.   (The  -w0	option
	      enables  level 3 messages.)  Useful messages associated with the
	      -check and -portable options.  Less useful -check and  -portable
	      messages	than  the messages associated with level 4. The -check
	      option is	 equivalent  to	 -msg_enable  level5.	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 messages added by level 6.

	      Message  Groups:	Messages  reporting code or practices that may
	      have unintended consequences on 64-bit architectures.   Messages
	      reporting	 unusual  or  inefficient  data	 alignment.   Messages
	      reporting the use of C features that would be invalid or have  a
	      different	 meaning  if  compiled	by  a  C++ compiler.  Messages
	      reporting code or practices that, although correct  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).	Messages reporting the
	      use of obsolete features, features that were accepted by early C
	      compilers but were subsequently removed from the language.  Mes‐
	      sages reporting the use of features that are not in the ANSI C89
	      standard. Same as noc89.	Messages reporting the use of features
	      that are not in the ANSI C89 standard. Same as noansi.  Messages
	      reporting the use of features that are not in the ANSI C99 stan‐
	      dard.  Messages reporting the use of features that  are  new  in
	      the  ANSI	 C99 standard.	Messages reporting the use of features
	      that are valid in ANSI C, but which are identified in the	 stan‐
	      dard as being obsolescent and likely to be removed from the lan‐
	      guage in a future version of the standard.   Messages  reporting
	      assignments  and/or  casts that may cause overflow or other loss
	      of data significance.  Messages reporting code that might result
	      in  poor	run-time  performance.	 Messages reporting the use of
	      language extensions or other constructs that might not be porta‐
	      ble  to  other  compilers or platforms.  -msg_enable portable is
	      equivalent to -portable.	 Messages  reporting  questionable  or
	      non-portable  use of preprocessing constructs.  Messages report‐
	      ing questionable coding practices. Similar to  check,  but  mes‐
	      sages  in	 this  group are more likely to indicate a programming
	      error, not just a non-robust style.  Messages relating to	 func‐
	      tion  return  values.   Messages reporting expressions, declara‐
	      tions, and code paths that are not used.	Directs	 the  compiler
	      to issue diagnostics for certain constructs that may not be por‐
	      table to other compilers or platforms.  -portable is  equivalent
	      to -msg_enable portable.	Suppresses certain warning- and infor‐
	      mational-level diagnostic messages that  are  inappropriate  for
	      system  header files. The suppressed messages relate to non-por‐
	      table 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 options 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 pro‐
	      vides  message  suppression  in  the  file   __DECC_include_pro‐
	      logue.h.)	  Produces longer error and warning messages. Messages
	      in this form may give the user more hints about why the compila‐
	      tion  failed.   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: Displays compiler messages for less
	      important issues. This is equivalent to -msg_enable level3.  For
	      Tru64  UNIX  V4.0E and later versions, -msg_enable level2 is the
	      default.	Suppresses warning and informational messages and dis‐
	      plays error and fatal messages. This is equivalent to specifying
	      -w.  If the compiler encounters an error that generates a	 warn‐
	      ing-level	 diagnostic message, the compiler displays the message
	      and then aborts.	Does not  print	 warning  messages.   However,
	      when warnings occur, exits with nonzero status.  Causes the com‐
	      piler 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 Options
       Passes all comments directly to the preprocessor	 output,  except  com‐
       ments  on preprocessor directive lines.	Determines whether to call the
       C macro preprocessor on C and assembly source files before compiling.

	      -cpp is the default.  Defines the name  as  if  with  a  #define
	      statement.  If no definition is given, the name is defined as 1.
	      Runs only the C macro preprocessor on the files  and  sends  the
	      result  to  the standard output device.  Specifies a search path
	      for header files whose names do not indicate a  specific	direc‐
	      tory  path  (that	 is,  whose  names do not begin with a /). The
	      actual search path depends upon the form of the #include	direc‐
	      tive  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 con‐
	      tains the directive, then in the search path indicated by the -I
	      option, and finally in the standard directory, /usr/include.  If
	      the #include <filename> form of the directive is used, the  pre‐
	      processor	 searches  for the file first in the search path indi‐
	      cated by the -I option, and  then	 in  the  standard  directory,
	      /usr/include.

	      You can specify multiple iterations of the -I[dir] option in the
	      cc command line; each instance  of  the  -[dir]  option  appends
	      locations	 to the previously established -I[dir] search path. If
	      no dir is specified in any instance of the -I[dir] option, the C
	      macro   preprocessor  never  searches  the  standard  directory,
	      /usr/include, for header files.

	      The -nocurrent_include option can also modify the	 search	 path.
	      Outputs  a  set  of make dependency rules to standard output for
	      each source file on the command line  (and  suppresses  compila‐
	      tion).  The  make	 dependencies  include all of the header files
	      upon which each source file depends. The make  targets  are  the
	      object  files  for  those	 source	 files.	 The  output lines are
	      indented to show header file nesting.  Requests dependency files
	      from  the	 preprocessor  (and linker if it is also run). It does
	      not suppress compilation like the	 -M  option.  This  option  is
	      passed  directly to the preprocessor and linker. For more infor‐
	      mation, see cpp(1) and  ld(1).   Changes	the  behavior  of  the
	      #include	"filename"  directive  to not search the source file's
	      directory for filename. This option causes the  #include	"file‐
	      name"  directives to behave like #include <filename> directives.
	      This option allows makefiles to control  the  search  order  for
	      header  files  by using -I options.  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.   Runs  only
	      the  C  preprocessor and puts the result for each or source file
	      in a corresponding file. The file has no #line_number preproces‐
	      sor directives in it.  Extracts prototype declarations for func‐
	      tion definitions and puts them in a suffixed file. The suboption
	      i	 includes  identifiers	in  the prototype, and the suboption s
	      generates prototypes for static functions as well.  Directs  the
	      preprocessor to use single quotes in __FILE__ expansions instead
	      of double quotes. See cpp(1) for	details.   Removes  any	 macro
	      definition  of name at the start of the compilation.  name could
	      have been defined with a -D option or  predefined	 by  the  com‐
	      piler. If no name is specified or if name is not defined, the -U
	      option is ignored. (To display a list of predefined macros,  use
	      the -v option.)

   Options that Affect the Linker or Loader
       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.  Passes the
       -compress option to the compilation phase (if the -c option is present)
       or  passes  the -compress_r option to ld (if the -r option is present).
       Use of this option causes the output object file to be produced in com‐
       pressed object file format, resulting in a substantially smaller object
       file.  Runs the procedure rearranger, cord, on the resulting file after
       linking.	 The rearrangement is done to reduce the cache conflicts asso‐
       ciated with accessing the program's text. The output of cord is left in
       the  file  specified  by	 the  -o output option or a.out by default. At
       least one -feedback file must be specified. See prof(1) for information
       on  creating  feedback  files.	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	 wildcard  characters  must be properly quoted to prevent them
       from being expanded by the shell.  For  more  information,  see	sh(1).
       Used  in	 conjunction  with  -call_shared  to request strict dependency
       testing for the executable file produced.  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.  Makes the  procedure
       represented  by	the  symbol into a termination routine.	 A termination
       routine is a routine that is called without an argument when either the
       file that contains the routine is unloaded or the program that contains
       the routine exits.  Makes the procedure represented by the symbol  into
       an  initialization routine. An initialization routine is a routine that
       is called without an argument when either the file  that	 contains  the
       routine	is loaded or the program that contains the routine is started.
       Directs the linker to read the contents of file filename as if the con‐
       tents had been supplied on the ld command line.

	      Inside file filename, lines ending with \ are treated as contin‐
	      uation lines, and lines starting with # are treated  as  comment
	      lines  and  ignored.  The	 -v  option can be used to display the
	      expansion of files specified in a -input file. The files can  be
	      nested  up to 20 levels.	Prevents the linker from using archive
	      libraries to resolve symbols. This option is used in conjunction
	      with  -call_shared. The -noarchive option is position sensitive;
	      it affects only those options and variables that	follow	it  on
	      the command line. This option can also be used more than once on
	      the command line.	 Directs the linker to produce a  static  exe‐
	      cutable.	The  output  object created by the linker will not use
	      any shared objects during execution.  Directs the linker to  use
	      the  threadsafe  version	of  any	 library specified with the -l
	      option when linking programs. This option also tells the	linker
	      to include the POSIX 1003.1c-conformant DECthreads interfaces in
	      libpthread when linking the program. This	 option	 also  defines
	      the  _REENTRANT  macro.  Produces dynamic shareable objects. The
	      loader will produce a shareable object that other	 dynamic  exe‐
	      cutables can use at run time.

	      The following options are used with -shared: 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. Multi‐
	      ple instances of this option  are	 allowed.   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	${VAR‐
	      NAME}, the linker interprets it as an environment variable.

	      Additional rpath directories found in shared objects on the link
	      command line  are	 appended  to  path.   Duplicate  entries  are
	      excluded.	 The loader uses the rpath record to search for shared
	      libraries at run time.  Establishes the version  identifier  (or
	      identifiers)  associated	with a shared library. The string ver‐
	      sion-string is either a single version identifier	 or  a	colon-
	      separated	 list  of  version  identifiers.  No  restrictions are
	      placed on the names  of  version	identifiers;  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 ver‐
	      sion or, if a list of  version  identifiers  is  specified,  the
	      rightmost	 version specified 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.  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  pathname
	      (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.  Registers the location of this shared object's seg‐
	      ments  and  makes sure they stay out of the way of others in the
	      location_file.  Location_file is	updated	 if  it	 is  writable.
	      Directs  the  linker  to	load  the executable file in the lower
	      31-bit addressable virtual address range.	 The -T and -D options
	      to the ld command can also be used, respectively, to ensure that
	      the text and data segments are loaded into low memory.

	      The -taso	 option,  however,  in	addition  to  setting  default
	      addresses	 for  text  and	 data  segments,  also	causes	shared
	      libraries linked outside the 31-bit address space to  be	appro‐
	      priately relocated by the 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 option
	      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).   Directs
	      the  linker  to use the threadsafe version of any library speci‐
	      fied with the -l option when linking programs. This option  also
	      tells the linker to include the POSIX 1003.4a Draft 4 conformant
	      DECthreads interfaces. It is supported  only  for	 compatibility
	      with  earlier releases of Tru64 UNIX. New designs should use the
	      -pthread option.

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

	      The  aliasing  rules are explained in Section 3.3, paragraphs 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 A character type.”

	      If  your	program does not access the same data through pointers
	      that have different types (and  for  this	 purpose,  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 pointers that
	      have different types (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 gen‐
	      eration of incorrect code.

	      The -noansi_alias option turns off ANSI C aliasing rules.

	      The  default  is	-noansi_alias except when compiling with -std1
	      (when combined with -O3 or higher) or -fast.  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  -noansi_args	means  that  the argument type may not
	      match the expected parameter type. This option is important, for
	      example, when the caller passes a parameter of type long and the
	      called routine expects an int. The  -noansi_args	option	forces
	      the  compiler  to generate argument cleaning code to convert the
	      argument to the appropriate type. Except when the	 -std1	option
	      is specified, -noansi_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.  Specifies the assumption that all array parame‐
	      ters  are	 or  are  not restricted. The default is -assume noar‐
	      ray_parameter_restricted_pointers. For the  sample  declaration:
	      foo(int * __restrict p1, int p2[], int * p3, int **p4);

	      The   following	statements  apply:  By	default,  only	p1  is
	      restricted.     If    you	   specify    -assume	 array_parame‐
	      ter_restricted_pointers, p1 and p2 are restricted.  If you spec‐
	      ify -assume parameter_restricted_pointers, p1, p2, p3 and p4 are
	      restricted,  but	*p4  is	 not restricted If you specify -assume
	      restricted_pointers, p1, p2, p3, p4, and *p4 are restricted.  If
	      you  specify -assume ignore_restricted_pointers, no pointers are
	      restricted, not even p1.

	      Each of these assumptions is negatable independently by  prefix‐
	      ing  a no to the assumption name. By default, all of the assump‐
	      tions are in this negated state. The state of each assumption is
	      resolved	separately  by	processing  negations in left-to-right
	      order.  For  example,  -assume   norestricted_pointers   -assume
	      restricted_pointers is resolved to -assume restricted_pointers.

	      At  the same time, the four assumptions have strictly-increasing
	      strength in the order shown, such that the  behavior  is	deter‐
	      mined  only  by the strongest assumption in effect at the end of
	      the command line, regardless of their relative  placement.  Thus
	      if  -ignore_restricted_pointers  is  in effect, the state of any
	      other assumption is ignored. For	the  other  assumptions,  this
	      "strength" effect is a natural result of supersetting.

	      The -assume norestricted_pointers option disables the __restrict
	      keyword from all pointers. This can  help	 detect	 inappropriate
	      use of __restrict. If the code works correctly at high optimiza‐
	      tion 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 erro‐
	      neous assertions.	 Specifies the assumption that the  restricted
	      attribute	 is or is not ignored for all pointers. The default is
	      -assume noignore_restricted_pointers. For more information,  see
	      -assume  [no]array_parameter_restricted_pointers.	  Controls the
	      compiler's assumption about a program's dependence on  the  set‐
	      ting  of	errno  by  math	 library routines: By default (-assume
	      math_errno), the compiler assumes that the program might	inter‐
	      rogate  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 unfor‐
	      tunately 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	 prac‐
	      tice,  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.  Specifies the assumption
	      that all pointer parameters  are	or  are	 not  restricted.  The
	      default  is  -assume  noparameter_restricted_pointers.  For more
	      information, see	-assume	 [no]array_parameter_restricted_point‐
	      ers.   Specifies the assumption that all pointers are or are not
	      restricted. The default is  -assume  norestricted_pointers.  For
	      more	information,	 see	 -assume     [no]array_parame‐
	      ter_restricted_pointers.	Specifies that no occurrences  of  the
	      address-of  operator  (&)	 are being applied outside the current
	      compilation unit to extern variables that	 are  declared	inside
	      the  current compilation unit.  Making this assertion allows the
	      compiler to perform better optimizations.

	      This option is often suitable for	 use  with  the	 -ifo  option,
	      which presents a group of source files to the compiler as a sin‐
	      gle compilation  unit.   Enables	runtime	 checking  of  certain
	      OpenMP  constructs.  This	 includes runtime detection of invalid
	      nesting and other invalid OpenMP cases. When invalid nesting  is
	      discovered  at  runtime  and  this option is set, the executable
	      will fail with a Trace/BPT trap. If this option is not  set  and
	      invalid  nesting	is  discovered,	 the behavior is indeterminate
	      (the executable may hang, and so on).  See also the -mp and -omp
	      options.	 Provides  a single method for turning on a collection
	      of optimizations for increased performance.

	      Note that the -fast option can  produce  different  results  for
	      floating-point arithmetic and math functions, although most pro‐
	      grams are not sensitive to these differences.

	      The -fast option defines the following compiler options and sym‐
	      bols  to	improve run-time performance. You can adjust the opti‐
	      mizations by  specifying	the  negation  of  any	given  option.
	      Directs  the  compiler  to assume the ANSI C aliasing rules, and
	      thus allows the optimizer to be more aggressive in its optimiza‐
	      tions.

	      See  the	description of this option elsewhere in this reference
	      page for more detailed information about this operation.	 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 func‐
	      tion prototype is present so the compiler can automatically per‐
	      form the expected type conversion.

	      See  the	description of this option elsewhere in this reference
	      page for more detailed information about this operation.	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 option elsewhere in this reference
	      page for more detailed information about this operation.	Speci‐
	      fies  that  this	is  a  strictly-conforming ANSI C program with
	      respect to  the  dereferencing  of  pointer-to-short  variables.
	      This  allows  the	 compiler  to  assume  that any short accessed
	      through a pointer	 is  naturally	aligned	 (as  the  C  language
	      requires).  It  typically	 produces  the	fastest	 code  but can
	      silently generate the wrong results if  any  such	 short	object
	      crosses a quadword boundary.

	      See  the	description of this option elsewhere in this reference
	      page for more detailed information about this  operation.	  This
	      option  affects  the  compilation	 of  a number of system header
	      files, causing them to compile #pragma intrinsic directives  for
	      certain	functions  that	 they  declare.	 The  exact  functions
	      affected may vary depending on the language mode and other macro
	      definitions.  See	 the  header  files math.h, stdio.h, stdlib.h,
	      string.h, and strings.h for details. The exact  effect  of  each
	      #pragma  intrinsic  varies by function, by optimization options,
	      and by other compile-time	 options.   The	 basic	effect	is  to
	      inform the compiler that the function specified in the pragma is
	      the one by that name whose behavior is  known  to	 the  compiler
	      (that  is,  it is a standard C or commonly-used library function
	      rather than a user-written external function).  This  gives  the
	      compiler	license	 to  perform additional checks on the usage of
	      the function and issue diagnostics, and to optimize  and/or  re‐
	      write  calls to it based on the compiler's understanding of what
	      the function does. Some possible optimizations include  generat‐
	      ing  complete  inline  code, generating partial inline code with
	      calls to one or more different functions, or just using  charac‐
	      teristics of the function to move the call site or avoid some of
	      the overhead triggered by an external call.  This option affects
	      the compilation of stdio.h in two ways: Whenever the header file
	      would otherwise define getc  and	putc  as  preprocessor	macros
	      expanding	 into  code to access the _cnt and _ptr members of the
	      referenced  FILE	object	directly,  instead  these  macros  are
	      defined to invoke inlined static functions defined in the header
	      file. The use of an inlined static function instead of a	simple
	      macro  prevents the argument from being evaluated more than once
	      (so arguments containing side effects do not cause  a  problem),
	      and  the	function generally will produce better code because it
	      uses local declarations to avoid aliasing assumptions  that  the
	      compiler has to make when analyzing the traditional macro expan‐
	      sions of getc and putc. Note that getc and putc are not expanded
	      inline when i/o locking is required, as is normally the case for
	      reentrant or thread-safe	compilations.	If  -D_INTRINSICS  was
	      also  specified,	making printf and fprintf intrinsic functions,
	      then certain of the low-level runtime support routines that  may
	      be  called  for  special	cases of format strings are defined as
	      inline static functions in the header  file,  avoiding  external
	      calls to these routines in libc.	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 accu‐
	      rate functions are used. The fast math routines do  not  support
	      IEEE  exceptional	 behavior.   Tells the compiler that it is not
	      necessary to promote expressions of type float to type double.

	      See the description of this option elsewhere in  this  reference
	      page for more detailed information about this operation.	Allows
	      floating-point operations to be reordered during optimization.

	      See the description of this option elsewhere in  this  reference
	      page  for	 more detailed information about this operation.  Per‐
	      forms inter-file optimizations, but only if more than  one  file
	      is specified on the command line.

	      See  the	description of this option elsewhere in this reference
	      page for more detailed information about this  operation.	  Con‐
	      trols  whether  the  compiler  recognizes	 certain  functions as
	      intrinsic functions.

	      See the description of this option elsewhere in  this  reference
	      page  for	 more detailed information about this operation.  Sets
	      the optimization level.

	      See the description of this option elsewhere in  this  reference
	      page  for more detailed information about this operation.	 Makes
	      string literals read-only for improved performance.

	      See the description of this option elsewhere in  this  reference
	      page for more detailed information about this operation.	Speci‐
	      fies that the compiler should use the profile  information  con‐
	      tained in file when performing optimizations.

	      There are two forms of this option. One form is selected if file
	      is a data file, typically	 produced  by  prof  after  running  a
	      pixie-instrumented  version  of  the  program. The other form is
	      selected if file is an executable program file.	The  -feedback
	      option  automatically  determines whether file is a data file or
	      an executable file and processes it accordingly.

	      If file is a data file, the -feedback option uses	 the  data  in
	      file  to guide the compiler optimizer (and cord if -cord is also
	      specified). The -g1 debug level is recommended  here  in	either
	      case.

	      If  file	is  an	executable file, the -feedback option uses the
	      data in file to guide  the  compiler  optimizer  (and  spike  if
	      -spike is also specified). If file does not exist, this compila‐
	      tion step prepares it to receive profiling data in  the  future.
	      See  Spike and Profile-Directed Optimization in the Programmer's
	      Guide for details. The compiler defaults to the -g1 debug	 level
	      here,  overriding any explicit -g0, but honoring any -g, -g2, or
	      -g3 option.

	      While both the cord and spike post-link optimizers reorder  pro‐
	      cedures  to  reduce  cache  thrashing,  spike  is typically more
	      effective. When employing both -feedback and spike, use the sec‐
	      ond  (executable)	 form  of file, which allows both the compiler
	      and spike to use data derived from  a  single  profile  training
	      run.  Specifies whether certain code transformations that affect
	      floating-point operations are allowed.  These changes can affect
	      the accuracy of the program's results.

	      The  -nofp_reorder  option, the default, directs the compiler to
	      use only certain scalar rules for calculations. This setting can
	      prevent  some  optimizations.  The  -fp_reorder option frees the
	      compiler to reorder floating-point operations based on algebraic
	      identities  (inverses,  associativity,  and  distribution).  For
	      instance, this allows the compiler  to  move  divide  operations
	      outside of loops, thus improving performance.

	      If  you  specify	-fp_reorder  and the compiler reorders code to
	      improve performance, the results can differ  from	 the  default,
	      for  example,  due  to the way intermediate results are rounded.
	      However, the -fp_reorder	results	 are  not  categorically  less
	      accurate	than  those  gained  by the default.  Provide improved
	      optimization  (inter-file	 optimization)	and  code   generation
	      across  file  boundaries that would not be possible if the files
	      were compiled separately.

	      When you specify -ifo on the command line in conjunction with  a
	      series of file specifications, the compiler does not concatenate
	      each of the  specified  source  files.  Instead,	each  file  is
	      treated separately for purposes of parsing, except that the com‐
	      piler will issue diagnostics about conflicting external declara‐
	      tions  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.  Specifies whether to provide inline expansion  of
	      functions.  This is the default for -O2, -O3, -O4. The -noinline
	      option disables this optimization.

	      When choosing calls to expand inline, the compiler also  consid‐
	      ers  the function size, how often the call is executed, how many
	      registers the inline expansion will require, and other factors.

	      You can specify one of the following as the keyword  to  control
	      inlining:	 No  inlining  is done, even if requested by a #pragma
	      inline preprocessor directive.  This is the default when compil‐
	      ing  with	 the  -O0  option.   Inlines only those function calls
	      explicitly requested for inlining by a #pragma inline directive.
	      This is the default when compiling with the -O1 option.  Inlines
	      all of the function calls in the manual category, plus any addi‐
	      tional 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
	      option.  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  signifi‐
	      cantly  increase	the  size  of the program.  Inlines every call
	      that can be inlined while still generating correct code.	Recur‐
	      sive  routines, however, will not cause an infinite loop at com‐
	      pile time.

	      For optimization level 0 (-O0), the -inline  option  is  ignored
	      and  no  inlining	 is  done.  The	 #pragma noinline preprocessor
	      directive can  also  prevent  inlining  of  any  function.   The
	      -intrinsics  option  causes  the compiler to recognize intrinsic
	      functions wherever it can automatically, based only on name  and
	      call  signature.	Unlike	-D_INTRINSICS,	this  option can treat
	      library function calls as intrinsic even	when  the  appropriate
	      header  file  is	not included. Any function declaration or call
	      site (in the case of implicit declaration) with a name  matching
	      the  name	 of  an	 intrinsic  function is examined to see if its
	      parameters and return result are consistent with	the  intrinsic
	      function of that name. If so, calls are treated as being intrin‐
	      sic. If not, a diagnostic is issued and  calls  are  treated  as
	      ordinary external function calls.

	      When  the	 compiler  identifies a function as an intrinsic func‐
	      tion, it is then free to make  code  optimizations  (transforma‐
	      tions)  based on what it knows about the operations performed by
	      the standardized version of that function--given an optimization
	      level (-On) that enables the intrinsic treatment of that partic‐
	      ular function.

	      The optimization level determines which functions can be treated
	      as  intrinsics:  No  intrinsic functions. The -intrinsics option
	      has no effect at this optimization  level.   Memory  and	string
	      functions:  alloca,  bcopy, bzero, memcpy, memmove, memset, str‐
	      cpy, strlen

	      Math functions: abs, fabs, labs,	atan,  atan2,  atan2f,	atand,
	      atand2, atanf, ceil, ceilf, cos, cosd, cosf, floor, floorf, sin,
	      sind, sinf.  fprintf, printf,  snprintf,	sprintf	 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 cumulative;
	      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	option is in effect by default. To disable the
	      default,	specify	 the  -nointrinsics  option.  To  disable  the
	      intrinsic	 treatment  of individual functions, specify the func‐
	      tion names in a pragma function directive in either your	source
	      code  or	a  file	 associated  with a -FI option (“file include”
	      option).

	      Although -intrinsics is the default (and it will generally treat
	      calls to [f]printf as intrinsic), in order to have the low-level
	      support routines for intrinsic [f]printf inlined,	 the  compila‐
	      tion  must  include  and	also  specify  both  -D_INTRINSICS and
	      -D_INLINE_INTRINSICS on the command line.	 Causes	 the  compiler
	      to  recognize  an older form of parallel programming directives,
	      as well as OpenMP directives, and pass libots3  and  appropriate
	      thread  libraries	 to  the  linker. It also predefines the macro
	      _OPENMP with a value of 0. Programs may use both forms of direc‐
	      tives  if they are in sections of code that do not interact with
	      each other -- the purpose being to ease migration from the older
	      form  to	OpenMP.	 See  also  the	 -omp  and -check_omp options.
	      Determines the level of optimization. The following table	 lists
	      the types of optimizations that can be performed at each level:

	      ────────────────────────────────────────────────────────────────────────
	      Level		  Optimization
	      ────────────────────────────────────────────────────────────────────────
	      -O0		  None
	      -O1		  Local	 optimizations and recognition of common sub‐
				  expressions. Global optimizations,  including	 code
				  motion,  strength  reduction	and test replacement,
				  split lifetime analysis, and code scheduling.
	      -O2, -O		  Inline expansion of static  procedures.  Additional
				  global  optimizations	 that  improve	speed (at the
				  cost of extra code size), such as integer multipli‐
				  cation  and division expansion (using shifts), loop
				  unrolling,  and  code	 replication   to   eliminate
				  branches.
	      -O3		  Inline expansion of global procedures.
	      -O4		  Software pipelining using dependency analysis, vec‐
				  torization of some loops on 8-bit and	 16-bit	 data
				  (char and short), and insertion of NOP instructions
				  to improve scheduling.
	      ────────────────────────────────────────────────────────────────────────

	      If your application will be built into a shared  library,	 avoid
	      using  the -O3 and -O4 options, because these levels may inhibit
	      the ability to preempt symbols.  Also,  benchmarking  is	recom‐
	      mended  to determine if -O4 is better than -O3 for your particu‐
	      lar application, as this is  not	always	true.	Performs  code
	      optimization   after   linking,  including  nop  (no  operation)
	      removal, removal,	 and  reallocation  of	common	symbols.  This
	      option  also positions the $gp register so that the maximum num‐
	      ber of addresses fall in the $gp-accessible window. This	option
	      is  most	effective when used with the -non_shared option.  When
	      you specify -om by itself, you get the full  range  of  postlink
	      optimizations.  You  can	request	 a  particular optimization by
	      specifying -om followed by one of the following options: Removes
	      unused  entries after optimization, and then compresses the sec‐
	      tion.  Removes dead code	(unreachable  instructions)  generated
	      after  applying optimizations.  The section is not compressed by
	      this option.  Uses the pixie-produced information stored in  the
	      augmented	 executable  by	 means	of  the cc command's -feedback
	      option and the pixie (or prof) command's -update	option.	  Sets
	      the  size	 threshold  of “common” symbols. Every “common” symbol
	      whose size is less than or equal to num will be allocated	 close
	      to  each other. This option can be used to improve the probabil‐
	      ity that the symbol can be accessed directly from the $gp regis‐
	      ter.  (Normally,	om  tries  to  collect	all  “common”  symbols
	      together, not just symbols that conform  to  certain  size  con‐
	      straints.)   Uses	 the pixie-produced information in file.Counts
	      and file.Addrs to reorganize the instructions  to	 reduce	 cache
	      thrashing.   Turns off instruction scheduling.  Turns off align‐
	      ment of labels. Normally, the -om option will align the  targets
	      of  all  branches on quadword boundaries to improve loop perfor‐
	      mance.  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 pro‐
	      duced by a representative run of the program. The	 hot  segments
	      are  stored  near	 other parts of the program that are also exe‐
	      cuted 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-techre‐
	      ports@decwrl.dec.com, specifying help on the subject line. Then,
	      follow  the  instructions	 in  the  reply	 you receive to obtain
	      report number 94/1.  Causes the compiler to recognize the OpenMP
	      (http://www.openmp.org)  shared  memory parallel programming API
	      pragmas and pass libots3 and appropriate thread libraries to the
	      linker.  It  also	 predefines  the  macro _OPENMP with a nonzero
	      value.  Note that under this option, the older parallel program‐
	      ming  directives enabled by the -mp option are ignored. See also
	      the -mp and -check_omp options.  Supports symbol preemption on a
	      module-by-module	basis.	During	optimization, inlining is per‐
	      formed only on functions within a single compilation unit.  This
	      is  the  default	in the following cases: At optimization levels
	      -O3 and -O4.  When -ifo is used.	When the compilation  is  pro‐
	      ceeding directly to an a.out executable file, that is, when none
	      of the following options are specified on the command line:  -c,
	      -r, or -shared.

	      In  all  other cases, -preempt_symbol is the default.  Preserves
	      full symbol preemption; that is, supports symbol preemption on a
	      symbol-by-symbol	basis  within a module as well as between mod‐
	      ules. Restricts the optimizer so that calls to extern  functions
	      are ineligible for inline replacement.

	      The default taken for a compilation is either -preempt_symbol or
	      -preempt_module. See  the	 description  of  the  -preempt_module
	      option for details on the conditions that determine which option
	      is taken as the default.	Specifies that speculation  may	 occur
	      anywhere in the executable image.

	      Speculation  is a compiler optimization that causes the hardware
	      to begin executing an operation before it	 determines  that  the
	      flow  of control will actually reach that operation. If the flow
	      of control does reach that operation, the result will be	avail‐
	      able  sooner  than it would have been without speculative execu‐
	      tion. If the flow of control does not reach that operation,  the
	      result will simply be ignored.

	      Since  unsuccessful  speculative	operations can generate excep‐
	      tions, all exceptions are dismissed when any  module  that  con‐
	      tributes	to the application is compiled with the -speculate all
	      option (though floating-point instructions  specifying  software
	      completion  are  still  handled normally).  This optimization is
	      therefore inappropriate for codes that use  any  form  of	 local
	      exception handling (or is linked to other codes that do).	 Spec‐
	      ifies that speculation is allowed only in the code 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  mod‐
	      ules  that  do. The run-time system checks each exception to see
	      if it occurred in a speculative routine. It dismisses exceptions
	      from  routines  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 handling.) As a result, you	should
	      use  the	-speculate by_routine option 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 excep‐
	      tions, it may result in an overall performance loss. If this  is
	      so, you should discontinue use of this feature.

	      The  -speculate  by_routine option yields somewhat slower execu‐
	      tion than the -speculate all option, but does not restrict  trap
	      and  fault  handling  in	other modules with which it is linked.
	      Invokes the spike tool to perform code optimization after	 link‐
	      ing a program.  -spike is a replacement for -om and does similar
	      optimizations.  See spike(1) for	complete  information  on  the
	      spike  command,  its  options,  and  its relationship to -spike.
	      -spike is particularly useful with -feedback. All of  the	 spike
	      command's	 options can be passed directly to -spike by using the
	      -WS compiler option. The following example shows the  syntax:  %
	      cc -spike -feedback prog -o prog *.c \
		   -WS,-splitThresh,.999,-noaggressiveAlign

	      For detailed examples using the -spike option and spike command,
	      see spike(1) and the Programmer's Guide.	 Instructs  the	 opti‐
	      mizer  to	 tune  the  application	 for a specific version of the
	      Alpha hardware. This will not prevent the application from  run‐
	      ning  correctly  on  other versions of Alpha but it may run more
	      slowly than generically-tuned code on those versions.

	      The option argument can be one of the following,	which  selects
	      instruction  tuning appropriate for the listed processor(s): All
	      Alpha processors.	 This is the default.  The processor on	 which
	      the  code is compiled.  The 21064, 21064A, and 21068 processors.
	      The 21164 processor.  (Both EV5 and EV56	are  numbered  21164.)
	      The 21264 processor.  The 21264A processor.  The 21164PC proces‐
	      sor.

	      See also the -arch option for an explanation of the  differences
	      between  -tune and -arch.	 Controls the loop-unrolling optimiza‐
	      tion (available only at  levels  -O2  and	 higher).   -unroll  n
	      allows  the  compiler  to unroll loops up to n times.  -unroll 1
	      disables the optimization.  -unroll 0 (the default)  allows  the
	      compiler to decide what is best.

   Feedback-directed Optimization Options
       Generates  accurate profile information to be used with -feedback opti‐
       mizations, as follows: Compile the source code with  the	 -gen_feedback
       option.	 Run  pixie on the executable file.  Execute the pixie version
       of the program to generate execution statistics on  the	program.   Use
       prof  to	 create a feedback file from the execution statistics.	Recom‐
       pile the program with the -feedback option and optimization  level  -O1
       or  above.  This	 provides the compiler with execution information that
       the compiler can use to improve certain	optimizations.	 Generates  an
       executable image that has profiling code added to it. Using this option
       is equivalent to running the pixie command on an	 existing  image.  The
       pixie-instrumented  file	 is  called a.out (or as specified with the -o
       option). The uninstrumented file	 is  given  an	extension  of  of  the
       -prof_use_om_feedback,  -prof_dir, and -pids options.  Generates a non-
       optimized executable image that, when run, will generate profiling data
       that  the  compiler  can	 use to improve its optimization choices (with
       -prof_use_feedback).

	      This  switch  is	equivalent  to	 the   combination   -prof_gen
	      -gen_feedback  and  does not require the direct use of the pixie
	      or prof tools or the -feedback option. It is the simplest way to
	      use feedback-directed compiler optimization.

	      The  recommended	usage  is  as follows: Compile the source code
	      with -prof_gen_noopt.  Run the program.	Recompile  the	source
	      code with -prof_use_feedback.

	      For  more	 information, see pixie(5) and prof(1), and -prof_gen,
	      -gen_feedback, and  -prof_use_feedback.  For  information	 about
	      manipulating  the	 name and location of the feedback data files,
	      see -pids and prof_dir.  Uses profiling feedback to improve com‐
	      piler optimization. Using this option is equivalent to using the
	      prof(1) command to produce a feedback file, and then  using  the
	      cc -feedback command to recompile the program.

	      To use the -prof_use_feedback option, first compile your program
	      with the -prof_gen and -gen_feedback options and	then  run  the
	      program  to  generate the needed profiling data.	Uses profiling
	      feedback to rearrange the resulting image to reduce  cache  con‐
	      flicts  of  the  program text. This option uses the -om postlink
	      optimizer, and is	 equivalent  to	 using	the  -om  -WL,-om_ire‐
	      org_feedback  options.  If  the  -pids option is also specified,
	      this option merges the performance data  files  using  the  prof
	      -pixie -merge command.

	      To use the -prof_use_om_feedback option, first compile your pro‐
	      gram with the -prof_gen option and then run the program to  gen‐
	      erate  the  profiling  data.   Specifies a location to which the
	      profiling data files  (.Counts  and  -prof_gen  option  and  the
	      -prof_use_feedback  or -prof_use_om_feedback option to specify a
	      location for the profiling data files. If	 you  do  not  specify
	      this  option,  the  profiling  files  are written to the current
	      directory.

	      Specifying the -prof_dir option also enables the	-pids  option.
	      [Disables]  or  enables  the  addition  of the process-id to the
	      filename of the basic block counts file (.Counts). This  facili‐
	      tates  collecting	 information  from multiple invocations of the
	      pixie output file. Unless the -prof_dir option is specified, the
	      default is -nopids.

   Source-code Debugging Options
       Produces symbol table information for debugging. When no value is spec‐
       ified for n, the compiler produces symbol table	information  for  full
       symbolic	 debugging  and	 suppresses optimizations that limit full sym‐
       bolic debugging (same as -g2).

	      The value of n can be one of the following (-g is	 the  same  as
	      -g2): 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 proce‐
	      dure traceback  and  all	instruction-level  commands.  However,
	      line-oriented  commands  do not work. No symbol types are avail‐
	      able, and the names of stack-frame and static variables are  not
	      available.   All	optimizations are supported.  Produces limited
	      symbol table information. Profiling and debugging tools  provide
	      line  numbers,  source file names, and the names of local proce‐
	      dures, when appropriate. Line-oriented debugging commands	 work,
	      but  symbol types and the names of stack-frame variables are not
	      available. Most profiling tools work to their  fullest  ability,
	      but  some	 advanced  Atom	 tools may provide more information at
	      higher debug levels.  All optimizations are supported.  Produces
	      symbol  table  information  for full symbolic debugging and sup‐
	      presses some optimizations. Symbol types and  stack-frame	 vari‐
	      ables  names  are	 available.  Optimization  is  suppressed (-g2
	      implies -O0).  Produces symbol table information for fully opti‐
	      mized  code.  This level of debugging supplies the same informa‐
	      tion 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 Options
       Determines the level of profiling. The -p option prepares for profiling
       by  periodically sampling the value of the program counter. This option
       affects linking only, so that when linking occurs,  the	standard  run-
       time startup routine is replaced by the profiling run-time startup rou‐
       tine (mcrt0.o) and  the	level  1  profiling  library  (libprof1.a)  is
       searched.  When you use the -p option together with either the -pthread
       option or the -threads option, the profiling  library  libprof1_r.a  is
       used.

	      When profiling begins, the startup routine calls monstartup (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: Do not permit any pro‐
	      filing.  This is the default. If linking	occurs,	 the  standard
	      run-time	startup	 routine  (crt0.o)  is	used, and no profiling
	      library is searched.  Same as -p.	 Turns gprof profiling	on  or
	      off  when	 compiling  and linking the file immediately following
	      this option. The gprof profiler produces a  call	graph  showing
	      the execution of a C program.

	      When  this  option  is  turned on, the standard run-time startup
	      routine is replaced by the gcrt0.o routine.  Programs  that  are
	      linked  with  the	 -pg option 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 option together with	either	the  -pthread  option  or  the
	      -threads option, the profiling library libprof1_r.a is used.

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

   Data Alignment Options
       Controls the alignment assumptions for code generated for indirect load
       and store instructions.

	      The -assume aligned_objects option 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  sys‐
	      tems, dereferencing 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 option causes the compiler to gen‐
	      erate  longer  code sequences to perform indirect load and store
	      operations in order to avoid hardware alignment faults for arbi‐
	      trarily	  aligned    addresses.	    Although	the    -assume
	      noaligned_objects option may generate 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 option is the default. The compiler
	      assumes that the alignment of pointers meets or exceeds that  of
	      the  objects  to	which they point. The following rules apply: 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 speci‐
	      fied #pragma nomember_alignment for struct).

	      If  your	module	breaks	one  of	 these rules, you must use the
	      -assume noaligned_objects option to compile the  module;	other‐
	      wise,  your  program  may get alignment faults during execution,
	      which will degrade performance.

	      The  -assume  aligned_objects  and   -assume   noaligned_objects
	      options can be used in the same cc command, allowing you to turn
	      this option on and off as needed by individual source files.

	      The -misalign option is a synonym for -assume  noaligned_objects
	      and   the	  -nomisalign	option	 is   a	 synonym  for  -assume
	      aligned_objects.	Controls whether the compiler can assume  that
	      this is a strictly-conforming ANSI C program with respect to the
	      dereferencing of pointer-to-short variables.

	      Specifying -assume trusted_short_alignment allows	 the  compiler
	      to  assume  that	any short object accessed through a pointer is
	      naturally aligned. This may produce the  fastest	code  but  can
	      silently	generate  the  wrong  results if any such short object
	      crosses a quadword boundary.

	      Specifying -assume notrusted_short_alignment tells the  compiler
	      that dereferenced short objects may not be naturally aligned (as
	      both ANSI C and K&R C require). This may produce slightly slower
	      code,  but that code will produce the correct results regardless
	      of data alignment. This is the default.

	      Note that -assume notrusted_short_alignment  does	 not  override
	      the  __unaligned	type  qualifier,  the -misalign option, or the
	      -assume  noaligned_objects  option.   Controls  the   compiler's
	      alignment	 assumptions  for code generated for indirect load and
	      store instructions.

	      The -misalign option is a synonym for -assume  noaligned_objects
	      and   the	  -nomisalign	option	 is   a	 synonym  for  -assume
	      aligned_objects. The -assume [no]aligned_objects option is  dis‐
	      cussed  earlier in this reference page.  Directs the compiler to
	      byte-align data structure members (with the  exception  of  bit-
	      field members).

	      By default, data structure members are aligned on natural bound‐
	      aries (that is, on the next boundary appropriate to the type  of
	      the  member) instead of the next byte. For example, an int vari‐
	      able 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_align‐
	      ment, or #pragma pack directives within the  source  code	 over‐
	      rides the setting established by this option.

	      The  use	of  the -nomember_alignment option can cause conflicts
	      between the compiler's assumptions about 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.  Aligns structure members and entire struc‐
	      tures based on the integer n, where n can be 1, 2, 4, or 8. This
	      option  sets a limit on the alignment given to structure members
	      so that each member after the first is stored on a maximum of an
	      n-byte  boundary. For example, a 4-byte int member is aligned on
	      a 4-byte boundary under either -Zp8 or -Zp4. But under  -Zp2  it
	      is aligned to the next 2-byte boundary, and under -Zp1 it begins
	      at the next byte (that is, it is unaligned).  -Zp is  equivalent
	      to -Zp1.

	      This  option  can also affect the alignment of the entire struc‐
	      ture, which is computed by  default  as  the  maximum  alignment
	      requirement  of  any of its members. For example, if a structure
	      contains an 8-byte pointer followed by a 4-byte int, the	entire
	      structure	 is  assumed  to  be  8-byte  aligned and padded to 16
	      bytes, by default (effectively -Zp8).  Therefore, in an array of
	      such structures each array element starts on an 8-byte boundary.
	      Under -Zp4, the  layout  of  members  within  the	 structure  is
	      unchanged	 (the  pointer	is still at offset 0 and the int is at
	      offset 8), but now the entire structure is assumed  to  be  only
	      4-byte  aligned, and there is no padding added after the int, so
	      the size of the entire structure is only 12 bytes.

	      The use of the -Zpn option  (where  n!=8)	 can  cause  conflicts
	      between  the  compiler's	assumptions about 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.

   Data Volatility Options
       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	option	allows
       byte  and  word	access	of  data  at byte granularity. 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.	 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. This is the default.

	      The  -weak_volatile option 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 performed in a multithreaded
	      environment (for example, two volatile shorts stored in a	 long‐
	      word and accessed asynchronously).

   C Language Options
       Promotes	 expressions of type float to double. This is the default when
       -std0 is used.  Prevents the compiler  from  promoting  expressions  of
       type  float  to	type double. This is the default except in -std0 mode.
       Causes the compiler to assign the type float (rather  than  double)  to
       floating-point  constants  if their values can be represented in single
       precision. This option is not available in -std1 mode.  Allows the com‐
       piler  to  assume  that string literals are read-only. This may improve
       application performance. This option overrides -writable_strings, which
       is the default.

	      Attempting  to  modify string literals when -readonly_strings is
	      specified may yield unpredictable results (for example,  a  seg‐
	      mentation fault).	 Causes all char declarations to have the same
	      representation and range of values as signed char	 declarations.
	      This  is	used  to override a previous -unsigned option. This is
	      the default.  Causes all char declarations to have the same rep‐
	      resentation  and	range of values as unsigned char declarations.
	      Prints warnings for all lines that may require  the  <varargs.h>
	      macros.  Causes all variables to be treated as volatile.	Causes
	      all string literals to be writable. This is the default.

	      This option overrides -readonly_strings.

   Stack-handling and Pointer-handling Options
       Forces  all  uninitialized  stack  variables  to	 be  initialized  with
       0xfff58005fff58005.  When  this value is used as a floating-point vari‐
       able, it is treated as a floating-point NaN and causes a floating-point
       trap.  When  it is used as a pointer, an address or segmentation viola‐
       tion  usually  occurs.	Causes	the  compiler	to   respect   #pragma
       pointer_size  directives,  which	 control  the  size of pointers. These
       directives are ignored otherwise. Also causes the -taso	option	to  be
       passed to the linker (if linking).

	      Pointers	are 64 bits by default. This option, when used in con‐
	      juction with the pointer_size pragmas,  allows  applications  to
	      use  32-bit  pointers.  Images  built  with  this option must be
	      linked with the -taso option in order to run correctly. See  the
	      Programmer's  Guide  for	information  on	 #pragma pointer_size.
	      Same as the -xtaso option, except -xtaso_short also directs  the
	      compiler	to  allocate 32-bit pointers by default. You can still
	      use 64-bit pointers, but only by the use of  pointer_size	 prag‐
	      mas.

	      The  use	of the -xtaso_short option 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.  Makes all procedures in
	      the source file use $fp (register 15) as the frame pointer.

   IEEE Floating-point Support Options
       Specifies chopped rounding mode (round toward zero).  Dynamically  sets
       rounding	 mode for IEEE floating-point instructions. The dynamic round‐
       ing mode is determined from the contents of the floating-point  control
       register	 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	float‐
       ing-point rounding mode defaults to round to nearest.  Specifies normal
       rounding mode (unbiased round to nearest). This is the default.	Speci‐
       fies  round toward minus infinity mode.	Generates instructions that do
       not trigger floating-point underflow or	inexact	 trapping  modes.  Any
       floating	 point	overflow,  divide-by-zero,  or	invalid operation will
       unconditionally generate a trap. The -fptm n  option  is	 the  default.
       Generates  traps	 on  floating-point  underflow	as  well  as overflow,
       divide-by-zero, and invalid operation.  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  num‐
       bers, NaNs, and infinities and the handling of error cases. This option
       also sets the _IEEE_FP C preprocessor macro.

	      If your program must use IEEE signaling features	that  are  not
	      portable	across different IEEE implementations, see the ieee(3)
	      reference page for a discussion of how to access them under  the
	      Tru64  UNIX  operating  system.	Ensures that any trap (such as
	      floating-point overflow) 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.

   Compiler Development Options (Not Generally Used)
       Halts compiling after the pass specified by the character c,  producing
       an  intermediate	 file for the next pass. The c character can be one of
       the following: [fablL] (see the	-t  option  for	 an  explanation).  It
       selects	the  compiler  pass  in the same way as the -t option. If this
       option 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 file is always	 retained  after  the  compilation  is
       halted.	 Passes	 the  argument,	 or  arguments (argi), to the compiler
       pass, or passes (c[c...]). Each c character can be one of  the  follow‐
       ing: [ ablLzpfy ] (see the -t option for an explanation). The c selects
       the compiler pass in the same way as the -t option.  The -t, -h, and -B
       options	are used together to specify a location and/or name for one or
       more compiler passes, tools, libraries, or include  files,  other  than
       their normal locations or names.

	      The  -t  option  specifies which compiler passes (or components)
	      the -h and -B options that follow apply to.   The	 c  characters
	      can be one or more of the following:

	      ────────────────────────────────────────────────────────────
	      Character	  Name of pass, tool, or component
	      ────────────────────────────────────────────────────────────
	      h		  header file location (see note following table)
	      p		  cpp
	      f		  gemc_cc
	      a		  as0
	      b		  as1
	      l		  ld

	      z		  cord
	      r		  [m]crt0.o
	      n		  libprof1.a
	      L		  om
	      C		  pixie
	      D		  prof
	      y		  ftoc
	      B		  bbtool
	      ────────────────────────────────────────────────────────────

					    Note

	      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_TAR‐
	      GET_ROOT/usr/include/string.  This directory is to  contain  the
	      header  files  for the string release of the compiler. The stan‐
	      dard directory is still searched.

	      If -t is not specified, the -h and -B options are applied to all
	      tools.

	      The -t and -h options are not processed until the next -B option
	      is processed. If more than one -t option or  more	 than  one  -h
	      option  appear  on  the  command line before the next -B option,
	      only the last of the previous -t and  -h	option	arguments  are
	      used.   Specifies	 the directory where the tool (or other compo‐
	      nent) specified with -t is located. If -h is omitted,  the  tool
	      is   assumed   to	  be  in  the  usual  location	(for  example,
	      /usr/lib/complrs/cc).  If path is omitted, the tool  is  assumed
	      to  be  in the root directory (/).  Specifies a suffix to add to
	      the normal names of any components specified with the -t option.
	      If  string  is  omitted,	the  usual  component  names are used.
	      Directs the compiler to give recognizable names to  intermediate
	      files  and  retain  them	for  debugging purposes.  Each file is
	      given the name of the last component of the source file, replac‐
	      ing its suffix with the conventional suffix for the type of file
	      (for example, suffix 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 option is specified, the base name of the files cre‐
	      ated 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.

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

       In the following example, the -t, -h, and -B options specify  that  the
       gemc_cc	 component   to	  be  used  by	the  compiler  is  located  in
       /usr/projects  and  has	the   name   gemc_cc.debugging:	  %   cc   -tf
       -h/usr/projects -B.debugging prog1.c

DESCRIPTION
       The  cc command invokes the C compiler. It accepts any of the following
       file arguments: Arguments whose names end with  are  assumed  to	 be  C
       source  programs. They are compiled, and each object program is left in
       a file whose name consists of the last component	 of  the  source  with
       substituted  for	 file  is deleted only when a single source program is
       compiled and loaded all at once.	 Arguments whose names	end  with  are
       assumed	to  be	symbolic  assembly  language source programs. They are
       assembled, producing a  file.   Arguments  whose	 names	end  with  are
       assumed	to be C source files after being processed by the C preproces‐
       sor.  Arguments whose names do not end with are assumed to be either C-
       compatible  object  files,  typically produced by an earlier cc run, or
       libraries of C-compatible routines.

       The cc command accepts options that are specific to either the cc  com‐
       mand or the ld command (linker). When the compiler recognizes position-
       sensitive linker options (-L, -all, -exclude,  -exported_symbol,	 -hid‐
       den,  -hidden_symbol,  -l,  -none,  -non_hidden, -noarchive, -noso, and
       -so_archive), it maintains their relative order for  the	 linker.  This
       reference  page	describes the options that are specific to the cc com‐
       mand. See ld(1) for a description of the linker options.

       All of the input files, plus  the  results  of  the  compilations,  are
       loaded  in  the	order  given to produce an executable program with the
       default name a.out. The compiler can produce object files  in  extended
       COFF  format  (the  normal result). It can also produce object files in
       symbolic assembly language format when invoked with the -S option.

       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 reference these macros in  #ifdef  statements
       to  isolate  code that applies to a particular language or environment.
       Use the following  statement  to	 uniquely  identify  Tru64  UNIX:  #if
       defined (__digital__) && defined (__unix__)

       The  C 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 option
       ─────────────────────────────────────────────────────────────────
       __DECC		       .c
       __DECC_VER	       .c		  -std0, -std, -std1
       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
       _LONGLONG	       .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 option to control which
       functions are declared in header files and to obtain standards  confor‐
       mance  checking.	 See  standards(5)  for	 a list of the macro names and
       details on the function declarations and standards conformance checking
       associated with the various macros.

       While  the  -D  option  controls which functions are declared in header
       files, the -stdn options 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 option.

       To facilitate setting default  compiler	options,  you  can  create  an
       optional	 configuration	file named comp.config or an environment vari‐
       able named DEC_CC: The comp.config file allows system administrators to
       establish a set of compilation options that are applied to compilations
       on a system-wide basis. The compiler options  in	 comp.config  must  be
       specified  on  a single line, and the comp.config file should be stored
       in the compiler target directory, /usr/lib/cmplrs/cc.  The DEC_CC envi‐
       ronment	variable  allows  C  users  to	establish a set of compilation
       options that are applied to subsequent compilation on a per-user basis.

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

	      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 options are treated as prologue options by default.
	      Any vertical bar found after the first vertical bar  is  treated
	      as whitespace and a warning is issued.

       Compiler options are processed in the following order during a compila‐
       tion: comp.config prologue options DEC_CC prologue options command line
       options DEC_CC epilogue options comp.config epilogue options

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

EXAMPLES
       To compile the file helloworld.c using the compiler's defaults use  the
       following command: cc helloworld.c

	      Because  no output file is named in the command line, the result
	      of the compilation is  written  to  the  executable  file	 named
	      a.out.  In this example, the -v option displays the name of each
	      compilation pass--and its arguments--as it executes.  cc -v hel‐
	      loworld.c

	      /usr/lib/cmplrs/cc/gemc_cc -D__LANGUAGE_C__ -D__unix__ -D__osf__
	      -D__alpha -D_SYSTYPE_BSD -D_LONGLONG -D__digital__  -D__arch64__
	      -I/usr/include  -v  -preempt_module  -intrinsics	-g0  -O2  -std
	      -noansi_alias -o helloworld.o helloworld.c

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

	      -D__DECC	-D__osf__ -D__arch64__ -D__PRAGMA_ENVIRONMENT -D_LONG‐
	      LONG  -D__digital__   -D__X_FLOAT	  -D__DATE__="Sep    2	 1998"
	      -D__DECC_MODE_RELAXED    -D__DECC_VER=50860509	-D_SYSTYPE_BSD
	      -D__ALPHA	  -D__IEEE_FLOAT   -D__unix__	 -D__TIME__="10:34:23"
	      -D__Alpha_AXP  -D__INITIAL_POINTER_SIZE=0	 -D__STDC__=0 -D__LAN‐
	      GUAGE_C__ -D__alpha /usr/lib/cmplrs/cc/gemc_cc: 0.05u 0.02s 0:00
	      77%  0+10k  0+3io 0pf+0w 10stk+1288mem /usr/lib/cmplrs/cc/ld -g0
	      -O1  -call_shared	 /usr/lib/cmplrs/cc/crt0.o  helloworld.o   -lc
	      /usr/lib/cmplrs/cc/ld:  0.01u 0.01s 0:00 14% 0+11k 0+11io 0pf+0w
	      11stk+1288mem

ENVIRONMENT VARIABLES
       The following environment  variables  can  affect  compiler  operation:
       Allows  C  users	 to  establish	a  set of compilation options that are
       applied to subsequent compilation on a per-user basis. See the DESCRIP‐
       TION  section for more information.  The compiler driver uses the value
       of DRV_DUMP to control the display of internal messages. This  variable
       is  primarily used to diagnose the driver behavior.  If set, causes the
       compiler driver to display all the commands that would be invoked,  but
       to  not	actually execute those commands.  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.	If set
       to a non-empty string, this variable overrides  values  in  all	locale
       variables,  including  LANG.  Determines the locale for the interpreta‐
       tion of sequences of bytes of text data	as  characters	(for  example,
       single-	as  opposed  to	 multi-byte  characters in arguments and input
       files).	Determines the locale used for	diagnostic  messages.	Deter‐
       mines the locale of message catalogs for the processing of LC_MESSAGES.
       Provides a pathname that overrides the default directory for  temporary
       files, if any.

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

FILES
       Input file Object file Loaded output Temporary  Compiler	 configuration
       file  (optional) C macro preprocessor HP C compiler Post-link optimizer
       Symbolic to binary assembly language translator	Binary	assembly  lan‐
       guage  assembler and reorganizer Run-time startup Startup for prof pro‐
       filing Startup for gprof profiling Standard library, see intro(3) Level
       1  profiling  library Reentrant level 1 profiling library for code com‐
       piled with -pthread or -threads Standard	 directory  for	 header	 files
       Interface  between prof and cord Procedure-rearranger File produced for
       analysis by prof File produced for analysis by gprof

SEE ALSO
       as(1), atom(1), c89(1), cord(1), dbx(1), ftoc(1), gprof(1),  hiprof(5),
       ieee(3),	  ladebug(1),	ld(1),	monitor(3),  pixie(5),	prof(1),  pro‐
       tect_headers_setup(8), standards(5), third(5), what(1)

       ANSI X3.159-1989

       B. W. Kernighan and D. M. Ritchie, The C Programming Language

       B. W. Kernighan, Programming in C -- a tutorial

       D. M. Ritchie, C Reference Manual

       Programmer's Guide

       Assembly Language Programmer's Guide

       Compaq C Language Reference Manual

									 cc(1)
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server OSF1

List of man pages available for OSF1

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net