Content-type: text/html Man page of cc

cc

Section: Misc. Reference Manual Pages (1old)
Index Return to Main Contents
 

NAME

cc - C compiler (outdated)  

SYNOPSIS

cc [-newc] [option...] file...

cc -oldc [option...] file...

cc -migrate [option...] file...


 

Default Options:

cc -newc -assume aligned_objects -cpp -call_shared -double -fprm n -fptm n -g0 -I/usr/include -inline manual -member_alignment -no_fp_reorder -no_misalign -O1 -oldcomment -p0 -no_pg -preempt_symbol -signed -archgeneric -std0 -tune generic -writable_strings


 

OPTIONS

Options described in this section are divided into the following categories: Compiler selection options Overall compiler behavior options C preprocessor options Linker or loader options Optimization options Feedback-directed optimization options Source-code debugging options Program profiling options Code portability options Data alignment options Data volatility options C language options Rounding-mode options (IEEE floating-point) Stack-handling and pointer-handling options IEEE floating-point support options Ucode generation options (enabled by -oldc) Compiler development options (not generally used)
 

Compiler Selection Options

Invokes the new implementation of the C compiler, with defaults that make it compatible with the -oldc compiler. This is the default. Invokes the new implementation of the C compiler, but with a slightly different set of compiler options and default optimizations. These options and optimizations provide backward compatibility for applications relying on the -migrate option provided in previous implementations of the cc command. Invokes the older, ucode-based implementation of the C compiler.
 

Overall Compiler Behavior Options

Specifies which version of the Alpha architecture to generate instructions for. All Alpha processors implement a core set of instructions and, in some cases, the following extensions: BWX (byte/word-manipulation extension), MVI (multimedia extension), FIX (square root and floating-point 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: Generate instructions that are appropriate for all Alpha processors. This option is the default. Generate instructions for the processor that the compiler is running on (for example, EV6 instructions on an EV6 processor). Generate instructions for the EV4 processor (21064, 20164A, 21066, and 21068 chips) and EV5 processor (some 21164 chips). (Note that chip number 21164 is used for both EV5 and EV56 processors.)
Applications compiled with this option will not incur any emulation overhead on any Alpha processor. 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. Generate instructions for EV6 processors (21264 chips).
This option permits the compiler to generate any EV6 instruction, plus any instructions contained in the following extensions: BWX, MVI, FIX, and CIX.
Applications compiled with this option may incur emulation overhead on EV4, EV5, EV56, and PCA56 processors. 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 processor. Beginning with Tru64 UNIX V4.0 and continuing with subsequent versions, the operating system kernel includes an instruction emulator. This capability allows any Alpha chip to execute and produce correct results from Alpha instructions--even if the some of the instructions are not implemented on the chip. Applications using emulated instructions will run correctly, but may incur significant emulation overhead at run time.
The psrinfo -v command can be used to determine which type of processor is installed on any given Alpha system. Suppresses the loading phase of the compilation and forces the creation of an object file. 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. Sets a limit on the number of errors that the compiler will option. The default is 30. Specifies a file that is to be included before the first line in a source file is actually compiled. This enables users to develope include files containing sets of pragmas that control a particular aspect of a compilation (for example, optimizations or diagnostics).
[The -FIfilename option is not available when you use the -oldc option.] 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 message text strings).
The -msg_actiontype option has eight different forms, each resulting in a different action that changes the status, severity, or frequency that will be applied to the messages identified by the msg_list argument. The following message-control options are supported: Enable a specific message or group of messages. Disable a specific message or group of messages. (Note that messages with error or fatal severity cannot be disabled; only warning and informational messages can be disabled.) Always emit the messages identified by the msg_list argument. Emit the identified messages only once. Change the identified messages to be fatal, compilation-ending errors. Change the identified messages to be warnings. (Note that error- or fatal-severity messages cannot be changed to warning-severity messages.) Change the identified messages to be informational messages. (Note that error- or fatal-severity messages cannot be changed to informational-severity messages.) 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 levels, and disabling a level also disables all higher levels. For example, disabling level 3 messages disables levels 3 - 6. Operations other than enabling or disabling apply only to the specified (or default) level, not to lower levels.
The following message levels and message groups are supported:
Message Levels: Very important messages that are enabled by default. Level 0 messages cannot be disabled as a class (level0), but individual level 0 messages can be disabled if they are warning- or informational-severity messages. (Error- or fatal-severity messages cannot be disabled.)
Messages at this level correspond to messages covered by pragma nostandard. These include all messages that should be displayed for code in header files. Important messages, but less important than level 0 messages. These messages are not displayed if pragma nostandard is active. Level 1 is the default for Tru64 UNIX releases prior to V4.0E. Moderately important messages. Level 2 is the default for the Tru64 UNIX V4.0E and later versions. Less important messages. (The -w0 option enables level 3 messages.) Useful messages associated with the -check and -portable options. Less useful -check and -portable messages than the messages associated with level 4. (The -check option enables level 5 messages.) All messages, including all messages not in any of the lower levels. Disabling level 6 messages does not affect the lower-level messages; it affects only the messages added by level 6.
Message Groups: Messages reporting unusual or inefficient data alignment. Messages reporting the use of C features that would be invalid or have a different meaning if compiled by a C++ compiler. Messages reporting code or practices that, although correct and perhaps portable, are sometimes considered ill-advised because they can be confusing or fragile to maintain (for example, assignment as the test expression in an if statement). Messages reporting the use of obsolete features, features that were commonly accepted by early C compilers but were subsequently removed from the language. Messages reporting the use of non-ANSI C features. Messages reporting the use of features that are valid in ANSI C, but which are identified in the standard as being obsolescent and likely to be removed from the language in a future version of the standard. Messages reporting assignments and/or casts that may cause overflow or other loss of data significance. Messages reporting code that might result in poor run-time performance. Messages reporting the use of language extensions or other constructs that might not be portable to other compilers or platforms. Messages reporting questionable or non-portable use of preprocessing constructs. 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. Messages relating to function return values. Messages reporting expressions, declarations, and code paths that are not used. Sets the nesting-level limit for include files. The default is 50. Includes the generated machine code in the listing file. By default, machine code is not listed. To produce the listing file, you must also specify -source_listing.
[The -machine_code option is not available when you use the -oldc option.] 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.
[The -noobject option is not available when you use the -oldc option.] Names the final output file output. Ensures that the compiler's assumptions about pointer sizes and data alignments are not in conflict with the default values that were in effect when the system libraries were created.
The keywords for the -protect_headers option are as follows: Enables the protect headers feature. This is the default if the file being compiled is a C source file. Disables the protect headers feature. This is the default if the file being compiled is a non-C source file. Cancels any previous -protect_headers options and places the compiler's default behavior in effect.
If more than one such switch appears on the command line, only the last one is applied. See protect_headers_setup(8) for details.
[The -protect_headers option is not available when you use the -oldc option.] Compiles the specified source files and generates symbolic assembly language output in corresponding files suffixed with .s. Specifies one or more items to be included in the listing file. When specifying multiple keywords, separate them by commas and no intervening blanks. To use any of the -show keywords, you must also specify the -source_listing option.
The keywords for the -show option are as follows: Turns off all show options. Turns on all show options. 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. Produces header lines at the top of each page of listing. Places contents of header files in program listing. Places source program statements in program listing. Places compile-time performance statistics in the program listing.
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).
[The -show option is not available when you use the -oldc option.] 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.
[The -source_listing option is not available when you use the -oldc option.] Prints the compiler passes as they execute with their arguments and their input and output files. Also prints resource usage in the C-shell time format. If specified more than once, the passes are printed but not executed.
When specified with -newc or -migrate, the -v option also directs the compiler to display the macros defined at the start of the compilation. Prints the version of the compiler driver and, when the -oldc option is specified, the versions of all passes in the same format as the what command. Produces longer error and warning messages. Messages in this form may give the user more hints about why the compilation failed. Controls the display of messages as well as the actions that occur as a result of the messages. The value of n can be one of the following: Displays all levels of compiler messages (warnings, errors, fatals, and, when -newc or -migrate is specified, informational messages). Suppresses warning messages. The -w1 option displays error and fatal messages and, when -newc or -migrate is specified, informational messages. Specifying -w is the equivalent of specifying -w1. If the compiler encounters an error that generates a warning-level diagnostic message, the compiler displays the message and then aborts. Does not print warning messages. However, when warnings occur, exits with nonzero status.
If no -w option is specified (the default), only warning, error, and fatal messages are displayed. 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

