Fortran Analysis, Engineering
& Migration
Fortran programs are used to design aircraft, ships, bridges, power plant,
space craft, medical drugs ... Perhaps most importantly, they are used to model the Earth's climate and to inform the
prediction of climate change. The engineers and scientists already know that the results they generate are about right.
Man years of program development on expensive equipment are invested for the last few percent
of accuracy which go beyond the engineer or scientist's intuition. The achievement of this last few percent depends on
the quality of the code.
The issues handled by fpt are:
Is it well formatted, adequately commented and are the variable names meaningful?
-
fpt automatically handles code layout and formatting. Please see the reference manual pages:
code formatting.
-
fpt measures the number of comments and, more importantly, the number of words in comments. These are reported by the
SHOW METRICS command.
-
Non-local names should be sufficiently long to be meaningful. fpt measures the average length of the names used
for objects visible in multiple routines to provide a measure of meaningfulness - see
SHOW METRICS.
-
Names visible in many different routines should be unique so that they cannot be confused with local names.
fpt measures the proportion of the names used for non-local objects which are unique. Again, please see the
Code Metrics page and the SHOW METRICS command.
Do the tests exercise all of the code? Is the test suite well automated?
-
fpt provides tools for coverage analysis. The tests show the proportion of
the code exercised in a test, and facilities are provided to merge coverage data from different test runs.
-
The record / replay facility may be used to create automated test suites, particularly where there are manual
inputs to a program, or where the program accesses a database.
-
The run-time trace facility may also be used to automate testing, and may be used to eliminate numerical
drift from test runs where code is tested under different compilers or environments.
When fpt reads a program it carries out a detailed syntactic and semantic analysis in the same way as a Fortran compiler. Diagnostics are
reported, for example:
-
If fpt is unable to analyse all or part of the syntax of a statement, probably because it is incorrect Fortran
-
If names are used inappropriately, for example, where a Fortran keyword is used to name a variable, or where the use of a name
conflicts with its declaration.
-
If expressions are constructed in such a way that there is a loss of precision.
-
If the actual arguments passed to sub-programs cannot have the INTENT required by the sub-program code - e.g. where a constant is
passed to a sub-program in an argument to which the sub-program writes a result.
Most, but not all of these occurrences indicate problems. fpt supports nearly all of the language extensions used in different compilers
but there must be some which we have not yet encountered. We attempt to keep fpt up to date with the latest Fortran standard, but new
keywords and constructs are added every few years.
These diagnostics are always issued unless they have been explicitly suppressed
(See the SUPPRESS ERROR command).
Commands are available to check for specific classes of errors. Most of the checks may also be modified by filters which suppress reports
of the less serious cases. The checks include:
-
Sub-program Argument Check -
fpt checks that the actual arguments passed to sub-programs are consistent with the formal arguments in
the sub-program declarations. The arguments must match in:
Data type, i.e. INTEGER, REAL, COMPLEX, CHARACTER, Derived TYPE etc.
Data kind and size, e.g. REAL(4), Real(8) or REAL*4, REAL*8 etc.
Intent, whether input, output, input and output, sub-program argument etc.
Protocol, whether passed by reference, value, address and length, descriptor etc.
Array shape. The array shapes must conform (though they need not match exactly).
-
Name Check -
If the same name is used for two or more objects in a program, fpt checks that the attributes of the objects are the same.
In particular, checks are made for variables with the same name at different COMMON block addresses, and for Fortran parameters
with the same names but different values in different routines. Note that these occurrences are not Fortran errors
but may indicate coding errors.
-
Check of Alignment -
this checks is for variables forced to mis-aligned addresses by SEQUENCE DERIVED TYPE, STRUCTURE/MAP/UNION, COMMON block
or EQUIVALENCE constructs.
-
Check of EQUIVALENCE -
Checks are made for:
Different objects forced to the same COMMON block address without an explicit EQUIVALENCE statement.
Objects of different data types or kinds which are set at the same address by EQUIVALENCE statements.
-
Check of DATA in COMMON -
A check is made that each COMMON block is initialised by DATA statements in at most only one program unit. This command
detects a problem with the Linux, Unix and Windows default linkers. If a COMMON block is initialised in more than one
BLOCK DATA or other program unit, these linkers overwrite all of the initialisations by the last one linked. All of the other
initialisations are lost. This issue is trapped by most modern compilers including ifx and gfortran.
-
Check of Data Type Coercion -
Checks are made for the use of inappropriate data types in Fortran constructs. The most common to be encountered is the use
of an integer variable in a context which requires a logical. Many compilers do not report this as an error.
-
Check of Array Bounds -
fpt checks that all array indices are within the bounds of the array. Two checks are made. If the index is a constant, it
is checked and an error is reported if it is out-of-bounds (Most compilers also make this check). If the index is a variable,
the relevant assignments of the variable are identified. If the variable is expected to go out-of-bounds a warning is issued.
-
Check of Usage -
Checks are made for variables which are, or may be:
assigned values which are never used
declared but never used.
-
Check of Whole Array Assignments -
fpt checks for unsubscripted whole arrays which are assigned to scalar values across an equals sign. This is legal Fortran
(Fortran 90 and Gould-SEL Extended Fortran 77) but is a common source of error.
-
Check of Program Flow -
fpt checks for unreachable code.
-
Check for Ambiguous Flow -
fpt checks for cases where the program flow is ambiguous. This occurs when a statement contains two or more function invocations
at equivalent levels of expression nesting. The Fortran standard explicitly states that the order of evaluation is undefined.
This may lead to inconsistent results, and it makes comparison of program behaviour under different compilers difficult.
-
Check of Overloaded Assignments -
Fortran 90 (and later) allows the assignment of variables of derived types to be overloaded and to be
carried out by user-defined subroutines. If no overload exists, the values of the types are copied directly. A problem
exists that an error in exporting or declaring the overload may prevent it from taking place. This check confirms
that where an overload exists, the assignment is always overloaded and is never made directly.
In auditing the objective is to assess the state of a code, not to change it. It is recommended that a standard test regime is set up in
an fsp file with a chosen set of checks, and that this is applied to a number of projects to gain a comparative feel
for code quality. The procedure for setting up projects and fsp files is described in
"Running fpt" in the fpt Reference Manual.
In addition to the error checks described above the following may be useful:
If the intention is to enforce a QA regime and to remove errors, it is recommended that the project is set up in the same way
as a software migration. This is essentially a migration from the original sources to a corrected code base. Please see the description
of Migration in the fpt Reference Manual. We recommend setting up
parallel original_source, modified_source and
fpt_output directory structures as described there. fpt may then be used to reformat the code and to
make some of the changes.
The commands for automatic error correction are described in Error Correction.
The following systematic changes may also be useful: