If you have a current maintenance contract or your licence is less than one year old please download new versions of fpt
and WinFPT to extend and update your installations.
Download the New Versions
An error was corrected in de-referencing of pointers at sub-program call sites.
Handling of the data sizes of objects referenced by pointers has been revised. This improves behaviour of the
argument check when pointers are passed as arguments.
The command SEPARATE FSP FILES has been implemented to simplify
the process of setting up large fpt projects.
The OMP keywords up to and including OpenMP version 3.1 are recognised. Variables in the OpenMP statements are
identified, are found by the interactive find and search commands and may be obfuscated. This is a preliminary
release. The read/write intents of the variables are not identified and the OpenMP blocks are not indented in this
version. This will be addressed in the next release.
Command recall and command editing are now supported in interactive mode. The up-arrow key now works!
Identification of symbols has been revised. The % separator is now used for all
parent-child relationships. Thus, for example, the type component x of the type coords in the subroutine kinematics
is identified as kinematics%coords%x. This applies to all variants of the
SHOW SYMBOL, FIND, SET SCOPE and
Obfuscation has been revised. The way in which the variable names are obfuscated is now based on the original
name and not on the symbol. The result is that the same name in two or more alternative modules is changed to the
same obfuscated name.
Handling of all block constructs has been extensively revised. fpt and WinFPT now
process BLOCK - END BLOCK, DO CONCURRENT - ENDDO,
FORALL - END FORALL, WHERE - END WHERE
and ASSOCIATE - END ASSOCIATE constructs.
Handling of the sub-statements in IF, FORALL and
WHERE statements has been revised.
fpt and WinFPT now handle the FORALL and BLOCK-END BLOCK constructs.
Emulation of real arithmetic has been extended to provide for multi-component emulation types and to support
initialisation of the emulation system. If the emulation types have only a single component, which is a real
or complex type with the same kind as the object emulated, there is no need to modify the I/O statements in
the code. This was the situation in our original studies. If the emulation types have multiple components,
for example, with components to specify precision or to track units and dimensions, the I/O statements must
be modified to read only the numeric values. If the emulation system requires initialisation, for example
to specify a different precision regime on different runs, code must be inserted at the start of each main
program to support this. The new commands are:
EMULATE REAL ARITHMETIC: MODIFY I/O STATEMENTS,
EMULATE REAL ARITHMETIC: INITIALISE ON INPUT and
INITIALISE EMULATED REAL ARITHMETIC.
The command EMULATE EXEC SQL WHENEVER
inserts code after Oracle Pro*FORTRAN SQL blocks to trap the SQL WHENEVER conditions.
The commands SEPARATE DECLARATIONS and
SEPARATE SQL DECLARATIONS rewrite declaration statements with one variable declared on each line.
This simplifies the handling of Oracle Pro*FORTRAN SQL declarations by
Sector7's pf2pc tool.
The command REMOVE TYPE DECLARATIONS FOR SUBROUTINES
removes spurious data type declarations of subroutines. These are tolerated by the DEC VMS compiler, and cause
errors in migration.
fpt and WinFPT now handle most object-oriented Fortran constructs, including CLASS declaratons
and type-bound procedures (Methods).
Oracle Pro*FORTRAN constructs are now recognised.
The command COMMENT-OUT PRO*FORTRAN
is provided to comment-out the SQL constructs in order to
test compilation of the pure Fortran code. The constructs may be left in place to be processed by
Sector7's pf2pc tool.
The code for the Fortran modules which support emulation of real arithmetic is included in the fpt and WinFPT
distributions. Users are invited to repeat the tests made in the paper
Collins J. 2017, Testing the Numerical Precisions Required to Execute Real World Programs", IJSEA Vol 8, No 2, March 2017
with their own codes. We would like to hear of any interesting results.
The command ENFORCE ORDER OF EVALUATION IN LOGICAL EXPRESSIONS
has been implemented. The Fortran standard explicitly states that when a statement contains two or more function
invocations, the order of evaluation is undefined. This creates the problem that any mechanism which tracks
program execution (Such as the run-time trace facility in fpt)
may not be reproducible between compilers. This command enforces an order of execution.
The command CHECK OPTIONAL ARGUMENTS checks that all
accesses to optional arguments are enclosed in IF PRESENT() constructs. The check
reports whether or not unprotected arguments are ever not present.
The command CHECK PROTECTED SYMBOLS checks that variables in modules
which are declared to be protected are not written to outside the modules. Compilers usually cannot make this check
when the variables are passed into external routines.
COMMAND FILE AFTER WRITING FORTRAN. This command specifies a command (batch) file which will
be run after the Fortran output files have been written by fpt or WinFPT. By default the command
file is sought in the primary output directory. The command file may be used, for example, to copy
the output files to alternative directories or to build an application.
SHOW INCLUDE TREE and
SHOW MODULE TREE.
These commands report the INCLUDE and USE trees of
the program. They are not yet implemented in the WinFPT GUI but may be accessed through the
Tools | FPT Command Line menu.
SHOW LIVES and
SEPARATE SYMBOL LIVES. A scalar Fortran variable has multiple
lives if it is used to hold different quantities within a program or sub-program. Different
quantities are assigned or initialised in different assignment statements. If either one of two
different assignments may be used as the same right-hand-side input to the same statement, the assignments
contribute to the same life. If the different assignments only reach separate right-hand-side uses
the lives are separate. If a variable has separate lives, the meaning of the program would not
change if the separate lives had different names and occupied different memory locations. The command
SEPARATE SYMBOL LIVES renames duplicate lives
and inserts appropriate declarations. This may be important in implementing some optimisations, and has
been used in translating codes for execution by new computer architectures. Please see the description of
SCALARIZE. This command replaces array references in the code with
constant indices by scalar variables. It is used with the command UNWIND ALL LOOPS to break
an array based algorithm into scalar expressions which may then be optimised for parallel computer
UNWIND INNER LOOPS FIRST
and UNWIND OUTER LOOPS FIRST. fpt versions before
3.7-m always carried out loop unwinding starting with the innermost loop. This creates the most
efficient code if the loop unwinding is incomplete. However, the inner loop control variables may
sometimes depend on the variables in the outer loops, for example, when unwinding loops for half-diagonal
arrays. These commands specify the order of unwinding.
SIMPLIFY EXPRESSIONS TO TRIPLES.
This command separates long scalar expressions into
series of short expressions of the form A = B <operator> C. This exposes the code to more
efficient optimisation and has been used in preparing code for execution by new parallel computer
architectures. New temporary variables are created to hold intermediate results and declarations
are inserted automatically.
An additional filter has been added to the sub-program argument check:
ARGUMENT CHECK TO IGNORE ARRAY RANK.
This command may be used to suppress warnings when arrays are re-shaped across a sub-program
call site, for example, where a 2-dimensional array is passed into a routine which treats it internally
as a 3-dimensional array. Note that SimCon does not recommend this practice!
The handling of the filter NAME CHECK TO IGNORE ARGUMENTS
has been revised. This filter suppresses warnings when the same variable name is used for a variable in one routine
and for a formal argument in another. In versions of fpt before 3.7-m there were circumstances in which the warnings
could not be suppressed.
fpt version 3.7-d and earlier sometimes reported ENDIF statements as unreachable. This has been corrected.
The code modifications made by the command PROTECT AGAINST DIVISION BY ZERO have been revised.
In some circumstances code containing Fortran 90 derived types and trailing comments was handled
incorrectly by fpt versions 3.7-d and before.
The code generated by the commands CHANGE ENCODE TO INTERNAL WRITE and CHANGE DECODE TO
INTERNAL READ has been revised so as to use the number of characters specified in the ENCODE and
DECODE statements in all cases.
WinFPT version 3,7-d runs under Windows 7. Microsoft changed some aspects of he Windows
registry between Windows Vista and Windows 7, The result was that a number of applications,
including WinFPT 3.7-c, would not run. WinFPT 3.7-d does not use the registry features affected.
The keyword ELEMENTAL is recognised by WinFPT 3.7-d.
Coverage analysis has been revised. WinFPT now inserts code to track entry to sub-programs.
An error has been corrected in the handling of WHERE constructs. Versions of WinFPT before
3.7-c would sometimes attempt to insert coverage counters within the constructs. This is
illegal and the error has now been corrected.
Trailing semicolon characters in declaration statements caused earlier versons of WinFPT
to insert executable code for run-time trace and coverage amongst the declarations. This is
corrected in version 3.7-d. (The trailing semicolon is itself probably an error in any case!)
The analysis of Fortran declarations has been completely revised in version 3.7-a. The revisions
were made in order to handle some aspects of Fortran 95 declarations within modules. In particular:
USE statements may appear within interface blocks within modules, in module sub-programs and in
internal sub-programs within module sub-programs. These can generate circular references to
modules which are successfully resolved by some compilers. fpt and WinFPT can
now handle most of these cases.
Module sub-programs and INTERFACE blocks which contain MODULE PROCEDURE statements
may have compilation dependencies on other module sub-programs. This situation can usually be resolved by
compiling all of the declarations in all module sub-programs and interface blocks in a module before compiling
the sub-program bodies. WinFPT and fpt now do this for each module in turn. Please note that some
compilers are less tolerant of interlocking declarations and therefore a successful analysis by fpt or WinFPT does
not always guarantee that the code will compile in these situations.
Overloading of pre-defined operators has been revised. Overloads are now correctly cumulated from each module to
the next. For example, if module a contains an interface of the form:
INTERFACE OPERATOR (*)
MODULE PROCEDURE str_mult_r_ch
and module a is used by module b, which contains an interface
INTERFACE OPERATOR (*)
MODULE PROCEDURE str_mult_ch_ch
the two overloads are both applied within module b or when module b
is referenced in a USE statement.
The WHERE, ELSEWHERE and ENDWHERE constructs are now fully supported.
Earlier versons of WinFPT sometimes inserted INCLUDE statements before USE statements. This has been
Earlier versions of fpt sometimes reported a spurious array reference out-of-bounds in references of the form:
INTEGER :: ia(0:10)
The spurious report occurred at the reference to ia(0:). This has been corrected.
The intrinsic function PRESENT returns a default logical scalar result. In earlier versions
of fpt and WinFPT the result was incorrectly interpreted as having the shape of the corresponding
argument. This did not change the code generated by WinFPT but lead to spurious reports of
mis-matched shapes. The error has been corrected.