SimCon logo

SimCon - Fortran Analysis, Engineering & Migration

  FPT Reference ManualDownloadsLicensingHome

WinFPT - Building a WinFPT Project, and Quality Assurance Analysis - a First Tutorial
In this tutorial we will:
  • Build a WinFPT project for a small Fortran program
  • Carry out a Q.A. audit - find and fix some errors
  • Reformat the code into your house style
  • Write out the re-formatted Fortran code.
The Original Program - MILATC
MILATC is an air traffic control simulation. There is a military airfield in a valley on the edge of a mountain range. Transport aircraft will take off from this airfield and fly away from the mountains. Shortly after take-off, they pass close to a commercial air corridor which crosses the mountains. The commercial aircraft are hidden by the mountains from the military radar. What is the risk of a near miss?

MILATC is made up of 3 files:


If you installed WinFPT in the default location under C:\Program Files you will find them in the folder:

C:\Program Files\SimCon\WinFPT\FPTeg\milatc\original

If you installed WinFPT elsewhere, please use the corresponding directories in your installation as you follow this tutorial.

There is a Microsoft Developer Studio and Compaq Visual Fortran project in the directory:

C:\Program Files\SimCon\WinFPT\FPTeg\milatc\original\milatc

You can build and run the program. It should compile and run without errors (Though as we will see, it gives the wrong answers!). The results are written to the terminal window.


Building the WinFPT Project
If you are doing this for the first time it is simplest to use the project wizard. When you launch WinFPT the initial screen shows:

Select the Project Wizard. The Wizard's introductory screen appears. If you are already running WinFPT, you can start the Project Wizard by selecting the menu item File | Project Wizard....

Click on Next. The Wizard asks for a project name and the folder in which you want to work. Name the project milatc.fpp and browse to the folder

C:\Program Files\SimCon\WinFPT\FPTeg\milatc\fpt

This folder is empty when WinFPT is first installed.

Click on Next. The Wizard now asks for the input files. Click on Add Files... and browse to the source directory,

C:\Program Files\SimCon\WinFPT\FPTeg\milatc\original

and select the three Fortran files. Click on Next. The Wizard asks where the include files will be found. MILATC doesn't use include files, so accept the default by clicking on Next to continue to the next screen.

The last Wizard screen asks whether you would like to carry out the analysis at once. Click on the button No, do not carry out the analysis straight away. We don't need to change anything, but this way you will see a WinFPT project as it would normally be loaded. Click on Finish. The new project appears in the Project tree window in the top left-hand corner of the display.

Generally, the tree contains the list of primary input files (the files which contains programs, subroutines and so on) and commands which tell WinFPT such things as the code layout and the locations of include files. You have created your project. Save it by clicking on the project save button on the toolbar,

or by selecting the menu item File | Save Project.... WinFPT will ask which continuation character to use - accept the default.


Analysing the Code
Up to now, WinFPT has checked that the Fortran files exist, but it has not read and analysed them. There are two ways to launch the analysis.

The Analysis Menu and Analysis Button

Select the menu item Analysis | Analyse Code.... A large window opens with a range of options for the code characteristics. You can choose, for example, whether to accept dollar and underscore as alphabetic characters, or you can set up the sizes of the integer and real variables:

This window may look a little alarming, but in most Fortran projects, you can simply use the default settings. You only need this window when the system for which the code is written has unusual characteristics, like 8-byte integers or special characters in the variable names. Dismiss it, by clicking on the Cancel button. Launch a default analysis by clicking on the Analysis button:

WinFPT reads and analyses the code. It builds the program call-tree in the Call tree window. Any error messages and warnings about the analysis are written to the Report view at the bottom of the screen. The messages are colour-coded. Errors are red, warnings are orange and informational notes are green. Scroll up to the top of the report window. The analysis of MILATC generates two notes, one error and three warnings:


Investigating the Errors
Double-click the first red error message, number 2183. WinFPT displays the code where the error was detected in the Code window.