Passes all comments directly to the preprocessor, except comments on preprocessor directive lines. Determines whether to call the C macro preprocessor on C and assembly source files before compiling.

The -cpp option is the default. Defines the name as if with a #define statement. If no definition is given, the name is defined as 1. Runs only the C macro preprocessor on the files and sends the result to the standard output device. Specifies a search path for header files whose names do not indicate a specific 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 standard directory, /usr/include. If the #include <filename> form of the directive is used, the preprocessor searches for the file first in the search path indicated by the -I 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. Requests a dependency list. This option is passed directly to the preprocessor. See cpp(1) for details. Requests a dependency file. This option is passed directly to the preprocessor and linker. For more information, see cpp(1) and ld(1). Controls the search order for header files. This option is passed directly to the preprocessor. For more information, see cpp(1). Directs the preprocessor to delete comments (replacing them with nothing at all). This allows traditional token concatenation.
This is the default in -std0 mode. In -std and -std1 mode, the default is to replace comments with a single space. Runs only the C preprocessor and puts the result for each .c or .s source file in a corresponding .i file. The .i file has no #line_number preprocessor macro lines in it. Extracts prototype declarations for function definitions and puts them in a .H suffixed file. The suboption i includes identifiers in the prototype, and the suboption s generates prototypes for static functions as well. Directs the preprocessor to use single quotes in __FILE__ expansions instead of double quotes. See cpp(1) for details. Removes any definition of name, where name is either a symbol previously defined with the -D option or a reserved symbol that is predefined by the compiler. If no name is specified, the -U option is ignored. (To display a list of predefined symbols, enter the cc command with the -v option.)
 

Linker or Loader Options

Produces a dynamic executable file that uses shareable objects during run time. This is the default. The loader uses shareable objects to resolve undefined symbols. The run-time loader (/sbin/loader) is invoked to bring in all required shareable objects and to resolve any symbols that remained undefined during static link time. Passes the -compress option to the compilation phase (if the -c option is present) or passes the -compress_r option to ld (if the -r option is present). Use of this option causes the output object file to be produced in compressed object file format, resulting in a substantially smaller object file. Runs the procedure rearranger, cord, on the resulting file after linking. The rearrangement is done to reduce the cache conflicts 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. 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. Causes any unresolved symbols matching pattern to be ignored. Such symbols are not displayed and are not treated as errors or warnings. You can enter this option multiple times on a command line. The patterns use shell wildcard characters (?, *, [, ]). The wildcard characters must be properly quoted to prevent them from being expanded by the shell. For more information, see sh(1). Makes the procedure represented by the symbol into a termination routine. A termination routine is a routine that is called without an argument when either the file that contains the routine is unloaded or the program that contains the routine exits. Makes the procedure represented by the symbol into an initialization routine. An initialization routine is a routine that is called without an argument when either the file that contains the routine is loaded or the program that contains the routine is started. Directs the linker to read the contents of file filename as if the contents had been supplied on the ld command line.

Inside file filename, lines ending with \ are treated as continuation lines, and lines starting with # are treated as comment lines and ignored. The -v option can be used to display the expansion of files specified in a -input file. The files can be nested up to 20 levels. Prevents the linker from using archive libraries to resolve symbols. This option is used in conjunction with -call_shared. The -no_archive option is position sensitive; it affects only those options and variables that follow it on the command line. This option can also be used more than once on the command line. Directs the linker to produce a static executable. The output object created by the linker will not use any shared objects during execution. Produce 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: 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. Creates an rpath record containing the specified path string. The path string is a colon-separated list of directories that is meaningful only when creating an executable with shared linkage. If an item in the path supplied to -rpath is of the form $VARNAME or ${VARNAME}, the linker interprets it as an environment variable.
Additional rpath directories found in shared objects on the link command line are appended to path. Duplicate entries are excluded. The loader uses the rpath record to search for shared libraries at run time. Establishes the version identifier (or identifiers) associated with a shared library. The string version-string is either a single version identifier or a colon-separated list of version identifiers. No restrictions are placed on the names of version identifiers; however, it is highly recommended that UNIX directory naming conventions be followed.
If a shared library is built with this option, any executable built against it will record a dependency on the specified 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. Sets DT_SONAME for a shared object. The name can be a single component name (for example, libc.a), a full pathname (starting with a slash), or a relative pathname (containing a slash). The default DT_SONAME used for shared objects is the filename component of the output file name. Specify the output file name using the -o option as described previously. Registers the location of this shared object's segments and makes sure they stay out of the way of others in the location_file. The location_file is updated if it is writable. Directs the linker to use the threadsafe version of any library specified with the -l option when linking programs. This option also tells the linker to include the POSIX 1003.1c-conformant DECthreads interfaces in libpthread when linking the program. 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 addresses 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). Directs the linker to use the threadsafe version of any library specified with the -l option when linking programs. This option also tells the linker to include the POSIX 1003.4a Draft 4 conformant DECthreads interfaces. It is supported only for compatibility with earlier releases of Tru64 UNIX. New designs should use the -pthread option.
 

