Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

FORTRAN code is linking even with SUBROUTINE/CALL parameter mismatch

Sudip_Chakraborty
393 Views

Recently I was working with some legacy FORTRAN code (after a long time) to compile and generate 64bit binaries. There was a mistake in the code in which parameters used (number of parameters) in SUBROUTINE and corresponding CALL were not matching as illustrated below.

      SUBROUTINE ABCD(NEQ,MA,NBLOCK,NEQB,NWA,MI,NSTIF,NRED,NL,
     *         NR,AC,DM,DC,GAMA,AKEFFC,XNDIS,NUMIMD,
     $         XNACC,NUMIMA,STFSPG,NUMSPG,XNSPG)

     CALL ABCD(N,MBW,NBLOCK,NEQB,NAV,MI,L14,L17,L13,L12,AC)

To my surprise I did not notice the error until linking failure occured when I tried to create 32 bit binaries. The linker is not complaining and producing the final application binary without any error when I create 64 bit binaries!

Is this behavior expected? BTW, I am using Visual Studio 2017 Version 15.9.14 & Intel® Parallel Studio XE 2019 Update 4 Composer Edition for Fortran.

0 Kudos
3 Replies
mecej4
Honored Contributor III
393 Views

Yes, this is expected behavior with 32 and 64 bit compilations with the Intel compiler with the default subprogram calling convention. You may have used in the past a compiler (MS Fortran, Digital/Compaq Fortran) that decorated the names with @nn, with nn being the bytes taken by the subprogram arguments. 

There are compiler options available to check interfaces that you can use to catch this kind of error. Or, you can put subprograms into modules and USE those modules, in which case interface checking is done at compile time without needing any special option. You may also use internal subprograms.

0 Kudos
Sudip_Chakraborty
393 Views

Thanks for the clarification. Can you please elaborate on the available compiler option to flag this error during compile time? Which option should I turn on?

0 Kudos
mecej4
Honored Contributor III
393 Views

Look up these options in your compiler documentation: /gen_interfaces and /warn:interfaces . There are corresponding settings in the Visual Studio IDE.

0 Kudos
Reply