FPT and WinFPT Reference Manual - Command-line Commands

| SimCon Home | Reference Manual Home |


Checking Code for Errors
 

 

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:

The commands available to check for errors are:
 
Sub-program Arguments:

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:
  • data type, i.e. INTEGER, REAL, COMPLEX, CHARACTER, Derived TYPE etc.;

  • data kind and size, e.g. 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.

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, have been known to 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

and

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 by the COMMON block organisation without an explicit EQUIVALENCE statement. Checks that all objects with the same memory address are of the same data type and kind.
 
CHECK DATA IN COMMON Checks 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 one of the two sets of intialisations.
 
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 relevant 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 marked as errors.
 
CHECK USAGE Checks are made for variables which are, or may be:
  • used before they are assigned;

  • assigned values which are never used;

  • declared but never used.

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.
 
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.
Program Flow:
CHECK FLOW Checks for un-reachable code.
 
CHECK AMBIGUOUS FLOW Checks for situations wher ethe 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. A problem exists that 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 Code is inserted 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 Code is inserted 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 Code is inseerted to trap situations where a division by zero could occur. The routines inserted count the occurrences and return a user-defined value for the division. The program is not halted.


Copyright ©1995 to 2014 Software Validation Ltd. All rights reserved.