You can use directives in a Fortran source program to influence certain aspects of the compilation process.
1 – General Directives
HP FORTRAN provides several general-purpose compiler directives
to perform tasks during compilation.
General directives begin with the cDEC$ prefix. These directives
are enabled in all Fortran compilation units, regardless of the
options used on the command line.
The general directives are:
ALIAS MESSAGE
ATTRIBUTES OBJCOMMENT
DECLARE and NODECLARE OPTIONS
DEFINE and UNDEFINE PACK
FIXEDFORMLINESIZE PSECT
FREEFORM and NOFREEFORM REAL
IDENT STRICT and NOSTRICT
IF and IF DEFINED SUBTITLE and TITLE
INTEGER UNROLL
IVDEP
The "c" in the directive prefix (cDEC$) is one of the following: C
(or c), !, or *.
The following are source form rules for directive prefixes:
o Prefixes beginning with C (or c) and * are only allowed in
fixed and tab source forms.
In these source forms, the prefix must appear in columns 1
through 5; column 6 must be a blank or tab. From column 7 on,
blanks are insignificant, so the directive can be positioned
anywhere on the line after column 6.
o Prefixes beginning with ! are allowed in all source forms.
The prefix can appear in any valid column, but it cannot be
preceded by any nonblank characters on the same line. It can
only be preceded by whitespace.
A general directive ends in column 72 (or column 132, if a compiler
option is specified).
General directives cannot be continued.
A comment can follow a directive on the same line.
Additional Fortran statements (or directives) cannot appear on the
same line as the general directive.
General directives cannot appear within a continued Fortran
statement.
If a blank common is used in a general compiler directive, it must
be specified as two slashes (/ /).
1.1 – ALIAS
cDEC$ ALIAS
Specifies an alternate external name to be used when referring to
external subprograms. It takes the following form:
cDEC$ ALIAS internal-name, external name
c Is one of the following: C (or c), !, or *.
internal-name Is the name of the subprogram as used
in the current program unit.
external name Is a name, or a character constant delimited
by quotation marks or apostrophes.
If a name is specified, the name (in uppercase) is used as the
external name for the specified "internal-name". If a character
constant is specified, it is used as is; the string is not changed
to uppercase nor are blanks removed.
The ALIAS directive affects only the external name used for
references to the specified "internal-name".
Names that are not acceptable to the linker will cause link-time
errors.
This directive can be useful when compiling applications written
for other platforms that have different naming conventions.
1.2 – ATTRIBUTES
cDEC$ ATTRIBUTES
Lets you specify properties for data objects and procedures. It
takes the following form:
cDEC$ ATTRIBUTES att [,att]... :: object [,object]...
c Is one of the following: C (or c), !, or *.
att Is one of the following properties:
ADDRESS64
ALIAS EXTERN
ALLOW_NULL IGNORE_LOC
NO_ARG_CHECK
C NOMIXED_STR_LEN_ARG
DECORATE REFERENCE
DEFAULT REFERENCE32
DESCRIPTOR REFERENCE64
DESCRIPTOR32 STDCALL
DESCRIPTOR64 VALUE
VARYING
object Is the name of a data object or procedure.
The properties can be used in function and subroutine definitions,
in type declarations, and with the INTERFACE and ENTRY statements.
Properties applied to entities available through use or host
association are in effect during the association. For example,
consider the following:
MODULE MOD1
INTERFACE
SUBROUTINE SUB1
!DEC$ ATTRIBUTES C, ALIAS:'othername' :: NEW_SUB
END SUBROUTINE
END INTERFACE
CONTAINS
SUBROUTINE SUB2
CALL NEW_SUB
END SUBROUTINE
END MODULE
In this case, the call to NEW_SUB within SUB2 uses the C and ALIAS
properties specified in the interface block.
Options C, STDCALL, REFERENCE, VALUE, and VARYING affect the
calling conventions of routines:
o You can specify C, STDCALL, REFERENCE, and VARYING for an
entire routine.
o You can specify VALUE and REFERENCE for individual arguments.
For compatibility, !MS$ATTRIBUTES can be used in place of cDEC$
ATTRIBUTES.
The properties are described in the following sections.
1.2.1 – ADDRESS64
Specifies that the data object has a 64-bit address. This property can be specified for any variable or dummy argument, including ALLOCATABLE and deferred-shape arrays. However, variables with this property cannot be data-initialized. It can also be specified for COMMON blocks or for variables in a COMMON block. If specified for a COMMON block variable, the COMMON block implicitly has the ADDRESS64 property. ADDRESS64 is not compatible with the AUTOMATIC attribute.
1.2.2 – ALIAS
Specifies an alternate external name to be used when referring to
external subprograms. Its form is:
ALIAS:external-name
external-name Is a character constant delimited by apostrophes
or quotation marks. The character constant is
used as is; the string is not changed to uppercase,
nor are blanks removed.
The ALIAS property overrides the C (and STDCALL) property. If both
C and ALIAS are specified for a subprogram, the subprogram is given
the C calling convention, but not the C naming convention. It
instead receives the name given for ALIAS, with no modifications.
ALIAS cannot be used with internal procedures, and it cannot be
applied to dummy arguments.
cDEC$ ATTRIBUTES ALIAS has the same effect as the cDEC$ ALIAS
directive.
1.2.3 – ALLOW_NULL
Enables a corresponding dummy argument to pass a NULL pointer (defined by a zero or the NULL intrinsic function) by value for the argument. ALLOW_NULL is only valid if the REFERENCE property is also specified; otherwise, it has no effect.
1.2.4 – C and STDCALL
Specify how data is to be passed when you use routines written in C
or assembler with FORTRAN or Fortran 95/90 routines.
C and STDCALL are interpreted as synonyms.
When applied to a subprogram, these properties define the
subprogram as having a specific set of calling conventions.
The difference between the calling conventions is this: If C or
STDCALL is specified for a subprogram, arguments (except for
arrays and characters) are passed by value. Subprograms using
standard Fortran 95/90 conventions pass arguments by reference.
Character arguments are passed as follows:
o By default, hidden lengths are put at the end of the argument
list.
o If C or STDCALL (only) is specified:
On all systems, the first character of the string is passed
(and padded with zeros out to INTEGER(4) length).
o If C or STDCALL is specified, and REFERENCE is specified for
the argument:
On all systems, the string is passed with no length.
o If C or STDCALL is specified, and REFERENCE is specified for
the routine (but REFERENCE is not specified for the argument,
if any):
On all systems, the string is passed with the length.
1.2.5 – DECORATE
Specifies that the external name used in cDEC$ ALIAS or cDEC$ ATTRIBUTES ALIAS should have the prefix and postfix decorations performed on it that are associated with the calling mechanism that is in effect. These are the same decorations performed on the procedure name when ALIAS is not specified. The case of the external name is not modified. If ALIAS is not specified, this property has no effect.
1.2.6 – DEFAULT
Overrides certain compiler options that can affect external routine and COMMON block declarations. It specifies that the compiler should ignore compiler options that change the default conventions for external symbol naming and argument passing for routines and COMMON blocks (/iface, /names, and /assume:underscore). This option can be combined with other cDEC$ ATTRIBUTES options, such as STDCALL, C, REFERENCE, ALIAS, etc. to specify attributes different from the compiler defaults. This option is useful when declaring INTERFACE blocks for external routines, since it prevents compiler options from changing calling or naming conventions.
1.2.7 – DESCRIPTOR
Specifies that the argument is passed by VMS descriptor. This property can be specified only for dummy arguments in an INTERFACE block (NOT for a routine itself).
1.2.8 – DESCRIPTOR32
Specifies that the argument is passed as a 32-bit descriptor.
1.2.9 – DESCRIPTOR64
Specifies that the argument is passed as a 64-bit descriptor.
1.2.10 – EXTERN
Specifies that a variable is allocated in another source file. EXTERN can be used in global variable declarations, but it must not be applied to dummy arguments. EXTERN must be used when accessing variables declared in other languages.
1.2.11 – IGNORE_LOC
Enables %LOC to be stripped from an argument. IGNORE_LOC is only valid if the REFERENCE property is also specified; otherwise, it has no effect.
1.2.12 – NO_ARG_CHECK
Specifies that type and shape matching rules related to explicit interfaces are to be ignored. This permits the construction of an INTERFACE block for an external procedure or a module procedure that accepts an argument of any type or shape; for example, a memory copying routine. NO_ARG_CHECK can appear only in an INTERFACE block for a non-generic procedure or in a module procedure. It can be applied to an individual dummy argument name or to the routine name, in which case the property is applied to all dummy arguments in that interface. NO_ARG_CHECK cannot be used for procedures with the PURE or ELEMENTAL prefix. If an argument has an INTENT or OPTIONAL attribute, any NO_ARG_CHECK specification is ignored.
1.2.13 – NOMIXED_STR_LEN_ARG
Specifies that hidden lengths be placed in sequential order at the end of the argument list.
1.2.14 – REFERENCE and VALUE
Specify how a dummy argument is to be passed. REFERENCE specifies a dummy argument's memory location is to be passed instead of the argument's value. VALUE specifies a dummy argument's value is to be passed instead of the argument's memory location. When a dummy argument has the VALUE property, the actual argument passed to it can be of a different type. If necessary, type conversion is performed before the subprogram is called. When a complex (KIND=4, KIND=8, or KIND=16) argument is passed by value, two floating-point arguments (one containing the real part, the other containing the imaginary part) are passed by immediate value. Character values, substrings, assumed-size arrays, and adjustable arrays cannot be passed by value. If REFERENCE (only) is specified for a character argument, the string is passed but the length is not passed. If REFERENCE is specified for a character argument, and C (or STDCALL) has been specified for the routine, the string is passed but the length is not passed. This is true even if REFERENCE is also specified for the routine. If REFERENCE and C (or STDCALL) are specified for a routine, but REFERENCE has not been specified for the argument, the string is passed with the length. VALUE is the default if the C or STDCALL property is specified in the subprogram definition.
1.2.15 – REFERENCE32
Specifies that the argument is accepted only by 32-bit address.
1.2.16 – REFERENCE64
Specifies that the argument is accepted only by 64-bit address.
1.2.17 – VARYING
Allows a variable number of calling arguments. If VARYING is specified, the C property must also be specified. Either the first argument must be a number indicating how many arguments to process, or the last argument must be a special marker (such as -1) indicating it is the final argument. The sequence of the arguments, and types and kinds must be compatible with the called procedure.
1.3 – DECLARE and NODECLARE
cDEC$ DECLARE cDEC$ NODECLARE The DECLARE directive generates warnings for variables that have been used but have not been declared (like the IMPLICIT NONE statement). The NODECLARE directive (the default) disables these warnings. The "c" in cDEC$ is one of the following: a C (or c), !, or *. The DECLARE directive is primarily a debugging tool that locates variables that have not been properly initialized, or that have been defined but never used. For compatibility, !MS$DECLARE and !MS$NODECLARE can be used in place of cDEC$ DECLARE and cDEC$ NODECLARE.
1.4 – DEFINE and UNDEFINE
cDEC$ DEFINE
cDEC$ UNDEFINE
The DEFINE directive creates a symbolic variable whose existence or
value can be tested during conditional compilation. The UNDEFINE
directive removes a defined symbol.
The DEFINE and UNDEFINE directives take the following forms:
cDEC$ DEFINE name [=val]
cDEC$ UNDEFINE name
c Is one of the following: C (or c), !, or *.
name Is the name of the variable.
val Is an INTEGER(4) value assigned to "name".
DEFINE and UNDEFINE create and remove variables for use with the IF
(or IF DEFINED) directive. Symbols defined with the DEFINE
directive are local to the directive. They cannot be declared in
the Fortran program.
Because Fortran programs cannot access the named variables, the
names can duplicate Fortran keywords, intrinsic functions, or
user-defined names without conflict.
To test whether a symbol has been defined, use the IF DEFINED
(name) directive. You can assign an integer value to a defined
symbol. To test the assigned value of "name", use the IF
directive. IF test expressions can contain most logical and
arithmetic operators.
Attempting to undefine a symbol which has not been defined produces
a compiler warning.
The DEFINE and UNDEFINE directives can appear anywhere in a
program, enabling and disabling symbol definitions.
For compatibility, !MS$DEFINE and !MS$UNDEFINE can be used in place
of cDEC$ DEFINE and cDEC$ UNDEFINE.
Examples:
Consider the following:
!DEC$ DEFINE testflag
!DEC$ IF DEFINED (testflag)
write (*,*) 'Compiling first line'
!DEC$ ELSE
write (*,*) 'Compiling second line'
!DEC$ ENDIF
!DEC$ UNDEFINE testflag
1.5 – FIXEDFORMLINESIZE
cDEC$ FIXEDFORMLINESIZE
Sets the line length for fixed-form source code. The directive
takes the following form:
cDEC$ FIXEDFORMLINESIZE:{72 | 80 | 132}
c Is one of the following: C (or c), !, or *.
You can set FIXEDFORMLINESIZE to 72 (the default), 80, or 132
characters. The FIXEDFORMLINESIZE setting remains in effect until
the end of the file, or until it is reset.
The FIXEDFORMLINESIZE directive sets the source-code line length in
include files, but not in USE modules, which are compiled
separately. If an include file resets the line length, the change
does not affect the host file.
This directive has no effect on free-form source code.
For compatibility, !MS$FIXEDFORMLINESIZE can be used in place of
cDEC$ FIXEDFORMLINESIZE.
Examples:
Consider the following:
CDEC$ NOFREEFORM
CDEC$ FIXEDFORMLINESIZE:132
WRITE(*,*) 'Text that goes past the 72nd column without continuation'
1.6 – FREEFORM and NOFREEFORM
cDEC$ FREEFORM cDEC$ NOFREEFORM The FREEFORM directive specifies that source code is in free-form format. The NOFREEFORM directive specifies that source code is in fixed-form format. The "c" in cDEC$ is one of the following: a C (or c), !, or *. When the FREEFORM or NOFREEFORM directives are used, they remain in effect for the remainder of the file, or until the opposite directive is used. When in effect, they apply to include files, but do not affect USE modules, which are compiled separately. For compatibility, !MS$FREEFORM and !MS$NOFREEFORM can be used in place of cDEC$ FREEFORM and cDEC$ NOFREEFORM.
1.7 – IDENT
cDEC$ IDENT string Lets you specify a string that can be used to identify an object module. The compiler places the string in the identification field of an object module when it generates the module for each source program unit. The "string" is a character constant containing up to 31 printable characters. Only the first IDENT directive is effective -- the compiler ignores any additional IDENT directives in a program unit. IDENT has no effect when you specify the /NOOBJECT compiler option.
1.8 – IF and IFDEFINED
cDEC$ IF
cDEC$ IF DEFINED
The IF and IF DEFINED directives specify a conditional compilation
construct. IF tests whether a logical expression is .TRUE. or
.FALSE.. IF DEFINED tests whether a symbol has been defined.
The directive-initiated construct takes the following form:
cDEC$ IF (expr) [or cDEC$ IF DEFINED (name)]
block
[cDEC$ ELSE IF (expr)
block]...
[cDEC$ ELSE
block]
cDEC$ ENDIF
c Is one of the following: C (or c), !, or *.
exp A logical expression that evaluates to .TRUE.
or .FALSE..
name Is the name of a symbol to be tested for definition.
block Are executable statements that are compiled (or not)
depending on the value of logical expressions in
the IF directive construct.
The IF and IF DEFINED directive constructs end with an ENDIF
directive and can contain one or more ELSEIF directives and at most
one ELSE directive. If the logical condition within a directive
evaluates to .TRUE. at compilation, and all preceding conditions
in the IF construct evaluate to .FALSE., then the statements
contained in the directive block are compiled.
A "name" can be defined with a DEFINE directive, and can optionally
be assigned an integer value. If the symbol has been defined, with
or without being assigned a value, IF DEFINED (name) evaluates to
.TRUE.; otherwise, it evaluates to .FALSE..
If the logical condition in the IF or IF DEFINED directive is
.TRUE., statements within the IF or IF DEFINED block are compiled.
If the condition is .FALSE., control transfers to the next ELSEIF
or ELSE directive, if any.
If the logical expression in an ELSEIF directive is .TRUE.,
statements within the ELSEIF block are compiled. If the expression
is .FALSE., control transfers to the next ELSEIF or ELSE directive,
if any.
If control reaches an ELSE directive because all previous logical
conditions in the IF construct evaluated to .FALSE., the statements
in an ELSE block are compiled unconditionally.
You can use any Fortran logical or relational operator or symbol in
the logical expression of the directive. The logical expression
can be as complex as you like, but the whole directive must fit on
one line.
For compatibility, each directive in the construct can begin with
the prefix !MS$ instead of cDEC$.
Examples:
Consider the following:
! When the following code is compiled and run,
! the output depends on whether one of the expressions
! tests .TRUE.; or all test .FALSE.
!DEC$ DEFINE flag=3
!DEC$ IF (flag .LT. 2)
WRITE (*,*) "This is compiled if flag less than 2."
!DEC$ ELSEIF (flag >= 8)
WRITE (*,*) "Or this compiled if flag greater than &
or equal to 8."
!DEC$ ELSE
WRITE (*,*) "Or this compiled if all preceding &
conditions .FALSE."
!DEC$ ENDIF
END
1.9 – INTEGER
cDEC$ INTEGER
Specifies the default integer kind. It takes the following form:
cDEC$ INTEGER:{2 | 4 | 8}
c Is one of the following: C (or c), !, or *.
The INTEGER directive specifies a size of 2 (KIND=2), 4 (KIND=4),
or 8 (KIND=8) bytes for default integer numbers.
When the INTEGER directive is effect, all default integer variables
are of the kind specified in the directive. Only numbers specified
or implied as INTEGER without KIND are affected.
The INTEGER directive can only appear at the top of a program unit.
A program unit is a main program, an external subroutine or
function, a module or a block data program unit. The directive
cannot appear between program units, or at the beginning of
internal subprograms. It does not affect modules invoked with the
USE statement in the program unit that contains it.
The default logical kind is the same as the default integer kind.
So, when you change the default integer kind you also change the
default logical kind.
For compatibility, !MS$INTEGER can be used in place of cDEC$
INTEGER.
Examples:
Consider the following:
INTEGER i ! a 4-byte integer
WRITE(*,*) KIND(i)
CALL INTEGER2( )
WRITE(*,*) KIND(i) ! still a 4-byte integer
! not affected by setting in subroutine
END
SUBROUTINE INTEGER2( )
!DEC$ INTEGER:2
INTEGER j ! a 2-byte integer
WRITE(*,*) KIND(j)
END SUBROUTINE
1.10 – IVDEP
cDEC$ IVDEP
The IVDEP directive assists the compiler's dependence analysis. It
can only be applied to iterative DO loops. This directive can also
be specified as INIT_DEP_FWD (INITialize DEPendences ForWarD).
The IVDEP directive takes the following form:
cDEC$ IVDEP
c Is one of the following: C (or c), !, or *.
The IVDEP directive is an assertion to the compiler's optimizer
about the order of memory references inside a DO loop.
The IVDEP directive tells the compiler to begin dependence analysis
by assuming all dependences occur in the same forward direction as
their appearance in the normal scalar execution order. This
contrasts with normal compiler behavior, which is for the
dependence analysis to make no initial assumptions about the
direction of a dependence.
The IVDEP directive must precede the DO statement for each DO loop
it affects. No source code lines, other than the following, can be
placed between the IVDEP directive statement and the DO statement:
o An UNROLL directive
o Placeholder lines
o Comment lines
o Blank lines
The IVDEP directive is applied to a DO loop in which the user knows
that dependences are in lexical order. For example, if two memory
references in the loop touch the same memory location and one of
them modifies the memory location, then the first reference to
touch the location has to be the one that appears earlier lexically
in the program source code. This assumes that the right-hand side
of an assignment statement is "earlier" than the left-hand side.
The IVDEP directive informs the compiler that the program would
behave correctly if the statements were executed in certain orders
other than the sequential execution order, such as executing the
first statement or block to completion for all iterations, then the
next statement or block for all iterations, and so forth. The
optimizer can use this information, along with whatever else it can
prove about the dependences, to choose other execution orders.
Examples:
In the following example, the IVDEP directive provides more
information about the dependences within the loop, which may enable
loop transformations to occur:
!DEC$ IVDEP
DO I=1, N
A(INDARR(I)) = A(INDARR(I)) + B(I)
END DO
In this case, the scalar execution order follows:
1. Retrieve INDARR(I).
2. Use the result from step 1 to retrieve A(INDARR(I)).
3. Retrieve B(I).
4. Add the results from steps 2 and 3.
5. Store the results from step 4 into the location indicated by
A(INDARR(I)) from step 1.
IVDEP directs the compiler to initially assume that when steps 1
and 5 access a common memory location, step 1 always accesses the
location first because step 1 occurs earlier in the execution
sequence. This approach lets the compiler reorder instructions, as
long as it chooses an instruction schedule that maintains the
relative order of the array references.
1.11 – MESSAGE
cDEC$ MESSAGE
Specifies a character string to be sent to the standard output
device during the first compiler pass; this aids debugging.
This directive takes the following form:
cDEC$ MESSAGE:string
c Is one of the following: C (or c), !, or *.
string Is a character constant specifying a message.
For compatibility, !MS$MESSAGE can be used in place of cDEC$
MESSAGE.
Examples:
Consider the following:
!DEC$ MESSAGE:'Compiling Sound Speed Equations'
1.12 – OBJCOMMENT
cDEC$ OBJCOMMENT
Specifies a library search path in an object file. This directive
takes the following form:
cDEC$ OBJCOMMENT LIB:library
c Is one of the following: C (or c), !, or *.
library Is a character constant specifying the name
and, if necessary, the path of the library
that the linker is to search.
The linker searches for the library named by the OBJCOMMENT
directive as if you named it on the command line, that is, before
default library searches. You can place multiple library search
directives in the same source file. Each search directive appears
in the object file in the order it is encountered in the source
file.
If the OBJCOMMENT directive appears in the scope of a module, any
program unit that uses the module also contains the directive, just
as if the OBJCOMMENT directive appeared in the source file using
the module.
If you want to have the OBJCOMMENT directive in a module, but do
not want it in the program units that use the module, place the
directive outside the module that is used.
For compatibility, !MS$OBJCOMMENT can be used in place of cDEC$
OBJCOMMENT.
Examples:
Consider the following:
! MOD1.F90
MODULE a
!DEC$ OBJCOMMENT LIB: "opengl32.lib"
END MODULE a
! MOD2.F90
!DEC$ OBJCOMMENT LIB: "graftools.lib"
MODULE b
!
END MODULE b
! USER.F90
PROGRAM go
USE a ! library search contained in MODULE a
! included here
USE b ! library search not included
END
1.13 – OPTIONS
cDEC$ OPTIONS
Affects data alignment and warnings about data alignment. The
OPTIONS directive takes the following form:
cDEC$ OPTIONS option [option]
...
cDEC$ END OPTIONS
c Is one of the following: C (or c), !, or *.
option Is one or both of the following:
o /WARN=[NO]ALIGNMENT
Controls whether warnings are issued by the compiler for
data that is not naturally aligned. By default, you receive
compiler messages when misaligned data is encountered
(/WARN=ALIGNMENT).
o /[NO]ALIGN[=p]
Controls whether the VSI Fortran compiler naturally aligns
fields in derived-type and record structures and data items
in common blocks for performance reasons, or whether the
compiler packs those fields and data items together on
arbitrary byte boundaries.
p Is a specifier with one of the following forms:
[class =] rule
(class = rule,...)
ALL
NONE
class Is one of the following keywords:
COMMONS (for common blocks)
RECORDS (for derived-type and record structures)
STRUCTURES (a synonym for RECORDS)
rule Is one of the following keywords:
PACKED - Packs fields in structures or data
items in common blocks on arbitrary
byte boundaries.
NATURAL - Naturally aligns fields in structures
and data items in common blocks on
up to 64-bit boundaries (inconsistent
with the FORTRAN 77 standard).
If you specify NATURAL, the compiler will
naturally align all data in a common
block, including INTEGER*8, REAL*8, and
all COMPLEX data.
STANDARD - Naturally aligns data items in common
blocks on up to 32-bit boundaries (con-
sistent with the FORTRAN 77 standard).
Note that this keyword only applies to
common blocks; so, you can specify
/ALIGN=COMMONS=STANDARD, but you cannot
specify /ALIGN=STANDARD.
ALL Is the same as /ALIGN, /ALIGN=NATURAL, and
/ALIGN=(RECORDS=NATURAL,COMMONS=NATURAL).
NONE Is the same as /NOALIGN, /ALIGN=PACKED, and
/ALIGN=(RECORDS=PACKED,COMMONS=PACKED)
cDEC$ OPTIONS (and accompanying cDEC$ END OPTIONS) directives must
come after OPTIONS, SUBROUTINE, FUNCTION, and BLOCK DATA statements
(if any) in the program unit, and before statement functions or the
executable part of the program unit.
For performance reasons, VSI Fortran always aligns local data
items on natural boundaries. However, EQUIVALENCE, COMMON, RECORD,
and STRUCTURE data declaration statements can force misaligned
data. If /WARN=NOALIGNMENT is specified, warnings will not be
issued if misaligned data is encountered.
NOTE
Misaligned data significantly increases the time it
takes to execute a program. As the number of
misaligned fields encountered increases, so does
the time needed to complete program execution.
Specifying cDEC$ OPTIONS/ALIGN (or the /ALIGN
compiler option) minimizes misaligned data.
To request aligned, data in common blocks, specify
/ALIGN=COMMONS=STANDARD (for data items up to 32 bits in length) or
/ALIGN=COMMONS=NATURAL (for data items up to 64 bits in length), or
place source data declarations within the common block in
descending size order, so that each data field is naturally
aligned.
To request packed, unaligned data in a record structure, specify
/ALIGN=RECORDS=PACKED, or consider placing source data declarations
for the record so that the data is naturally aligned.
The OPTIONS directive supersedes the /ALIGN compiler option.
OPTIONS directives must be balanced and can be nested up to 100
levels, for example:
CDEC$ OPTIONS /ALIGN=PACKED ! Group A
declarations
CDEC$ OPTIONS /ALIGN=RECO=NATU ! Group B
more declarations
CDEC$ END OPTIONS ! End of Group B
still more declarations
CDEC$ END OPTIONS ! End of Group A
Note that common blocks within Group B will be PACKED. The CDEC$
OPTION specification for Group B only applies to RECORDS, so
COMMONS retains the previous setting (in this case, from the Group
A specification).
For more information on alignment and data sizes, see the HP
Fortran for OpenVMS User Manual.
1.14 – PACK
cDEC$ PACK
Specifies the memory starting addresses of derived-type items. It
takes the following form:
cDEC$ PACK:[{1 | 2 | 4}]
c Is one of the following: C (or c), !, or *.
Items of derived types and record structures are aligned in memory
on the smaller of two sizes: the size of the type of the item, or
the current alignment setting. The current alignment setting can
be 1, 2, 4, or 8 bytes. The default initial setting is 8 bytes
(unless a compiler option specifies otherwise). By reducing the
alignment setting, you can pack variables closer together in
memory.
The PACK directive lets you control the packing of derived-type or
record structure items inside your program by overriding the
current memory alignment setting.
For example, if CDEC$ PACK:1 is specified, all variables begin at
the next available byte, whether odd or even. Although this
slightly increases access time, no memory space is wasted. If
CDEC$ PACK:4 is specified, INTEGER(1), LOGICAL(1), and all
character variables begin at the next available byte, whether odd
or even. INTEGER(2) and LOGICAL(2) begin on the next even byte;
all other variables begin on 4-byte boundaries.
If the PACK directive is specified without a number, packing
reverts to the compiler option setting (if any), or the default
setting of 8.
The directive can appear anywhere in a program before the
derived-type definition or record structure definition. It cannot
appear inside a derived-type or record structure definition.
For compatibility, !MS$PACK can be used in place of cDEC$ PACK.
Examples:
Consider the following:
! Use 4-byte packing for this derived type
! Note PACK is used outside of the derived-type definition
!DEC$ PACK:4
TYPE pair
INTEGER a, b
END TYPE
! revert to default or compiler option
!DEC$ PACK:
1.15 – PSECT
cDEC$ PSECT /common-name/ attr [,attr,...]
Lets you modify several characteristics of a common block.
Specify the name of a common block, preceded and followed by a
slash, and one of the following keywords ("attr"):
o ALIGN=val or ALIGN=keyword
Specifies alignment for the common block.
"val" must be a constant ranging from 0 through 16.
The specified number is interpreted as a power of 2. The value
of the expression is the alignment in bytes.
"keyword" is one of the following:
Keyword Equivalent to "val"
BYTE 0
WORD 1
LONG 2
QUAD 3
OCTA 4
PAGE [see note] Alpha: 16
Intel: 12
note: Range for Alpha is 0 to 16; for
Intel, 0 to 12.
The default is octaword alignment (4).
o GBL
Specifies global scope. This is the default scope.
o LCL
Specifies local scope. This keyword is opposite to GBL and
cannot appear with it.
o [NO]MULTILANGUAGE
Controls whether the compiler pads the size of overlaid psects
(program sections) to ensure compatibility when the psect is
shared by code created by other OpenVMS compilers.
When a psect generated by a Fortran common block is overlaid
with a psect consisting of a C structure, linker error messages
can occur. This is because the sizes of the psects are
inconsistent; the C structure is padded, but the Fortran common
block is not.
Specifying MULTILANGUAGE ensures that VSI Fortran follows a
consistent psect size allocation scheme that works with HP
C psects shared across multiple images. Psects shared in a
single image do not have a problem.
The default is NOMULTILANGUAGE. This is also the default
behavior of HP Fortran 77 and is sufficient for most
applications.
To specify MULTILANGUAGE for all COMMON blocks in a module, use
compiler option /ALIGN=COMMON=MULTILANGUAGE. (For more
information, see the HP Fortran for OpenVMS User Manual.)
o [NO]SHR
Determines whether the contents of a common block can be shared
by more than one process. The default is NOSHR.
o [NO]WRT
Determines whether the contents of a common block can be
modified during program execution. The default is WRT.
Global or local scope is significant for an image that has more
than one cluster. Program sections with the same name that are
from different modules in different clusters are placed in separate
clusters if local scope is in effect. They are placed in the same
cluster if global scope is in effect.
If one program unit changes one or more characteristics of a common
block, all other units that reference that common block must also
change those characteristics in the same way.
Default characteristics apply if you do not modify them with a
PSECT directive.
See the "OpenVMS Linker Utility Manual" for detailed information
about default attributes of common blocks.
1.16 – REAL
cDEC$ REAL
Specifies the default real kind. It takes the following form:
cDEC$ REAL:{4 | 8 | 16}
c Is one of the following: C (or c), !, or *.
The REAL directive specifies a size of 4 (KIND=4), 8 (KIND=8), or
16 (KIND=16) bytes for default real numbers.
When the REAL directive is effect, all default real variables are
of the kind specified in the directive. Only numbers specified or
implied as REAL without KIND are affected.
The REAL directive can only appear at the top of a program unit. A
program unit is a main program, an external subroutine or function,
a module or a block data program unit. The directive cannot appear
between program units, or at the beginning of internal subprograms.
It does not affect modules invoked with the USE statement in the
program unit that contains it.
For compatibility, !MS$REAL can be used in place of cDEC$ REAL.
Consider the following:
REAL r ! a 4-byte REAL
WRITE(*,*) KIND(r)
CALL REAL8( )
WRITE(*,*) KIND(r) ! still a 4-byte REAL
! not affected by setting in subroutine
END
SUBROUTINE REAL8( )
!DEC$ REAL:8
REAL s ! an 8-byte REAL
WRITE(*,*) KIND(s)
END SUBROUTINE
1.17 – STRICT and NOSTRICT
cDEC$ STRICT
cDEC$ NOSTRICT
The STRICT directive disables language features not found in the
language standard specified on the command line (Fortran 95 or
Fortran 90). The NOSTRICT directive (the default) enables these
language features.
The "c" in cDEC$ is one of the following: a C (or c), !, or *.
If STRICT is specified and no language standard is specified on the
command line, the default is to disable features not found in
Fortran 90.
The STRICT and NOSTRICT directives can appear only appear at the
top of a program unit. A program unit is a main program, an
external subroutine or function, a module or a block data program
unit. The directives cannot appear between program units, or at
the beginning of internal subprograms. They do not affect any
modules invoked with the USE statement in the program unit that
contains them.
For compatibility, !MS$STRICT and !MS$NOSTRICT can be used in place
of cDEC$ STRICT and cDEC$ NOSTRICT.
Examples:
Consider the following:
! NOSTRICT by default
TYPE stuff
INTEGER(4) k
INTEGER(4) m
CHARACTER(4) name
END TYPE stuff
TYPE (stuff) examp
DOUBLE COMPLEX cd ! non-standard data type, no error
cd =(3.0D0, 4.0D0)
examp.k = 4 ! non-standard component designation,
! no error
END
SUBROUTINE STRICTDEMO( )
!DEC$ STRICT
TYPE stuff
INTEGER(4) k
INTEGER(4) m
CHARACTER(4) name
END TYPE stuff
TYPE (stuff) samp
DOUBLE COMPLEX cd ! ERROR
cd =(3.0D0, 4.0D0)
samp.k = 4 ! ERROR
END SUBROUTINE
1.18 – TITLE and SUBTITLE
cDEC$ TITLE string cDEC$ SUBTITLE string The TITLE directive lets you specify a string and place it in the title field of a listing header. Similarly, SUBTITLE lets you place a specified string in the subtitle field of a listing header. The "string" is a character constant containing up to 31 printable characters. To enable TITLE and SUBTITLE directives, you must specify the /LIST compiler option. When TITLE or SUBTITLE appears on a page of a listing file, the specified string appears in the listing header of the following page. If two or more of either directive appear on a page, the last directive is the one in effect for the following page. If either directive does not specify a string, no change occurs in the listing file header. For compatibility, !MS$TITLE: and !MS$SUBTITLE: can be used in place of cDEC$ TITLE and cDEC$ SUBTITLE.
1.19 – UNROLL
cDEC$ UNROLL
The UNROLL directive tells the compiler's optimizer how many times
to unroll a DO loop. It can only be applied to iterative DO loops.
The UNROLL directive takes the following form:
cDEC$ UNROLL [(n)]
c Is one of the following: C (or c), !, or *.
n Is an integer constant. The range of "n" is 0 through 255.
The UNROLL directive must precede the DO statement for each DO loop
it affects. No source code lines, other than the following, can be
placed between the UNROLL directive statement and the DO statement:
o An IVDEP directive
o Placeholder lines
o Comment lines
o Blank lines
If "n" is specified, the optimizer unrolls the loop "n" times. If
"n" is omitted, or if it is outside the allowed range, the
optimizer picks the number of times to unroll the loop.
The UNROLL directive overrides any setting of loop unrolling from
the command line.