argument list matching

[Mark_Jablin]

When I build my project using the Intel Fortran Compiler version 9.1.3192.2005 in MS Visual Studio, I do not see any errors/warnings about argument list mismatches between subroutine calls and the subroutine itself. After searching the forums, I tried using the /gen-interfaces and /warn:interfaces options, which seem to make no difference except reporting errors when passing user-defined types as arguments.

To test the problem, I created a simple project that calls two subroutines, one within the same project and other from a statically-linked library. I turned on the /warn:interfaces option but not the /gen-interfaces option. For the call to the subroutine in the same project, I get an error if I don't pass an argument or try to pass an argument of a different type than the subroutine is expecting. I do not get the error when I call the subroutine in the static library.

I've compared the compiler setting between my projects, and I can't find any difference. Does anyone know why I get the error in my simple test project, but not in a larger project? Also, why don't a I get the error when I call between projects? How can I get these errors reported? Thanks.

Mark

[TimP]

In order for /warn:interfaces to work, the compiler has to be working from source code for both caller and callee, or /gen-interfaces must have been used to preserve the information. A debug build also would preserve such information.

[Steven_L_Intel1]

The interface checking works by creating modules (named routinename_MOD.mod) when the source to the routine is compiled. These modules must be visible (in the INCLUDE path) of any source that calls the routine, otherwise no checking can be done. If you are using multiple projects, be sure to have the output directory of the library added to the INCLUDE path of the parent project - this is NOT done automatically.

[jarvusluntatintel]

I have not been able to get this to work for me for version 9.1 either. I hadn't worried too much about it, but since it is relevant to this thread. For the following code:

SUBROUTINE foo1 (JobControl)

TYPE JobControlStruc

INTEGER NumOfNodes

END TYPE

TYPE (JobControlStruc) JobControl

REAL X

CALL foo2 (JobControl, X)

RETURN

END

SUBROUTINE foo2 (JobControl, X)

TYPE JobControlStruc

INTEGER NumOfNodes

END TYPE

TYPE (JobControlStruc) JobControl

REAL X

WRITE (*,*) X

I get the following message:

foo1.for
C:Documents and Settingsuser1My DocumentsOtherFmainFmainfoo1.for(14) : Error: The type of the actual argument differs from the type of the dummy argument. [JOBCONTROL]
compilation aborted for C:Documents and Settingsuser1My DocumentsOtherFmainFmainfoo1.for (code 1)

If I turn the check interface off, it compiles and runs correctly. However, without the check, it is easy to make mistakes, such as typing:

CALL foo2 (JobControl)

instead of

CALL foo2 (JobControl, X)

which compiles without errors, but produces runtime problems that can be difficult to track down. Am I missing something simpleor does this work the way I would like for version 10?

[Steven_L_Intel1]

An interesting case. As far as the compiler is concerned, you have two independent declarations of type JOBCONTROL and by the language definition, these are two different types.

May I suggest putting the type ONCE into a module and referencing that? Even better, put the subroutine in the module too, or make the subroutine a CONTAINed procedure of the main program - which you choose depends on how large the application is.

I don't think you can get the generated interface checking to consider those two declarations to be the same.

[Steve_Nuchia]

I found this thread while investigating a closely related issue, perhaps it's something obvious that I'm just not seeing. In any case the answers already provided have been very enlightening.

I'm porting a fair-sized bunch of code from Digital Visual Fortran + VC6 to IVF 10.0 + VC9. The parameter mismatches are throwing warnings in DVF. In IVF (32-bit, on a 32-bit host) they are silently accepted in Release mode and throw an error in Debug mode. Many of these cases have caller and callee in the same source file. The diagnostic and include path settings for the two modes are as close to identical as I know how to make them. Only the library selections and optimizer settings differ intentionally.

Clues? Thanks!

-steve

[Steven_L_Intel1]

We could help better if you showed the source in question and the text of the diagnostics. My guess is that you are seeing generated interface checking in a Debug configuration as that is the default there.

[Steve_Nuchia]

Sure enough, thank you. I had missed the difference in the generate option.

From the discussion above I had thought the generated interfaces only affected the checking between source files but obviously that was a mistaken impression. Turning off interface generation for the afflicted projects, but leaving the interface checking option on, brings the debug configuration into line with release.

-steve