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

Fortran 10.0.25 does not produce a warning

gorg
Principiante
1.450 Visualizações
To check the interactions of the many calls in a set of Fortran subroutines, I decided to use interface statements. I used the option "/gen-interfaces:source" to generate all the interfaces. I then recompiled using the option "/warn:interfaces" to check my call statements. I first tried using the option to generate a list of all called items - no warnings. I otherwise found the called items and included the *.mod files with use statements. No warnings, there shouldn't be any. I then commented out a use statement - no warning produced.

The documentation is not the clearest as to what the option "/warn:interfaces" does, but I read it as "if used there must be an interface statement for every reference", similar to "Implicit none" requiring every variable to be defined.

Errors in call statements produced the expected errors/warnings independent of using / not using the option "/warn:interfaces". The only problem I found was no warning for a missing interface.

All this was done from the command line.

0 Kudos
8 Respostas
Steven_L_Intel1
Funcionário
1.450 Visualizações
You misunderstand this option. It is an error-checking option for programs that do not use explicit interfaces for everything. It creates an interface block for each external procedure (that is, not module procedures). When the compiler sees a call to a procedure for which there is not an explicit interface, it looks at the generated interface and checks to see if the arguments match. If there is a mismatch, you get an error just as you would if there had been an explicit interface. It does NOT warn you if you are missing an interface. Another important point is that a generated interface is not a substitute for a required explicit interface, and the compiler will let you know if that is the case.

Here's a simple example:

subroutine sub (i,x)
integer i
real x
print *, i, x
end subroutine sub

program test
call sub (3.0) ! Wrong number and type of arguments
end

f:MyProjects>ifort /gen_interface /warn:interface t.f90
Intel Visual Fortran Compiler for applications running on IA-32, Version 10.1 Build 20080602 Package ID: w_fc_p_10.1.024
Copyright (C) 1985-2008 Intel Corporation. All rights reserved.

t.f90(8) : Error: The type of the actual argument differs from the type of the dummy argument. [3.0]
call sub (3.0) ! Wrong number and type of arguments
----------^
t.f90(8) : Error: A non-optional actual argument must be present when invoking a procedure with an explicit interface.
call sub (3.0) ! Wrong number and type of arguments
-----^
compilation aborted for t.f90 (code 1)

Note that the called routine must be compiled before the call for this to work.
tdoxsee
Principiante
1.450 Visualizações

Hi Steve,

So is it possible to generate a warning for a missing interface?

I'm trying to add explicit declarations to legacy f77 code by migrating it to f90 and using the MODULE, INTERFACE and USE functionality of f90. I want to make sure that every function call has an explicit interface. Some of the fortran is calling C, so I'll need to create fortran INTERFACEs for the C functions. Is there a compiler option that will give a warning if function A is calling function B, but function B does not have an INTERFACE that is visible by function A? (A and B are in different files. A is in fortran but B may be in fortran or C.) I'm using ifort 10.1 IA-32 Build 20090203

Thanks,

tdoxsee

Steven_L_Intel1
Funcionário
1.450 Visualizações

If an interface is not required by the language, then no, we don't have an option like that.

I recommend putting your routines in modules and NOT using INTERFACE for Fortran code. That will guarantee an explicit interface is always used.

tdoxsee
Principiante
1.450 Visualizações

Hi Steve,

Thanks for the answer. Yes, I was planning to put all of the Fortran code into modules. I was also planning to create Fortran INTERFACES for the C code that is called from Fortran. It would be a very nice enhancement to the Intel Fortran compiler to provide a warning for Fortran calls to a function for which no inteface (via a MODULE or INTERFACE) is provided. With this warning capability, a developer could ensure that all functions have an explicit interface.

Thanks,

Tad

Steven_L_Intel1
Funcionário
1.450 Visualizações
If you always use IMPLICIT NONE (or /warn:declarations), then any functions you call without declarations will get an error. This won't help with calling subroutines, though.
tdoxsee
Principiante
1.450 Visualizações

Steve,

Thanks. Unfortunately, most of my calls to C from Fortran look like subroutine calls (from the perspective of the Fortran compiler). I guess I'll have to be extra careful to make sure I create interfaces for all of the C functions that are called from Fortran. A compiler warning would have been nice.

Tad

Steven_L_Intel1
Funcionário
1.450 Visualizações

If the C routines don't have names in all uppercase, then it's simple as without the interface and ALIAS or BIND(C), the names won't match.

qolin
Novato
1.450 Visualizações

As Steve says, the best way to ensure an explicit interface exists, is to put the subroutine(s) in (a) module(s). if subroutine AA is in a module, then nothing can call AA unless it has a USE statement to the module containing AA; absent a USE, you get a link error. This is useful, but its a pain to have to wait until the link. So there is an interesting game you can play.

Consider a call statement like "CALL AA(ONE, TWO, TRE, FOR)", to a subroutine declared as "SUBROUTINE AA (A1, A2, A3, A4)". You can use a keyword-type argument in the call, as in "CALL AA(ONE, TWO, TRE, A4=FOR)". Doing this doesn't change the meaning of the call, and doesn't require the subroutine declaration to be changed. However, since keyword arguments are only valid with an explict interface, then if the compiler han't got one for AA, it throws a compile-time error.

Now, I agree this is not the same as the global compiler option you were asking for, but it may prove useful as a testing tool to ensure an explicit interface exists in some circumstances.

Responder