Legacy Fortran Compiling Woes

[Tripp_L_]

I have legacy Fortran code ranging in date from the 60s to 90s that I need to be able to compile.

The code works as it is written, even if it uses some old practices that are no longer standard. It was successfully built on the Intel Visual Fortran 2011 Compiler and Visual Studio 2008. I am now on Visual Studio 2012 and Intel Visual Fortran 2013. I can't seem to find the right options to flip to allow it to build.

The major problem is that huge equivalence arrays are used and often instead of passing an array or an actual pointer to a subroutine they are just passing a single value of the pointer equivalence arrays and somehow it is implied to use a sequence of values. The main errors are

• the type of actual argument differs from the type of dummy argument
• if the actual argument is scalar, the dummy argument shall be scalar unless the actual argument is of type character or is an element of an array that is not assumed shape, pointer, or polymorphic

Once again. I know that the code does work as built. Any helpful suggestions will be appreciated.

[IanH · Accepted solution]

The type mismatch is a "real" error that you should investigate further and consider fixing at some stage.  Passing array elements as a proxy for an array element sequence is permitted by the language, subject to the constraints listed in the error message - this is known as sequence association.

What options have you tried?

Assuming this is a debug configuration, have you tried compiling with the property Fortran > Diagnostics > Compile Time Diagnostics set to Disable All (/warn:none)?  Or perhaps as an intermediate step set that option to custom, and then ensure that "Check Routine Interfaces" is "no".  Do these things after Clean-ing your project (i.e. Build > Clean xyz) so that the files associated with interface checking are deleted.

Noting well, that turning off compile time diagnostics means that you won't get any compile time diagnostics.  There be dragons.

I've come across a few cases of code which was "known to work as built", which later turned out to be more fortunate coincidence or random good luck.  In one case random good luck turned into random bad luck.

[Steven_L_Intel1]

You can turn off Diagnostics > Check routine interfaces, and the code should build. Your code is not legal Fortran, but probably works if coded carefully. It's sort of like running a power saw with the blade guard removed. Just be aware that there may be bugs in the program that are harder to find because of the deliberate violation of the language rules.

[mecej4]

In many older library subroutines that implement mathematical algorithms, the number of arguments is fixed and often some of those arguments have to be passed even if it is certain that in a particular call those arguments will not be accessed or set. For example, in the following subroutine call

CALL pardiso (pt, maxfct, mnum, mtype, phase, n, a, ia, ja, &
     idum, nrhs, iparm, msglvl, ddum, ddum, error)

the arguments idum and ddum are dummy arguments that will not be touched. Nevertheless, the compiler, having seen an interface to pardiso, will complain about these arguments being scalars. One way to quieten the compiler is to give the declarations

INTEGER idum(1)
REAL(KIND=DP) ddum(1)

[Tripp_L_]

Thank you all. I really appreciate the help diagnostics>check routine interfaces worked perfectly.

Oh I know it is horrible coding practices. I know there is no good way for me to prove it works. the newest code was written when I was 4 though, and I had nothing to do with it. They've been using this code for the last 10-20 years at my company and they think it has been correct so far so I'm not going to argue. My hope is that since this code is to simulate something that is being phased out, the code will be as well, so I really don't want to spend a ton of time on it if I don't have to. I'm basically the sole programmer on tens of thousands of lines of legacy code and I'm trying to spend my time efficiently. Rewriting the more important parts that will be around for likely another 10-20 years that I can start using soon.

Thank you again for the help. Worked like a charm, and saved me several months of rewriting work.