The code displayed by WinFPT is syntax-coloured. Fortran keywords and intrinsic functions are blue, comments are green and variable names and numbers are black. Error messages are red. This is true syntax colouring. If a keyword is used as a variable name it is coloured black, not blue.

WinFPT has reported an error in the statement

      IF (LOAD) THEN C1 = C1 - MCLLOD
The problem is that the keyword THEN has been used incorrectly. Space characters are not significant in fixed-format Fortran, so the statement becomes
      IF (LOAD) THENC1 = C1 - MCLLOD
and the new variable, THENC1 is never used again so the result is thrown away. Note that THEN is coloured black, not blue. WinFPT has recognised that it cannot be a keyword in this context. The programmer should either have written
      IF (LOAD) C1 = C1 - MCLLOD
      IF (LOAD) THEN
         C1 = C1 - MCLLOD
Note that this erroneous code compiles and runs without warnings on most systems.

The Error Table

If you double-click the first two messages in the report window, WinFPT displays a message that they do not relate to specific lines in the code. WinFPT has reported, for example, that there are some lines longer than 72 characters, and that there are spaces embedded in numbers. WinFPT writes only one message for issues like this, otherwise reports of more serious problems disappear in a mass of similar messages. To find all of the errors and warnings in the code, open the Error Table by clicking on the button

or the menu item Tools | Error Table.... WinFPT displays the table of error messages and warnings. Sort the table in order of frequency of occurrence by clicking on the column heading Count.

The first warning, number 1901, is that a line of code runs into the comment field after column 72. Note that WinFPT doesn't report delimited comments which run past the end of the code line. Double-click the error number to display the code where the problem occurs. You will see two messages associated with the same code line. The second, number 1941, is that a space or continuation line has been removed from within a number. The expression in the parameter statement, 50.01000/60/60, also looks suspicious!

To see what has happened, scroll across to the end of the line. The * character in the original expression was in column 73, and was therefore treated as a comment, both by WinFPT and by the Fortran compiler. WinFPT has inserted the ! character so that the comment is now properly delimited. The programmer intended the expression to be 50.0*1000/60/60, converting kilometres per hour into metres per second.

Double-click the error numbers in the Error Table to examine the code for the other errors and warnings. In particular, look at the warning number 2345, "Data type of parameter does not match that of the expression". Why is MSCLIM different from the other parameters?

The Symbol Table

To investigate MSCLIM, open the Symbol Table by clicking on the toolbar button

or the menu item Tools | Symbol Table.... WinFPT displays a table of all of the symbols in the program. Filter the table to display only the Fortran parameters, by clearing the check-boxes for Show all symbols and Any usage and checking PARAMETER. Scroll down to MSCLIM.

MSCLIM is the only integer parameter in the table. It has the integer value 3. To find MSCLIM in the code, click on the name in the symbol table. WinFPT displays the first occurrence in the code, which is the parameter statement.

Use the Find and Next buttons on the symbol table to see all of the occurrences. There are only two.

There is no type declaration for MSCLIM. It begins with the letter "M" so the implicit typing makes it an integer. In the parameter statement it has the value 3.0, so even if it is an integer its value is the same. Perhaps it doesn't matter.

When you use the symbol table to search for objects in the code, take care that the search scope is set up as you intend. The scope, and the position of the cursor, are displayed below the Project tree and Call tree on the left of the WinFPT window.


Checking Arguments, Names and Usage of Variables
When WinFPT reads the code it checks the syntax of each individual statement. We are now going to run checks between statements and between subroutines.

Dismiss the Error Table and Symbol Table, and click on Check on the main menu. The available checks are listed in the Check drop-down menu.


Select Arguments... from the drop-down menu.

WinFPT displays a menu of options for the argument check. Accept the defaults by clicking on OK. The report is displayed in the Report view. Inconsistent arguments are reported for two routines.

