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

Application builds with inconsistent Call statement

acar
Beginner
1,008 Views
I've just had a situation where the compiler/linker does not pick up the fact that a call to a subroutine (which has arguments) is made with no arguments:
Call Boris
Subroutine Boris(arg1)
logical::arg1
return
end
Is this expected behaviour and/or do I have some warning switched off in the compiler/linker options?
Thanks, ACAR.
0 Kudos
1 Solution
Steven_L_Intel1
Employee
1,008 Views
To clarify - the compiler option /warn:interface (/gen-interface is implied by this and no longer exposed in the property pages) will warn of such things, as long as the source for the subroutine being called was compiled first (or is in the same source file). For example:

E:\Projects>ifort /c /warn:interface boris.f90 main.f90
Intel Visual Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.1.127 Build 20101116
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

main.f90(1): error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface. [ARG1]
call boris
-----^

This option is enabled by default in the Debug configuration of new Visual Studio projects (Diagnostics > Check routine interfaces.) You may have turned it off, or you may have converted an old project where this was off.

Sometimes you will not see this on an initial build if the caller is compiled before the called routine, but if you recompile the caller you'll see the error.

View solution in original post

0 Kudos
5 Replies
lklawrie
Beginner
1,008 Views
Usually, you'll get some warning about inconsistent arguments or inconsistent number of arguments. Are these in the same module as shown or different modules?

Linda
0 Kudos
John4
Valued Contributor I
1,008 Views

The behavior is expected!

In Fortran, program units (e.g., functions, subroutines, modules, etc.) are independent, even if they are on the same file ---i.e., in Fortran a file is NOT a boundary.

That means the units will be compiled independently and only rely upon the interfaces provided (or the ones assumed). You can provide explicit interfaces either by placing your functions/subroutines after the CONTAINS statement in a MODULE or PROGRAM unit, or by creating INTERFACE blocks for them.

Besides guaranteeing that the compiler will check the invoked procedures for type, rank, number of arguments, etc., the concept of explicit interface is required in some F90+ constructs, so it's a good idea to get used to it ---which, in its easiest form, means to get used to working with modules.

0 Kudos
TimP
Honored Contributor III
1,008 Views
The ifort option -warn-interfaces (set by default in Visual Studio) is meant to catch these, in the absence of f90 machinery (interface block or module subroutine).
CVF performed checking for multiple subroutines in the same source file, but ifort does not, unless one of the precautions mentioned above is taken.
0 Kudos
Steven_L_Intel1
Employee
1,009 Views
To clarify - the compiler option /warn:interface (/gen-interface is implied by this and no longer exposed in the property pages) will warn of such things, as long as the source for the subroutine being called was compiled first (or is in the same source file). For example:

E:\Projects>ifort /c /warn:interface boris.f90 main.f90
Intel Visual Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.1.127 Build 20101116
Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

main.f90(1): error #6631: A non-optional actual argument must be present when invoking a procedure with an explicit interface. [ARG1]
call boris
-----^

This option is enabled by default in the Debug configuration of new Visual Studio projects (Diagnostics > Check routine interfaces.) You may have turned it off, or you may have converted an old project where this was off.

Sometimes you will not see this on an initial build if the caller is compiled before the called routine, but if you recompile the caller you'll see the error.
0 Kudos
acar
Beginner
1,008 Views
Thanks to all. I do use modules and contain structures BUT while I am developing the code this is something of a pain since if the module is used widely (as some of mine are) then a small tweek to a routine in the module can lead to a time consuming and therefore frustrating build. In these cases I've tended to keep modules seperate from routines that operate on the module's data. I guess as my application comes closer to release I will tidy things up but, rightly or wrongly (?) this is the way I'm currently operating. I've found in the solution properties a diagnostic called Check Routine Interfaces. It was switched to NO (possibly as Steve suggests the reason for it being switched of may be that the solution was imported from an old CVF project). So, I've switched it on and it has immediately picked up one instance of the issue I reported. Great! Thanks again. ACAR.
0 Kudos
Reply