Optimization Options

Directs the compiler to assume the ANSI C aliasing rules, and thus allows the optimizer to be more aggressive in its optimizations. The -noansi_alias option turns off ANSI C aliasing rules.

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 of a different type (and for this purpose, signed and qualified versions of an otherwise same type are considered to be the same type), then assuming ANSI C aliasing rules allows the compiler to generate better optimized code.
If your program does access the same data through pointers of a different type (for example, by a ``pointer to int'' and a ``pointer to float''), you must not allow the compiler to assume ANSI C aliasing rules because these rules can result in the generation of incorrect code.
The default is to assume no ANSI C aliasing rules when compiling with the -vaxc, -std, or -std0 option. The default is -ansi_alias when compiling with the -std1 option.
The -noansi_alias option turns off ANSI C aliasing rules.
The -[no]ansi_alias option is not available when you use the -oldc option. Tells the compiler whether the source code follows all ANSI rules about arguments, that is, whether the type of an argument matches the type of the parameter in the called function or whether a function prototype is present so the compiler can automatically perform the expected type conversion.
Specifying -no_ansi_args means that the argument type may not match the expected parameter type. This option is important, for example, when the caller passes a parameter of type long and the called routine expects an int. The -no_ansi_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, -no_ansi_args is the default. Note that it is safe to specify -ansi_args if you use ANSI-style function prototypes at all call sites.
Specifying -ansi_args means that your code meets the ANSI C requirements, so no special argument cleaning code is generated. This is a performance gain. When -std1 is specified, -ansi_args is the default.
[The -[no_]ansi_args option is not available when you use the -oldc option.] Specifies the assumption that all array parameters are restricted. In the following code, for example, only b will be considered a restricted pointer when this option is not specified, even though for all other purposes parameters a and b have identical type: extern int foo(char * a, char b[]);
When this option is specified, both a and b are treated as restricted pointers. Controls the compiler's assumption about a program's dependence on the setting of errno by math library routines: By default (-assume math_errno), the compiler assumes that the program might interrogate errno after any call to a math libarry routine that is capable of setting errno. The definition of the ANSI C math library allows programs to depend on this behavior, which unfortunately restricts optimization because this causes most math functions to be treated as having side effects. Specifying -assume nomath_errno instructs the compiler to assume that the program does not look at the value of errno after calls to math functions. This assumption allows the compiler to reorder or combine computations to improve the performance of those math functions that it recognizes as intrinsic functions. In practice, robust floating-point code seldom relies on errno to detect domain or range errors, so -assume nomath_errno can often be safely used to improve performance.
[The -assume [no]math_errno option is not available when you use the -oldc option.] Specifies the assumption that all pointer parameters are restricted. Specifies the assumption that all pointers are restricted.
The -assume norestricted_pointers option disables the __restrict keyword from all pointers. This can help detect inappropriate use of __restrict. If the code works correctly at high optimization with __restrict turned off, but breaks with it turned on, it is likely that the compiler encountered a pointer that was restricted in error. Restricted pointers are an assertion by the programmer to aid optimization; the compiler cannot detect erroneous assertions. Specifies that no occurrences of the address-of operator (&) are being applied outside the current compilation unit to extern variables that are declared inside the current compilation unit. Making this assertion allows the compiler to perform better optimizations.
This option is often suitable for use with the -ifo option, which presents a group of source files to the compiler as a single compilation unit. 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. 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. 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. 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. Specifies that any short accessed through a pointer is naturally aligned. This generates the fastest code, but can silently generate the wrong results if any of the short objects cross a quadword boundary.
See the description of this option elsewhere in this reference page for more detailed information about this operation. Declares certain functions to be intrinsic. When a function is intrinsic, the compiler is free to generate faster code that provides the same function behavior (but may not actually call the function). Directs the compiler to inline some of the intrinsic functions, avoiding the overhead of a function call. Causes the /usr/include/math.h file to redefine the names of certain common math routines, including sqrt and exp, so that faster but slightly less accurate functions are used. The fast math routines do not support IEEE exceptional behavior. Tells the compiler that it is not necessary to promote expressions of type float to type double.
See the description of this option elsewhere in this reference page for more detailed information about this operation. Allows floating-point operations to be reordered during optimization.
See the description of this option elsewhere in this reference page for more detailed information about this operation. Performs inter-file optimizations.
See the description of this option elsewhere in this reference page for more detailed information about this operation. 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. The -newc and -oldc options set the optimization level to -O3.
The -migrate option sets the optimization level to -O4.
See the description of these options elsewhere in this reference page for more detailed information about this operation. Makes string literals read-only for improved performance.
See the description of this option elsewhere in this reference page for more detailed information about this operation. Specifies the name of a feedback file (produced by prof after running a pixie version of the program). The feedback file contains information that the compiler can use when performing optimizations.
You can also use a feedback file as input to the cord utility, using -feedback and the -cord options to link the program. Specifies whether certain code transformations that affect floating-point operations are allowed. These changes can affect the accuracy of the program's results.
The -no_fp_reorder option, the default, directs the compiler to use only certain scalar rules for calculations. This setting can prevent some optimizations. The -fp_reorder option frees the compiler to reorder floating-point operations based on algebraic identities (inverses, associativity, and distribution). For instance, this allows the compiler to move divide operations outside of loops, thus improving performance.
If you specify -fp_reorder and the compiler reorders code to improve performance, the results can differ from the default, for example, due to the way intermediate results are rounded. However, the -fp_reorder results are not categorically less accurate than those gained by the default. Specifies the maximum size, in bytes, of a data item that is to be put in one of the small data sections. Data items in the small data sections are more likely to be candidates for global pointer optimizations by link-time optimizations. The num argument is interpreted as a decimal number. The default value for num is 8 bytes. This value cannot be changed when using the -newc or -migrate option. Provide improved optimization (inter-file optimization) and code generation across file boundaries that would not be possible if the files were compiled separately.
When you specify -ifo on the command line in conjunction with a series of file specifications, the compiler does not concatenate each of the specified source files. Instead, each file is treated separately for purposes of parsing, except that the 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.
[The -ifo option is not available when you use the -oldc option.] Specifies whether to provide inline expansion of functions. The -no_inline option disables the inlining optimization that would otherwise be performed by default under the following compiler optimization -O[n] options: When -O2, -O3, or -O4 is specified under -newc When -O4 or -O5 is specified under -migrate When -O3 is specified under -oldc
When choosing calls to expand inline, the compiler also considers the function size, how often the call is executed, how many registers the inline expansion will require, and other factors.
You can specify one of the following as the keyword to control inlining: No inlining is done, even if requested by a #pragma inline preprocessor directive. This is the default when compiling with the -O0 optimization level. Inlines only those function calls explicitly requested for inlining by a #pragma inline directive. This is the default when compiling with the -O1 option under -newc. 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 under -newc, or the -O, -O4, or -O5 option under -migrate. 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. Inlines every call that can be inlined while still generating correct code. Recursive routines, however, will not cause an infinite loop at compile time.
For optimization level 0 (-O0), the -inline option is ignored and no inlining is done. The #pragma noinline preprocessor directive can also prevent inlining of any function.
[The -inline option is not available when you use the -oldc option.] Controls whether the compiler recognizes certain functions as intrinsic functions--even if the appropriate header file is not included and the function names are not specified in a pragma intrinsic directive. Recognition is based on the function name and the call signature (arguments and return types).
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: No intrinsic functions. The -intrinsics option has no effect at this optimization level. 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. fprintf, printf, snprintf, sprintf acos, acosf, asin, asinf, cosh, coshf, exp, expf, log, log10, log10f, logf, log2, pow, powf, sqrt, sqrtf, sinh, sinhf, tan, tand, tanf, tanh.
The effects of the various optimization levels are cumulative; for example, -fast causes the functions at the -02 (or -O) and -O3 optimization levels to be treated as intrinsics - in addition to the intrinsic function treatment that is triggered by -fast itself.
The -intrinsics option is in effect by default. To disable the default, specify the -no_intrinsics 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). Enables the compiler to process parallel decomposition pragmas (directives) in C source code. It also triggers the link phase to link with the appropriate thread and compiler support libraries that are needed to run the generated multiprocessor code.
A correctly coded program that makes use of the parallel decomposition pragmas can be compiled either with or without -mp. With -mp, the pragmas cause the program to run in several concurrent threads that may execute in a significantly shorter elapsed time on a Tru64 UNIX multiprocessor system. Without -mp, the compiler will ignore the pragmas and the program will run sequentially as a normal C program.
[The -ifo option is not available when you use the -oldc option.] Determines the level of optimization. The following table lists the types of optimizations that can be performed. The default optimization level is -O1. Note, however, that different optimizations are performed at each level, depending on whether you invoke the compiler with the -newc, -oldc, or -migrate option.