WinFPT shows the sub-program declaration statement, and then the statements where the arguments are inconsistent. The attributes of the inconsistent arguments are tabulated with the formal arguments (the argument in the sub-program code) on the left and the actual arguments passed in on the right. The inconsistent attributes are marked by *** on the right of the table.

Scroll down to the first inconsistency, argument 4 in CLOSAP.

The problem here is that the formal argument, CRITA, is declared to be REAL, and the actual argument, ALTCR is declared to be REAL*4. The characters df following the data size of CRITA indicates that the size is inferred from the system defaults.

This is not an error because the default size of a REAL number on the PC is 4 bytes. The argument will be passed as intended. But if the code were run on a machine with a default REAL size of 8 or 16 bytes the program would not work.

Suppose that we are only concerned with things which will cause errors on the current system. We can tell WinFPT to ignore the issue of default data sizes. Select the menu item Check | Arguments... again. This time, un-check the Check default sizes box and run the check again.

WinFPT only reports one routine with inconsistent arguments.

The integer parameter MSCLIM, which we have seen already, has been passed into DEVIAT which expects a REAL. The bit pattern of the integer value 3 will be read as if it were a real number, and with the IEEE numbers on a PC will have a value very close to zero.

The report shows the file and line number where the error occurs. It is in milatc.for at line 91. To examine the code, double-click MILATC.FOR in the project tree window. The file is displayed in the code window. The original source line numbers are shown on the left. Scroll down to line 91. WinFPT has marked the problem with an error message.

C1 is the mean climb, MMCLIM, plus a random deviate with standard error MSCLIM. MSCLIM will be read as zero, so this term in the expression for C1 has been lost.

WinFPT can correct errors like this automatically. Select the software engineering button on the main toolbar.

or select the menu item Tools | Software Engineering ....

Select the Arguments tab and check Correct inconsistent arguments.

Click Apply and dismiss the window. The code at line 91 has now been changed, and there is a new message, marking the change.

WinFPT has corrected the error at the call-site. The integer MSCLIM has been converted explicitly to a real number with the intrinsic function REAL.


Checking Names

Fortran compilers do not know that the names used for variables mean anything. In particular, they cannot recognise that the same name used for two different variables in different sub-programs may be intended to refer to the same object.

WinFPT checks that names are used consistently in different sub-programs. For example, an inconsistency is reported if the same name is used for two different COMMON block addresses, or for Fortran parameters with two different values. To run the check, select the menu item Check | Names.... A dialog box appears showing filters for the check. Accept the defaults by clicking on OK. The results of the check are written in the Report view..

WinFPT reports inconsistent use of 6 names. The first is BEAR1, which is a local variable in the main program, MILATC, and a variable in a COMMON block in the subroutine PATHS. Should they really be the same?

To investigate BEAR1, open the symbol table by clicking on the button on the toolbar:

Check the Show all symbols box. Check that the current Search scope is All files. It is selected in the panel below the Project Tree. Click on the instance of BEAR1 in MILATC in the symbol table. The code window displays the first occurrence, which is the declaration. Click the Find and Next buttons on the symbol table to examine all of the occurrences. BEAR1 is assigned once and used three times. It all looks perfectly reasonable.

Click on the instance of BEAR1 in PATHS. Again, use the Find and Next buttons to see the occurrences. Note that WinFPT searches all of the files for the COMMON block variable. There are three occurrences, but apparently BEAR1 is never assigned. To check this, click on the Find Assigs button. WinFPT searches the entire code for any situation where BEAR1 could be assigned. It displays direct assignments, assignments to variables which are equivalenced to BEAR1 and assignments to objects which share the same memory in the COMMON block. For BEAR1 it reports Not in search scope. There are none!

BEAR1 is in a COMMON block. To see what has happened, WinFPT can display the COMMON block organisation. Select the menu item Report | COMMON Blocks. A listing of the variables in COMMON blocks is displayed in the report window. The listing is arranged in address order.

