NAG Fortran Compiler Release 6.2 Release Note
NAG Fortran Compiler Release 6.2 Release Note
Table of Contents
- 1 Introduction
- 2 New Features Summary
- 3 New Fortran 2003 Features
- 4 New Fortran 2008 Features
- 5 New Draft Fortran 2018 Features
- 6 Other Extensions
- 7 Additional error checking
- 8 Miscellaneous enhancements
1 Introduction
Release 6.2 of the NAG Fortran Compiler is a minor update.
Customers upgrading from a previous release of the NAG Fortran Compiler will need a new licence key for this release.
See KLICENCE.txt for more information about Kusari Licence Management.
1.1 Compatibility with Release 6.1
Programs which use features from HPF (High Performance Fortran), for example the ILEN intrinsic function or the HPF_LIBRARY module, are no longer supported.The previously deprecated -abi=64 option on Linux x86-64 has been withdrawn. This option provided an ABI with 64-bit pointers but 32-bit object sizes and subscript arithmetic, and was only present for compatibility with Release 5.1 and earlier.
With the exception of HPF support and the deprecated option removal, Release 6.2 of the NAG Fortran Compiler is fully compatible with Release 6.1.
1.2 Compatibility with Release 6.0
With the exception of HPF support and the deprecated option removal, Release 6.2 of the NAG Fortran Compiler is compatible with Release 6.0 except that programs that use allocatable arrays of “Parameterised Derived Type” will need to be recompiled (this only affects module variables and dummy arguments).1.3 Compatibility with Releases 5.3.1, 5.3 and 5.2
With the exception of HPF support and the deprecated option removal, Release 6.2 of the NAG Fortran Compiler is fully compatible with Release 5.3.1. It is also fully compatible with Releases 5.3 and 5.2, except that on Windows, modules or procedures whose names begin with a dollar sign ($) need to be recompiled.For a program that uses the new “Parameterised Derived Types” feature, it is strongly recommended that all parts of the program that may allocate, deallocate, initialise or copy a polymorphic variable whose dynamic type might be a parameterised derived type, should be compiled with Release 6.2.
1.4 Compatibility with Release 5.1
Release 6.2 of the NAG Fortran Compiler is compatible with NAGWare f95 Release 5.1 except that:- programs that use features from HPF are not supported;
- programs or libraries that use the CLASS keyword, or which contain types that will be extended, need to be recompiled;
- 64-bit programs and libraries compiled with Release 5.1 on Linux x86-64 (product NPL6A51NA) are binary incompatible, and need to be recompiled.
1.5 Compatibility with Earlier Releases
Except as noted, the NAG Fortran Compiler release 6.2 is compatible with NAGWare f90 Releases 2.1 and 2.2, as well as with all NAGWare f95 Releases from 1.0 to 5.0, except as noted below.The following incompatibilities were introduced in Release 5.1:
- The value returned by STAT=, on an ALLOCATE or DEALLOCATE statement, may differ from the pre-5.1 value in some cases. For further information see the F90_STAT module documentation.
- Programs that used type extension (EXTENDS attribute) in 5.0 need to be recompiled.
- Formatted output for IEEE infinities and NaNs is different, and now conforms to Fortran 2003.
- List-directed output of a floating-point zero now uses F format, as required by Fortran 2003, instead of E format.
- An i/o or format error encounted during NAMELIST input will now skip the erroneous record. This behaviour is the same as all other formatted input operations including list-directed.
2 New Features Summary
With the addition of defined input/output, and recursive specification functions, Fortran 2003 is fully supported by Release 6.2. The other major new feature is single image coarray support (Fortran 2008).
Several other new features have been added from Fortran 2008, and some from the draft Fortran 2018 standard. Some other common (obsolete) extensions have been added.
This release also contains additional error checking functionality and other minor enhancements.
3 New Fortran 2003 Features
-
A function that is used in a specification expression is now permitted to be
recursive (defined with the RECURSIVE attribute).
For example
PURE INTEGER RECURSIVE FUNCTION factorial(n) RESULT(r) INTEGER,INTENT(IN) :: n IF (n>1) THEN r = n*factorial(n-1) ELSE r = 1 END IF END FUNCTIONcan now be used in a specification expression. Note that a specification function must not invoke the procedure that invoked it. - Defined input/output (for derived types) is now available. For details see the Fortran 2003 language documentation, or any good textbook.
4 New Fortran 2008 Features
-
Coarray syntax and semantics are accepted (and checked for correctness).
Coarrays are part of an SPMD (Single Program Multiple Data) programming model,
where multiple copies of a program, called “images”, are executed in parallel.
In this release of the NAG Fortran Compiler, execution is limited to a single image;
that is, without parallel execution.
For further details on coarrays, see the Fortran 2008 language documentation, or any good textbook.
- The pure inquiry function C_SIZEOF has been added to the intrinsic module ISO_C_BINDING. This function takes one argument (X) which must be interoperable, and returns the storage size in bytes, like the C sizeof operator. If X is an array, the result is the size of the whole array, not just a single element. Note that X cannot be an assumed-size array.
-
The name of an external procedure with a binding label is now considered
to be a local identifier only, and not a global identifier.
That means that code like the following is now standard-conforming:
SUBROUTINE sub() BIND(C,NAME='one') PRINT *,'one' END SUBROUTINE SUBROUTINE sub() BIND(C,NAME='two') PRINT *,'two' END SUBROUTINE PROGRAM test INTERFACE SUBROUTINE one() BIND(C) END SUBROUTINE SUBROUTINE two() BIND(C) END SUBROUTINE END INTERFACE CALL one CALL two END PROGRAM - An internal procedure is permitted to have the BIND(C) attribute, as long as it does not have a NAME= specifier. Such a procedure is interoperable with C, but does not have a binding label (as if it were specified with NAME='').
-
The intrinsic functions MAXLOC and MINLOC now have an additional
optional argument BACK following the KIND argument.
It is scalar and of type Logical; if present with the value .True., if
there is more than one element that has the maximum value (for MAXLOC)
or minimum value (for MINLOC), the array element index returned is for
the last element with that value rather than the first.
For example, the value of
MAXLOC( [ 5,1,5 ], BACK=.TRUE.)is the array [ 3 ], rather than [ 1 ]. -
An ALLOCATE statement with the SOURCE= clause is permitted to
have more than one allocation.
The source-expr is assigned to every variable allocated in the statement.
For example,
PROGRAM multi_alloc INTEGER,ALLOCATABLE :: x(:),y(:,:) ALLOCATE(x(3),y(2,4),SOURCE=42) PRINT *,x,y END PROGRAMwill print the value “42” eleven times (the three elements of x and the eight elements of y). If the source-expr is an array, every allocation needs to have the same shape. -
The restrictions that formerly applied to data-implied-do loop limits, and
to subscripts in a data-i-do-object, have been lifted.
These restrictions did not permit use of intrinsic functions that were permitted
in other constant expressions.
For example,
DATA (x(i),i=1,SIZE(x))/1,2,3,4,5,6,7,8,9,10/is now permitted. -
A dummy argument with the VALUE attribute is permitted to be an array,
and is permitted to be of type CHARACTER with length non-constant and/or
not equal to one.
(It is still not permitted to have the ALLOCATABLE or POINTER
attributes, and is not permitted to be a coarray.)
The effect is that a copy is made of the actual argument, and the dummy argument is associated with the copy; any changes to the dummy argument do not affect the actual argument. For example,
PROGRAM value_example_2008 INTEGER :: a(3) = [ 1,2,3 ] CALL s('Hello?',a) PRINT '(7X,3I6)',a CONTAINS SUBROUTINE s(string,j) CHARACTER(*),VALUE :: string INTEGER,VALUE :: j(:) string(LEN(string):) = '!' j = j + 1 PRINT '(7X,A,3I6)',string,j END SUBROUTINE END PROGRAMwill produce the outputHello! 2 3 4 1 2 3
5 New Draft Fortran 2018 Features
- The expression in an ERROR STOP or STOP statement can be non-constant. It is still required to be default Integer or default Character.
-
The ERROR STOP and STOP statements now have an optional QUIET= specifier,
which is preceded by a comma following the optional stop-code.
This takes a Logical expression; if it is true at runtime then the STOP (or
ERROR STOP) does not output any message, and information about any IEEE exceptions
that are signalling will be suppressed.
For example,
STOP 13, QUIET = .True.will not display the usual ‘STOP: 13’, but simply do normal termination, with a process exit status of 13. Note that this means that the following two statements are equivalent:STOP, QUIET=.True. STOP 'message not output', QUIET=.TRUE. -
The intrinsic subroutine MOVE_ALLOC now has optional STAT and
ERRMSG arguments.
The STAT argument must be of type Integer, with a decimal range of at
least four (i.e. not an 8-bit integer); it is assigned the value zero if the
subroutine executes successfully, and a nonzero value otherwise.
The ERRMSG argument must be of type Character with default kind.
If STAT is present and assigned a nonzero value, ERRMSG will be
assigned an explanatory message (if it is present); otherwise, ERRMSG
will retain its previous value (if any).
For example,
INTEGER,ALLOCATABLE :: x(:),y(:) INTEGER istat CHARACTER(80) emsg ... CALL MOVE_ALLOC(x,y,istat,emsg) IF (istat/=0) THEN PRINT *,'Unexpected error in MOVE_ALLOC: ',TRIM(emsg)The purpose of these arguments is to catch errors in multiple image coarray allocation/deallocation, such as STAT_STOPPED_IMAGE and STAT_FAILED_IMAGE. As this release of the NAG Fortran Compiler only supports single image execution, STAT will always be assigned zero, and ERRMSG will never be assigned anything.
6 Other Extensions
-
Obsolete extension: D (debug) lines in Fixed Source Form.
A line with the letter ‘D’ (or ‘d’) in column one is a D line. If the -d_lines option is used, this will be treated as a normal Fortran line, as if the D were a space. Otherwise, it will be treated as a comment line, as if the D were a C.For example, in
SUBROUTINE TEST(N) INTEGER N D PRINT *,'TESTING N' ...the PRINT statement will be compiled only if -d_lines is used.Note that if the initial line of a statement is a D line, any continuation lines it may have must also be D lines. Similarly, if the initial line of a statement is not a D line, any continuation lines must not be D lines.
A D line can use TAB format, with the TAB expanding to one less space as the letter D already accounts for a space.
-
Obsolete (“dusty deck”) extension: named COMMON blocks with different sizes.
With the -dusty option, named COMMON blocks with different sizes (in the same file) are permitted. The effect is that all the copies of that COMMON block are increased to the maximum size. Note that if a COMMON block in a separately compiled file has a different size, the results are indeterminate, especially if the COMMON block is initialized in a BLOCK DATA subprogram where it has a smaller size.Use of this feature is strongly disrecommended. Also, a COMMON block that is OpenMP THREADPRIVATE is still required to be the same size everywhere, even with the -dusty option.
-
When overriding a byte-length specifier for non-CHARACTER type, the syntax
“*(integer)” is accepted; previously, only
“*integer” was accepted.
For example,
REAL X*4, Y*(8)Note that byte length specifiers are an obsolete extension. Kind type parameters should be used instead.
7 Additional error checking
-
The runtime option show_dangling enables tracing of dangling pointers,
for code compiled with -C=dangling.
Runtime options are controlled by the NAGFORTRAN_RUNTIME_OPTIONS environment variable. If show_dangling is specified, messages will be produced on the runtime error file when a dangling pointer is created, reassociated with something else, nullified, or ceases to exist. For example,
[file.f90, line 20: Dangling pointer P detected (number 1), associated at file.f90, line 18] [file.f90, line 7: Dangling pointer P (number 1) has been reassociated] [file.f90, line 9: Dangling pointer Q (number 2) has been nullified] [file.f90, line 21: Dangling pointer R (number 3) no longer exists]
The dangling pointer number is incremented every time a dangling pointer is detected. If an array with dangling pointer components ceases to exist, a message will be produced for each dangling pointer component of each element; however, the element subscripts will not be shown, instead ‘(...)’ will be produced to indicate that it is an array element, e.g.[file.f90, line 44: Dangling pointer X(...)%A (number 8) no longer exists]
- A “Questionable” warning message is now produced if a DO index variable (in a DO statement, or an i/o-implied-do) is liable to accidental modification. That is, if it has the POINTER or TARGET attribute, is in a COMMON block or EQUIVALENCE, or is a non-local variable being accessed by use or host association.
- A warning message is now produced if the result of an intrinsic function or operation underflows to zero. Previously this warning only appeared for exponentiation.
-
The -C=do option has been extended to check for modifying an
active DO index variable via host association. With this option, the example
Program example Do i=1,10 Call inner Print *,i End Do Contains Subroutine inner i = 999 End Subroutine End Programwill produce the outputRuntime Error: example.f90, line 8: Assignment to active DO index I Program terminated by fatal error -
Use in a READ statement of a character constant format or a FORMAT
statement that has a character string edit descriptor is now detected at compile
time.
For example,
Read 1,n 1 Format("Oops",I10)will produce an error at compile time. - When an input/output unit number is a 64-bit integer, having an invalid value such as being negative or greater than HUGE(0_int32) is now more reliably detected. Negative values will now always raise IOERR_BAD_UNIT, and positive values that are out of range will be treated as a nonexistent unit (thus raising IOERR_BAD_UNIT except for CLOSE, INQUIRE, and WAIT with no ID= specifier).
-
The new option -C=alias enables checking for violation of the
dummy argument aliasing rules; specifically, assignment to a scalar dummy
argument is checked to determine whether it affects another scalar dummy argument;
if so, a runtime error is produced.
For example, if the file sub.f90 contains the following program,
Subroutine sub(a,b) a = 1 b = 2 End Subroutine Program test Call sub(x,x) Print *,x End Programand it is compiled with -C=alias, the outputRuntime Error: sub.f90, line 2: Assignment to A affects dummy argument B Program terminated by fatal errorwill be produced at runtime.This option is included in -C=all, but not included in the plain -C option, as when it is extended to cover other aliasing cases (in particular, arrays), it may have a large performance impact.
- Assignment of an out-of-range value (e.g. a large magnitude double precision value to a single precision variable) now produces a warning at compile time.
- An actual argument that is not simply contiguous when the corresponding dummy argument is a CONTIGUOUS pointer now produces an error message.
- Better error messages are now produced when a symbol has been accessed by USE association before an attempt to IMPORT it.
8 Miscellaneous enhancements
-
The interface generator (“nagfor =interfaces”) now
outputs USE statements in a standardised form, with entities
required by each resulting interface block imported using the ONLY
clause and with unneeded module imports omitted.
For example, given the code
Subroutine s(n, x) Use iso_fortran_env Integer (int32) :: n Real (real64) :: x(n) Print *, compiler_options() x = 42._real64 End Subroutinean interface module of the formModule interfaces ! Interface module generated on ... Interface Subroutine s(n, x) Use, Intrinsic :: iso_fortran_env, Only: int32, real64 Integer (int32) :: n Real (real64) :: x(n) End Subroutine End Interface End Moduleis created. - Callgraph output (from “nagfor =callgraph”) now indicates when an actual procedure for a non-optional dummy could not be found in the input source.
- The polisher (“nagfor =polish”) and dependency analyser (“nagfor =depend”) now accept the -maxcontin= option, and so can be used on programs with more than 255 continuation lines.
- The default polish setting -name_scopes=Insert has been changed to -name_scopes=Keywords.
-
There is a new polish option -dcolon_in_decls=X which controls the optional
double colon in declaration and specification statements. X can be one of:
‘Asis’, to make no change, ‘Insert’, to insert an optional double
colon when it is missing, and ‘Remove’, to remove the double colon when
it is optional.
For example, with the code
Real x Real :: y Real, Save :: zthe -dcolon_in_decls=Insert option producesReal :: x Real :: y Real, Save :: zand the -dcolon_in_decls=Remove option producesReal x Real y Real, Save :: z -
The new enhanced polisher tool provides advanced options for polishing files
that are compilable.
These options are:
- -add_arg_keywords
- Add keywords to actual arguments in references to user-defined procedures with
an explicit interface and at least two dummy arguments, and in references to
intrinsic procedures and intrinsic module procedures with at least three dummy
arguments (except for MAX and MIN, where it is at least three
actual arguments).
Keywords are not added to arguments that precede a label argument. The order of the arguments is unchanged.
- -add_arg_keywords=proc_class_list
- Add keywords to actual arguments in procedure references, when the procedure
has an explicit interface, for the classes of procedure listed in
proc_class_list, which is a comma-separated list that may contain the
following suboptions:
all (all classes of procedure), bound (object-bound and type-bound procedures), dummy (dummy procedures), external (external procedures), internal (internal procedures), intrinsic (intrinsic procedures and intrinsic module procedures), module (non-intrinsic module procedures), user (procedures other than intrinsic procedures and intrinsic module procedures). Keywords are not added to arguments that precede a label argument. The order of the arguments is unchanged. Procedure pointer components are also known as “object-bound procedures”, and thus included in -add_arg_keywords=bound; named procedure pointers are treated as external procedures and thus included in -add_arg_keywords=external.
A suboption name may be followed by a single nonzero digit (e.g. “intrinsic3”); this specifies that for procedures covered by that suboption, keywords are only to be added if the procedure has at least that many dummy arguments. For type-bound and object-bound procedures, the passed-object dummy argument does not count towards the limit (as it never appears in the argument list). The intrinsic MAX and MIN functions use the number of actual arguments instead.
A suboption name followed by a digit may be further followed by the letter ‘a’ (e.g. “intrinsic3a”; this specifies that the argument limit applies to the number of actual arguments in a reference to the procedure, not the number of dummy arguments (the number of actual arguments will be less than the number of dummy arguments when an optional argument is omitted).
Note that suboptions are parsed from left to right, and later suboptions override earlier ones.
- -intrinsic_case=analogy
- Specifies whether the case of an intrinsic procedure name should be the same as other names (as_names), or the same as language keywords (as_keywords).
- -remove_intrinsic_stmts
- Specifies that intrinsic procedure names that were not passed as actual arguments should be removed from INTRINSIC statements, and that if all the names in an INTRINSIC statement are removed in this way, the INTRINSIC statement itself should be removed. Any comments associated with the INTRINSIC statement will remain.
- The precision unifier now has more accurate analysis of EQUIVALENCE statements, improving the usefulness of its warning messages.
- Assigning a scalar value of intrinsic (non-Character) type to a contiguous array of the same type and kind has improved performance in many cases.
-
The new -kind=unique option makes all intrinsic kind type
parameter values unique across the intrinsic types (except that the kinds of
Real and Complex are the same).
This means that using the kind type parameter of one intrinsic type to
declare the kind of a different intrinsic type will produce a compile-time
error.
For example,
Integer,Parameter :: rkind = Selected_Real_Kind(15) Integer,Parameter :: ikind = Selected_Int_Kind(9) Real(rkind) :: x Integer(rkind) :: nwill produce an error for the ‘Integer(rkind)’ statement. -
The new -Warn=class option causes additional warning messages to be
produced according to class as follows:
- allocation
- warn if an intrinsic assignment might cause allocation of the variable (or a subcomponent thereof) being assigned to;
- constant_coindexing
- warn if all the cosubscripts in an image-selector are constant;
- reallocation
- warn if an intrinsic assignment might cause reallocation of an already-allocated variable (or a subcomponent thereof) being assigned to;
- subnormal
- warn if an intrinsic function or operation with normal operands produces a subnormal result (reduced precision, less than TINY(...)).
Reallocation only occurs when the shape of an array, the value of a deferred type parameter, or the dynamic type (if polymorphic), differs between the variable (or subcomponent) and the expression (or the corresponding subcomponent). Allocation can occur also when the variable (or subcomponent) is not allocated prior to execution of the assignment (except for broadcast assignment). Note that -Warn=allocation thus subsumes -Warn=reallocation.
For example, in
Subroutine s(x,y) Integer,Allocatable :: x,y(:) x = 123 y = [ 1,2,3 ] End Subroutineboth assignments might cause allocation (and thus produce warnings with -Warn=allocation), but only the assignment to y can cause reallocation (and thus produce a warning with -Warn=reallocation). -
Conversion errors in PARAMETER declarations now produce more accurate
line number information.
Previously these errors were reported on the use of the parameter, rather than
its declaration.
Similarly, errors in initialisation of a variable could sometimes be reported
with no line information; these are now reported at the line of the initialisation.
For example, if a source file contains the following code,
Program bad Use Iso_Fortran_Env Integer(int8),Parameter :: x = 1000 Print *,x End Programthe conversion error for X will be reported at line 3 rather than at line 4.Furthermore, if an overflow arises converting a floating-point constant value to an integer in such a context, this is now considered to be an error rather than a warning. (The previous behaviour can still be obtained with the -dusty option.) For example, if a source file contains
Subroutine s Integer :: x = 1d300 x = x + 1 Print *,x End Subroutinethe conversion overflow will be reported as an error at line 2. -
The fpp preprocessor now allows unrecognised directives in unprocessed sections.
For example, if the file “test.ff90” contains the text
Program test #if 0 #unknown directive #endif Print *,'ok' End Programit will now compile successfully instead of producing an error message, and print ‘ok’ when executed. - The full compiler manual is now available in HTML. It is located in html/manual/compiler.html.