Why does -warn interfaces not issue warning even if an external subroutine does not have interface?

[efnacy]

I am using ifort 18.0.0 and I am trying to make it check the presence of explicit interfaces in my codes. My interfaces are placed in module mymod contained in file mymod.f90. In a procedure somesub, a call to another procedure mysub is made. The interface for mysub is inside mymod module. The codes are more or less like the following.

mymod.f90

module mymod
  use, intrinsic :: iso_c_binding
  implicit none
  interface
     subroutine mysub(a)
       integer(c_long) :: a
     end subroutine mysub
  end interface
end module mymod

somesub.f90

subroutine somesub()
  use, intrinsic :: iso_c_binding
  use mymod, only : mysub
  implicit none
  integer(c_long) :: a = 1
  call mysub(a)
end subroutine somesub

somesub() is an external procedure.

And my compile command is

ifort -warn interfaces -nogen-interfaces -mkl -I../MOD/ -c somesub.f90

MOD is the directory where mymod.f90, mymod.o, and mymod.mod are. When the ''use mymod, only : mysub'' line in somesub.f90 is commented out, it should be oblivious of the presence of mysub interface, yet ifort doesn't give any warning nor error.

[Arjen_Markus]

It used to be impossible to specify an explicit interface - FORTRAN 77 has no provisions for that at all. So, even if nowadays it may be considered good practice to provide such interfaces, a lot of program code still does not or at least not in a completely consistent manner. I guess it is a choice open to the compiler writers to include warnings about this. The current Fortran standard does allow you to use:

IMPLICIT NONE (TYPE, EXTERNAL)

in which case the compiler will always complain about routines that have no explicit interface.

[andrew_4619]

Is IMPLICIT NONE (EXTERNAL) implemented in any version of Ifort? I have been looking forward to having this feature for some time because of those annoying and regular instances I use one of my subroutines from a  module and for get to add a USE or add it it to the ONLY list. The failure only comes at link time .

[Arjen_Markus]

In Intel Fortran 19.1 according to this page: https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-developer-guide-and-reference/top/language-reference/a-to-z-reference/h-to-i/implicit.html

[andrew_4619]

Thanks Argen I had read that topic also. The Feature isn't in XE2019 update 4 but the naming can be confusing what does 19.1 actually mean?  I think 19.1 means XE2020 why do they do that?

[mfinnis]

Warn interfaces checks interfaces against interfaces defined in mod files external to the source not whether the interface exists.  The default behaviour when using warn interfaces is for the compiler to generate interfaces for any it can't find so that you would get a warning if you invoked a procedure in a way incompatible with its declaration. (Look for files with __genmod appended to the file name in your output directory which will tell you which procedures don't have supplied interfaces .)

[efnacy]

So, -warn interfaces -nogen-interfaces option does practically nothing? I do know that without -nogen-interfaces, ifort will create its own module files containing the interface and I had seen this myself. But it generates the interface files regardless of whether or not an external file (of my own) containing interfaces is visible in the calling unit, e.g. through use statement of the module where my own interfaces are.

But when I purposely pass arguments to a subroutine incorrectly while having the above use statement in the calling procedure, the compiler did catch the error, meaning that it actually recognizes my own interfaces.

[Steve_Lionel]

-gen_interfaces is sort of obsolete. When interface checking was first introduced in version 9.0, you had to specify both that and -warn interface. Now, -warn interface implies generating interfaces. -gen-interface by itself does have a use if you want the compiler to generate interfaces that you'll then incorporate into your own module, but you should verify them as the .f90 source doesn't always represent the full interface.

As noted, this feature is completely independent of -warn external or IMPLICIT NONE (EXTERNAL), which is new in F2018.

[efnacy]

I think -warn external is only in 19.0.0, the one I am using is 18.0.0.

[andrew_4619]

yes you need 19.x for the new f2018 feature Implicit none (external) . Bit that has a bug it seems I just filed a ticket (see thread https://community.intel.com/t5/Intel-Fortran-Compiler/implicit-none-type-external-discussion/m-p/1192942#M150623 )

[efnacy]

Is IMPLICIT NONE (TYPE, EXTERNAL) intel 19.0 only or the general standard? I tried this in somesub() subroutine and I got error saying that the syntax for implicit none is unrecognized.

[efnacy]

It seems like there is no way to check the presence of user defined interface in ifort 18.0.0.

[mecej4 · Accepted solution]

Sometimes, the user provides an interface but that provided interface may have some errors. If so, and the interface and implementation are in separate files, there may be no signs of the error until the program is built and run. It is helpful when in doubt to 1) ask the compiler to generate the interfaces (/gen-interfaces) and then 2) run the compiler a second time (/warn:interfaces). The second compilation will then show a message such as

xchkint.f90(7): error #8000: There is a conflict between local interface block and external interface block. 

This was from IFort 16.0.8.

[efnacy]

Is the local interface the compiler-generated one?

[mecej4]

The "local interface" is the one that I provided, in the caller's declarations section. The external one is compiler-generated, in one of the *_genmod.f90" files.

It is a convenience that the generated interface is saved to a file, because in cases where a conflict is signaled the user can compare and reconcile the two interfaces.

As a test, I had deliberately introduced an error in the local interface.

[andrew_4619]

Why not use submodules? The interface and implementation are cross checked by default.