Scroll down to the variable BEAR1. The usage of each variable is displayed in the right-hand column. BEAR1 is marked as read, but never written, and there is a variable named BERR1 at the same address, declared only in MILATC, which is unused.

Click on BERR1 in the symbol table. Now we can see what is going on. The COMMON block declaration of BEAR1 in MILATC has been mis-spelled. BEAR1 is therefore not in the COMMON block, and the variable in PATHS never receives a value.

The Name Check report in the Report view has been overwritten by the COMMON block listing. Select the menu item Check | Names to restore it.

The second inconsistent name is CPATH. This is used for an array in MILATC and in PATCOM. The arrays are both REAL*4, they have the same COMMON block address and the same array bounds. They differ in that CPATH in PATHS is declared explicitly to be REAL*4 but CPATH in MILATC is declared REAL with no data size specification. The data size comes from the system defaults. This is the meaning of the annotation df following the data size in the report.

This is a bug waiting to happen.

If this code were moved to a system where the default real size were 8 bytes, the two arrays would no longer occupy the same memory. If we are only going to run this program under Win32, the difference in declarations will not matter. As with the argument check, we can filter out these reports. Run the name check again, and un-check the Check default size box in the filter menu. The report for CPATH disappears.

There are now 4 names used inconsistently. We already know about BEAR1. In the remaining cases, DT, I and NSTEP, a name has been used for a local variable in one routine and as a formal argument in another. This is quite common practice and does not usually indicate a problem. WinFPT can filter these reports out. Re-run the name check and, on the filter dialog, un-check the box Distinguish between arguments and local variables. Now only BEAR1 remains.


Checking Usage

In the name check, we found that BEAR1 was read, but was never written to. Are there any more errors like this one? WinFPT can check for this directly.

Select the menu item Check | Usage. WinFPT checks for variables which are read but never written, written to but never read, and declared but never used.

As expected, the report shows that BEAR1 in PATHS is read but never written to, and there are no other variables like this. The variable THENC1, created accidentally by the mis-used keyword THEN in MILATC is reported as written to but never read.


Checking Equivalence

The equivalence check looks for objects which occupy the same memory. WinFPT reports:

  • Objects of different data types or different data sizes which are equivalenced together;
  • Different objects which occupy the same memory locations in COMMON blocks without an explicit EQUIVALENCE statement.
We know about BEAR1 and BERR1 in /PATCOM/. Are there any more?

Select the menu item Check | Equivalences.... A dialog box appears to ask whether to check or to ignore the issue of default data sizes. On the first pass, un-check the box. The report is written in the report window. It shows the implied equivalence of BEAR1 and BERR1.

This is an implied equivalence because the two objects occupy the same memory, but there is no explicit EQUIVALENCE statement. This is the only occurrence.

Repeat the check, checking the Check default sizes box. WinFPT now reports implied and mixed (i.e. mixed data type) equivalences for MPATH and CPATH. If the program ever moves to a 64-bit machine these will cause problems!


Formatting the Code

Unless you have already discovered the format dialog, all of the code which you have seen so far has been written with upper case letters and very few spaces between the tokens. Perhaps this is not your favourite style!

WinFPT completely rewrites the code, including the diagnostics which mark errors and changes, according to rules which you specify. The code will be output to file exactly as it appears in the code window, except that it will be a plain ASCII text file, so the syntax colouring will disappear.

Double-click the main program, MILATC, in the call-tree window. The program is displayed and you can use it as a guide in choosing a format.

Open the formatting dialog by clicking the toolbar button:

or by selecting the menu item Tools | Format Fortran Code....


Select the Layout tab. WinFPT writes code in Fortran 77 fixed format, Fortran 90 free format or in tab format. Tab format is a non-standard but widely supported format in which the label field of a line is delimited by a tab character, and continuation lines are written with a numeric continuation character following a tab. Check that your system supports tab format before you use it. It is supported under Compaq Visual Fortran, under all DEC operating systems and under HP-UX and SGI Irix.

