HP Fortran for OpenVMS
Language Reference Manual

14.5 DEFINE and UNDEFINE Directives

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 * (see Section 14.1).
name
Is the name of the variable.
val
Is an INTEGER(4) value assigned to name.

Rules and Behavior

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 that has not been defined produces a compiler warning.

The DEFINE and UNDEFINE directives can appear anywhere in a program, enabling and disabling symbol definitions.

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

For More Information:

On syntax rules for all general directives, see Section 14.1.
On the IF and IF DEFINED directives, see Section 14.9.

Note

¹ The following forms are also allowed: !MS$DEFINE name[=val] and !MS$UNDEFINE name.

14.6 FIXEDFORMLINESIZE Directive

The FIXEDFORMLINESIZE directive 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 * (see Section 14.1).

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.

Examples

Consider the following:

CDEC$ NOFREEFORM CDEC$ FIXEDFORMLINESIZE:132 WRITE(*,*) 'Sentence that goes beyond the 72nd column without continuation.'

For More Information:

On syntax rules for all general directives, see Section 14.1.
On fixed-format source code, see Section 2.3.2.

Note

¹ The following form is also allowed: !MS$FIXEDFORMLINESIZE:{72|80|132}.

14.7 FREEFORM and NOFREEFORM Directives

The FREEFORM directive specifies that source code is in free-form format. The NOFREEFORM directive specifies that source code is in fixed-form format.

These directives take the following forms: ¹

cDEC$ FREEFORM cDEC$ NOFREEFORM

c
Is one of the following: C (or c), !, or * (see Section 14.1).

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

On syntax rules for all general directives, see Section 14.1.
On free-form and fixed-form source code, see Section 2.3.

Note

¹ The following forms are also allowed: !MS$FREEFORM and !MS$NOFREEFORM.

14.8 IDENT Directive

The IDENT directive specifies a string that identifies 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 IDENT directive takes the following form:

cDEC$ IDENT string

c
Is one of the following: C (or c), !, or * (see Section 14.1).
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 or module.

For More Information:

On syntax rules for all general directives, see Section 14.1.

14.9 IF and IF DEFINED Directives

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 * (see Section 14.1).
expr
Is 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.

Rules and Behavior

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, including: .LT., <, .GT., >, .EQ., ==, .LE., <=, .GE., >=, .NE., /=, .EQV., .NEQV., .NOT., .AND., .OR., and .XOR.. The logical expression can be as complex as you like, but the whole directive must fit on one line.

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

For More Information:

On syntax rules for all general directives, see Section 14.1.
On the DEFINE and UNDEFINE directives, see Section 14.5.

Note

¹ Each directive in the construct can begin with !MS$ instead of cDEC$

14.10 INTEGER Directive

The INTEGER directive specifies the default integer kind. This directive takes the following form: ¹

cDEC$ INTEGER:{1|2|4|8}

c
Is one of the following: C (or c), !, or * (see Section 14.1).

Rules and Behavior

The INTEGER directive specifies a size of 1 (KIND=1), 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.

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

For More Information:

On syntax rules for all general directives, see Section 14.1.
On the INTEGER data type, see Section 3.2.1.
On the REAL directive, see Section 14.17.

Note

¹ The following form is also allowed: !MS$INTEGER:{2|4|8}.

14.11 IVDEP Directive

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 * (see Section 14.1).

Rules and Behavior

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:

An UNROLL directive
Placeholder lines
Comment lines
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:

Retrieve INDARR(I).
Use the result from step 1 to retrieve A(INDARR(I)).
Retrieve B(I).
Add the results from steps 2 and 3.
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.

For More Information:

On syntax rules for all general directives, see Section 14.1.

14.12 MESSAGE Directive

The MESSAGE directive 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 * (see Section 14.1).
string
Is a character constant specifying a message.

Examples

Consider the following:

!DEC$ MESSAGE:'Compiling Sound Speed Equations'

For More Information:

On syntax rules for all general directives, see Section 14.1.

Note

¹ The following form is also allowed: !MS$MESSAGE:string.

14.13 OBJCOMMENT Directive

The OBJCOMMENT directive 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 * (see Section 14.1).
library
Is a character constant specifying the name and, if necessary, the path of the library that the linker is to search.

Rules and Behavior

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.

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

For More Information:

On syntax rules for all general directives, see Section 14.1.

Note

¹ The following form is also allowed: !MS$OBJCOMMENT LIB:library.

