Introduction

Release 5.0 of the NAGWare f95 Compiler is a major release containing significant improvements to the compiler.

NAGWare f95 5.0 is fully compatible with NAGWare f90 Releases 2.1 and 2.2, as well as with NAGWare f95 Releases 1.0, 4.0, 4.1 and 4.2.

  • GUI debugger.
  • Type extension (including polymorphic variables and type selection).
  • Rank-remapping pointer assignment.
  • Improved memory allocation tracing facilities.
  • Additional checking facilities.
  • Performance enhancements.
  • Various minor enhancements.

A modified version of the open-source debugger "ups" is available on most platforms.

Type extension provides the first phase of object orientation; inheritance and polymorphic objects.

Any non-SEQUENCE derived type can be extended using the EXTENDS keyword. The extended type inherits all the components of the parent type and may add extra components.

For example:

  TYPE point

    REAL x,y

  END TYPE

  TYPE,EXTENDS(point) :: point_3d

    REAL z

  END TYPE

The type point_3d has x, y and z components. Additionally, it has a point component which refers to the inherited part.

A polymorphic variable is a pointer, allocatable array or dummy argument that is declared using the CLASS keyword instead of the TYPE keyword. A CLASS(typename) variable can assume any type in the class of types consisting of TYPE(typename) and all extensions of typename.

For example:

  REAL FUNCTION bearing(a)

    CLASS(point) a

    bearing = atan2(a%y,a%x)

  END

The function bearing may be applied to a TYPE(point) object or to a TYPE(point_3d) object, or indeed to an object of any type that is an extension of TYPE(point).

The ALLOCATE statement may now include a type-spec; this specifies the type to allocate for polymorphic variables.

For example:

  CLASS(t),POINTER :: x

  ...

  ALLOCATE(t2::x)

The type specification must be a derived-type name, and must be followed by a double colon. Note that the type specification is just type-name, not TYPE(type-name). Each item in the allocation list must be type-compatible with the type specified (in particular, if an item is not polymorphic, it must be of the same type as that specified).

The SELECT TYPE construct provides both a means of testing the dynamic type of a polymorphic variable and access to the extended components of that variable.

For example:

  CLASS(t) x

  ...

  SELECT TYPE(p=>x)

  TYPE IS (t1)

    !

    ! This section is executed only if X is exactly of TYPE(t1), not an

    ! extension thereof.  P is TYPE(t1).

    !

  TYPE IS (t2)

    !

    ! This section is executed only if X is exactly of TYPE(t2), not an

    ! extension thereof.  P is TYPE(t2).

    !

  CLASS IS (t3)

    !

    ! This section is executed if X is of TYPE(t3), or of some extension

    ! thereof, and if it is not caught by a more specific case.  P is CLASS(t3).

    !

  END SELECT

Note that "SELECT TYPE(x)" is short for "SELECT TYPE(x=>x)".

This feature allows a multi-dimensional pointer to point to a single-dimensional object.

For example:

  REAL,POINTER :: diagonal(:),matrix(:,:),base(:)

  ...

  ALLOCATE(base(n*n))

  matrix(1:n,1:n) => base

  diagonal => base(::n+1)

  !

  ! ``diagonal'' now points to the diagonal elements of ``matrix''.

  !

The -mtrace suboptions have been completely revised. Control is provided over whether the address, size, and line number of each allocation is displayed, or the tracing output can be suppressed entirely. A "paranoia" mode is provided where the memory allocator protects its data structures against inadvertent modification by the user program.

Runtime environment variables may be used to override the tracing options a program was built with, and to specify where to write the tracing output. These are only operative if the program was built with some tracing option (-mtrace=off will build a program with the tracing-capable memory allocator). The -mtrace option is now compatible with the -thread_safe option, but remains incompatible with the -gc option.

For more details see the NAGWare f95 man page.

  • Use of "dangling" pointers, which point to objects that no longer exist, can be detected with the -C=dangling option.
  • Use of undefined variables can be detected with the -C=undefined option. Program units compiled with this option are incompatible with program units compiled without this option (i.e. the whole program must be compiled the same way). For this reason, -C=undefined is not part of -C or -C=all.

    Currently, there are a number of other limitations on the use of -C=undefined.

    1. It is incompatible with ALLOCATABLE functions.
    2. It is incompatible with pointers in an initialised COMMON.
    3. The only intrinsic modules available with it are F90_KIND, F90_STAT and F90_IOSTAT.
    4. Internal READ from a CHARACTER array requires the entire specified array subobject to be "defined", even those elements corresponding to records not actually read.
    5. Internal WRITE to a CHARACTER array is considered to define the entire specified array subobject, even those elements corresponding to records not actually written.
    6. Certain intrinsic functions require the entirety of their arguments to be defined, even if some portions are not actually required for the value of the function. For example, the PAD argument to RESHAPE when no padding is actually required, and elements of the ARRAY argument to PACK that correspond to false elements of the MASK argument.
  • Recursive invocation of a non-recursive procedure can be detected with the -C=recursion option.
  • Additional checking on arguments to the bit intrinsics (ISHFT et al) to detect values out of range can be done with the -C=bits option.
  • The -nan option to initialise variables to a signalling NaN now affects saved variables as well as unsaved variables.
  • The -C=calls option now detects an attempt to use a dummy argument that is currently associated with an expression, being used as a DO variable.

The following intrinsic functions have had their performance improved:

  • The COMPLEX versions of the ABS intrinsic (FreeBSD and Linux only).
  • The COMPLEX versions of the COS and SIN intrinsics.
  • The CSHIFT intrinsic.
  • The DOT_PRODUCT intrinsic for short non-COMPLEX arguments.
  • The EXP and SQRT intrinsic (FreeBSD and Linux only).
  • The MATMUL intrinsic.
  • The RESHAPE intrinsic.

Other performance enhancements are:

  • Produce better (more optimisable) code for array assignment and WHERE.
  • Optimise storage layout of non-SEQUENCE derived types.
  • Add "constant propagation" optimisation. This might result in some potential runtime errors being detected at compile time, and so can be disabled.
  • When opening scratch files, use the TMPDIR environment variable (if set).
  • Accept scale factor followed by repeat count (in format specifications), but detect it as an error with -C=scale.
  • Allow '$' character in names, as if it were a letter.
  • VOLATILE keyword.
  • Option -wmismatch= to suppress data type and arrayness consistency checking for a list of external procedures.
  • The compiler driver now checks to make sure that it is invoking the correct version of the compiler.
  • Module information file error messages now mention the actual file name.
  • Option -f90_sign to use the Fortran-77/90 version of the SIGN intrinsic instead of the Fortran 95 one (negative zero is treated differently).

The extensions (described above) which follow the rules proposed by the proposed Final Committee Draft of the revised Fortran standard are:

  • Pointer rank remapping.
  • Scale factor followed by repeat count.
  • Type extension (including polymorphic variables and type selection).
  • Typed allocation.
  • VOLATILE keyword.

For information see J3 document "03-007.ps".