Transition F77 code from Lahey Fortran to Intel IFORT

[sindizzy]

I have inherited a fairly sizable program written in F77 and compiled with Lahey Fortran 90 Compiler Release 4.50i. I am looking to transition to IFORT (yes I know its deprecated but still require x86 targets).

The code is 25k+ lines of code and has been in production for at least several decades. I have done very minimal changes and was able to compile it successfully with IFORT. Now, the issue is with mismatches in interfaces. A sample is transcribed below in its simplest form.

From what I have gathered this was ok to do in the old days and some compilers even allowed it without too much trouble. (Doesn't mean it was right). If I omit the IFORT switch warn:interfaces it will bypass the compile warning BUT it will still throw an error when running the program.

There are many, many other instances of these interface mismatches. Is there a switch that will allow IFORT to bypass the warnings and also the run time errors?

SUBROUTINE ANALYZE
       CHARACTER*32 a,b,c
       !read a, b, and c
       CALL TBLNK(a)
END

SUBROUTINE TBLNK(REC)
        CHARACTER*80 REC
        ! do stuff        
END

[GVautier]

You said there is one source code including 2 include files.

How is the code organized?

Is there one include for the commons, one for the subroutines and functions and the source file for the main program?

[sindizzy]

The includes seem to be just COMMONs

[GVautier]

If so, all functions and subroutines are in the main source file? And this file has 25000 lines?

Have you tried to embed all the functions and subroutines in a module?

By example

      module my_module
! All functions and subroutines
      end module
      program main
      use my_module
      include "commons..
! main program code
      end program

I think that, with this layout, functions and subroutines interfaces will be generated first and call mismatches will be more accurately detected. Next it will be easier to fix the mismatches.

[garraleta_fortran]

Although this should never be done.
Yes, it is possible. With these two options, I was able to compile and run your little test program.

With IFX
I don't have IFORT

I would fix the program even if it takes you a lot of time.

[andrew_4619]

Was there any conclusion to this topic?

[sindizzy]

Still in the works. I am going to try the compile trick that was suggested to see if Ic an get all the interface mismatches in one shot. Hopefully I can do this by next week. 

[sindizzy]

Yes it does work. We have thoroughly tested it and it has worked for decades. Moving on to Intel IFORT I realize now that we will have to make the proper updates and run it through validity tests. For one the Lahey compiler deals with binary direct files differently so there has to be a little work there. Plus a LIB that worked with Lahey is now rejected by Intel. Thats ok. One issue at a time.

[sindizzy]

Ok I tried the method suggested by @andrew_4619 and it gave me 4 mismatches. so maybe there is not as many as I thought. Let me fix these and see if it compiles. Once it does compile, of course, I will have to review the entire codebase to make sure it works as intended.

[GVautier]

Good news.

The problem when the subroutines and functions are not in a module is that the first encounter defines the interface for the compiler. If this occurrence is incorrect, all correct calls will be detected as erroneous. Encapsulating functions and subroutines in a module avoid this behavior with no side effects.