fpt and WinFPT Reference Manual - Command-line Commands
| SimCon Home | Ref Manual Home |
Checking Code for Errors
fpt Diagnostic Reports
When fpt detects an error or anomaly in the code, a diagnostic report is written to the fpt list file (<project name>.fpl) and, if the diagnostic relates to a specific statement, the report is inserted as a comment in the re-written code. The token at which the anomaly was detected is marked, for example:
A1(I)=0 !-----------^------------------------------------------------------------------ !!! FPT - 3679 Array index is above upper bound !------------------------------------------------------------------------------
Checks Which are Always Carried Out
fpt analyses code in the same way as a Fortran compiler. It identifies the sub-programs, variables and control contructs and it analyses the program flow and the interfaces of routines. If any inconsistency is found during these analyses, fpt reports an error. These reports are always made unless they have been deliberately suppressed. If the error occurs at a specific position in the code, the code is marked with an error message. The errors are reported in the list file and may be found interactively by the FIND ERROR command.
If there are no errors, please note that this does not guarantee that the code will compile. fpt supports all of the Fortran extensions in DEC VMS and Compaq Visual Fortran, all of the extensions in Gould-SEL Fortran and most of the extensions made by other vendors. An absence of errors at this stage means that fpt has identified all of the sub-programs, variables, and control constructs and has not identified anything which will not compile somewhere. However, an attempt is made to catch all syntax errors.
Checks Selected by the User
Many checks are made only in response to commands by the user and are not made by default (Though note that defaults may be changed in the configuration file).
This decision was made because:
Commands to Check for Errors
CHECK ARGUMENTS 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:
There are filters to allow, for example, complex passed where real is expected.
CHECK INTENT checks that the INTENT declarations of sub-program arguments are consistent with the way in which the arguments are used. This differs from the check made by CHECK ARGUMENTS. In the CHECK ARGUMENTS analysis it is assumed that the INTENT declarations are correct and that the actual arguments may be wrong. In the CHECK INTENT analysis it is assumed that the usage is correct and that the INTENT declarations may be wrong.
Declarations and Memory Layout
CHECK NAMES checks that the names used for sub-programs, variables and other objects are used to represent objects with the same attributes in different routines. In particular, fpt checks that the same variable names occupy consistent COMMON block addresses and that the same Fortran parameter names have the same values in different routines.
SHOW KEYWORDS USED FOR SYMBOLS shows all Fortran keyword and intrinsic function names which have been used for user-defined symbols. Variables named "DATA", "RESULT" and "INDEX", for example, could cause problems!
CHECK PARAMETER VALUES checks that the same Fortran parameter name has the same data type and value in all routines in which it appears. It is unlikely, for example, that the declarations of a Fortran parameter g should be written:
REAL,PARAMETER :: g=32.174
REAL,PARAMETER :: g = 9.80665
in different routines in the same program.
CHECK ALIGNMENT checks that no variables are forced to mis-aligned addresses as a result of SEQUENCE DERIVED TYPE, COMMON block STRUCTURE/MAP/UNION or EQUIVALENCE constructs.
CHECK EQUIVALENCE checks that no objects are forced to the same memory locations in COMMON blocks without an explicit EQUIVALENCE statement, and checks that all objects with the same memory addresses are of the same data types and kinds.
CHECK DATA IN COMMON checks that each COMMON block is initialised by DATA statements in 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 but one of the sets of intialisations. Multiple initialisation of COMMON blocks is illegal in Fortran 95 and later.
CHECK DATA IN STRUCTURES checks for data initialisation in STRUCTURE declarations where the records of the structures are in COMMON. This leads to the same problem as that detected by CHECK DATA IN COMMON.
The Way Variables are Used
CHECK DATA TYPE COERCION checks for questionable data type coercions in arithmetic statements and logical expressions. The most commmon of these is the use of integer variables in contexts which require logical variables, particularly in migration from VMS.
CHECK ARRAY BOUNDS checks that 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 possible assignments of the variable are identified. If the variable is expected to go out-of-bounds a warning is made. Compilers do not usually make this check.
CHECK OPTIONAL ARGUMENTS checks that optional arguments are guarded against access when they are not present. fpt identifies IF (PRESENT(...)) constructs and analyses the program flow to statements which reference the optional arguments. Those which may be accessed without a check for presence are reported and marked as possible errors.
CHECK USAGE checks for variables which are, or may be:
CHECK WHOLE ARRAY ASSIGNMENTS checks for unsubscripted whole arrays which are assigned across an equals sign. In particular, fpt checks for the situation where a whole array is assigned the value of a scalar variable or scalar expression. These sometimes indicate programming errors.
CHECK PROTECTED VARIABLES: in Fortran 2008 and later, variables in modules may be declared to be protected. The Fortran standard states that a protected variable may be assigned only in access routines contained within its parent module. However, if a protected variable is passed as an argument into an external routine it is usually not possible for a compiler to check that it has not been assigned. The command CHECK PROTECTED VARIABLES makes this check.
CHECK UNITS: fpt attempts to infer the units and dimensions of scalar real variables, and to detect inconsistent uses. Please note that this command is experimental and forms part os a research project. It may crash fpt.
CHECK FLOW checks for un-reachable code.
CHECK AMBIGUOUS FLOW checks for situations where the program flow is ambiguous or undefined. This occurs when a statement contains two or more function invocations at the same level of function nesting. Program flow differs between different compilers. This may lead to inconsistent results, and it makes comparison of program behaviour difficult.
The Way Sub-Programs are Used
CHECK 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. An error in exporting or declaring the overload may prevent it from taking place. This command checks that, where an overload exists, the assignment is always overloaded and is never made directly.
Checks Made at Program Run-Time
INSERT ARRAY BOUNDS CHECK inserts code to trap and to count array references out-of bounds. Each possible occurrence is given a unique integer identifier which is used to find the reference out-of bounds in the code. The program is not halted.
INSERT CHECK OF OPTIONAL ARGUMENTS inserts code to count accesses to optional arguments when they are not present. Each possible occurrence is given a unique integer identifier which is used to find the reference in the code. The program is not halted. Note that programs do not always crash when they reference optional arguments which are not present.
PROTECT AGAINST DIVISION BY ZERO inserts code to trap situations where a division by zero could occur. The inserted routines count the occurrences and return a user-defined value for the division. The program is not halted.
Copyright ©1995 to 2018 Software Validation Ltd. All rights reserved.