-newc-oldc-migrateOptimization

-O0-O0-O0None
-O1-O1-O1 Local optimizations and recognition of common subexpressions.
-O1 -O2, -O -O2, -O Global optimization, including code motion, strength reduction and test replacement, split lifetime analysis, and code scheduling.
-O2, -O -O2, -O -O3 Additional global optimizations that improve speed (at the cost of extra code size), such as integer multiplication and division expansion (using shifts), loop unrolling, and code replication to eliminate branches.
-O2, -O -O3-O4 Inline expansion of static procedures.
-O3-O3-O4 Inline expansion of global procedures.
-O4N/A-O5 Software pipelining using dependency analysis, vectorization of some loops on 8-bit and 16-bit data (char and short), and insertion of NOP instructions to improve scheduling.

To determine whether using -O4 with -newc benefits your program, you should compare program execution times for the same program compiled at levels -O3 and -O4.
If you are using the -O (or -O2) optimization level when compiling code that will never end up in a shared library, you should consider changing to the -O3 level because it provides additional compiler optimizations. (The -O3 level may inhibit the ability to preempt symbols, so it should not be used for shared libraries.) Specifies the maximum size, in basic blocks, of a routine that will be optimized by the global optimizer. If a routine has more than this number of basic blocks, it will not be optimized and a message will be printed. A option specifying that the global optimizer is to be run (-O2 or -O3) must also be specified. The num is assumed to be a decimal number. The default value for num is 500 basic blocks.
[The -Olimit option is not available with the -newc or -migrate options.] 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. The -om option is supported only for programs compiled with the -non_shared option. The following options can be passed directly to -om by using the -WL compiler option: Removes unused .lita entries after optimization, and then compresses the .lita section. Removes dead code (unreachable instructions) generated after applying optimizations. The .lita section is not compressed by this option. Sets the size threshold of ``common'' symbols. Every ``common'' symbol whose size is less than or equal to num will be allocated close to each other. This option can be used to improve the probability that the symbol can be accessed directly from the $gp register. (Normally, om tries to collect all ``common'' symbols together, not just symbols that conform to certain size constraints.) Uses the pixie-produced information in file.Counts and file.Addrs to reorganize the instructions to reduce cache thrashing. Turns off instruction scheduling. Turns off alignment of labels. Normally, the -om option will quadword align the targets of all branches to improve loop performance. Splits frequently accessed routines into ``hot'' and ``cold'' code segments, and stores these segments in different parts of the image. The hot segments are the most frequently executed parts of the code, as determined by feedback data produced by a 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 [email protected], specifying help on the subject line. Then, follow the instructions in the reply you receive to obtain report number 94/1. Supports symbol preemption on a module-by-module basis. During optimization, inlining is performed only on functions within a single compilation unit. This is the default in the following cases: At optimization levels -O3 and -O4 when -newc is used At optimization levels -O4 and -O5 when -migrate is used 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. Preserves full symbol preemption; that is, supports symbol preemption on a symbol-by-symbol basis within a module as well as between modules. During optimization, if inlining is requested, only static functions are eligible.
The default taken for a compilation is either -preempt_symbol or -preempt_module. See the description of the -preempt_module option for details on the conditions that determine which option is taken as the default. Specifies that speculation may occur anywhere in the executable image.
A conditionally-executed operation is speculated by beginning the operation's execution prior to testing the condition that guards the use of the value of that operation. If execution reaches the conditionally-executed use of the operation's value, then that value will be available for immediate use. If execution does not reach the conditionally executed use of the operation's value, then the speculatively computed value is ignored.
If any module in a program is compiled with -speculate all, all exceptions throughout the entire program are dismissed on the assumption that the execution is caused by an unsuccessful speculative instruction. (Note, though, that floating-pointing instructions specifying software completion [/S] are still given normal exception handling.) Code compiled with the -speculate all option cannot use any form of local exception handling nor be linked with any routines that do. As a result, you should use the -speculate all option only in programs 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 all option is not available when you use the -oldc option.] 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 handling in other modules with which it is linked.
[The -speculate by_routine option is not available when you use the -oldc option.] Selects processor-specific instruction tuning for a specific implementation of the Alpha architecture. Tuning for a specific implementation can provide improvements in run-time performance.
Regardless of the setting of the -tune option, the generated code will run correctly on all Alpha processors. Note that code tuned for a specific target may run more slowly on another target than generically-tuned code.
The option keyword can be one of the following: Selects instruction tuning that is appropriate for all Alpha processors. This option is the default. Selects instruction tuning that is appropriate for the processor on which the code is being compiled. Selects instruction tuning for the 21064, 21064A, 21066, and 21068 chips. Selects instruction tuning for the 21164 chip. (Chip number 21164 is used for both EV5 and EV56 processors.) Selects instruction tuning for the 21264 chip. Controls loop unrolling done by the optimizer at levels -O2 and above for -newc. Specifying -unroll n unrolls loop bodies n times. Specifying -unroll 0 means the optimizer uses its own default unroll amount. Specifying -unroll 1 means no unrolling. The default is -unroll 0.
[The -unroll option is not available when you use the -oldc option.]
 

