Check of number of parameters

[rase]

One thing I miss in IVF is the automatic check of the numbers of parameters when calling a subroutine or function. The check in CVF during the link step was very helpful (sometimes annoying). I could create interface definitions, allright, but this seems not justified for smaller projects. I was not able to locate an option in the project settings which eventually does the check for proper parameter numbers. Or did I miss something? Greetings, Wolf

[Antoon]

Quoting - rase

One thing I miss in IVF is the automatic check of the numbers of parameters when calling a subroutine or function. The check in CVF during the link step was very helpful (sometimes annoying). I could create interface definitions, allright, but this seems not justified for smaller projects. I was not able to locate an option in the project settings which eventually does the check for proper parameter numbers. Or did I miss something? Greetings, Wolf

You don't have to create interface definitions yourself, just embed each subroutine in a module procedure. In the codewhere calling the subroutine insert the USE assocations for that subroutine, and you get a so-called explicit interface. That means that IVF checks the complete interface, so number of arg, type and kind of arguments.

If you want to stick to stand-alone subroutines, then set in the Fortran property page, under Diagnostics , Generate Iinterface Blocks on Yes, the effect will be te same as above. The weird thing is that IVF even checks the interface in absence of the USE assoc !

[rase]

Thanks a lot, that's exactly I was looking for.

[Steven_L_Intel1 · Accepted solution]

Quoting - Antoon

You don't have to create interface definitions yourself, just embed each subroutine in a module procedure. In the codewhere calling the subroutine insert the USE assocations for that subroutine, and you get a so-called explicit interface. That means that IVF checks the complete interface, so number of arg, type and kind of arguments.

If you want to stick to stand-alone subroutines, then set in the Fortran property page, under Diagnostics , Generate Iinterface Blocks on Yes, the effect will be te same as above. The weird thing is that IVF even checks the interface in absence of the USE assoc !

This is not quite right. I will agree with the first paragraph completely - and any Fortran 90+ compiler will do that. This is the method I would recommend.

If you want to use generated interface blocks, you should also set "Check routine interfaces". This is NOT the same as adding a USE in that generated interfaces are looked at for diagnostic purposes only. If your program requires an explicit interface to be visible, say you have OPTIONAL arguments, then a generated interface will not suffice. (The compiler will warn you though if it sees this.)

The whole point of generated interface checking is to provide additional diagnostic capability when explicit interfaces are not used. This goes well beyond the check of argument count you got from CVF because of its use of STDCALL. Note that generated interface checking is on by default for new projects.

[rwg]

Quoting - rase

One thing I miss in IVF is the automatic check of the numbers of parameters when calling a subroutine or function. The check in CVF during the link step was very helpful (sometimes annoying). I could create interface definitions, allright, but this seems not justified for smaller projects. I was not able to locate an option in the project settings which eventually does the check for proper parameter numbers. Or did I miss something? Greetings, Wolf

I miss this too, but your solution (generating interfaces, explicit or implict) will cause a lot of trouble for me. My project consists of 60 static libraries, each containing about 100-200 subroutines. They all call each other. A lot of them use intergers but these are declared als reals in the calling subroutine. Some use single integers while the called subroutine uses Integer-Arrays (or the other way around). So writing explicit interfaces will take some years. Using implicit interfaces or automatic generates interfaces will cause thousands of warnings. So is there an other solution of simply checking the number of parameters like CVF did it? Or is it possible to automatically generate Interfaces which check the number but not the type of the arguments?

[Steven_L_Intel1]

CVF itself did not check. It used the STDCALL convention which requires that the number of bytes pushed on the stack match what the called routine popped and decorated the external name with that number. You can do the same in Intel Fortran if you wish with /iface:cvf

[rwg]

Hello Steve,

