unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Page:
Section:
Apropos / Subsearch:
optional field



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


  -newc
      Invokes the compiler with	the default option settings shown in the
      SYNOPSIS section.	 This option is	provided to turn off -migrate, and it
      is the default.

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

  -std
      Selects the relaxed ANSI language	mode. This is the default. Enforces
      the ANSI C standard, but allows some common programming practices
      disallowed by the	standard.

      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	C reserved names are visible from the ANSI C header
      files, use the _ANSI_C_SOURCE macro. See standards(5) for	more details.

      This option sets the macro __STDC__ to 0.

  -std0
      Selects the K & R	language mode. Enforces	the K &	R programming style,
      with certain ANSI	extensions in areas where the K	& R behavior is	unde-
      fined or ambiguous. In general, -std0 compiles most pre-ANSI C programs
      and produces expected results.  The -std0	option leaves the __STDC__
      macro undefined.

  -std1
      Selects the strict ANSI language mode. Strictly enforces the ANSI	C
      standard and all its prohibitions	(such as those that apply to the han-
      dling of void types, the definition of lvalues in	expressions, the mix-
      ing 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	C reserved names are visible from the ANSI C header
      files, use the _ANSI_C_SOURCE macro. See standards(5) for	more details.

      This option sets the macro __STDC__ to 1.	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).

  -ms 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	pro-
      vides the	following extensions. Except for these extensions, the -ms
      option is	equivalent to -std. Thread Local Storage (TLS) and structured
      exception	handling are always enabled.

	+  Allow a declaration of an unnamed structure within another struc-
	   ture. 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 example:


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

	+  Allow declaration of	a structure with a trailing incomplete 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 exam-
	   ple:


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

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


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

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


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

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


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

	+  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 semi-
	   colons; that	is, allow completely empty declarations	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	iden-
	   tifier 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



  -common
      Selects the K & R	language mode. This option is equivalent to -std0.

  -traditional
      Selects the K & R	language mode. This option is equivalent to -std0.

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


  -accept option1[,option2,...]
      Causes the compiler to recognize additional keywords. The	following
      options are available:

      [no]vaxc_keywords
	  The default compilation mode on OpenVMS systems includes recogni-
	  tion of the following	keywords that are not available	on Tru64 UNIX
	  except in -vaxc mode:	_align,	globaldef, globalref, globalvalue,
	  noshare, readonly, variant_struct, and variant_union.	This option
	  causes these keywords	to be recognized. It may help in porting
	  applications from OpenVMS systems.

      [no]restrict_keyword
	  Cause	the compiler to	recognize the restrict keyword (from the C9X
	  review draft).

  -arch	option
      Specifies	which version of the Alpha architecture	to generate instruc-
      tions for. All Alpha processors implement	a core set of instructions
      and, in some cases, the following	extensions: BWX	(byte/word-
      manipulation extension), MVI (multimedia extension), FIX (square root
      and floating-point convert extension), 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:

      generic
	  Generate instructions	that are appropriate for all Alpha proces-
	  sors.	This option is the default.

      host
	  Generate instructions	for the	processor that the compiler is run-
	  ning on (for example,	EV6 instructions on an EV6 processor).

      ev4,ev5
	  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 emulation
	  overhead on any Alpha	processor.

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

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

	  Applications compiled	with this option may incur emulation overhead
	  on EV4 and EV5 processors.

      ev6 Generate instructions	for EV6	processors (21264 chips).

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

	  Applications compiled	with this option may incur emulation overhead
	  on EV4, EV5, EV56, and PCA56 processors.

      ev67
	  Generate instructions	for EV67 processors (21264A chips).

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

	  If your application uses CIX instructions, it	may incur emulation
	  overhead on all processors that are older than EV67.

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

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

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

      A	program	compiled with any of the options will run on any Alpha pro-
      cessor.  Beginning with DIGITAL UNIX V4.0	and continuing with subse-
      quent versions, the operating system kernel includes an instruction
      emulator.	This capability	allows any Alpha chip to execute and produce
      correct results from Alpha instructions--even if the some	of the
      instructions are not implemented on the chip. Applications using emu-
      lated instructions will run correctly, but may incur significant emula-
      tion overhead at run time.

      The psrinfo -v command can be used to determine which type of processor
      is installed on any given	Alpha 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 generate evx-specific instructions, but those are
	   always amask-guarded. That expands the code size but	avoids
	   instruction emulation.

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

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

  -[no]check_bounds
      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	com-
      putation even though the final result of the computation is within
      bounds. A	failed bounds check at runtime produces	a Trace/BPT trap,
      which may	be caught by signal(SIGTRAP, handler). See the Programmer's
      Guide for	more details.

      The -nocheck_bounds option (the default) disables	the runtime checking
      of array bounds.

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

      The n argument specifies the number of times a compilation can be
      interrupted in this way. If no number is specified, the compile-edit-
      compile cycle repeats indefinitely until all errors are corrected.  The
      -edit0 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.

  -[no]error_limit nn
      Sets a limit on the number of error-level	diagnostics that the compiler
      will emit. The default is	30.

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

  -granularity size
      Controls the size	of shared data in memory that can be safely accessed
      from different threads. The possible size	values are byte, longword,
      and quadword.

      Specifying byte allows single bytes to be	accessed from different
      threads sharing data in memory without corrupting	surrounding 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 memory.  Access-
      ing 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 memory.  Access-
      ing 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.

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

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

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

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

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

  -o output
      Names the	final output file output.

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

      The keywords for the -protect_headers option are as follows:

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

      none
	  Disables the protect headers feature.	This is	the default if the
	  file being compiled is a non-C source	file.

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

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

  -show	keyword[,keyword,...]
      Specifies	one or more items to be	included in the	listing	file. When
      specifying multiple keywords, separate them by commas and	no interven-
      ing 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:

      none
	  Turns	off all	show options.

      all Turns	on all show options.

      [no]brief
	  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.

      [no]cross_reference
	  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 numbers that span included	files, and appear just before
	  the text of each source line in the source listing.  When appropri-
	  ate, the line	number designating a reference to a symbol is anno-
	  tated	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
	   . Member selection (no indirection)
	   [] Subscripted (that	is, using [] syntax)
	   b Invoked as	a builtin function

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

      [no]header
	  Produces header lines	at the top of each page	of listing.

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

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

      [no]statistics
	  Places compile-time performance statistics in	the program listing.

      [no]symbols
	  Same as [no]brief, except that unreferenced macros and symbols are
	  not suppressed.

      If you specify -source_listing but do not	specify	-show keywords,	the
      compiler includes	header lines and source	statements in the program
      listing (-show header,source).

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

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

  -V  Prints the version of the	compiler driver.

  Compiler Diagnostic Controls Options


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

	  The -check option is equivalent to -msg_enable level5. The cc
	  driver converts -check into -msg_enable level5 (the -v option	noti-
	  fies you of this transformation).

  -msg_dump
	  Causes the compiler to dump, to stdout, all messages enabled by any
	  given	cc command line. The compiler then exits, without doing	a
	  compilation.

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

	  The -msg_actiontype option has eight different forms,	each result-
	  ing in a different action that changes the status, severity, or
	  frequency that will be applied to the	messages identified by the
	  msg_list argument. The following message-control options are sup-
	  ported:

	  -msg_enable
	      Enable a specific	message	or group of messages.

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

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

	  -msg_once
	      Emit the identified messages only	once.

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

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

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

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

	  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 lev-
	  els, and disabling a level also disables all higher levels. For
	  example, disabling level 3 messages disables levels 3	- 6. Opera-
	  tions	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:

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

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

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

	  level2
	      Moderately important messages. Level 2 is	the default for	DIGI-
	      TAL UNIX V4.0E and later (Tru64 UNIX) versions.

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

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

	  level5
	      Less useful -check and -portable messages	than the messages
	      associated with level 4. The -check option is equivalent to
	      -msg_enable level5.

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

	  Message Groups:

	  64bit
	      Messages reporting code or practices that	may have unintended
	      consequences on 64-bit architectures.

	  alignment
	      Messages reporting unusual or inefficient	data alignment.

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

	  check
	      Messages reporting code or practices that, although 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).

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

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

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

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

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

	  portable
	      Messages reporting the use of language extensions	or other con-
	      structs that might not be	portable to other compilers or plat-
	      forms.  -msg_enable portable is equivalent to -portable.

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

	  questcode
	      Messages reporting questionable coding practices.	Similar	to
	      check, but messages in this group	are more likely	to indicate a
	      programming error, not just a non-robust style.

	  returnchecks
	      Messages relating	to function return values.

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

  -portable
	  Directs the compiler to issue	diagnostics for	certain	constructs
	  that may not be portable to other compilers or platforms.  -port-
	  able is equivalent to	-msg_enable portable.

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

	  The default is -SD/usr/include.

	  Specifying -SD without a directory string cancels the	effect of any
	  previous -SD 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	provides mes-
	  sage suppression in the file __DECC_include_prologue.h.)

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

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

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

	  1   Suppresses warning and informational messages and	displays
	      error and	fatal messages.	This is	equivalent to specifying -w.

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

	  3   Does not print warning messages.	However, when warnings occur,
	      exits with nonzero status.

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









  C Preprocessor Options


  -C  Passes all comments directly to the preprocessor output, except com-
      ments on preprocessor directive lines.

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

      -cpp is the default.

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

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

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

	+  If the #include "filename" form of the directive is used, the C
	   macro preprocessor searches for the file first in the directory in
	   which it found the file that	contains the directive,	then in	the
	   search path indicated by the	-I option, and finally in the stan-
	   dard	directory, /usr/include.

	+  If the #include <&lt;filename>&gt; form of the directive is used, the
	   preprocessor	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.

  -M  Outputs a	set of make dependency rules to	standard output	for each
      source file on the command line (and suppresses compilation). 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.

  -MD 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
      information, see cpp(1) and ld(1).

  -nocurrent_include
      Changes the behavior of the #include "filename" directive	to not search
      the source file's	directory for filename.	This option causes the
      #include "filename" directives to	behave like #include <&lt;filename>&gt;
      directives. This option allows makefiles to control the search order
      for header files by using	-I options.

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

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

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

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

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

  -Uname
      Removes any 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


  -call_shared
      Produces a dynamic executable file that uses shareable objects during
      run time.	This is	the default.  The loader uses shareable	objects	to
      resolve undefined	symbols. The run-time loader (/sbin/loader) is
      invoked to bring in all required shareable objects and to	resolve	any
      symbols that remained undefined during static link time.

  -compress
      Passes the -compress 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 pro-
      duced in compressed object file format, resulting	in a substantially
      smaller object file.

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

  -expect_unresolved pattern
      Causes any unresolved symbols matching pattern to	be ignored. Such sym-
      bols 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).

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

  -fini	symbol
      Makes the	procedure represented by the symbol into a termination rou-
      tine.  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.

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

  -input_to_ld filename
      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 continuation
      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.

  -noarchive
      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 vari-
      ables that follow	it on the command line.	This option can	also be	used
      more than	once on	the command line.

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

  -pthread
      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.1c-conformant DECthreads inter-
      faces in libpthread when linking the program. This option	also defines
      the _REENTRANT macro.

  -shared
      Produces dynamic shareable objects. The loader will produce a shareable
      object that other	dynamic	executables can	use at run time.

      The following options are	used with -shared:

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

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

	  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.

      -set_version version-string
	  Establishes the version identifier (or identifiers) associated with
	  a shared library. The	string version-string is either	a single ver-
	  sion 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 con-
	  ventions be followed.

	  If a shared library is built with this option, any executable	built
	  against it will record a dependency on the specified version or, if
	  a list of version identifiers	is specified, the rightmost version
	  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.

      -soname shared_object_name
	  Sets DT_SONAME for a shared object. The name can be a	single com-
	  ponent 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.

      -update_registry location_file
	  Registers the	location of this shared	object's segments and makes
	  sure they stay out of	the way	of others in the location_file.
	  Location_file	is updated if it is writable.

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

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


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

      The 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 ver-
      sions 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 generation 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.

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

      Specifying -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 func-
      tion prototypes at all call sites.

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

  -assume [no]array_parameter_restricted_pointers
      Specifies	the assumption that all	array parameters are or	are not	res-
      tricted. The default is -assume noarray_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_parameter_restricted_pointers, p1 and
	   p2 are restricted.

	+  If you specify -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 prefixing	a no
      to the assumption	name. By default, all of the assumptions 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 determined	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 key-
      word from	all pointers. This can help detect inappropriate use of
      __restrict. If the code works correctly at high optimization with
      __restrict turned	off, but breaks	with it	turned on, it is likely	that
      the compiler encountered a pointer that was restricted in	error. Res-
      tricted pointers are an assertion	by the programmer to aid optimiza-
      tion; the	compiler cannot	detect erroneous assertions.

  -assume [no]ignore_restricted_pointers
      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.

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

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

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

  -assume [no]parameter_restricted_pointers
      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_pointers.

  -assume [no]restricted_pointers
      Specifies	the assumption that all	pointers are or	are not	restricted.
      The default is -assume norestricted_pointers. For	more information, see
      -assume [no]array_parameter_restricted_pointers.

  -assume whole_program
      Specifies	that no	occurrences of the address-of operator (&&amp;) are being
      applied outside the current compilation unit to extern variables that
      are declared inside the current compilation unit.	 Making	this asser-
      tion 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 single compila-
      tion unit.

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

  -fast
      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 programs are not
      sensitive	to these differences.

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

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

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

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

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

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

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

      -assume trusted_short_alignment
	  Specifies 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	typi-
	  cally	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.

      -D_INTRINSICS
	  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 defini-
	  tions. See the header	files math.h, stdio.h, stdlib.h, string.h,
	  and strings.h	for details. The exact effect of each #pragma intrin-
	  sic 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 diagnos-
	  tics,	and to optimize	and/or rewrite calls to	it based on the
	  compiler's understanding of what the function	does. Some possible
	  optimizations	include	generating complete inline code, generating
	  partial inline code with calls to one	or more	different functions,
	  or just using	characteristics	of the function	to move	the call site
	  or avoid some	of the overhead	triggered by an	external call.

      -D_INLINE_INTRINSICS
	  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 argu-
	       ment from being evaluated more than once	(so arguments con-
	       taining 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	expansions 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	for-
	       mat strings are defined as inline static	functions in the
	       header file, avoiding external calls to these routines in
	       libc.

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

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

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

      -fp_reorder
	  Allows floating-point	operations to be reordered during optimiza-
	  tion.

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

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

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

      -O3 Sets the optimization	level.

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

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

  -feedback file
      Specifies	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 compilation 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 procedures
      to reduce	cache thrashing, spike is typically more effective. When
      employing	both -feedback and spike, use the second (executable) form of
      file, which allows both the compiler and spike to	use data derived from
      a	single profile training	run.

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

      The -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 com-
      piler to move divide operations outside of loops,	thus improving per-
      formance.

      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.

  -ifo
      Provide improved optimization (inter-file	optimization) and code gen-
      eration 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 compiler will issue diagnostics
      about conflicting	external declarations and function definitions that
      occur in different files.	For purposes of	code generation, the compiler
      treats the files as one application. The default is to not provide
      inter-file optimization.

  -[no]inline keyword
      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 considers	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 inlin-
      ing:

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

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

      size
	  Inlines all of the function calls in the manual category, plus any
	  additional calls that	the compiler determines	would improve run-
	  time performance without significantly increasing the	size of	the
	  program. This	is the default when compiling with the -O2 or -O3
	  option.

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

      all Inlines every	call that can be inlined while still generating
	  correct code.	Recursive routines, however, will not cause an infin-
	  ite loop at compile 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.

  -[no]intrinsics
      The -intrinsics option causes the	compiler to recognize intrinsic	func-
      tions wherever it	can automatically, based only on name and call signa-
      ture. 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 impli-
      cit 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 intrinsic. If not, a diagnostic is issued and calls	are treated
      as ordinary external function calls.

      When the compiler	identifies a function as an intrinsic function,	it is
      then free	to make	code optimizations (transformations) 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 particular function.

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

      -O0 or -O1
	  No intrinsic functions. The -intrinsics option has no	effect at
	  this optimization level.

      -O2 (or -O)
	  Memory and string functions: alloca, bcopy, bzero, memcpy, memmove,
	  memset, strcpy, strlen

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

      -O3 fprintf, printf, snprintf, sprintf

      -fast (due to its	supplying -assume nomath_errno and -O3)
	  acos,	acosf, asin, asinf, cosh,coshf,	exp, expf, log,	log10,
	  log10f, logf,	log2, pow, powf, sqrt, sqrtf, sinh, sinhf, tan,	tand,
	  tanf,	tanh.

      The effects of the various optimization levels are cumulative; for
      example, -fast causes the	functions at the -02 (or -O) and -O3 optimi-
      zation 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	function 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 rou-
      tines for	intrinsic [f]printf inlined, the compilation must include and
      also specify both	-D_INTRINSICS and -D_INLINE_INTRINSICS on the command
      line.

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

  -O[n]
      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
			  subexpressions. Global optimizations,	including
			  code motion, strength	reduction and test replace-
			  ment,	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	recommended to determine if
      -O4 is better than -O3 for your particular application, as this is not
      always true.

  -om Performs code optimization after linking,	including nop (no operation)
      removal, .lita removal, and reallocation of common symbols. This option
      also positions the $gp register so that the maximum number 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 partic-
      ular optimization	by specifying -om followed by one of the following
      options:

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

      -WL,-om_dead_code
	  Removes dead code (unreachable instructions) generated after apply-
	  ing optimizations.  The .lita	section	is not compressed by this
	  option.

      -WL,-om_feedback
	  Uses the pixie-produced information stored in	the augmented execut-
	  able by means	of the cc command's -feedback option and the pixie
	  (or prof) command's -update option.

      -WL,-om_Gcommon,num
	  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 probability that
	  the symbol can be accessed directly from the $gp register. (Nor-
	  mally, om tries to collect all "common" symbols together, not	just
	  symbols that conform to certain size constraints.)

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

      -WL,-om_no_inst_sched
	  Turns	off instruction	scheduling.

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

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

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

  -omp
      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 programming directives enabled by the -mp option are
      ignored. See also	the -mp	and -check_omp options.

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

	+  At optimization levels -O3 and -O4.

	+  When	-ifo is	used.

	+  When	the compilation	is proceeding 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.

  -preempt_symbol
      Preserves	full symbol preemption;	that is, supports symbol preemption
      on a symbol-by-symbol basis within a module as well as between modules.
      Restricts	the optimizer so that calls to extern functions	are ineligi-
      ble 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.

  -speculate all
      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 con-
      trol will	actually reach that operation. If the flow of control does
      reach that operation, the	result will be available sooner	than it	would
      have been	without	speculative execution. If the flow of control does
      not reach	that operation,	the result will	simply be ignored.

      Since unsuccessful speculative operations	can generate exceptions, all
      exceptions are dismissed when any	module that contributes	to the appli-
      cation 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).

  -speculate by_routine
      Specifies	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 modules 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
      exceptions, 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 execution	than
      the -speculate all option, but does not restrict trap and	fault han-
      dling in other modules with which	it is linked.

  -spike
      Invokes the spike	tool to	perform	code optimization after	linking	a
      program.	-spike is a replacement	for -om	and does similar optimiza-
      tions.  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.

  -tune	option
      Instructs	the optimizer 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 instruc-
      tion tuning appropriate for the listed processor(s):

      generic
	  All Alpha processors.	 This is the default.

      host
	  The processor	on which the code is compiled.

      ev4 The 21064, 21064A, and 21068 processors.

      ev5,ev56
	  The 21164 processor.	(Both EV5 and EV56 are numbered	21164.)

      ev6 The 21264 processor.

      ev67
	  The 21264A processor.

      pca56
	  The 21164PC processor.

      See also the -arch option	for an explanation of the differences between
      -tune and	-arch.

  -unroll n
      Controls the loop-unrolling optimization (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


  -gen_feedback
      Generates	accurate profile information to	be used	with -feedback optim-
      izations,	as follows:

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

       2.  Run pixie on	the executable file.

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

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

       5.  Recompile the program with the -feedback option and optimization
	   level -O1 or	above. This provides the compiler with execution
	   information that the	compiler can use to improve certain optimiza-
	   tions.

  -prof_gen
      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 .non_pixie. See also	the descriptions of the
      -prof_use_om_feedback, -prof_dir,	and -pids options.

  -prof_gen_noopt
      Generates	a non-optimized	executable image that, when run, will gen-
      erate profiling data that	the compiler can use to	improve	its optimiza-
      tion 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	com-
      piler optimization.

      The recommended usage is as follows:

       1.  Compile the source code with	-prof_gen_noopt.

       2.  Run the program.

       3.  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 manipulat-
      ing the name and location	of the feedback	data files, see	-pids and
      prof_dir.

  -prof_use_feedback
      Uses profiling feedback to improve compiler 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.

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

      To use the -prof_use_om_feedback option, first compile your program
      with the -prof_gen option	and then run the program to generate the pro-
      filing data.

  -prof_dir
      Specifies	a location to which the	profiling data files (.Counts and
      .Addrs) are written. Use this option in conjunction with the -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.

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

  Source-code Debugging	Options


  -g[n]
      Produces symbol table information	for debugging. When no value is
      specified	for n, the compiler produces symbol table information for
      full symbolic debugging and suppresses optimizations that	limit full
      symbolic debugging (same as -g2).

      The value	of n can be one	of the following (-g is	the same as -g2):

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

      1	  Produces limited symbol table	information. Profiling and debugging
	  tools	provide	line numbers, source file names, and the names of
	  local	procedures, when appropriate. Line-oriented debugging com-
	  mands	work, but symbol types and the names of	stack-frame variables
	  are not available. Most profiling tools work to their	fullest	abil-
	  ity, but some	advanced Atom tools may	provide	more information at
	  higher debug levels.	All optimizations are supported.

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

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

  Program Profiling Options


  -p[n]
      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 moni-
      tor(3)) and produces, in file mon.out, execution-profiling data for use
      with the postprocessor prof(1).

      The value	n can be one of	the following:

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

      1	  Same as -p.

  -[no]pg
      Turns gprof profiling on or off when compiling and linking the file
      immediately following this 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


  -assume [no]aligned_objects
      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 indi-
      cated by the pointer to the object. On Alpha systems, dereferencing a
      pointer to a longword- or	quadword-aligned object	is more	efficient
      than dereferencing a pointer to a	byte- or word-aligned object. There-
      fore, 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 generate
      longer code sequences to perform indirect	load and store operations in
      order to avoid hardware alignment	faults for arbitrarily aligned
      addresses.  Although the -assume noaligned_objects 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 align-
	   ment, or byte alignment if you have specified #pragma
	   nomember_alignment for struct).

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

      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.

  -assume [no]trusted_short_alignment
      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.

  -[no]misalign
      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 discussed earlier in this refer-
      ence page.

  -[no]member_alignment
      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	boundaries
      (that is,	on the next boundary appropriate to the	type of	the member)
      instead of the next byte.	For example, an	int variable member is
      aligned on the next longword boundary, and a short variable member is
      aligned on the next word boundary.

      Any use of the #pragma member_alignment, #pragma nomember_alignment, or
      #pragma pack directives within the source	code overrides the setting
      established by this 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.

  -Zp[n]
      Aligns structure members and entire structures 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 structure,
      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 struc-
      ture 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


  -strong_volatile
      Affects the generation of	code for assignments to	objects	that are less
      than or equal to 16 bits in size (for instance char, short) that have
      been declared as volatile. The generated code includes a 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.

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

  C Language Options


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

  -float
      Prevents the compiler from promoting expressions of type float to	type
      double. This is the default except in -std0 mode.

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

  -readonly_strings
      Allows the compiler 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 speci-
      fied may yield unpredictable results (for	example, a segmentation
      fault).

  -signed
      Causes all char declarations to have the same representation and range
      of values	as signed char declarations. This is used to override a	pre-
      vious -unsigned option. This is the default.

  -unsigned
      Causes all char declarations to have the same representation and range
      of values	as unsigned char declarations.

  -varargs
      Prints warnings for all lines that may require the <&lt;varargs.h>&gt; macros.

  -volatile
      Causes all variables to be treated as volatile.

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

      This option overrides -readonly_strings.

  Stack-handling and Pointer-handling Options


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

  -xtaso
      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 conjuction
      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 infor-
      mation on	#pragma	pointer_size.

  -xtaso_short
      Same as the -xtaso option, except	-xtaso_short also directs the com-
      piler to allocate	32-bit pointers	by default. You	can still use 64-bit
      pointers,	but only by the	use of pointer_size pragmas.

      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.

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

  IEEE Floating-point Support Options


  -fprm	c
      Specifies	chopped	rounding mode (round toward zero).

  -fprm	d
      Dynamically sets rounding	mode for IEEE floating-point instructions.
      The dynamic rounding mode	is determined from the contents	of the
      floating-point control 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 floating-point rounding mode defaults to	round to nearest.

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

  -fprm	m
      Specifies	round toward minus infinity mode.

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

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

  -ieee
      Ensure support of	all portable features of the IEEE Standard for Binary
      Floating-Point Arithmetic	(ANSI/IEEE Std 754-1985), including the
      treatment	of denormalized	numbers, NaNs, and infinities and the han-
      dling 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.

  -scope_safe
      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 occurring 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)


  -Hc 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	.T, and	the file is always retained after the compi-
      lation is	halted.

  -Wc[c...],arg1[,arg2...]
      Passes the argument, or arguments	(argi),	to the compiler	pass, or
      passes (c[c...]).	Each c character can be	one of the following: [
      ablLzpfy ] (see the -t option for	an explanation). The c selects the
      compiler pass in the same	way as the -t option.

  -tc[c...]
      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_TARGET_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.

  -hpath
      Specifies	the directory where the	tool (or other component) 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 (/).

  -Bstring
      Specifies	a suffix to add	to the normal names of any components speci-
      fied with	the -t option. If string is omitted, the usual component
      names are	used.

  -K  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, replacing its suffix with the
      conventional suffix for the type of file (for example, .B	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	created	after the ucode	link is	u.out, by default. If -ko
      output is	specified, the base name of the	object file, if	it exists, is
      output. If output	includes a suffix, the suffix is not included as part
      of the base name.

  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 .c 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 .o substituted
       for .c. The .o file is deleted only when	a single source	program	is
       compiled	and loaded all at once.

    +  Arguments whose names end with .s are assumed to	be symbolic assembly
       language	source programs. They are assembled, producing a .o file.

    +  Arguments whose names end with .i are assumed to	be C source files
       after being processed by	the C preprocessor.

    +  Arguments whose names do	not end	with .c, .s, or	.i 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 command
  or the ld command (linker). When the compiler	recognizes position-sensitive
  linker options (-L, -all, -exclude, -exported_symbol,	-hidden,
  -hidden_symbol, -l, -none, -non_hidden, -noarchive, -noso, and
  -so_archive),	it maintains their relative order for the linker. This refer-
  ence page describes the options that are specific to the cc command. 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 iden-
  tify 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 follow-
  ing statement	to uniquely identify Tru64 UNIX:

       #if defined (__digital__) &&amp;&&amp; 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 func-
  tions	are declared in	header files and to obtain standards conformance
  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 variable 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 environment variable allows Compaq 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	com-
       pilation	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 compilation:

   1.  comp.config prologue options

   2.  DEC_CC prologue options

   3.  command line options

   4.  DEC_CC epilogue options

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

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

   2.  In this example,	the -v option displays the name	of each	compilation
       pass--and its arguments--as it executes.
	    cc -v helloworld.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_LONGLONG	-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__LANGUAGE_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:

  DEC_CC
      Allows Compaq C users to establish a set of compilation options that
      are applied to subsequent	compilation on a per-user basis. See the
      DESCRIPTION section for more information.

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

  DRV_SKIP_COMMAND
      If set, causes the compiler driver to display all	the commands that
      would be invoked,	but to not actually execute those commands.

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

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

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

  LC_MESSAGES
      Determines the locale used for diagnostic	messages.

  NLSPATH
      Determines the locale of message catalogs	for the	processing of
      LC_MESSAGES.

  TMPDIR
      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

  file.c
      Input file

  file.o
      Object file

  a.out
      Loaded output

  /tmp/ctm?
      Temporary

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

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

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

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

  /usr/lib/cmplrs/cc/as0
      Symbolic to binary assembly language translator

  /usr/lib/cmplrs/cc/as1
      Binary assembly language assembler and reorganizer

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

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

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

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

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

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

  /usr/include
      Standard directory for header files

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

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

  mon.out
      File produced for	analysis by prof

  gmon.out
      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),
  protect_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