Feedback-directed Optimization Options

Generates an executable image that has profiling code added to it. Using this option is equivalent to running the pixie(5) command on an existing image, except the resulting image will not have the .pixie extension. See also the descriptions of the -prof_use_om_feedback, -prof_dir, and -pids options. Uses profiling feedback to improve runtime performance. Using this option is equivalent to using the prof(1) command to produce a feedback file, and then using the cc -feedback command to recompile the program.

To use the -prof_use_feedback option, first compile your program with the -prof_gen and -gen_feedback options and then run the program to generate the needed profiling data. Uses profiling feedback to rearrange the resulting image to reduce cache 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 profiling data. 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. [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 -no_pids.
 

Source-code Debugging Options

Determines the production of symbol table information. 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: Produces only enough symbol table information for linking. Names and addresses of external symbols, and the addresses and basic layout of the stack-frame are available. Profiling tools work, but the names of local procedures, source lines, and source file names are not available. The debugger allows procedure traceback and all instruction-level commands. 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 supported. 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 commands work, but symbol types and the names of stack-frame variables are not available. Most profiling tools work to their fullest ability, but some advanced Atom tools may provide more information at higher debug levels. All optimizations are supported. Produces symbol table information for full symbolic debugging and suppress some optimizations. Symbol types and stack-frame variables names are available. Optimization is suppressed (-g2 implies -O0). Produces symbol table information for fully optimized code. This level of debugging supplies the same information as -g2, but it also allows all compiler optimizations. As a result, some of the correlation is lost between the source code and the executable program.
 

Program Profiling Options

Generates accurate profile information to be used with -feedback optimizations, as follows: Compile the source code with the -gen_feedback option. Run pixie on the executable file. Execute the pixie version of the program to generate execution statistics on the program. Use prof to create a feedback file from the execution statistics. Recompile the program with the -feedback option and either the -O2 or -O3 option (for -newc) or the -O2, -O3, -O4, or -O5 option (for -migrate). This provides the compiler with execution information that the compiler can use to improve certain optimizations.

[The -gen_feedback option is not available when you use the -oldc option.] 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 routine (mcrt0.o) and the level 1 profiling library (libprof1.a) is searched. When you use the -p option together with either the -pthread option or the -threads option, the profiling library libprof1_r.a is used.
When profiling begins, the startup routine calls monstartup (see monitor(3)) and produces, in file mon.out, execution-profiling data for use with the postprocessor prof(1).
The value n can be one of the following: Do not permit any profiling. This is the default. If linking occurs, the standard run-time startup routine (crt0.o) is used, and no profiling library is searched. Same as -p. Turns gprof profiling on or off when compiling and linking the file immediately following this option. The gprof profiler produces a call graph showing the execution of a C program.
When this option is turned on, the standard run-time startup routine is replaced by the gcrt0.o routine. Programs that are linked with the -pg option and then run will produce, in file gmon.out, a dynamic call graph and profile. You then run gprof on the gmon.out file to display the output. When you use the -pg option together with either the -pthread option or the -threads option, the profiling library libprof1_r.a is used.
For more information, see the gprof(1) reference page.
 

Code Portability Options

Overcomes the problem of DEC C's relaxed ANSI mode (-std, the default option) accepting many VAX C keywords that are not accepted in K&R mode. Without this option, a user program will stop compiling if it contains a variable with the same name as one of the VAX C keywords. The following options are available: Determines whether certain VAX C keywords can be used as names of variables in programs being compiled. If vaxc_keywords is specified, the compiler will recognize the VAX C keywords no matter what standard option is specified. Cause the compiler to recognize the restrict keyword (C9X standard) no matter what standard mode is specified. 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. This option is available for -newc and -migrate only. 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. Directs the compiler to interpret source code according to certain language rules followed by the C compiler provided with the Microsoft Visual C++ compiler product. Compatibility with this implementation is not complete; however, the compiler recognizes the following extensions and responds to them by relaxing a standard behavior and, in most instances, suppressing a diagnostic message: Allow a declaration of an unnamed structure within another structure. You can reference all members of the inner structure as members of the named outer structure. This is similar to the C++ treatment of nested unions lacking a name, but extended to both structures and unions. For example:

struct {
   struct {
      int a;
      int b;
   };  /*No name here */
   int c; }d; /* d.a, d.b, and d.c are valid member names. */ 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 example:
struct {
   int a;
   int b[]; }s; Allow a static function declaration in block scope (that is, inside another function). For example:
f() {
    static int a(int b); } Allow & to produce an lvalue expression in certain cases. For example:
int *a, *b;
   f() {
       &*a=b; } Allow integers and pointers to be compared without a cast. For example:
int *a,b; f() { if (a==b)
   b=1; } Treat the char type as either signed char or unsigned char, depending of the default in effect. For example, a pointer to char can be assigned to a pointer to signed char, assuming that the -signed option is in effect:
signed char *a; Suppress warning messages for declarations that contain two semicolons; that is, allow completely empty declarations at file scope. For example:
int a;; Suppress warning messages for declarations that contain a variable name but no type. For example:
b; Ignore any extra comma at the end of the last enumerator in an enumeration declaration. For example:
enum E {a, b, c,}; /* Ignore the comma after "c". */ Allow typedef declarations that have a type specifier but no identifier name declaring the new type. For example:
typedef struct { int a; }; Suppress warning messages when one of the following unsupported Microsoft pragmas is encountered:
#pragma code_seg #pragma optimize #pragma warning
The -stdn option and the -ms options are mutually exclusive. When both of these options are specified, the last one seen by the driver program is placed in effect. (When -ms is in effect, -std is the default.) Directs the compiler to issue diagnostics for any nonportable coding that it encounters.
[The -portable option is not available when you use the -oldc option.] Suppresses certain warning- and informational-level diagnostic messages that are inappropriate for system header files. The suppressed messages relate to non-portable constructs in header files whose pathnames are prefixed by string directory.
The default is -SD/usr/include.
Specifying -SD without a directory string cancels the effect of any previous -SD 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 message suppression in the file __DECC_include_prologue.h.) Directs the compiler to issue warnings when it encounters language constructs that are not standard in the language. The default is -std.
The following values are accepted: Enforces the ANSI C standard, but allows some common programming practices disallowed by the standard. The -std option causes the macro __STDC__=0 to be passed to the preprocessor. Enforces the K & R programming style, with certain ANSI extensions in areas where the K & R behavior is undefined or ambiguous. In general, -std0 compiles most pre-ANSI C programs and produces expected results. The -std0 option causes the __STDC__ macro to be undefined. Strictly enforces the ANSI C standard and all its prohibitions (such as those that apply to the handling of void types, the definition of lvalues in expressions, the mixing of integrals and pointers, and the modification of rvalues). This option does not, however, restrict the name space defined by the Tru64 UNIX implementation to only reserved names as specified by ANSI C.
The -std1 option causes the macro __STDC__=1 to be passed to the preprocessor. Note that the -std1 option also affects linker-defined symbols. See ld(1) for more information.
None of the -std* options restrict or expand the name space defined by the Tru64 UNIX implementation (for example, items declared in system header files). To restrict the name space so that only ANSI C reserved names are made visible from the system header files listed in the ANSI C standard, use the _ANSI_C_SOURCE macro. For details on _ANSI_C_SOURCE and other standard macros, see standards(5). Places the compiler in VAX C compatibility mode. In addition to supporting the ANSI C language, this mode of compilation also supports VAX C extensions that are incompatible with the ANSI C standard and that change the language semantics. This mode provides compatibility for programs that depend on old VAX C behavior. This option is not available when you use the -oldc option.
 

