| 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 HP 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 HP 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 HP 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,SEQUENCE)- 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,NOSEQUENCE)- 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 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 HP Fortran follows a consistent program section size allocation scheme that works with HP C program sections that are shared across multiple images. Program sections shared in a single image do not have a problem. The equivalent HP 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.[NO]SEQUENCE
Specifying /ALIGNMENT=SEQUENCE means that components of derived types with the SEQUENCE attribute will obey whatever alignment rules are currently in use. The default alignment rules align components on natural boundaries.The default value of /ALIGNMENT=NOSEQUENCE means that components of derived types with the SEQUENCE attribute will be packed, regardless of whatever alignment rules are currently in use.
Specifying /FAST sets /ALIGNMENT=SEQUENCE so that components of derived types with the SEQUENCE attribute will be naturally aligned for improved performance. Specifying /ALIGNMENT=ALL also sets /ALIGNMENT=SEQUENCE.
ALL
Specifying /ALIGNMENT=ALL is equivalent to /ALIGNMENT, /ALIGNMENT=NATURAL), or /ALIGNMENT=(COMMONS= (NATURAL,NOMULTILANGUAGE),RECORDS=NATURAL,SEQUENCE).NONE
Specifying /ALIGNMENT=NONE is equivalent to /NOALIGNMENT, /ALIGNMENT=PACKED, or /ALIGNMENT=(COMMONS=(PACKED, NOMULTILANGUAGE), RECORDS=PACKED,NOSEQUENCE).
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),NOSEQUENCE,RECORDS=NATURAL) |
| Omit /ALIGNMENT and specify /FAST |
/ALIGNMENT=(COMMONS=NATURAL,
RECORDS=NATURAL,SEQUENCE) |
| /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 HP Fortran for OpenVMS Language Reference Manual.
The /ALIGNMENT and /WARNINGS=ALIGNMENT qualifiers can be used together in the same command line.
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 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 specify a particular name as the name of the analysis file, 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.
2.3.5 /ANNOTATIONS --- Code Descriptions
The /ANNOTATIONS qualifier controls whether an annotated listing showing optimizations is included with the listing file.
The qualifier has the following form:
|
/ANNOTATIONS=
|
CODE
Annotates the machine code listing with descriptions of special instructions used for prefetching, alignment, and so on.DETAIL
Provides additional level of annotation detail, where available.INLINING
Indicates where code for a called procedure was expanded inline.LOOP_TRANSFORMS
Indicates where advanced loop nest optimizations have been applied to improve cache performance.LOOP_UNROLLING
Indicates where a loop was unrolled (contents expanded multiple times).PREFETCHING
Indicates where special instructions were used to reduce memory latency.SHRINKWRAPPING
Indicates removal of code establishing routine context when it is not needed.SOFTWARE_PIPELINING
Indicates where instructions have been rearranged to make optimal use of the processor's functional units.TAIL_CALLS
Indicates an optimization where a call can be replaced with a jump.TAIL_RECURSION
Indicates an optimization that eliminates unnecessary routine context for a recursive call.ALL
All annotations, including DETAIL, are selected. This is the default if no keyword is specified.NONE
No annotations are selected. This is the same as /NOANNOTATIONS.
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 (Alpha only) 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.
EV67
Generates code for chip implementations that use advanced instruction extensions of the Alpha architecture. This option permits the compiler to generate any EV67 instruction, including the following extensions to the base Alpha instruction set: BWX (Byte/Word manipulation), MVI (Multimedia) instructions, square root and floating-point convert extensions (FIX), and count extensions (CIX).Programs compiled with the EV67 keyword might incur emulation overhead on EV4, EV5, EV56, PCA56, and EV6 processors but still run correctly on OpenVMS Alpha 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.21) 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 (the 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, HP 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, HP 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, HP 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:
- HP Fortran Version 7.0 or later
- OpenVMS 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, HP 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]PROTECT_CONSTANTS
Specifies whether constant actual arguments can be changed. By default, actual arguments that are constants are read-only (/ASSUME=PROTECT_CONSTANTS): any attempt to modify them in the called routine results in an error. /ASSUME=NOPROTECT_CONSTANTS specifies that a copy of a constant actual argument is to be passed, so it can be modified by the called routine, even though the Fortran standard prohibits such modification. The constant is not modified in the calling routine.If NOPROTECT_CONSTANTS is specified, a writeable copy of the constant is passed as the actual argument.
[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.
| Previous | Next | Contents | Index |