14.14 OPTIONS Directive

The OPTIONS directive affects data alignment and warnings about data alignment. It takes the following form:

cDEC$ OPTIONS option [option] ... cDEC$ END OPTIONS

c
Is one of the following: C (or c), !, or * (see Section 14.1).
option
Is one (or both) of the following:

/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).

/[NO]ALIGN[=p]
Controls alignment of fields in record structures and data items in common blocks. The fields and data items can be naturally aligned (for performance reasons) or they can be packed 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 records
STRUCTURES: A synonym for RECORDS

rule
Is one of the following keywords:

PACKED
Packs fields in records or data items in common blocks on arbitrary byte boundaries.
NATURAL
Naturally aligns fields in records and data items in common blocks on up to 64-bit boundaries (inconsistent with the Fortran 95/90 standard).
This keyword causes the compiler to 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 (consistent with the Fortran 95/90 standard).
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 specifying /ALIGN, /ALIGN=NATURAL, and
/ALIGN=(RECORDS=NATURAL,COMMONS=NATURAL).
NONE
Is the same as specifying /NOALIGN, /ALIGN=PACKED, and
/ALIGN=(RECORDS=PACKED,COMMONS=PACKED).

Rules and Behavior

The OPTIONS (and accompanying END OPTIONS) directives must come after OPTIONS, SUBROUTINE, FUNCTION, and BLOCK DATA statements (if any) in the program unit, and before the executable part of the program unit.

The OPTIONS directive supersedes the compiler option that sets alignment and the compiler option that sets warnings about alignment.

For performance reasons, HP Fortran 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 compiler option that sets alignment) minimizes misaligned data.

If you want aligned data in common blocks, do one of the following:

Specify /ALIGN=COMMONS=STANDARD for data items up to 32 bits in length.
Specify /ALIGN=COMMONS=NATURAL for data items up to 64 bits in length.
Place source data declarations within the common block in descending size order, so that each data item is naturally aligned.

If you want packed, unaligned data in a record structure, do one of the following:

Specify /ALIGN=RECORDS=PACKED.
Place source data declarations in the record structure so that the data is naturally aligned.

An OPTIONS directive must be accompanied by an END OPTIONS directive; the directives can be nested up to 100 levels. For example:

CDEC$ OPTIONS /ALIGN=PACKED ! Start of Group A declarations CDEC$ OPTIONS /ALIGN=RECO=NATU ! Start of nested Group B more declarations CDEC$ END OPTIONS ! End of Group B still more declarations CDEC$ END OPTIONS ! End of Group A

The CDEC$ OPTIONS specification for Group B only applies to RECORDS; common blocks within Group B will be PACKED. This is because COMMONS retains the previous setting (in this case, from the Group A specification).

For More Information:

On syntax rules for all general directives, see Section 14.1.
On alignment and data sizes, see the HP Fortran for OpenVMS User Manual.
On compiler options, see the HP Fortran for OpenVMS User Manual.

Contents

Index

HP Fortran for OpenVMSLanguage Reference Manual

14.5 DEFINE and UNDEFINE Directives

c

name

val

1 The following forms are also allowed: !MS$DEFINE name[=val] and !MS$UNDEFINE name.

c

1 The following form is also allowed: !MS$FIXEDFORMLINESIZE:{72|80|132}.

c

1 The following forms are also allowed: !MS$FREEFORM and !MS$NOFREEFORM.

c

string

c

expr

name

block

1 Each directive in the construct can begin with !MS$ instead of cDEC$

c

1 The following form is also allowed: !MS$INTEGER:{2|4|8}.

c

c

string

1 The following form is also allowed: !MS$MESSAGE:string.

c

library

1 The following form is also allowed: !MS$OBJCOMMENT LIB:library.

c

option

p

class

rule

ALL

NONE

HP Fortran for OpenVMS
Language Reference Manual

¹ The following forms are also allowed: !MS$DEFINE name[=val] and !MS$UNDEFINE name.

¹ The following form is also allowed: !MS$FIXEDFORMLINESIZE:{72|80|132}.

¹ The following forms are also allowed: !MS$FREEFORM and !MS$NOFREEFORM.

¹ Each directive in the construct can begin with !MS$ instead of cDEC$

¹ The following form is also allowed: !MS$INTEGER:{2|4|8}.

¹ The following form is also allowed: !MS$MESSAGE:string.

¹ The following form is also allowed: !MS$OBJCOMMENT LIB:library.