HP Fortran for OpenVMS
User Manual


Previous Contents Index

2.3.3 /ALIGNMENT --- Data Alignment

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.

Note

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=
  • rule
  • class = rule
  • (class = rule [, ...])
  • [NO]SEQUENCE
  • ALL (or NATURAL)
  • NONE (or PACKED)

where: class =
  • COMMONS
  • RECORDS
  • STRUCTURES
and rule =
  • NATURAL
  • PACKED
  • STANDARD
  • [NO]MULTILANGUAGE

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:

rule

Specifies the alignment for the specified class of data blocks:

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

For More Information:

2.3.4 /ANALYSIS_DATA---Create Analysis Data File

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
    • DETAIL
    • INLINING
    • LOOP_TRANSFORMS
    • LOOP_UNROLLING
    • PREFETCHING
    • SHRINKWRAPPING
    • SOFTWARE_PIPELINING
    • TAIL_CALLS
    • TAIL_RECURSION
    [, ...]
    • ALL
    • NONE

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.

2.3.6 /ARCHITECTURE --- Architecture Code Instructions (Alpha only)

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
  • HOST
  • EV4
  • EV5
  • EV56
  • PCA6
  • EV6
  • EV67

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.

2.3.7 /ASSUME --- Compiler Assumptions

The /ASSUME qualifier specifies a variety of assumptions:

The qualifier has the following form:

/ASSUME=
    • [NO]ACCURACY_SENSITIVE
    • [NO]ALTPARAM
    • [NO]BUFFERED_IO
    • [NO]BYTERECL
    • [NO]DUMMY_ALIASES
    • [NO]FP_CONSTANT
    • [NO]INT_CONSTANT
    • [NO]MINUS0
    • [NO]PROTECT_CONSTANTS
    • [NO]SOURCE_INCLUDE
    [, ...]
    • ALL
    • NONE

[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:

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:

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


Previous Next Contents Index