Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
338 Views

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

Jump to solution

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.

0 Kudos

Accepted Solutions
Highlighted
Black Belt
238 Views

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.

View solution in original post

15 Replies
Highlighted
Valued Contributor II
321 Views

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.

0 Kudos
Highlighted
Valued Contributor III
315 Views

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 .

0 Kudos
Highlighted
Valued Contributor II
308 Views
0 Kudos
Highlighted
Valued Contributor III
306 Views

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?

 

0 Kudos
Highlighted
Beginner
298 Views

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 .)

0 Kudos
Highlighted
New Contributor I
286 Views

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.

0 Kudos
Highlighted
Black Belt Retired Employee
284 Views

-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.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
New Contributor I
278 Views

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.

0 Kudos
Highlighted
New Contributor I
276 Views

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

0 Kudos
Highlighted
Valued Contributor III
266 Views

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/119...)

 

 

Highlighted
New Contributor I
244 Views

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

0 Kudos
Highlighted
Black Belt
239 Views

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.

View solution in original post

Highlighted
New Contributor I
235 Views

Is the local interface the compiler-generated one?

0 Kudos
Highlighted
Black Belt
223 Views

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.

0 Kudos
Highlighted
Valued Contributor III
222 Views
Why not use submodules? The interface and implementation are cross checked by default.