The original code was written in a mixture of Fortran 77 styles. Select each layout in turn and view the changes in the code window. Here is a fragment of MILATC in fixed format:

The same code in tab format:

And in Fortran 90 free format. The continuation character has been defaulted to column 50 so that it shows on the narrow screen.


Use the Case tab to select the case in which symbols, keywords, intrinsic functions and operators are written.

Selecting As first written for symbols preserves mixed case naming conventions, so you can name a variable, for example, SymbolTable and the upper and lower case spelling will be preserved throughout the code.

Here is a code sample with the user-defined symbols in lower case:

Selecting Upper case for symbols with read access or symbols with write access shows how variables are accessed. This is particularly useful when they are used as sub-program arguments. WinFPT tracks the intent of arguments throughout the program. It uses the program code to determine the true intent, rather than relying on INTENT statements. This is an aid in analysing the code, rather than as a target format for the output files. For example, checking Upper case write access:

Setting the case of file names sets the case of the names in INCLUDE statements and the case with which they are written to the output directories. This may be important if you use disks cross-mapped to Unix systems or boot Linux on the same machine.


Use the Indentation tab to specify indentation to mark control constructs and nested declarations. You may also specify indentation for statement labels and additional indentation for continuation lines.

The Columns to indent code box applies to Fortran 90 free format.

You can choose to indent comments to line up with the code, or to leave them as first written. Header comments, which are comments written before the first statement other than a sub- program or options statement, are handled independently of comments in the body of the code.


There are four tabs with controls for spacing.

The Spacing tab has controls for the spacing before or after different types of token. The rule used is that a space is inserted between two token if a space is required after the first token, if a space is required before the second token, or if the first token ends with a letter or number and the second token begins with a letter or number. WinFPT does not insert two spaces if a space is required after the first token and before the second. In general, it is better to control spacing using the Space before controls rather than Space after. Otherwise spaces are sometimes inserted before commas or other delimiters.

The three remaining spacing tabs control spaces before or after specific operators and keywords. You can choose, for example, to write spaces either side of equals signs without affecting the other operators and delimiters.

Here is a fragment of MILATC, with spaces before most of the tokens, lower case symbols and free format layout:


Scroll up to the declaration section of the program code. Select the Format dialog Special tab, and check and un-check the Column format for declarations box. In the original file, the declarations were written as comma separated lists on one line. When Column format for declarations is selected, WinFPT breaks them into columns so that they may be marked by trailing comments. The Column format conditionals check box similarly formats the conditional clauses in IF statements so that matching open parentheses are aligned vertically.


Writing the Fortran Code

To write the Fortran code to files, select the Write Fortan code button on the main toolbar.

or select the menu item Tools | Write Fortran Code... . The Generated Fortran Code dialog opens:

Choose the output directory by browsing to

c:\program files\simcon\WinFPT\fpteg\milatc\fpt_out

This directory is empty when WinFPT is first installed. You may also need to change the primary output file name extension to make the output visible to your compiler.

Click on Generate Fortran Files to write the code.

Now dismiss the Generated Fortran Code dialog, re-open it, and try to write the files again. WinFPT displays a warning:

This has happened because Do not overwrite files has been selected in the Generated Fortran Code dialog. Click on Cancel and select Overwrite CHANGED files, WinFPT will now overwrite only those files in the output directories which have changed. This is useful if you use a makefile because it prevents unnecessary recompilations.


Saving the Project

To save the project, click on the Save Project button on the toolbar:

or the menu item File | Save Project . WinFPT displays a dialog to request a continuation character. The default, - will work well for Win32. You can re-load this project by double- clicking the file, or by browsing to it from the menu item File | Open Project.

This is the end of this tutorial, but you may wish to experiment with other checks and engineering tools. The errors in milatc are marked in the code. You may wish to correct them manually and run the program. The results are significantly different!

And thank you for taking the time to follow the tutorial.


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