The DEC C compiler performs the following functions:
The following sections discuss the CC command and its qualifiers.
To invoke the DEC C compiler, enter the CC command at the DCL prompt ($). The CC command has the following format:
CC[/qualifier...][ file-spec [/qualifier...]],...
You can include more than one file specification on the same command line by separating the file specifications with either a comma (,) or a plus sign (+). If you separate the file specifications with commas, you can control which source files are affected by each qualifier. In the following example, the DEC C compiler creates an object file for each source file but creates only a listing file for the source files PROG_1 and PROG_3:
$ CC /LIST PROG_1, PROG_2/NOLIST, PROG_3
If you separate file specifications with plus signs, the DEC C compiler concatenates each of the specified source files and creates one object file and one listing file. In the following example, only one object file is created, PROG_1.OBJ, and only one listing file is created, PROG_1.LIS. Both of these files are named after the first source file in the list, but contain all three modules.
$ CC PROG_1 + PROG_2/LIST + PROG_3
Any qualifiers specified for a single file within a list of files separated with plus signs affect all the files in the list. See the description of the /PLUS_LIST_OPTIMIZE qualifier for its affect on file concatenation.
A more common use of plus-list concatenation is for specifying text libraries. You can specify the name of a text library on the CC command line to compile a source program. A text library is a file that contains text organized into modules indexed by a table. Text libraries have a .TLB default file extension. In the following example, text libraries A.TLB and B.TLB are made available for searching for text library modules during the compilation of source file TEST.C:
$ CC TEST.C + A.TLB/LIB + B.TLB/LIB
Header files are pieces of source code that typically contain declarations shared among C programs. A header file often declares a set of related functions, as well as defining any types and macros needed for their use.
To make the contents of a header file available to your program, include the header file using the #include preprocessor directive.
The #include directive has three forms. Two of the forms are defined by the ISO C standard and are portable:
#include <file-spec>
#include "file-spec"
The third form is the text-module form. It is specific to OpenVMS systems and is not portable. See Section 5.2.3 for more information on the text-module form of inclusion.
The form of the #include directive used determines where the compiler will look to find the file to be included. Generally, the compiler looks in the following places, in the order listed:
See the /INCLUDE_DIRECTORY qualifier in Section 1.3.4 for a more complete description of the search- order rules that DEC C uses to locate included files.
See the DEC C Run-Time Library Reference Manual for OpenVMS Systems for information on the header files required to use DEC C Run-Time Library (RTL) functions and macros.
To list the names of system header files, use the following commands:
$ LIBRARY/LIST SYS$LIBRARY:SYS$STARLET_C.TLB (OpenVMS Alpha and OpenVMS VAX Version 7.1 and higher) $ LIBRARY/LIST SYS$LIBRARY:DECC$RTLDEF.TLB $ DIR SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C]*.H; $ DIR SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF]*.H; $ DIR SYS$LIBRARY:*.H;
These commands list, respectively:
Be aware that OpenVMS VAX operating systems prior to Version 7.1 do not have a file named SYS$LIBRARY:SYS$STARLET_ C.TLB. For these older versions of the operating system, the STARLET header files are generated during DEC C installation and placed in SYS$LIBRARY:DECC$RTLDEF.TLB and also in both SYS$COMMON:[DECC$LIB.REFERENCE.DECC$RTLDEF] and SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C].
DEC C has two complementary qualifiers that control which dialect of C is to be recognized by the compiler, and which messages are generated:
The /STANDARD qualifier causes the compiler to issue only those warnings appropriate for the dialect of C being compiled. For example, VAX C compatibility mode (/STANDARD=VAXC) does not issue warnings against VAX C extensions, while ANSI C mode does.
The DEC C compiler for OpenVMS systems provides several dialects of C, which are controlled by the /STANDARD qualifier:
You can use /STANDARD=ANSI89 with /[NO]WARNINGS to control issuance of informational or warning messages. However, since the compiler does not recognize many VAX C or common C extensions when in strict ANSI mode (for example, VAX C keywords not beginning with two underscores), many of the messages normally associated with flagging VAX C and common C extensions are not produced.
Specifying /STANDARD=ISOC94 defines the predefined macro __STDC_VERSION__=199409L and enables digraph processing.
/STANDARD=PORTABLE is supported for VAX C compatibility only. It is equivalent to the recommended combination of qualifiers /STANDARD=RELAXED_ANSI89/WARNINGS=ENABLE=PORTABLE.
With one exception, the /STANDARD qualifier options are mutually exclusive. Do not combine them. The exception is that you can specify /STANDARD=ISOC94 with any other option except VAXC.
DEC C modules compiled in different modes can be linked and executed together.
The /STANDARD qualifier is further described in Section 1.3.4.
The /STANDARD=MS qualifier instructs the DEC C compiler to interpret your source code according to certain language rules followed by the C compiler provided with the Microsoft Visual C++ compiler product. However, compatibility with this implementation is not complete. The following sections describe the compatibility situations that DEC C recognizes. In most cases, these situations consist of relaxing a standard behavior and suppressing a diagnostic message.
Allow a declaration of a structure with no name 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. A similar capability is provided by the VAX C variant_struct and variant_union types.
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 typedefs.
For example:
typedef int typedefname; typedef int typedefname;
Allow typedefs 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);
}
ANSI C does not allow the & operator to produce an lvalue expression. The Microsoft relaxation allows & to produce an lvalue 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 on the default in effect.
For example, a pointer to char can be assigned to a pointer to signed char, assuming the command-line default of /NOUNSIGNED_CHAR:
signed char *a;
char *b;
f() {
b=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 typedefs 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 following list shows all the command qualifiers and their defaults available with the CC command. A description of each qualifier follows the list.
You can place command qualifiers either on the CC command line itself or on individual file specifications (with the exception of the /LIBRARY qualifier). If placed on a file specification, the qualifier affects only the compilation of the specified source file and all subsequent source files in the compilation unit. If placed on the CC command line, the qualifier affects all source files in all compilation units unless it is overridden by a qualifier on an individual file specification.
| Command Qualifiers | Default |
|---|---|
| /[NO]ANALYSIS_DATA[=file-spec] | /NOANALYSIS_DATA |
| /[NO]ANSI_ALIAS (Alpha only) | See text. |
| /ASSUME=(option[, . . . ]) | See text. |
| /[NO]CHECK[=(option,...)] (Alpha only) | /NOCHECK |
| /[NO]COMMENTS=option | See text. |
| /[NO]DEBUG[=(option[, . . . ])] | /DEBUG=(TRACEBACK,NOSYMBOLS) (Alpha only) |
| /DEBUG=(TRACEBACK,NOINLINE,NOSYMBOLS) (VAX only) | |
| /DECC | See text. |
| /[NO]DEFINE=(identifier[=definition][, . . . ]) | /NODEFINE |
| /[NO]DIAGNOSTICS[=file- spec] | /NODIAGNOSTICS |
| /ENDIAN=option (Alpha only) | /ENDIAN=LITTLE |
| /[NO]ERROR_LIMIT[=number] | /NOERROR_LIMIT (VAX only) |
| /EXTERN_MODEL=option | /EXTERN_MODEL=RELAXED_ REFDEF |
| /FLOAT=option | /FLOAT=G_FLOAT (Alpha only) |
| /FLOAT=D_ FLOAT (VAX only) | |
| /[NO]G_FLOAT | /G_FLOAT (Alpha only) |
| /NOG_FLOAT (VAX only) | |
| /GRANULARITY=option (Alpha only) | /GRANULARITY=QUADWORD |
| /[NO]INCLUDE_ DIRECTORY=(pathname[, . . . ]) | /NOINCLUDE_ DIRECTORY |
| /IEEE_MODE=option (Alpha only) | IEEE_ MODE=FAST |
| /INSTRUCTION_SET=[NO]FLOATING_ POINT (Alpha only) | /INSTRUCTION_SET=FLOATING_POINT |
| /L_DOUBLE_SIZE=option (Alpha only) | /L_DOUBLE_SIZE=128 |
| /LIBRARY | See text. |
| /[NO]LINE_DIRECTIVES | /LINE_DIRECTIVES |
| /[NO]LIST[=file-spec] | /NOLIST (interactive mode) |
| /LIST (batch mode) | |
| /[NO]MACHINE_ CODE[=option] | /NOMACHINE_CODE |
| /[NO]MEMBER_ALIGNMENT | /MEMBER_ALIGNMENT (Alpha only) |
| /NOMEMBER_ALIGNMENT (VAX only) | |
| /[NO]MMS_DEPENDENCIES=option | /NOMMS_ DEPENDENCIES |
| /NAMES=option | /NAMES=UPPERCASE |
| /NESTED_ INCLUDE_DIRECTORY[=option] | /NESTED_ INCLUDE_DIRECTORY=INCLUDE_FILE |
| /[NO]OBJECT[=file-spec] | /OBJECT |
| /[NO]OPTIMIZE[=(option[, . . . ])] | /OPTIMIZE |
| /PDSC_MASK=option (Alpha only) | See text. |
| /[NO]PLUS_LIST_OPTIMIZE (Alpha only) | /NOPLUS_LIST_OPTIMIZE |
| /[NO]POINTER_SIZE[=option] (Alpha only) | /NOPOINTER_SIZE |
| /PRECISION[=option] | See text. |
| /[NO]PREFIX_LIBRARY_ENTRIES[=(option[, . . . ])] | See text. |
| /[NO]PREPROCESS_ ONLY[=filename] | /NOPREPROCESS_ONLY |
| /REENTRANCY=option (Alpha only) | /REENTRANCY=TOLERANT |
| /ROUNDING_MODE=option (Alpha only) | /ROUNDING_MODE=NEAREST |
| /[NO]SHARE_GLOBALS | /NOSHARE_ GLOBALS |
| /SHOW[=(option[, . . . ])] | /SHOW=(NODICTIONARY, |
| NOEXPANSION, | |
| NOINCLUDE, | |
| NOINTERMEDIATE, | |
| NOSTATISTICS, | |
| NOTRANSLATION, | |
| SOURCE, | |
| TERMINAL) | |
| /[NO]STANDARD[=(option[, . . . ])] | /NOSTANDARD (equivalent to /STANDARD=RELAXED_ANSI89 ) |
| /[NO]TIE (Alpha only) | /NOTIE |
| /[NO]UNDEFINE=(identifier[, . . . ]) | /NOUNDEFINE |
| /[NO]UNSIGNED_CHAR | /NOUNSIGNED_CHAR |
| /VAXC (VAX only) | See text. |
| /[NO]VERSION | /NOVERSION |
| /[NO]WARNINGS[=(option[, . . . ])] | /WARNINGS |
The aliasing rules referred to 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"), then you must not allow the compiler to assume ANSI C aliasing rules. Otherwise, incorrect code might be generated.
The default is /NOANSI_ALIAS for the /STANDARD=VAXC and /STANDARD=COMMON compiler modes. The default is /ANSI_ALIAS for all other modes.
| Option | Usage |
|---|---|
| [NO]ACCURACY_SENSITIVE (Alpha only) | Specifies whether certain code transformations that affect floating-point operations are allowed. These changes may or may not affect the accuracy of the program's results. |
| [NO]ALIGNED_OBJECTS (Alpha only) | Controls an optimization for dereferencing pointers. |
| [NO]HEADER_TYPE_DEFAULT | Controls whether or not the default file-type mechanism for header files is enabled. |
| [NO]POINTERS_TO_GLOBALS (Alpha only) | Controls whether or not the compiler can safely assume that global variables have not had their addresses taken in code that is not visible to the current compilation. |
| [NO]WRITABLE_STRING_LITERALS | Stores string constants in a writable psect. Otherwise, such constants are placed in a nonwritable psect. |
[NO]ACCURACY_SENSITIVE (Alpha only)
The default is ACCURACY_SENSITIVE.
If you specify NOACCURACY_SENSITIVE, the compiler is free to reorder floating-point operations based on algebraic identities (inverses, associativity, and distribution). This allows the compiler to move divide operations outside of loops, which improves performance.
The default, ACCURACY_SENSITIVE, directs the compiler to use only certain scalar rules for calculations. This setting can prevent some optimizations.
If you use the /ASSUME=NOACCURACY_SENSITIVE qualifier, DEC C might reorder code (based on algebraic identities) to improve performance. The results can be different from the default (/ASSUME=ACCURACY_ SENSITIVE) because of how the intermediate results are rounded. However, the NOACCURACY_SENSITIVE results are not categorically less accurate than those gained by the default.
[NO]ALIGNED_OBJECTS (Alpha only)
The default is /ASSUME=ALIGNED_OBJECTS.
On OpenVMS 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, the compiler can generate more optimized code if it makes the assumption that a pointer object of an aligned pointer type does point to an aligned object.
Since the compiler determines the alignment of the dereferenced object from the type of the pointer, and the program is allowed to compute a pointer that references an unaligned object (even though the pointer type indicates that it references an aligned object), the compiler must assume that the dereferenced object's alignment matches or exceeds the alignment indicated by the pointer type. Specifying /ASSUME=ALIGNED_OBJECTS (the default) allows the compiler to make such an assumption. With this assumption made, the compiler can generate more efficient code for pointer dereferences of aligned pointer types.
To prevent the compiler from assuming the pointer type's alignment for objects that it points to, use the /ASSUME=NOALIGNED_OBJECTS qualifier.
Before deciding whether to specify /ASSUME=NOALIGNED_OBJECTS or /ASSUME=ALIGNED_OBJECTS, you need to know what programming practices will affect your decision.
The compiler assumes that pointers point to objects that are aligned at least as much as the alignment of the pointer type. For example:
If your module breaks this rule, your program will suffer alignment faults at runtime that can seriously degrade performance. If you can identify the places in your code where the rule is broken, use the __unaligned type qualifier. Otherwise, the /ASSUME=NOALIGNED_ OBJECTS qualifier effectively treats all dereferences as if they were unaligned.
DEC C for OpenVMS Alpha Systems aligns all nonmember declarations on natural boundaries, so by default all objects do comply with the previous assumption. Also, the standard library routine malloc on OpenVMS systems returns quadword-aligned heap memory.
A program can violate the previous assumption in any of the following ways:
The following example explicitly specifies a lesser alignment for an object than the pointer type's alignment, which occurs when the address of an unaligned int member of a struct with #pragma nomember_alignment is used in a pointer dereference:
#pragma nomember_alignment
struct foo {
char C;
int i; /* i is unaligned because of char C */
};
struct foo st;
int *i_p;
i_p = &st.i;
... *i_p ... /* An expression containing a dereferenced i_p */
This example casts a pointer to a pointer type with stricter alignment:
int *i_p; char *c_p; ....... ....... i_p = (int *)c_p; ... *i_p ... /* An expression containing a dereferenced i_p */
The following example encloses a member-aligned object inside a nonmember-aligned object:
#pragma member_alignment
struct inside {
int i; /* this type asserts that its objects have at least
longword alignment (int is a longword)... */
};
#pragma nomember_alignment
struct outside {
char C;
struct inside s; /* ...but foo_ptr -> s is only byte-aligned! */
} *foo_ptr;
The expression foo_ptr -> s has a type whose alignment is explicitly specified to be longword (because longword is the strictest alignment of the structure's members), but the expression type is only guaranteed to be byte-aligned.
Also note that just as the pointer type information can direct the compiler to generate the appropriate code to dereference the pointer (code that does not cause alignment faults), it can also direct the compiler to generate even better code if it indicates that the object is at least longword-aligned.
The default is /ASSUME=HEADER_TYPE_DEFAULT.
In previous versions of DEC C, the #include directive always supplied a default file type of .h for C compilations. Similarly, DEC C++ supplied a default file type of .hxx for C++ compilations.
However, the ANSI C++ standard requires that, for example, #include <iostream> be distinguishable from #include <iostream.hxx>. This is not possible with the header file-type default mechanism in effect.
You can disable the type default mechanism for either DEC C or DEC C++ by specifying /ASSUME=NOHEADER_TYPE_DEFAULT.
With /ASSUME=NOHEADER_TYPE_DEFAULT specified, an #include directive written with the standard syntax for header name (enclosed in quotes or angle brackets) will use the filename as specified, without supplying a default file type. More precisely stated, the default file type will be empty (just ".").
For example, a directory might contain three files named IOSTREAM., IOSTREAM.HXX, and IOSTREAM.H. By default, the C++ compiler processes #include <iostream> such that the file IOSTREAM.HXX is found, while the C compiler would find IOSTREAM.H.
However, if /ASSUME=NOHEADER_TYPE_DEFAULT is specified, the same directive causes the file IOSTREAM. to be found by both compilers, and the only way to include the file named IOSTREAM.HXX or IOSTREAM.H is to specify the .hxx or .h file type explicitly in the #include directive. Be aware that while the OpenVMS operating system treats filenames as case-insensitive and normally displays them in uppercase, filenames in #include directives should use lowercase for best portability. This is more in keeping with other C and C++ implementations.
[NO]POINTERS_TO_GLOBALS (Alpha only)
The default is /ASSUME=POINTER_TO_GLOBALS, which directs the compiler to assume that global variables have had their addresses taken in separately compiled modules and that, in general, any pointer dereference could be accessing the same memory as any global variable. This is often a significant barrier to optimization.
The /ANSI_ALIAS command-line qualifier allows some resolution based on data type, but /ASSUME=NOPOINTER_TO_GLOBALS provides significant additional resolution and improved optimization in many cases.
/ASSUME=NOPOINTER_TO_GLOBALS tells the compiler that any global variable accessed through a pointer in the compilation must have had its address taken within that compilation. The compiler can see any code that takes the address of an extern variable. If it does not see the address of the variable being taken, the compiler can assume that no pointer points to the variable.
Consider the following code sequence:
extern int x; ... int *p; ... *p = 3;
Under /ASSUME=NOPOINTERS_TO_GLOBALS, the compiler can assume that x is not changed by the assignment through p when generating code. This can lead to faster code.
In combination with the /PLUS_LIST_OPTIMIZE qualifier, several source modules can be treated as a single compilation for the purpose of this analysis. Because run-time libraries such as the DEC C RTL do not take the addresses of global variables defined in user programs, source modules can often be combined into a single compilation that allows /ASSUME=NOPOINTER_TO_GLOBALS to be used effectively.
Be aware that /ASSUME=NOPOINTERS_TO_GLOBALS does not tell the compiler that the compilation never uses pointers to access global variables (which is seldom true of real C programs).
For /STANDARD=VAXC or /STANDARD=COMMON, the default is /ASSUME=WRITABLE_STRING_LITERALS.
For all other compiler modes, the default is /ASSUME=NOWRITABLE_ STRING_LITERALS.
Use /CHECK=UNINITIALIZED_VARIABLES to initialize all automatic variables to the value 0xfffa5a5afffa5a5a. This value is a floating NaN and, if used, causes a floating-point trap. If used as a pointer, this value is likely to cause an ACCVIO.
Use /CHECK=POINTER_SIZE to direct the compiler to generate code that checks 64-bit pointer values (used in certain contexts where 32-bit pointers are also present) to make sure they will fit in a 32-bit pointer. If such a value cannot be represented by a 32-bit pointer, the run-time code signals a range error (SS$_RANGEERR).
To control the types of pointer-size checks you want made, use one or more of the POINTER_SIZE option keywords shown in Table 1-3.
| Option | Usage |
|---|---|
| [NO]ASSIGNMENT | Check whenever a 64-bit pointer is assigned to a 32-bit pointer (including use as an actual argument). |
| [NO]CAST | Check whenever a 64-bit pointer is cast to a 32-bit pointer. |
| [NO]PARAMETER | Check all formal parameters at function startup to make sure that all formal parameters declared to be 32-bit pointers are 32-bit values. |
| ALL | Do all checks. |
| NONE | Do no checks. |
Omitting this qualifier defaults to /NOCHECK, which equates to /CHECK=(NOUNINITIALIZED_VARIABLE,NOPOINTER_SIZE).
Specifying /CHECK=POINTER_SIZE defaults to /CHECK=POINTER_ SIZE=(ASSIGNMENT,PARAMETER).
Specifying /CHECK defaults to /CHECK=(UNINITIALIZED_VARIABLES, POINTER_SIZE), which equates to /CHECK=(UNINITIALIZED_VARIABLES, POINTER_SIZE=(ASSIGNMENT,PARAMETER)).
For information about compiler features that affect pointer size, see the following:
The following contrived program contains a number of pointer assignments. The comment on each line indicates what /CHECK=POINTER_ SIZE keyword to specify to enable checking for that line.
#pragma required_pointer_size long
int *a;
char *b;
typedef char * l_char_ptr;
#pragma required_pointer_size short
char *c;
int *d;
foo(int * e) /* Check e if PARAMETER is specified. */
{
d = a; /* Check a if ASSIGNMENT is specified. */
c = (char *) a; /* Check a if CAST is specified. */
c = (char *) d; /* No checking ever. */
foo( a ); /* Check a if ASSIGNMENT is specified. */
bar( a ); /* No checking ever - no prototype */
b = (l_char_ptr) a; /* No checking ever. */
c = (l_char_ptr) a; /* Check a if ASSIGNMENT is specified */
b = (char *) a; /* Check if CAST is specified. */
}
Table 1-4 shows the /COMMENTS qualifier options.
| Option | Usage |
|---|---|
| AS_ IS | Specifies that the comment appears in the output file. |
| SPACE | Specifies that a single space replaces the comment in the output file. |
/NOCOMMENTS specifies that nothing replaces the comment in the output file. This can result in inadvertent token pasting.
The DEC C preprocessor might replace a comment at the end of a line or on a line by itself with nothing, even if /COMMENTS=SPACE is specified. Doing so does not change the meaning of the program.
The default is /COMMENTS=SPACE for the ANSI89, RELAXED_ANSI89, and MIA modes of the compiler. The default is /NOCOMMENTS for all other compiler modes.
Specifying /COMMENTS on the command line defaults to /COMMENTS=AS_IS.
The default on Alpha systems is /DEBUG=(TRACEBACK,NOSYMBOLS).
The default on VAX systems is /DEBUG=(TRACEBACK,NOINLINE, NOSYMBOLS).
Table 1-5 describes the debugger options.
| Option | Usage |
|---|---|
| ALL | Includes symbol table records and traceback records. This is equivalent to /DEBUG=INLINE. |
| INLINE (VAX only) | Generates debug information to cause a STEP command to STEP/INTO an inlined function call. |
| NOINLINE (VAX only) | Generates debug information to cause a STEP command to STEP/OVER an inlined function call. |
| NONE | Does not include any debugging information. This is equivalent to /NODEBUG. |
| NOTRACEBACK | Does not include traceback records. This option is used to exclude all extraneous information from thoroughly debugged program modules. This option is equivalent to /NODEBUG. |
| NOSYMBOLS | Includes only traceback records. This is the default if the /DEBUG qualifier is not present on the command line. |
| SYMBOLS | Includes symbol table records, but not the traceback records. |
| TRACEBACK | Includes only traceback records. This is the default if the /DEBUG qualifier is not present on the command line. |
On OpenVMS VAX systems, the CC command is used to invoke either the VAX C or DEC C compiler. If your system has a VAX C compiler already installed on it, the DEC C installation procedure provides the option of specifying which compiler will be invoked by default when just the CC command is used. To invoke the compiler that is not the default, use the CC command with the appropriate qualifier: CC /DECC for the DEC C compiler, or CC/VAXC for the VAX C compiler. If your system does not have a VAX C compiler installed on it, the CC command will invoke the DEC C compiler.
On OpenVMS Alpha systems, specifying /DECC is equivalent to not specifying it; this qualifier is supported to provide compatibility with DEC C on OpenVMS VAX systems.
Since /DEFINE and /UNDEFINE are not part of the source file, they are not associated with a listing line number or source line number. Therefore, when an error occurs in a command-line definition, the message displayed at the terminal does not indicate a line number. In the listing file, these diagnostic messages are placed before the source listing in the order that they were encountered. When the expansion of a definition causes an error at a specific source line in the program, the diagnostics-both at the terminal and in the listing file-are associated with that source line.
A command line containing the /DEFINE and the /UNDEFINE qualifiers can be long. Continuation characters cannot appear within quotes or they will be included in the macro stream. The length of a CC command line cannot exceed the maximum length allowed by DCL.
The /NODEFINE and /NOUNDEFINE qualifiers are provided for compatibility with other DCL qualifiers. You can use these qualifiers to cancel /DEFINE or /UNDEFINE qualifiers that you have specified in a symbol that you use to compile DEC C programs.
The defaults are /NODEFINE and /NOUNDEFINE.
Since the CC command line must be compatible with DCL, the syntax of the /DEFINE and /UNDEFINE qualifiers differs from the syntax of the #define and #undef preprocessor directives in the following way:
$ CC/DEFINE=TRUE #define TRUE 1
Note that the value of TRUE on the /DEFINE qualifier is automatically set to 1. Any other value must be specified. For example, the following are equivalent:
$ CC/DEFINE=MAYBE=2 #define MAYBE 2
$ CC/DEFINE=true #define TRUE 1
For example:
$ CC/DEFINE="true" ! Preserves lowercase $ CC/DEFINE="blank=' '" ! Contains and preserves the blank $ CC/DEFINE="f1=a+b" ! Contains a '+' character $ CC/DEFINE="funct(a)=2" ! Defines a function-like macro
$ CC/DEFINE="true=1" #define true 1
If a space is the delimiter, the following examples are equivalent:
$ CC/DEFINE="true =1" #define true =1
In this example, the space, preserved by the quotation marks, serves as the delimiter, assigning true a value of =1, which is clearly not intended.
$ CC/DEFINE= TRUE $ CC/DEFINE=(FALSE 0)
In the first example, DCL interprets TRUE as a file specification; in the second, DCL flags an invalid value specification.
You can pass an equal sign to the compiler in any of the following ways:
$ CC/DEFINE=(EQU==,"equ =","equal==")
In the first definition, the first equal sign is removed by DCL as the delimiter; the second equal sign is passed to the compiler. In the second example, the space is recognized as a delimiter because the definition is inside quotes; therefore, only one equal sign is required. In the third definition, the first equal sign is recognized as the delimiter and is removed; the second equal sign is passed to the compiler.
You can pass quotation marks in any of the following ways:
$ CC/DEFINE=(QUOTES="""","funct(b)=printf(")")
In both examples, DCL removes the first and last quotation marks before passing the definition to the compiler.
Here is a simple use of the /UNDEFINE qualifier to cancel a previous definition of TRUE:
$ CC/UNDEFINE=TRUE
The /UNDEFINE qualifier is useful for undefining the predefined DEC C preprocessor constants. For example, if you use a preprocessor system identification macro (such as __vaxc, __VAXC, __DECC, or __vms) to conditionally compile segments of DEC C specific code, you can undefine that constant to see how the portable sections of your program execute. Consider the following program:
main()
{
#if __DECC
printf("I'm being compiled with DEC C on an OpenVMS system.");
#else
printf("I'm being compiled on some other compiler.");
#endif
}
This program produces the following output:
$ CC EXAMPLE.C<Return> $ LINK EXAMPLE.OBJ<Return> $ RUN EXAMPLE.EXE<Return> I'm being compiled with DEC C on an OpenVMS system. $ CC/UNDEFINE="__DECC" EXAMPLE <Return> $ LINK EXAMPLE.OBJ<Return> $ RUN EXAMPLE.EXE<Return> I'm being compiled on some other compiler.
It controls whether big or little endian ordering of bytes is carried out in character constants. For example, consider the following declaration:
int foo = 'ABCD';
Specifying /ENDIAN=LITTLE places 'A' in the first byte, 'B' in the second byte, and so on.
Specifying /ENDIAN=BIG places 'D' in the first byte, 'C' in the second byte, and so on.
The default is /ENDIAN=LITTLE.
For example, assume the command line contains the following qualifiers:
/EXTERN_MODEL=STRICT_REFDEF="MYDATA"/NOSHARE
The compiler will behave as if the program begins with the following line:
#pragma extern_model strict_refdef "MYDATA" noshr
Table 1-6 describes the /EXTERN_MODEL qualifier options.
| Option | Usage |
|---|---|
| COMMON_BLOCK | Sets the compiler's extern_model to the common_block model. This is the model traditionally used for extern data by VAX C. |
| RELAXED_ REFDEF | Sets the compiler's extern_model to the
relaxed_refdef model. Some declarations are references and some
are definitions. Multiple uninitialized definitions for the same
object are allowed and are resolved into one by the linker. However,
a reference requires that at least one definition exist.
This is the model used by the portable C compiler (pcc) on UNIX systems. |
| STRICT_REFDEF [="name"] | Sets the compiler's extern_model
to the strict_refdef model. Some declarations are references and
some are definitions. There must be exactly one definition in the
program for any symbol referenced. The optional name, in
quotation marks, is the name of the psect for any definitions.
This is the model specified by ANSI C. Use it in a program that is to be a strict ANSI C conforming program. This model is the preferred alternative to the nonstandard storage- class keywords globaldef and globalref. |
| GLOBALVALUE | Sets the compiler's extern_model
to the globalvalue model. This model is similar to the strict_refdef
model except that these global objects have no storage; instead,
they are link-time constant values. There are two cases:
This model is the preferred alternative to the nonstandard storage- class keyword globalvalue. |
The default is /EXTERN_MODEL=RELAXED_REFDEF. This is different from VAX C, which uses the common block model for external objects.
On OpenVMS Alpha systems, representation of double variables defaults to G_floating format if not overridden by another format specified with the /FLOAT or /[NO]G_FLOAT qualifier.
If you are linking against object-module libraries, and /PREFIX=ALL is not specified on the command line:
The VAXCRTLX.OLB, VAXCRTLDX.OLB, and VAXCRTLTX.OLB libraries are used for the same floating-point formats, respectively, but include support for X_FLOAT format (/L_DOUBLE_SIZE=128). (Alpha only)
If /PREFIX=ALL is specified, then there is no need to link to the above- mentioned *.OLB object libraries. All the symbols you need are in STARLET.OLB. (Alpha only)
On OpenVMS VAX systems, representation of double variables defaults to D_floating format if not overridden by another format specified with the /FLOAT or /[NO]G_FLOAT qualifier. There is one exception: if /STANDARD=MIA is specified, G_floating is the default. If you are linking against object-module libraries, a program compiled with G_ floating format must be linked with the object library DECCRTLG.OLB. (VAX only)
Table 1-7 describes the /FLOAT qualifier options.
| Option | Usage |
|---|---|
| D_ FLOAT | double variables are represented in D_floating format. |
| G_FLOAT | double variables are represented in G_floating format. |
| IEEE_FLOAT (Alpha only) | float and double variables are represented in IEEE floating-point format (S_float and T_float, respectively). Use the /IEEE_MODE qualifier for controlling the handling of IEEE exceptional values. If /IEEE_MODE is not specified, the default behavior is /IEEE_MODE=FAST. |
If you specify /G_FLOAT, double variables are represented in G_ floating format.
If you specify /NOG_FLOAT, double variables are represented in D_ floating format. (See Section 4.5 for more information on the floating formats.)
On OpenVMS Alpha systems, representation of double variables defaults to G_floating format if not overridden by another format specified with the /FLOAT or /[NO]G_FLOAT qualifier.
If you are linking against object-module libraries, and /PREFIX=ALL is not specified on the command line:
The VAXCRTLX.OLB, VAXCRTLDX.OLB, and VAXCRTLTX.OLB libraries are used for the same floating-point formats, respectively, but include support for X_FLOAT format (/L_DOUBLE_SIZE=128). (Alpha only)
If /PREFIX=ALL is specified, then there is no need to link to the above- mentioned *.OLB object libraries. All the symbols you need are in STARLET.OLB. (Alpha only)
On OpenVMS VAX systems, representation of double variables defaults to D_floating format if not overridden by another format specified with the /FLOAT or /[NO]G_FLOAT qualifier. There is one exception: if /STANDARD=MIA is specified, G_floating is the default. If you are linking against object-module libraries, a program compiled with G_floating format must be linked with the object library DECCRTLG.OLB. (VAX only)
Granularity has two aspects: references inside a particular data segment and references between data segments.
The options are:
The default is /GRANULARITY=QUADWORD.
Table 1-8 describes the /IEEE_ MODE options.
| Option | Usage |
|---|---|
| FAST | During program execution, only finite values (no infinities, NaNs, or denorms) are created. Underflows and denormal values are flushed to zero. Exceptional conditions, such as floating-point overflow, divide-by-zero, or use of an IEEE exceptional operand are fatal. This is the default option. |
| UNDERFLOW_TO_ZERO | Generate infinities and NaNs. Flush denormalized results and underflow to zero without exceptions. |
| DENORM_RESULTS | Same as UNDERFLOW_TO_ ZERO, except that denorms are generated. |
| INEXACT | Same as DENORM_RESULTS, except that inexact values are trapped. This is the slowest mode, and is not appropriate for any sort of general-purpose computations. |
The default is /IEEE_MODE=FAST.
If one of the places is specified as an empty string, the compiler does not search any of its conventionally-named places:
Instead, it searches only places specified explicitly on the command line by the /INCLUDE_DIRECTORY and /LIBRARY qualifiers (or by the location of the primary source file, depending on the /NESTED_ INCLUDE_DIRECTORY qualifier). This behavior is similar to that obtained by specifying -I without a directory name to the Digital UNIX cc command.
The basic search order depends on the form of the header-file name (after macro expansion). Additional aspects of the search order are controlled by other command-line qualifiers and the presence or absence of logical name definitions.
Only the portable forms of the #include directive are affected by the pathnames specified on an /INCLUDE_DIRECTORY qualifier:
However, an empty string also affects the text-module form specific to OpenVMS systems (example: #include stdio).
Except where otherwise specified, searching a "place" means that the string designating the place is used as the default file-spec in a call to an RMS system service (for example, $SEARCH/$PARSE). The file-spec consists of the name in the #include directive without enclosing delimiters. The search terminates successfully as soon as a file can be opened for reading.
For the quoted form of inclusion, the search order is:
A place containing a "/" character is considered to be a UNIX- style name. If the name in the #include directive also contains a "/" character that is not the first character and is not preceded by a "!" character (it is not an absolute UNIX-style pathname), then the name in the #include directive is appended to the named place, separated by a "/" character, before applying the decc$to_ vms pathname translation function. The result of the decc$to_vms translation is then used as the filespec to try to open.
For the angle-bracketed form of inclusion, the search order is:
If the file is not found, perform the text library search described in the next step.
For any file type, the initial text libraries searched consist of those named on the command line with /LIBRARY qualifiers, searched in left-to-right order.
If the /INCLUDE_DIRECTORY qualifier contained an empty string, no further text libraries are searched. Otherwise, DECC$TEXT_LIBRARY is searched for all file types.
If DECC$LIBRARY_INCLUDE is defined as a logical name, then no further text libraries are searched. Otherwise, the subsequent libraries searched for each file type are:
Under /ASSUME=NOHEADER_TYPE_DEFAULT, the default file type is modified as usual.
For the text-module (nonportable) form of inclusion, the name can only be an identifier. It, therefore, has no associated file type.
The identifier is used as a module name to search the following:
The default for this qualifer is /NOINCLUDE_DIRECTORY.
The default is /INSTRUCTION_SET=FLOATING_POINT.
Specifying /L_DOUBLE_SIZE=64 treats all long double references as G_FLOAT, D_FLOAT, or T_FLOAT, depending on the value of the /FLOAT qualifier.
Specifying /L_DOUBLE_SIZE=128 treats all long double references as X_FLOAT.
The default is /L_DOUBLE_SIZE=128.
$ CC ONE + TWO + THREE/LIBRARY<Return>
Files ONE.C and TWO.C can contain references to modules in THREE.TLB. Consider the following example:
$ CC ONE + TWO + THREE/LIBRARY, FOUR<Return>
The file FOUR.C cannot contain references to modules in THREE.TLB since FOUR.C is located in a separate compilation unit separated by a comma. The placement of the library file specification does not matter. The following command lines are equivalent:
$ CC THREE/LIBRARY + ONE + TWO<Return> $ CC ONE + THREE/LIBRARY + TWO<Return> $ CC ONE + TWO + THREE/LIBRARY<Return>
The default is /LINE_DIRECTIVES.
By default, /LIST creates a listing file with the same name as the source file and with a file extension of .LIS. If you include a file specification with the /LIST qualifier, the compiler uses that specification to name the listing file.
In interactive mode, the default is /NOLIST. In batch mode, the default is /LIST. See the descriptions of the qualifiers /[NO]MACHINE_CODE, and /SHOW for related information. (For example, to suppress compiler messages to the terminal or to a batch log file, use the /SHOW=NOTERMINAL qualifier.)
On OpenVMS VAX systems, several formats exist to list machine code. Table 1-9 describes the /MACHINE_ CODE qualifier options.
| Option | Usage |
|---|---|
| AFTER | Causes the lines of machine code produced during compilation to print after all the source code in the listing. |
| BEFORE | Causes lines of machine code produced during compilation to print before any source code in the listing. |
| INTERSPERSED | Produces a listing consisting of lines of source code followed by the corresponding lines of machine code. This is the default option. |
On OpenVMS Alpha sytems, the format of the generated machine code listing is similar to what you would get using the AFTER keyword on OpenVMS VAX systems.
The default is /NOMACHINE_CODE.
Any use of the #pragma member_alignment or #pragma nomember_ alignment directives within the source code overrides the setting established by this qualifier. Specifying /NOMEMBER_ALIGNMENT causes data structure members to be byte-aligned (with the exception of bit-field members).
On OpenVMS Alpha systems, the default is /MEMBER_ALIGNMENT.
On OpenVMS VAX systems, the default is /NOMEMBER_ALIGNMENT.
See the description of #pragma [no]member_alignment in Section 5.4.9.
object_file_name :<tab><source file name>) object_file_name :<tab><full path to first include file>) object_file_name :<tab><full path to second include file>)
Table 1-10 shows the /MMS_ DEPENDENCIES qualifier options.
| Option | Usage |
|---|---|
| FILE[=filespec] | Specifies where to save the dependency file. The default file extension for a dependency file is .mms. Other than using this different default extension, /MMS_DEPENDENCY uses the same procedure that the /OBJECT and /LIST qualifiers do for determining the name of the output file. |
| [NO]SYSTEM_INCLUDE_FILES | Specifies whether or not to include dependency information about system include files (those included with #include <filename>.) If omitted, this option defaults to including dependency information about system include files. |
The default is /NOMMS_DEPENDENCY.
| Option | Usage |
|---|---|
| UPPERCASE | Converts to uppercase. |
| LOWERCASE | Converts to lowercase. |
| AS_IS | Leaves the case as specified in the source. |
The default is /NAMES=UPPERCASE. This provides the same behavior as VAX C does.
On OpenVMS Alpha systems, the /NAMES qualifier does not affect the names of the $ABS$, $BSS$, $CODE$, $DATA$, $LINK$, $LITERAL$, and $READONLY$ psects.
#include "file-spec"
Table 1-12 describes the /NESTED_ INCLUDE_DIRECTORY qualifier options.
| Option | Usage |
|---|---|
| PRIMARY_FILE | Directs the compiler to search the default file type for headers using the context of the primary source file (the .C file). This means that just the file type (".h" or ".") is used for the default file-spec, but the chain of "related file-specs" used to maintain the sticky defaults for processing the next top-level source file is also applied when searching for the include file. This most closely matches the behavior of VAX C. |
| INCLUDE_FILE | Directs the compiler to first search the directory of the source file containing the #include directive. If the file to be included is not found, the compiler continues searching by following normal inclusion rules. |
| NONE | Directs the compiler to skip the first step of processing #include "file.h" directives. The compiler starts its search for the include file in the /INCLUDE_DIRECTORY directories. It does not start by looking in the directory containing the including file or in the directory containing the top level source file. |
The default is /NESTED_INCLUDE_DIRECTORY=INCLUDE_FILE.
The compiler executes faster if it does not have to produce an object module. Use the /NOOBJECT qualifier when you need only a listing of a program or when you want the compiler to check a source file for errors. The default is /OBJECT.
You can specify the options described in Table 1-13.
| Option | Usage | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| [NO]DISJOINT (VAX only) | Optimizes the generated machine
code. For example, the compiler eliminates common subexpressions,
removes invariant expressions from loops, collapses arithmetic
operations into 3-operand instructions, and places local variables
in registers.
When debugging DEC C programs, use the /OPTIMIZE=NODISJOINT option if you need minimal optimization; if optimization during debugging is not important, use the /NOOPTIMIZE qualifier. | ||||||||||||
| [NO]INLINE (VAX only) | Provides automatic inline expansion of functions that yield optimized code when they are expanded. Whether or not a function is a candidate for inline expansion is based on its size, the number of times it is called, and whether it conforms to the rules specified in Section 5.4.6. | ||||||||||||
| [NO]INLINE[=keyword] (Alpha only) | Provides inline expansion of
functions that yield optimized code when they are expanded. Whether
or not a function is a candidate for inline expansion is based on
its size, the number of times it is called, and whether it conforms
to the rules specified in Section 5.4.6.
On OpenVMS Alpha systems, you can specify one of the following
keywords to control inlining:
The #pragma noinline preprocessor directive can be used to prevent inlining of any particular functions under the compiler-selected forms of inlining (SPEED, SIZE, or AUTOMATIC). The #pragma inline preprocessor directive (or the __inline storage- class modifier for OpenVMS Alpha systems) can be used to request inlining of specific functions under the AUTOMATIC or MANUAL forms of inlining. | ||||||||||||
| LEVEL=n (Alpha only) | Selects the level of optimization. Specify an integer from 0
(no optimization) to 4 (full optimization):
| ||||||||||||
| UNROLL=n (Alpha only) | Controls loop unrolling done by the optimizer. UNROLL=n means to unroll loop bodies n times, where n is between 0 and 16. UNROLL=0 means the optimizer will use its own default unroll amount. Specify UNROLL only at level 3 or higher. | ||||||||||||
| TUNE=keyword (Alpha only) | Selects processor-specific instruction
tuning for implementations of the Alpha architecture. Regardless of
the setting of the /OPTIMIZE=TUNE flag, the generated code will run
correctly on all implementations of the Alpha architecture. Tuning
for a specific implementation can provide improvements in run-time
performance. Code tuned for a specific target might run slower on
another target.
You can specify one of the following keywords:
|
For OpenVMS VAX systems the default, /OPTIMIZE, is equivalent to /OPTIMIZE=(DISJOINT,INLINE).
For OpenVMS Alpha systems the default, /OPTIMIZE, is equivalent to /OPTIMIZE=(INLINE=AUTOMATIC,LEVEL=4,UNROLL=0,TUNE=GENERIC).
Use /NOOPTIMIZE or /OPTIMIZE=LEVEL=0 (Alpha only) for a debugging session to ensure that the debugger has sufficient information to locate errors in the source program.
In most cases, using /OPTIMIZE will make the program execute faster. As a side effect of getting the fastest execution speeds, using /OPTIMIZE can produce larger object modules and longer compile times than /NOOPTIMIZE.
At optimization level 3 or above, DEC C attempts to unroll certain loops to minimize the number of branches and group more instructions together to allow efficient overlapped instruction execution (instruction pipelining). The best candidates for loop unrolling are innermost loops with limited control flow.
As more loops are unrolled, the average size of basic blocks increases. Loop unrolling generates multiple loop code iterations in a manner that allows efficient instruction pipelining.
The loop body is replicated a certain number of times, substituting index expressions. An initialization loop may be created to align the first reference with the main series of loops. A remainder loop may be created for leftover work.
The number of times a loop is unrolled can be determined by the optimizer or the user can specify the limit for loop unrolling using the /OPTIMIZE=UNROLL qualifier. Unless the user specifies a value, the optimizer unrolls a loop 4 times for most loops or 2 times for certain loops (large estimated code size or branches out the loop).
Software Pipelining (Alpha only)
Software pipelining and additional software dependence analysis are enabled by using /OPTIMIZE=LEVEL=5, which in certain cases improves run-time performance.
Loop unrolling (enabled at /OPTIMIZE=LEVEL=3 or higher) is constrained in that it cannot schedule across iterations of a loop. Because software pipelining can schedule across loop iterations, it can perform more efficient scheduling that eliminates instruction stalls within loops, by rearranging instructions between different unrolled loop iterations to improve performance.
For example, if software dependence analysis of data flow reveals that certain calculations can be done before or after that iteration of the unrolled loop, software pipelining reschedules those instructions ahead of or behind that loop iteration, at places where their execution can prevent instruction stalls or otherwise improve performance.
For this version of DEC C, loops chosen for software pipelining:
By modifying the unrolled loop and inserting instructions as needed before and/or after the unrolled loop, software pipelining generally improves run-time performance, except for cases where the loops contain a large number of instructions with many existing overlapped operations. In this case, software pipelining may not have enough registers available to effectively improve execution performance, and run-time performance using level 5 may not improve as compared to using level 4.
To determine whether using level 5 benefits your particular program, time program execution for the same program compiled at levels 4 and 5. For programs that contain loops that exhaust available registers, longer execution times may result with level 5.
In cases where performance does not improve, consider compiling using /OPTIMIZE=(UNROLL=1, LEVEL=5) to possibly improve the effects of software pipelining.
Ordinarily the PDSC$V_EXCEPTION_MODE field gets set automatically by the compiler, depending on the /IEEE_MODE qualifier setting. The /PDSC_MASK qualifier overrides the /IEEE_MODE qualifier setting of this field.
As shown in Table 1-14, the qualifier option keywords are exactly the allowed values defined in the OpenVMS Calling Standard for this field, stripped of the PDSC$V_EXCEPTION_ MODE prefix (for example, /PDSC_MASK=SIGNAL sets the field to PDSC$V_EXCEPTION_MODE_SIGNAL).
| Option | Maps to | Meaning |
|---|---|---|
| SIGNAL | PDSC$K_ EXCEPTION_MODE_SIGNAL | Raise exceptions for all except underflow (which is flushed to 0). |
| SIGNAL_ALL | PDSC$K_EXCEPTION_MODE_SIGNAL_ ALL | Raise exceptions for all. |
| SILENT | PDSC$K_EXCEPTION_MODE_SILENT | Raise no exceptions. Create only finite values: no infinities, no denorms, no NaNs. |
| FULL_IEEE | PDSC$K_EXCEPTION_MODE_FULL_IEEE | Raise no exceptions except as controlled by separate IEEE exception- enabling bits. Create exceptional values according to the IEEE standard. |
| CALLER | PDSC$K_ EXCEPTION_MODE_CALLER | Emulate the same mode as the caller. This is useful primarily for writing libraries that can be called from languages other than C. |
In the absence of the /PDSC_MASK qualifier, the compiler sets the PDSC$V_EXCEPTION_MODE field automatically, depending on the /IEEE_ MODE qualifier setting:
When you specify /PLUS_LIST_OPTIMIZE on the command line in conjunction with a series of file specifications separated by plus signs, the compiler does not concatenate each of the specified source files together; such concatenation is generally not correct for C code because a C source file defines a scope.
Instead, each file is treated separately for purposes of parsing, except that the compiler issues 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 and can perform optimizations across the source files.
The default is /NOPLUS_LIST_OPTIMIZE.
The default is /NOPOINTER_SIZE, which disables pointer-size features, such as the ability to use #pragma pointer_size, and directs the compiler to assume that all pointers are 32-bit pointers. This default represents no change over previous versions of DEC C.
Table 1-15 shows the /POINTER_SIZE qualifier options.
| Option | Usage |
|---|---|
| {SHORT|32} | The compiler assumes 32-bit pointers. |
| {LONG|64} | The compiler assumes 64-bit pointers. |
Specifying /POINTER_SIZE=32 enables pointer-size features and directs the compiler to assume that all pointers are 32-bit pointers.
Specifying /POINTER_SIZE=64 enables pointer-size features and directs the compiler to assume that all pointers are 64-bit pointers.
Specifying /POINTER_SIZE either alone or with a keyword value (32, 64, SHORT, or LONG) has the following effects:
For information about other compiler features that affect pointer size or warn about potential pointer size conflicts, see the following:
| Option | Usage |
|---|---|
| SINGLE | Performs floating-point operations in single precision. |
| DOUBLE | Performs floating-point operations in double precision. |
Your code may execute faster if it contains float variables and is compiled with /PRECISION=SINGLE. However, the results of your floating-point operations will be less precise. See the DEC C Language Reference Manual for more information on floating-point variables.
The default is /PRECISION=DOUBLE for /STANDARD=VAXC and /STANDARD=COMMON compiler modes.
The default is /PRECISION=SINGLE for /STANDARD=ANSI89 and /STANDARD=RELAXED_ANSI89 compiler modes.
The /[NO]PREFIX_LIBRARY_ENTRIES qualifier lets you control the DEC C RTL name prefixing. Table 1-17 describes the /PREFIX_LIBRARY_ENTRIES qualifier options.
| Option | Usage |
|---|---|
| EXCEPT = (name,...) | The names specified are not prefixed. |
| ALL_ENTRIES | All DEC C RTL names are prefixed. |
| ANSI_C89_ENTRIES | Only ANSI C library names are prefixed. |
| RTL="name" | Generates references to the C RTL indicated by the name keyword. (The name keyword has a length limit of 24 characters for OpenVMS VAX systems and 1017 characters for OpenVMS Alpha systems.) If no keyword is specified, then references to the DEC C RTL are generated by default. To use an alternate RTL, see its documentation for the name to use. |
If you want no names prefixed, specify /NOPREFIX_LIBRARY_ENTRIES.
On OpenVMS Alpha systems:
On OpenVMS VAX systems, the default is /PREFIX_LIBRARY_ENTRIES=(ALL_ ENTRIES), regardless of the /STANDARD setting.
If you do not specify a file name for the preprocessor output, the name of the output file defaults to the file name of the input file with a .I file type.
The default is /NOPREPROCESS_ONLY.
Table 1-18 describes the /REENTRANCY qualifier options.
| Option | Usage |
|---|---|
| AST | Uses the __TESTBITSSI built-in function to perform simple locking around critical sections of RTL code, and may additionally disable asynchronous system traps (ASTs) in locked region of codes. This type of locking should be used when AST code contains calls to DEC C RTL I/O routines. |
| MULTITHREAD | Designed to be used in conjunction with the DECthreads product. It performs DECthreads locking and never disables ASTs. |
| NONE | Gives optimal performance in the RTL, but does absolutely no locking around critical sections of RTL code. It should only be used in a single threaded environment when there is no chance that the thread of execution will be interrupted by an AST that would call the DEC C RTL. |
| TOLERANT | Uses the __TESTBITSSI built-in function to perform simple locking around critical sections of RTL code, but ASTs are not disabled. This type of locking should be used when ASTs are used and must be delivered immediately. |
The default is /REENTRANCY=TOLERANT.
| Option | Usage |
|---|---|
| NEAREST | Sets the normal rounding mode (unbiased round to nearest). This is the default. |
| DYNAMIC | Sets the rounding mode for IEEE floating-point instructions dynamically, as determined from the contents of the floating-point control register. |
| MINUS_INFINITY | Rounds toward minus infinity. |
| CHOPPED | Rounds toward 0. |
If /FLOAT=G_FLOAT or /FLOAT=D_FLOAT is specified, then rounding defaults to /ROUNDING_MODE=NEAREST, with no other choice of rounding mode.
Also, in conjunction with the /EXTERN_MODEL qualifier, controls whether the initial extern_model is shared or not shared (for those extern_models where it is allowed). The initial extern_model of the compiler is a fictitious pragma constructed from the settings of the /EXTERN_MODEL and /SHARE_GLOBALS qualifiers.
The default value is /NOSHARE_GLOBALS. This default value is different from VAX C, which treats external objects as shared by default. As a result, you may experience the following impact:
| Option | Usage |
|---|---|
| ALL | Prints all listing information. |
| [NO]DICTIONARY | Places CDD/Repository
definitions-included in the program with the #pragma dictionary
preprocessor directive-into the listing file. These data definitions
are marked in the listing file with an uppercase letter D in the
listing margin.
The NODICTIONARY option is the default. |
| [NO]EXPANSION | Places final macro expansions
in the program listing. When you specify this option, the number
printed in the margin indicates the maximum depth of macro
substitutions that occur on each line.
The NOEXPANSION option is the default. |
| [NO]HEADER | Produces the header lines at the top
of each page of a listing.
The HEADER option is the default. |
| [NO]INCLUDE | Places the contents of #include files
and modules in the program listing.
The NOINCLUDE option is the default. |
| [NO]INTERMEDIATE (VAX only) | Places all intermediate and final macro
expansions in the program listing.
The NOINTERMEDIATE option is the default. |
| NONE | Creates an empty listing file with only the header. If you specify this option on a CC command line that contains /LIST and /MACHINE_CODE, the compiler places machine code in the listing file. |
| [NO]SOURCE | Places the source program statements
in the program listing.
The SOURCE option is the default. |
| [NO]STATISTICS | Places compiler performance
statistics in the program listing.
The NOSTATISTICS option is the default. |
| [NO]TERMINAL (VAX only) | Displays compiler messages to the
terminal. Use /SHOW=NOTERMINAL to suppress compiler messages to
the terminal or to a batch log file.
The TERMINAL option is the default. |
| [NO]TRANSLATION (VAX only) | Places into the listing file all UNIX
system file specifications that the compiler translates to OpenVMS
file specifications. See the DEC C Run-
Time Library Reference Manual for OpenVMS Systems for more
information on file translation.
The NOTRANSLATION option is the default. |
| Option | Usage | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ANSI89 | Places the compiler in strict ANSI C Standard mode. | ||||||||||||||
| RELAXED_ANSI89 | Places the compiler in relaxed ANSI C Standard mode. | ||||||||||||||
| MS | Interprets source programs according to certain language rules followed by Microsoft's Visual C++ compiler. | ||||||||||||||
| ISOC94 | Places
the compiler in ISO C 94 mode, which enables digraph processing and
defines the macro __STDC_VERSION__=199409L.
Digraphs are pairs of characters that translate into a single character, much like trigraphs, except that trigraphs get replaced inside string literals, but digraphs do not. The digraphs are:
The ISOC94 option can be specified alone or in combination with any other option except VAXC. If specified alone, ISOC94 provides a default major mode of RELAXED_ANSI89. |
||||||||||||||
| COMMON | Places the compiler in common C mode. | ||||||||||||||
| VAXC | Places the compiler in VAX C mode. | ||||||||||||||
| PORTABLE | Places the compiler in RELAXED_ANSI89
mode, and enables the issuance of diagnostics that warn about any
nonportable usages encountered.
/STANDARD=PORTABLE is supported for VAX C compatibility only. It is equivalent to the recommended combination of qualifiers /STANDARD=RELAXED_ANSI89 /WARNINGS=ENABLE=PORTABLE. | ||||||||||||||
| MIA | Places the compiler in strict ANSI C
Standard mode with some behavior differences, as required by the MIA
standard:
Compiling a program with /STANDARD=MIA sets the __MIA predefined macro to 1. |
This qualifier directs the compiler to flag certain DEC C-specific constructs and DEC C relaxations of conventional C language constructs and rules. For example, the conversions from pointer to integer and back again are subject to more stringent tests when you specify /STANDARD=ANSI89.
The /STANDARD qualifier options are mutually exclusive. Do not combine them.
If you specify /STANDARD without an option, the default is /STANDARD= ANSI89.
The default is /NOSTANDARD, which is equivalent to /STANDARD= RELAXED_ANSI89.
With one exception, the /STANDARD qualifier options are mutually exclusive. Do not combine them. The exception is that you can specify /STANDARD=ISOC94 with any other option except VAXC.
DEC C modules compiled in different modes can be linked and executed together.
The CC command is used to invoke either the VAX C or DEC C compiler. If your system has a VAX C compiler installed on it, the DEC C installation procedure provides the option of specifying which compiler will be invoked by default when just the CC command is used. To invoke the compiler that is not the default, use the CC command with the appropriate qualifier: CC/DECC for the DEC C compiler, or CC/VAXC for the VAX C compiler.
If your system does not have a VAX C compiler installed on it, the CC command will invoke the DEC C compiler, and the /VAXC qualifier is not supported.
This qualifier makes it easier for you to report what compiler you are using.
CC/DECC/VERSION NL:
Table 1-21 describes the /WARNING qualifier options.
| Option | Usage |
|---|---|
| DISABLE=(message-list) | Suppresses the
issuance of the message identifiers or message group names listed.
See the ENABLE option description for a description of message-
list and a list of message group names.
Only messages of severity Warning (W) or Information (I) can be disabled. If the message has severity of Error (E) or Fatal (F), it is issued regardless of any attempt to disable it. |
| ENABLE=(message-list) | Enables
issuance of the message identifiers or message group names listed.
The message-list can be any one of the following:
|
| NOINFORMATIONALS | Suppresses informational messages. |
The SUMMARY informational message cannot be suppressed with /NOWARNINGS or /WARNINGS=NOINFORMATIONALS, but can be suppressed with the DISABLE option.
The default is /WARNINGS. This enables all diagnostic messages for the selected compiler mode except those in the PORTABLE and CHECK groups. The PORTABLE and CHECK groups must be explicitly enabled before their messages can be generated.
If there are errors in your source file when you compile your program, the DEC C compiler signals these errors and displays diagnostic messages. Reference the message, locate the error, and, if necessary, correct the error. See Appendix D or the online help for a list if all compiler diagnostic messages.
To display a particular compiler diagnostic message online, enter the following command:
$ HELP CC/DECC MESSAGE mnemonic<Return> (VAX only) $ HELP CC MESSAGE mnemonic<Return> (Alpha only)
To display a list of all message mnemonics, enter the following command:
$ HELP CC/DECC MESSAGE<Return> (VAX only) $ HELP CC MESSAGE<Return> (Alpha only)
Diagnostic messages have the following format:
%CC-s-ident, message-text
Listing line number m
At line number n in name
| F | Fatal error. The compiler stops executing when a fatal error occurs and does not produce an object module. You must correct the error before you can compile the program. |
| E | Error. The compiler continues, but does not produce an object module. You must correct the error before you can successfully compile the program. |
| W | Warning. The compiler produces an object module. It attempts to correct the error in the statement, but you should verify that the compiler's action is acceptable. Otherwise, your program may produce unexpected results. |
| I | Information. This message usually appears with other messages to inform you of specific actions taken by the compiler. No action is necessary on your part. |