Data Alignment Options

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

The -assume aligned_objects option causes the compiler to assume that a dereferenced object's alignment matches or exceeds the alignment indicated by the pointer to the object. On Alpha 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. Therefore, when the compiler assumes that a pointer object of an aligned pointer type does point to an aligned object, it can generate better code for pointer dereferences of aligned pointer types.
The -assume noaligned_objects option causes the compiler to 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 alignment, or byte alignment if you have specified #pragma nomember_alignment for struct).
If your module breaks one of these rules, you must use the -assume noaligned_objects option to compile the module; otherwise, your program may get alignment faults during execution, which will degrade performance.
The -assume aligned_objects and -assume noaligned_objects options can be used in the same cc command, allowing you to turn this option on and off as needed by individual source files.
The -assume aligned_objects and -assume noaligned_objects are not available when you use the -oldc option. However, the -misalign option is a synonym for -assume noaligned_objects and the -no_misalign option is a synonym for -assume aligned_objects. Controls the compiler's assumptions about the alignment of short types accessed through a pointer.
Specifying -assume trusted_short_alignment indicates that the compiler should assume any short accessed through a pointer is naturally aligned. This generates the fastest code, but can silently generate the wrong results if any of the short objects cross a quadword boundary. This is the behavior when -oldc is specified.
Specifying -assume notrusted_short_alignment tells the compiler that short objects may not be naturally aligned. The compiler generates slightly larger (and slower) code that will give the correct result, regardless of the actual alignment of the data. This is the default when -newc or -migrate is specified.
Note that assume notrusted_short_alignment does not override the __unaligned type qualifier, the -misalign option, or the assume noaligned_objects option.
[The -assume [no]trusted_short_alignment option is not available when you use the -oldc option.] Controls the alignment assumptions for code generated for indirect load and store instructions.
The -misalign option is a synonym for -assume noaligned_objects and the -no_misalign option is a synonym for -assume aligned_objects. The -assume [no]aligned_objects option is discussed earlier in this reference page. Directs the compiler to byte-align data structure members (with the exception of bit-field members).
By default, data structure members are aligned on natural 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.
[The -[no]member_alignment option is not available when you use the -oldc option.] Aligns structure members based on the integer n, where n can be 1, 2, 4, or 8. This option specifies packing so that each structure member after the first is stored on n-byte boundaries. When you specify the -Zp option without an n value, structure members are packed on 1-byte boundaries.
The use of the -Zpn option (where n!=8) can cause conflicts between the compiler's assumptions about data layouts and the default values that were in effect when the system libraries were created. See protect_headers_setup(8) for details on how to avoid this conflict.
 

Data Volatility Options

Affects the generation of code for assignments to objects that are less than or equal to 16 bits in size (for instance char, short) that have been declared as volatile. The generated code includes a load-locked instruction for the enclosing longword or quadword, an insertion of the new value of the object, and a store-conditional instruction for the enclosing longword or quadword. By using this locked instruction sequence for byte and word stores, the -strong_volatile option allows byte and word access of data at byte granularity. This means that assignments to adjacent volatile small objects by different threads in a multithreaded program will not cause one of the objects to receive an incorrect value.

[The -strong_volatile option is not available when you use the -oldc option.] Affects the generation of code for assignments to objects that are less than or equal to 16 bits in size (for instance char, short) that have been declared as volatile. The generated code includes a read of the enclosing longword or quadword, an insertion of the new value of the object, and a store of the enclosing longword or quadword.
The weak_volatile option does not generate locked instructions for this sequence. This allows byte or word access to memory-like I/O devices for which larger accesses will not cause read or write side effects. Because the sequence does not access byte or word data independently directly in memory (that is, ensure byte granularity), adjacent volatile data can be corrupted when such byte or word accesses are performed in a multithreaded environment (for example, two volatile shorts stored in a longword and accessed asynchronously).
[The -weak_volatile option is not available when you use the -oldc option.]
 

