HP Fortran for OpenVMS
Language Reference Manual


Previous Contents Index

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

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

Note

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

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

Note

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

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

Note

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

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

Note

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

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

Note

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

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.

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

  • 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

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

  • 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

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

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:

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

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:


Previous Next Contents Index