subroutine interface checking?

[dbruceg]

Consider the following:

...

call sub (1)

call sub (1,1)

...

subroutine sub (i)

...

I'm running version 9.0, and the /warn:interfaces compiler option does not appear to do anything. How do I instruct the compiler to find the bad call?

Bruce Gerdes

[Steven_L_Intel1]

You also need /gen_interface.


C:MyProjects>ifort /warn:interface /gen_interface t.f90
Intel Fortran Compiler for 32-bit applications, Version 9.1 Build 20060519Z Package ID: W_FC_C_9.1.025
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.

t.f90(2) : Error: The number of actual arguments cannot be greater than the number of dummy arguments.
_{call sub (1,1)
-----^}

[dbruceg]

Beautiful!! Do I need V9.1 to make that go? On my version ofV9.0, /gen_interfaces generates independent interface blocks as .f90 files; one for each subroutine, each containing a module named _mod containing the interface block for that subroutine. Unfortunately, though it has the information, the compiler does not USE it, declaring the compilation and subsequent linkage successful in spite of the obvious error. Last night I discovered that I could hack the generated interface blocksinto a single module (ULIB_Check, say), modify all (!) the subroutines to USE that module, and recompile. That procedure identifies all the bad calls, but at a pretty big price: it's invalid under F95 (subroutines can't have interface blocks that reference themselves),it's CLUMSY, and it's only asbulletproof as the user.

Am I missing something?

Bruce

[Steven_L_Intel1]

It's supposed to work in 9.0, though this feature got off to a rough start. I used 9.1, but any 9.0 released this year should work ok. (I am not about to go trying them, though.) There are still some bumps in this feature, which we continue to improve.

Your description of how the feature works is correct. An important difference is that the compiler is supposed to use the generated modules for error checking only, NOT to change the semantics of a program. For example, if you have a subroutine which requires an explicit interface, /warn:interface is not supposed to provide that interface when it "uses" the generated module. There was a bug where it did just that - I don't recall if it is fixed in 9.1.025 or is waiting for the next update.

[dbruceg]

Thanks, Steve. I guess I'd best be looking for a band-aid for my 2005 V9.0 or a possible upgrade to 9.1. I note in passing, though, that those subroutine mods generated by /gen_interfaces still have value in the sense that I described, since they make perfectly legitimate C-like header files- those generated from one file can be used by another, enabling the compiler to check interfaces across multiple files. Still a little clumsy, but it works, and it

produces a far better cross-check than the linker can do with decorated names.

Bruce

[Steven_L_Intel1]

Keep in mind that an upgrade to 9.1 is free if you have a current support license.

[dbruceg]

Well, THAT is pleasant news! The Intel download site suggests that V9.1 downloads are available only to current V9.1 users. I didn't even try. I DID, however, download and install the last version (029) of V9.0 and, as you suggested, the /warn:interface and /gen-interfaces options work, though there's an undocumented trick involved. On the FIRST compilation, turn on the /gen-interfaces option and the compiler will generate the subroutine module files and compile them. On subsequent compilations, turn the /gen-interfaces off or it will bomb with a code(1) compiler error and no explanation. It looks like the compiler might be trying to open the mod files as 'new' rather than 'unknown'. In order to regenerate the mod files you have to manually delete the existing files (I think).

Anyway, once those mod files are in place, turn /gen-interfaces off and /warn:interface on, and recompile to your heart's content. It'll find and report every interface violation..

On another note, it looks like a bug was introduced in the last six months or so, though I don't know if it made it into V9.1. The statement

allocate

[dbruceg]

(sorry)

allocate (ival(nval),stat=ierr) ; if (ierr.ne.0) go to 901

doesn't compile anymore. It has to be split into 2 lines:

allocate (ival(nval),stat=ierr)

if (ierr.ne.0) go to 901

Bruce

[Steven_L_Intel1]

You can use the 9.1 kit if your support license is current. I suggest uninstalling 9.0 first, including the Visual Studio integration. I can't reproduce a problem with the allocate statement in 9.1.025.

[dbruceg]

Thanks, Steve.

Bruce