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

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

The FIXEDFORMLINESIZE directive sets the line length for fixed-form source code. The directive takes the following form: ¹

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

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

c

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

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:

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.

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

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

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

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

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:

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:

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.

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

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'

The OBJCOMMENT directive specifies a library search path in an object file. This directive takes the following form: ¹

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

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

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.

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