Previous | Contents | Index |
The /ALIGNMENT qualifier controls the data alignment of numeric fields in common blocks and structures.
If you omit the /ALIGNMENT and /FAST qualifiers:
Although Compaq Fortran always aligns local data items on natural boundaries, certain data declaration statements and unaligned arguments can force unaligned data.
Use the /ALIGNMENT qualifier to control the alignment of fields associated with common blocks, derived-type structures, and record structures.
The compiler issues messages when it detects unaligned data by default (/WARNINGS=ALIGNMENT). For information about the causes of unaligned data and detection at run-time, see Section 5.3.
Unaligned data significantly increases the time it takes to execute a program, depending on the number of unaligned fields encountered. Specifying /ALIGNMENT=ALL (same as /ALIGNMENT=NATURAL) minimizes unaligned data. |
The qualifier has the following form:
/ALIGNMENT=
where: class =
|
STANDARD and MULTILANGUAGE are valid for class=COMMON (not class=RECORDS).
The /ALIGNMENT qualifier keywords specify whether the Compaq Fortran compiler should naturally align or arbitrarily pack the following:
class
Specifies the type of data blocks:
- COMMONS=rule applies to common blocks (COMMON statement); rule can be PACKED, STANDARD, NATURAL, or MULTILANGUAGE.
- RECORDS=rule applies to derived-type and record structures; rule can be PACKED or NATURAL. However, if a derived-type data definition specifies the SEQUENCE statement, the FORTRAN /ALIGNMENT qualifier has no effect on unaligned data, so data declaration order must be carefully planned to naturally align data.
- STRUCTURES=rule applies to derived-type and record structures; rule can be PACKED or NATURAL. For the Compaq Fortran language, STRUCTURES and RECORDS are the same (they may have a different meaning in other OpenVMS languages).
rule
Specifies the alignment for the specified class of data blocks:
- NATURAL requests that fields in derived-type and record structures and data items in common blocks be naturally aligned on up to 8-byte boundaries, including INTEGER (KIND=8) and REAL (KIND=8) data.
Specifying /ALIGNMENT=NATURAL is equivalent to any of the following:
/ALIGNMENT /ALIGNMENT=ALL /ALIGNMENT=(COMMONS=(NATURAL,NOMULTILANGUAGE), RECORDS=NATURAL)- PACKED requests that fields in derived-type and record structures and data items in common blocks be packed on arbitrary byte boundaries and not naturally aligned.
Specifying /ALIGNMENT=PACKED is equivalent to any of the following:
/ALIGNMENT=NONE /NOALIGNMENT /ALIGNMENT=(COMMONS=(PACKED,NOMULTILANGUAGE), RECORDS=PACKED)- STANDARD specifies that data items in common blocks will be naturally aligned on up to 4-byte boundaries (consistent with the FORTRAN-77, Fortran 90, and Fortran 95 standards).
The compiler will not naturally align INTEGER (KIND=8) and REAL (KIND=8) data declarations. Such data declarations should be planned so they fall on natural boundaries. Specifying /ALIGNMENT=COMMONS=STANDARD alone is the same as /ALIGNMENT=(COMMONS= (STANDARD,NOMULTILANGUAGE)),RECORDS=NATURAL).
You cannot specify /ALIGNMENT=RECORDS=STANDARD or /ALIGNMENT=STANDARD.- MULTILANGUAGE specifies that the compiler pad the size of common block program sections to ensure compatibility when the common block program section is shared by code created by other Compaq OpenVMS compilers.
When a program section generated by a Fortran common block is overlaid with a program section consisting of a C structure, linker error messages can result. This is because the sizes of the program sections are inconsistent; the C structure is padded and the Fortran common block is not.
Specifying /ALIGNMENT=COMMONS=MULTILANGUAGE ensures that Compaq Fortran follows a consistent program section size allocation scheme that works with Compaq C program sections that are shared across multiple images. Program sections shared in a single image do not have a problem. The equivalent Compaq C qualifier is /PSECT_MODEL=[NO]MULTILANGUAGE.
The default is /ALIGNMENT=COMMONS=NOMULTILANGUAGE, which also is the default behavior of Compaq Fortran 77 and is sufficient for most applications.
The [NO]MULTILANGUAGE keyword only applies to common blocks. You can specify /ALIGNMENT=COMMONS=[NO]MULTILANGUAGE, but you cannot specify /ALIGNMENT=[NO]MULTILANGUAGE.ALL
Specifying /ALIGNMENT=ALL is equivalent to /ALIGNMENT, /ALIGNMENT=NATURAL), or /ALIGNMENT=(COMMONS= (NATURAL,NOMULTILANGUAGE),RECORDS=NATURAL).NONE
Specifying /ALIGNMENT=NONE is equivalent to /NOALIGNMENT, /ALIGNMENT=PACKED, or /ALIGNMENT=(COMMONS=(PACKED, NOMULTILANGUAGE), RECORDS=PACKED).
Defaults depend on whether you specify or omit the /ALIGNMENT and /FAST qualifiers, as follows:
Command Line | Default |
---|---|
Omit /ALIGNMENT and omit /FAST | /ALIGNMENT=(COMMONS=(PACKED,NOMULTILANGUAGE), RECORDS=NATURAL) |
Omit /ALIGNMENT and specify /FAST | /ALIGNMENT=(COMMONS=(NATURAL,NOMULTILANGUAGE), RECORDS=NATURAL) |
/ALIGNMENT=COMMONS= rule | Use whatever the /ALIGNMENT qualifier specifies for COMMONS, but use the default of RECORDS=NATURAL |
/ALIGNMENT=RECORDS= rule | Use whatever the /ALIGNMENT qualifier specifies for RECORDS, but use the default for COMMONS (depends on whether /FAST was specified or omitted) |
You can override the alignment specified on the command line by using a cDEC$ OPTIONS directive, as described in the Compaq Fortran Language Reference Manual.
The /ALIGNMENT and /WARNINGS=ALIGNMENT qualifiers can be used together in the same command line.
For More Information:
The /ANALYSIS_DATA qualifier produces an analysis data file that contains cross-reference and static-analysis information about the source code being compiled.
Analysis data files are reserved for use by Compaq products such as, but not limited to, the Source Code Analyzer (SCA).
The qualifier has the following form:
/ANALYSIS_DATA[=filename.type] |
If you omit the file specification, the analysis file name has the name of the primary source file and a file type of ANA (filename.ANA).
The compiler produces one analysis file for each source file that it compiles. If you are compiling multiple files and you type in a file name, each analysis file is given that name (with an incremental version number).
If you do not specify the /ANALYSIS_DATA qualifier, the default is /NOANALYSIS_DATA.
For More Information:
On the Source Code Analyzer, see VAX Language-Sensitive Editor and VAX Source Code Analyzer User Manual.
2.3.5 /ARCHITECTURE --- Architecture Code Instructions
The /ARCHITECTURE qualifier specifies the type of Alpha architecture code instructions generated for a particular program unit being compiled; it uses the same options (keywords) as used by the /OPTIMIZE=TUNE qualifier (for instruction scheduling purposes).
OpenVMS Version 7.1 and subsequent releases provide an operating system kernel that includes an instruction emulator. This emulator allows new instructions, not implemented on the host processor chip, to execute and produce correct results. Applications using emulated instructions will run correctly, but may incur significant software emulation overhead at runtime.
All Alpha processors implement a core set of instructions. Certain Alpha processor versions include additional instruction extensions.
The qualifier has the following form:
/ARCHITECTURE=
|
GENERIC
Generates code that is appropriate for all Alpha processor generations. This is the default.Programs compiled with the GENERIC option run on all implementations of the Alpha architecture without any instruction emulation overhead.
HOST
Generates code for the processor generation in use on the system being used for compilation.Programs compiled with this option may encounter instruction emulation overhead if run on other implementations of the Alpha architecture.
EV4
Generates code for the 21064, 21064A, 21066, and 21068 implementations of the Alpha architecture. Programs compiled with the EV4 option run on all Alpha processors without instruction emulation overhead.EV5
Generates code for some 21164 chip implementations of the Alpha architecture that use only the base set of Alpha instructions (no extensions). Programs compiled with the EV5 option run on all Alpha processors without instruction emulation overhead.EV56
Generates code for some 21164 chip implementations that use the BWX (Byte/Word manipulation) instruction extensions of the Alpha architecture.Programs compiled with the EV56 option may incur emulation overhead on EV4 and EV5 processors, but still run correctly on OpenVMS Version 7.1 (or later) systems.
PCA56
Generates code for the 21164PC chip implementation that uses the BWX (Byte/Word manipulation) and MAX (Multimedia) instruction extensions of the Alpha architecture.Programs compiled with the PCA56 option may incur emulation overhead on EV4, EV5, and EV56 processors, but will still run correctly on OpenVMS Version 7.1 (or later) systems.
EV6
Generates code for the 21264 chip implementation that uses the following extensions to the base Alpha instruction set: BWX (Byte/Word manipulation) and MAX (Multimedia) instructions, square root and floating-point convert instructions, and count instructions.Programs compiled with the EV6 option may incur emulation overhead on EV4, EV5, EV56, and PCA56 processors, but will still run correctly on OpenVMS Version 7.1 (or later) systems.
The /ASSUME qualifier specifies a variety of assumptions:
The qualifier has the following form:
/ASSUME=
|
[NO]ACCURACY_SENSITIVE
If you use ACCURACY_SENSITIVE (the default unless you specified /FAST), the compiler uses a limited number of rules for calculations, which might prevent some optimizations.Specifying NOACCURACY_SENSITIVE allows the compiler to reorder code based on algebraic identities (inverses, associativity, and distribution) to improve performance. The numeric results can be slightly different from the default (ACCURACY_SENSITIVE) because of the way intermediate results are rounded. Specifying the /FAST qualifier (described in Section 2.3.18) changes the default to NOACCURACY_SENSITIVE.
Numeric results with NOACCURACY_SENSITIVE are not categorically less accurate. They can produce more accurate results for certain floating-point calculations, such as dot product summations.
For example, the following expressions are mathematically equivalent but may not compute the same value using finite precision arithmetic.
X = (A + B) - C X = A + (B - C)Optimizations that result in calls to a special reciprocal square root routine for expressions of the form 1.0/SQRT(x) or A/SQRT(B) are enabled only if /ASSUME=NOACCURACY_SENSITIVE is in effect.
[NO]ALTPARAM
Specifying the /ASSUME=ALTPARAM qualifier allows the alternate syntax for PARAMETER statements. The alternate form has no parentheses surrounding the list, and the form of the constant, rather than implicit or explicit typing, determines the data type of the variable. The default is /ASSUME=ALTPARAM.[NO]BUFFERED_IO
The /ASSUME=[NO]BUFFERED_IO qualifier is provided for compatibility with other platforms. On OpenVMS systems, the SET RMS command controls the number of output buffers.Specifying /ASSUME=BUFFERED_IO requests that buffered I/O be used for all Fortran logical units opened for sequential writing (default is NOBUFFERED_IO). On OpenVMS systems, this qualifier has an effect only if the system or process RMS default buffers are set to 1.
[NO]BYTERECL
Specifying the /ASSUME=BYTERECL qualifier:
- Indicates that the OPEN statement RECL value for unformatted files is in byte units. If you omit /ASSUME=BYTERECL, Compaq Fortran expects the OPEN statement RECL value for unformatted files to be in longword (4-byte) units.
- Returns the record length value for an INQUIRE by output item list (unformatted files) in byte units. If you omit /ASSUME=BYTERECL, Compaq Fortran returns the record length for an INQUIRE by output item list in longword (4-byte) units.
- Returns the record length value for an INQUIRE by unit or file name (unformatted files) in byte units if all of the following occur:
- You had specified /ASSUME=BYTERECL for the code being executed
- The file was opened with an OPEN statement and a RECL specifier
- The file is still open (connected) when the INQUIRE occurs.
If any one of the preceding conditions are not met, Compaq Fortran returns the RECL value for an INQUIRE in longword (4-byte) units.To specify /ASSUME=BYTERECL your application must be running on a system that has the associated Fortran Run-Time Library support. This support is provided by installing one of the following on the system where the application will be run:
- Compaq Fortran Version 7.0 or later
- OpenVMS Alpha Version 7.0 or later
If you specify /ASSUME=BYTERECL and your application is running on a system without the proper Run-Time Library support, it will fail with an INVARGFOR, Invalid argument to Fortran Run-Time Library error.
[NO]DUMMY_ALIASES
Specifies whether dummy (formal) arguments are permitted to share memory locations with COMMON block variables or other dummy arguments.If you specify DUMMY_ALIASES, the compiler must assume that dummy (formal) arguments to procedures share memory locations with other dummy arguments or with variables shared through use association, host association, or common block use.
These program semantics do not strictly obey the Fortran 90 and Fortran 95 Standards and slow performance.
If you use NODUMMY_ALIASES, the default, the compiler does not need to make these assumptions, which results in better run-time performance. However, omitting /ASSUME=DUMMY_ALIASES can cause some programs that depend on such aliases to fail or produce wrong answers.
You only need to compile the called subprogram with DUMMY_ALIASES.
If you compile a program that uses dummy aliasing with NODUMMY_ALIASES in effect, the run-time behavior of the program will be unpredictable. In such programs, the results will depend on the exact optimizations that are performed. In some cases, normal results will occur; however, in other cases, results will differ because the values used in computations involving the offending aliases will differ.
[NO]FP_CONSTANT
Specifies whether a single-precision constant assigned to a double-precision variable will be evaluated in double precision.If you use NOFP_CONSTANT, the default, a single-precision constant assigned to a double-precision variable is evaluated in single precision. The Fortran 90 and 95 standards require that the constant be evaluated in single precision.
If you specify FP_CONSTANT, a single-precision constant assigned to a double-precision variable is evaluated in double precision.
Certain programs created for FORTRAN-77 compilers (including Compaq Fortran 77) may show different results with FP_CONSTANT than when you use NOFP_CONSTANT, because they rely on single-precision constants assigned to a double-precision variable to be evaluated in double precision.
In the following example, if you specify FP_CONSTANT, identical values are assigned to D1 and D2. If you use NOFP_CONSTANT, Compaq Fortran will follow the standard and assign a less precise value to D1:
REAL (KIND=8) D1,D2 DATA D1 /2.71828182846182/ ! REAL (KIND=4) value expanded to double DATA D2 /2.71828182846182D0/ ! Double value assigned to double[NO]INT_CONSTANT
Specifies whether Compaq Fortran 77 or Fortran 90/95 semantics are used to determine the type for integer constants.If you specify /ASSUME=INT_CONSTANT, integer constants take their type from the value, as interpreted by Compaq Fortran 77.
If you specify /ASSUME=NOINT_CONSTANT, integer constants have Fortran 90/95 "default integer" type. This is the default.
[NO]MINUS0
Controls whether the compiler uses Fortran 95 standard semantics for the IEEE floating-point value of -0.0 (minus zero) in the SIGN intrinsic, if the processor is capable of distinguishing the difference between -0.0 and +0.0.The default is /ASSUME=NOMINUS0, which uses Fortran 90 and FORTRAN 77 semantics where the value -0.0 or +0.0 in the SIGN function is treated as an 0.0.
To request Fortran 95 semantics, specify /ASSUME=MINUS0 to allow use of the IEEE value -0.0 in the SIGN intrinsic and printing -0.0. This option applies only to programs compiled with the /FLOAT=IEEE_FLOAT qualifier.
[NO]SOURCE_INCLUDE
Controls whether the directory where the compiler searches for source files or text libraries specified by an INCLUDE statement is either:
- The current default directory (NOSOURCE_INCLUDE)
- The directory where the source file reside (SOURCE_INCLUDE)
The default, NOSOURCE_INCLUDE, indicates that the compiler should search in the current default directory.
Specifying SOURCE_INCLUDE causes the compiler to search the directory of the source file specified on the FORTRAN command line, instead of the current default directory.
You can specify additional directories for the compiler to search for module files, include files, or include libraries by using the /INCLUDE qualifier.
For More Information:
The /AUTOMATIC and /NOAUTOMATIC qualifiers are synonyms of /RECURSIVE
or /NORECURSIVE (see Section 2.3.35). This qualifier is provided for
Compaq Fortran 77 compatibility.
2.3.8 /BY_REF_CALL --- Character Literal Argument Passing
Specifying /BY_REF_CALL=routine-list indicates that character constants used as actual arguments in calls to the specified routines be passed by reference and not by character descriptor. This helps applications that pass quoted character constants to numeric dummy parameters, such as applications ported from OpenVMS VAX systems that rely on the OpenVMS VAX Linker to change the argument passing mechanism for character constant actual arguments.
By default, Compaq Fortran passes character constants used as actual arguments by the usual OpenVMS character descriptor mechanism.
You can specify a list of routines or use wildcard characters (such as an asterisk (*)) to indicate all routines, for example:
$ FORTRAN/BY_REF_CALL=(PROJA_ROUT,PROJB_ROUT) TEST.FOR $ FORTRAN/BY_REF_CALL=(*) APPLIC.FOR |
The first FORTRAN command requests special character constant actual argument handling for two specific routines. The second requests this for all routines. You can select routines whose names match certain characters and a wildcard, such as all routines that start with MY:
$ FORTRAN/BY_REF_CALL=(MY*) X.FOR |
The /CHECK qualifier requests certain error checking during program execution (run time). The compiler produces extra code that performs the checks.
The qualifier has the following form:
/CHECK=
|
[NO]BOUNDS
Controls whether run-time checking occurs for each dimension of an array reference or substring reference to determine whether it is within the range of the dimension specified by the array or character variable declaration.Specify BOUNDS to request array bounds and substring checking. With the default, NOBOUNDS, array bounds and substring checking does not occur.
[NO]FORMAT
Controls whether the run-time message number 61 (FORVARMIS) is displayed and halts program execution when the data type for an item being formatted for output does not match the format descriptor being used (such as a REAL data item with an I format).The default, FORMAT, causes FORVARMIS to be a fatal error and halts program execution.
Specifying NOFORMAT ignores the format mismatch, which suppresses the FORVARMIS error and allows program continuation.
If you omit /NOVMS and omit /CHECK=NOFORMAT, the default is /CHECK=FORMAT.
If you specify /NOVMS, the default is NOFORMAT (unless you also specify /CHECK=FORMAT).
[NO]FP_EXCEPTIONS
Controls whether run-time checking counts calculations that result in exceptional values. With the default, NOFP_EXCEPTIONS, no run-time messages are reported.Specifying FP_EXCEPTIONS requests reporting of the first two occurrences of each type of exceptional value and a summary run-time message at program completion that displays the number of times exceptional values occurred. Consider using FP_EXCEPTIONS when the /IEEE_MODE qualifier allows generation of exceptional values.
To limit reporting to only denormalized numbers (and not other exceptional numbers), specify UNDERFLOW instead of FP_EXCEPTIONS.
Using FP_EXCEPTIONS applies to all types of native floating-point data.
[NO]OUTPUT_CONVERSION
Controls whether run-time message number 63 (OUTCONERR) is displayed when format truncation occurs. Specifying /CHECK=NOOUTPUT_CONVERSION disables the run-time message (number 63) associated with format truncation. The data item is printed with asterisks. When OUTPUT_CONVERSION is in effect and a number could not be output in the specified format field length without loss of significant digits (format truncation), the OUTCONERR (number 63) error occurs.If you omit /NOVMS and omit /CHECK=NOOUTPUT_CONVERSION, the default is OUTPUT_CONVERSION.
If you specify /NOVMS, the default is NOOUTPUT_CONVERSION (unless you also specify /CHECK=OUTPUT_CONVERSION).
[NO]OVERFLOW
Controls whether run-time checking occurs for arithmetic overflow of all integer calculations (INTEGER, INTEGER with a kind parameter, or INTEGER with a length specifier). Specify OVERFLOW to request integer overflow checking.Real and complex calculations are always checked for overflow and are not affected by /NOCHECK. Integer exponentiation is performed by a routine in the mathematical library. The routine in the mathematical library always checks for overflow, even if NOOVERFLOW is specified.
With the default, NOOVERFLOW, overflow checking does not occur.
[NO]POWER
Specifying the /CHECK=NOPOWER qualifier allows certain arithmetic expressions containing floating-point numbers and exponentiation to be evaluated and return a result rather than cause the compiler to display a run-time message and stop the program. The specific arithmetic expressions include:
- 0.0 ** 0.0
- negative-value ** integer-value-of-type-real
For example, if you specify /CHECK=NOPOWER the calculation of the expression 0.0 ** 0.0 results in 1. The expression (--3.0) ** 3.0 results in --27.0.
If you omit /CHECK=NOPOWER for such expressions, an exception occurs, error message number 65 is displayed, and the program stops (default is /CHECK=POWER).
[NO]UNDERFLOW
Controls whether run-time messages are displayed for floating underflow (denormalized numbers) in floating-point calculations. Specifying UNDERFLOW might be used in combination with the /IEEE_MODE=DENORM_RESULTS qualifier. Specify UNDERFLOW to request reporting of the first two occurrences of denormalized numbers and a summary run-time message at program completion that displays the number of times denormalized numbers occurred.The default, NOUNDERFLOW, means that floating underflow messages are not displayed. To check for all exceptional values (not just denormalized numbers), specify /CHECK=FP_EXCEPTIONS.
ALL
Requests that all run-time checks (BOUNDS, FORMAT, FP_EXCEPTIONS, OUTPUT_CON2VERSION, OVERFLOW, and UNDERFLOW) be performed. Specifying /CHECK and /CHECK=ALL are equivalent.NONE
Requests no run-time checking. This is the default. Specifying /NOCHECK and /CHECK=NONE are equivalent.
For More Information:
Previous | Next | Contents | Index |