C Language Options

Promotes expressions of type float to double. This is the default when -std0 is used. Prevents the compiler from promoting expressions of type float to type double. This is the default for all -std levels other than 0. Causes the C front end to inspect the floating-point value and treat the value as a float if it can be represented as a single precision value. By default, all floating-point constants are treated as double precision.

To ensure that this change has no impact on standards conformance, the -float_const option is disabled when -std1 (strict ANSI mode) is also specified on the compile command line. When this situation occurs, the compiler issues a warning message indicating that the -float_const option is being ignored. Causes all string literals to be read-only. This is the default.
This option overrides -writable_strings. If you attempt to write to a string literal when -readonly_strings is specified, you might experience unpredictable results, such as a segmentation fault. Causes all char declarations to have the same representation and range of values as signed char declarations. This is used to override a previous -unsigned option. This is the default. Causes all char declarations to have the same representation and range of values as unsigned char declarations. Prints warnings for all lines that may require the <varargs.h> macros. Causes all variables to be treated as volatile. Causes all string literals to be writable. This is the default.
This option overrides -readonly_strings.
 

Rounding-mode Options (IEEE Floating Point)

Specifies chopped rounding mode (round toward zero). 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. Specifies normal rounding mode (unbiased round to nearest). This is the default. Specifies round toward minus infinity mode.
 

Stack-handling and Pointer-handling Options

Forces all uninitialized stack variables to be initialized with 0xfff58005fff58005. When this value is used as a floating-point variable, it is treated as a floating-point NaN and causes a floating-point trap. When it is used as a pointer, an address or segmentation violation usually occurs.

For programs compiled without the -trapuv switch, the debugger stops only on executable statements in which the value of a specified variable changes. With the -trapuv switch, the debugger stops on these statements and also stops on all local variable declarations. (The debugger treats the local variable declarations as assignment statements because the variables are initialized by the compiler.) Controls pointer size allocation by directing the compiler to respond to the #pragma pointer_size preprocessor directives. This option allows you to specify 32-bit pointers when used in conjunction with the pragma pointer_size directive. To use 32-bit pointers, you must place pragmas where appropriate in your program. Images built with this option must be linked with the -xtaso or -taso option in order to run correctly. See the Programmer's Guide for information on #pragma pointer_size. Directs the compiler to allocate 32-bit pointers by default. You can still use 64-bit pointers, but only by the use of 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. Makes all procedures in the source file use $fp (register 15) as the frame pointer.
 

IEEE Floating-point Support Options

Generates instructions that do not trigger floating-point underflow or inexact trapping modes. Any floating point overflow, divide-by-zero, or invalid operation will unconditionally generate a trap. The -fptm n option is the default. Generates traps on floating-point underflow as well as overflow, divide-by-zero, and invalid operation. Ensure support of all portable features of the IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985), including the treatment of denormalized numbers, NaNs, and infinities and the handling of error cases. This option also sets the _IEEE_FP C preprocessor macro.

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

Ucode Generation Options (Enabled by -oldc)

Compiles the specified source programs and leaves the ucode object file output in corresponding files suffixed with .u. This option is not available with the -newc and -migrate options. Passes options that start with a -k to the ucode loader. This option is used to specify ucode libraries (with -kl filename) and other ucode loader options. Names the output file created by the ucode loader as output. This file is not removed. If this file is compiled, the object file is left in a file whose name consists of output with the suffix changed to .o. If output has no suffix, a .o suffix is appended to output. This option is not available with the -newc and -migrate options.
 

Compiler Development Options (Not Generally Used)

Halts compiling after the pass specified by the character c, producing an intermediate file for the next pass. The c character can be one of the following: [ fjusmoca ]. 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 compilation is halted. 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 file for binary ucode produced by the front end). These intermediate files are never removed, even when a pass encounters a fatal error. When ucode linking is performed and the -K 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. Passes the argument, or arguments (argi), to the compiler pass, or passes (c[c...]). Each c character can be one of the following: [ pfjusdqmocablyz ]. The c selects the compiler pass in the same way as the -t option.

The options from the set -t[hpfjusmocablyzrntLCD], -hpath, and -Bstring select a name to use for a particular pass, startup routine, or standard library. These arguments are processed from left to right, so their order is significant. When the -B option is encountered, the selection of names takes place using the last -h and -t options. Therefore, the -B option is always required when using -h or -t. Sets of these options can be used to select any combination of names.

All -B options must be preceded by -p options. The -p option provides the location of startup routines and the profiling library.

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


-oldc Name-newc NameCharacter

includeh (see note following table)
cfegemc_ccp, f
ujoinj
uldu
usplits
umergem
uopto
ugenc
as0as0a
as1as1b
ldldl
ftocy
cordcordz
[m]crt0.o[m]crt0.or
libprof1.alibprof1.an
btou, utobt
omomL
pixiepixieC
profprofD

If the character h is in the -t argument, a directory is added to the list of directories to be used in searching for header files. The name of this directory has the form $COMP_TARGET_ROOT/usr/include/string. This directory is to contain the header files for the string release of the compiler. The standard directory is still searched. Use path instead of the directory where the name is normally found. Append string to all names specified by the -t option. If no -t option has been processed before the -B, the -t option is assumed to be hpfjusmocablyzrntL. This list designates all names.

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

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

DESCRIPTION

Note

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

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

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

You can access the ``newc'' compiler with either the -newc option or the -migrate option; however, the default options associated with these two options are different: The default options associated with the -newc option are similar to the defaults associated with the -oldc option. The default options associated with the -migrate option are the same as those previously associated with the -migrate option in the compilation environment for versions of the DEC OSF/1 operating system preceding Tru64 UNIX Version 4.0.

The ability to access the ``newc'' compiler with the -migrate option was retained in the Tru64 UNIX system's compilation environment so that prior users of -migrate can continue to use the compiler in the same way that they did previously (that is, the same command line accesses the same compiler with the same defaults).

The cc command can accept any of the following file 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.