here ist my FORTRAN Command Line (Debug-Version):
/nologo /debug:full /Od /DDEBUG/d_lines /debug-parameters:all
/warn:declarations /warn:unused /warn:truncated_source
/Qauto_scalar /align:commons /assume:byterecl /iface:cvf
/module:".Debug/" /object:".Debug/" /traceback /check:pointer
/check:bounds /check:uninit /check:format /check:output_conversion
/check:arg_temp_created /libs:static /threads /dbglibs /c

and here are my linker options:
/OUT:"C:xxx" /INCREMENTAL /NOLOGO /NODEFAULTLIB:"libcd" /NODEFAULTLIB:"libcmt" /NODEFAULTLIB:"libc"
/NODEFAULTLIB:"msvcrtd" /NODEFAULTLIB:"msvcmrtd" /MANIFEST /MANIFESTFILE:"c:xxx" /DEBUG
/PDB:".Debug/xxx" /SUBSYSTEM:WINDOWS kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib wntab32x.lib netapi32.lib rpcrt4.lib oncrpc.lib zlibstatd.lib mxst32.lib freeimaged.lib vfw32.lib htmlhelp.lib wininet.lib urlmon.lib oncrpc.lib uxtheme.lib

This source code givesno linker error (I think CVF gave a linker error):

SUBROUTINE UP1(I,J)
J=I
END

.
.
CALL UP1(1,K)
CALL UP1(1)
.
.

And its very annoying that only the Release-Version gives me a run-time error. The Debug-Version not!

Ralf

[Steven_L_Intel1]

If the subroutine and caller are in the same source file, you probably get interprocedural optimization.

Which compiler version created this project? Was it converted from CVF? Try this - under Diagnostics, enable "Check Routine Interfaces". If you are using a version earlier than 11.1, also set
"Generate Interface Blocks".

[Lorri_M_Intel]

Within the same file we're assuming both calls to UP1 are to the same routine, and we name it UP1@8, even in the case where we only pass 1 argument.

FWIW, I compiled the small example with CVF, and at default optimization, it compiled successfully too. With optimizations turned off, it gave a compile-time (not link time) message:

x.f90(8) : Warning: Routine UP1 called with different number and/or type of actual arguments in earlier call - C attribute required if intended.
call up1(2)
-----^

- Lorri

[rwg]

Quoting - Lorri Menard (Intel)

Within the same file we're assuming both calls to UP1 are to the same routine, and we name it UP1@8, even in the case where we only pass 1 argument.

FWIW, I compiled the small example with CVF, and at default optimization, it compiled successfully too. With optimizations turned off, it gave a compile-time (not link time) message:

x.f90(8) : Warning: Routine UP1 called with different number and/or type of actual arguments in earlier call - C attribute required if intended.
call up1(2)
-----^

- Lorri

Hello Lorri,

that's right. Generally we compile during program develop with debug turned on. This causes that optimizations were turned off. So we found such errors with CFV before releasing a subroutine. Now with IVF 11.0.074 [IA-32]
we don't get an error during development. Not until releasing the subrouine we get a runtime error which is not so easy to locate.

Steve,

we use about 10000 subroutines form 10000 source files where a lot of subroutines are called with realsand those parameters are declared as integers in the subroutine. These subroutines are stored in about 60 libraries. During development we add only the files to change directly to the project an change them. All other files are taken from the 60 libs. Changing the compiler options you mentionedonly affect those directly added files. So calling asubroutine from the libs with different numbers of parameterswill not generate an error message, because there is no interface for this subroutine.
Automatically generating interfaces for those 10000 subroutines will generate thousands of warnings or error messages because of mixed integers/reals in the parameter linies. I think we will get problems with the handling of 10000 mod-Files too. What'y our opinon?

[Steven_L_Intel1]

Well, my opinion is that your code violates the rules of the Fortran standard, but it was a common thing to do in the past. Given that, you cannot use compiler or language features to compare interfaces. If all you care about is the argument count, you can use /iface:cvf, though this doesn't work for calls in the same source file. I don't recommend this in general.

My suggestion to you would be to enable generated interface checking and do a test build. Look at the errors you get and fix those that are meaningful. Then turn the option off and rebuild.