When you use the -oldc option, the compiler accepts the following additional file arguments: Arguments whose names end with .c are compiled into ucode object files when -oldc's highest level of optimization is specified (-O3 option) or when only ucode object files are to be produced (-j option). The ucode object file is left in a file whose name consists of the last component of the source with .u substituted for .c. Arguments whose names end with .B, .O, .S, and .M are assumed to be binary ucode, produced by the front end, optimizer, ucode object file splitter, and ucode merger, respectively. Arguments whose names end with .U are assumed to be symbolic ucode. Arguments whose names end with .G are assumed to be binary assembly language, which is produced by the code generator and the symbolic to binary assembler. These files primarily aid in compiler development and are not generally used. Files that are assumed to be binary ucode, symbolic ucode, or binary assembly language by the suffix conventions are also assumed to have their corresponding symbol table in a file with a .T suffix.

The cc command can accept 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, -kl, -l, -none, -non_hidden, and -no_archive), it maintains their relative order for the linker. This reference 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 invoked with the -oldc option, it can also produce binary assembly language code, binary ucode, or symbolic ucode.

When the compiler is invoked, it defines C preprocessor macros that identify the language of the input files and the environments in which the code can run. You can reference these macros in #ifdef statements to isolate code that applies to a particular language or environment. The preprocessor macros are listed in the following table. Note that the type of standards you apply and the type of source file determine which macros are defined.


MacroSource File Type-std option

__DECC (-newc and -migrate only) .c
LANGUAGE_C.c-std0
__LANGUAGE_C__.c -std0, -std, -std1
unix.c, .s-std0
__unix__.c, .s -std0, -std, -std1
__osf__.c, .s -std0, -std, -std1
__alpha.c, .s -std0, -std, -std1
__arch64__.c, .s -std0, -std, -std1
__digital__.c, .s -std0, -std, -std1
SYSTYPE_BSD.c, .s-std0
_SYSTYPE_BSD.c, .s -std0, -std, -std1
LANGUAGE_ASSEMBLY.s -std0, -std, -std1
__LANGUAGE_ASSEMBLY__.s -std0, -std, -std1

You can explicitly define macros with the -D option to control which functions 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 DEC C users to establish a set of compilation options that are applied to subsequent compilation on a per-user basis.

The DEC_CC environment variable can contain two distinct sets of compilation options separated by a single vertical bar (|). The options before the vertical bar are known as prologue options and the options after the bar are know as epilogue options.
The DEC_CC environment variable can begin or end with a vertical bar, or have no vertical bar at all. If no vertical bar is present, the options are treated as prologue options by default. Any vertical bar found after the first vertical bar is treated as whitespace and a warning is issued.

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

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

ERRORS

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

EXAMPLES

Compile the file helloworld.c using the compiler's defaults. Because no output file is named in the command line, the result of the compilation is written to the executable file named a.out. cc helloworld.c This example invokes the C compiler with the -newc option. The -v option displays the name of each compilation pass, and its arguments, as it executes. cc -newc -v helloworld.c /usr/lib/cmplrs/cc/gemc_cc -D__LANGUAGE_C__ -D__unix__ -D__osf__ -D__alpha -D_S YSTYPE_BSD -D_LONGLONG -D__digital__ -D__arch64__ -I/usr/include -v -preempt_module -intrinsics -g0 -O2 -std -noansi_alias -o hello.o hello.c These macros are in effect at the start of the ---------------------------------------------- compilation. ------------- D__DECC -D__osf__ -D__arch64__ -D__PRAGMA_ENVIRONMENT -D_LONGLONG -D__digital__ -D__X_FLOAT -D__DATE__="Jan 28 1998" -D__DECC_MODE_RELAXED -D__DECC_VER=50760700 -D_SYSTYPE_BSD -D__ALPHA -D__IEEE_FLOAT -D__unix__ -D__TIME__="15:23:28" -D__Alpha_AXP -D__INITIAL_POINTER_SIZE=0 -D__STDC__=0 -D__LANGUAGE_C__ -D__alpha /usr/lib/cmplrs/cc/gemc_cc: 0.00u 0.02s 0:00 16% 0+9k 0+8io 0pf+0w 9stk+1032mem /usr/lib/cmplrs/cc/ld -g0 -O1 -call_shared /usr/lib/cmplrs/cc/crt0.o hello.o -lc /usr/lib/cmplrs/cc/ld: 0.01u 0.02s 0:00 17% 0+8k 0+15io 0pf+0w 8stk+1224mem


 

ENVIRONMENT VARIABLES

The following environment variables can affect compiler operation: Provides a default value for locale variables that are not set. If any of these variables contains an invalid setting, the compiler behaves as if none were set. If set to a non-empty string, this variable overrides values in all locale variables, including LANG. Determines the locale for the interpretation of sequences of bytes of text data as characters (for example, single- as opposed to multi-byte characters in arguments and input files). Determines the locale used for diagnostic messages. Determines the locale of message catalogs for the processing of LC_MESSAGES. Provides a pathname that overrides the default directory for temporary files, if any.

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

FILES

Input file Object file Loaded output Compiler error messages in English Temporary Compiler configuration file (optional) C front end C macro preprocessor DEC C compiler Binary ucode and symbol table joiner Ucode loader Binary ucode and symbol table splitter Procedure integrator Optional global ucode optimizer Post-link optimizer Code generator Symbolic to binary assembly language translator Binary assembly language assembler and reorganizer Run-time startup Startup for prof profiling Startup for gprof profiling Standard library, see intro(3) Level 1 profiling library Reentrant level 1 profiling library for code compiled with -pthread or -threads Standard directory for header files Interface between prof and cord Procedure-rearranger Binary to symbolic ucode translator Symbolic to binary ucode translator File produced for analysis by prof File produced for analysis by gprof
 

SEE ALSO

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

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

DEC C Language Reference Manual


 

Index

NAME
SYNOPSIS
Default Options:
OPTIONS
Compiler Selection Options
Overall Compiler Behavior Options
C Preprocessor Options
Linker or Loader Options
Optimization Options
Feedback-directed Optimization Options
Source-code Debugging Options
Program Profiling Options
Code Portability Options
Data Alignment Options
Data Volatility Options
C Language Options
Rounding-mode Options (IEEE Floating Point)
Stack-handling and Pointer-handling Options
IEEE Floating-point Support Options
Ucode Generation Options (Enabled by -oldc)
Compiler Development Options (Not Generally Used)
DESCRIPTION
ERRORS
EXAMPLES
ENVIRONMENT VARIABLES
FILES
SEE ALSO

This document was created by man2html, using the manual pages.
Time: 02:42:46 GMT, October 02, 2010