xxx_genmod.f90 files and interface checking

xxx_genmod.f90 files and interface checking

How close to the "actual" interface of an external procedure is it expected that the source in the /warn:interfaces generated Xxxx__genmod.f90 files should be? Should I expect the _genmod.f90 files to be "correct" compilable source? Would missing USE statements and "extra" USE statements not present in the specification part of the original external procedure be indicative of trouble elsewhere, and worth chopping out an example?

I don't know whether it helps, but I don't have any "use" statements in my automatically compiler generated interfaces although the original routines have "use module xy". (I assume you meant subroutines as external procedures).

Modules should not be necessary to judge the correctness of an interface, at least in simple procedure oriented programming. Or am I wrong?

Note how the ParseNodes module does not appear in the use statements in the generated interface source snippet, yet that module is the only thing that can provide the ParseNodeElement type required for the dummy argument.

Comment out the type bound procedure part of the ParseNode type (the lines marked #A) and the IfStmt module in the generated interface body changes to ParseNodes.

I have strong suspicions that in larger, more complicated examples (hundreds of source files) this, or something like it, leads to the compiler babbling incoherent nonsense about required interfaces missing for external procedures (even though the interfaces are declared just a few lines previous), and possibly an ICE.

When a procedure is compiled that is not in a module or contained, a generated interface module is constructed. Two files are created - one, the .mod, is used later by the compiler (see below). A .f90 is also created - this is supposed to reflect the generated interface, and most cases does exactly, but sometimes there are attributes that don't make it in if they're not required for error checking. The compiler never looks at the .f90 - it's simply there for your viewing pleasure.

When the compiler sees a reference to a procedure for which there is no explicit interface, it checks to see if a generated interface module exists. If it does, it uses the generated interface for error checking ONLY - making sure number of arguments, types match, etc. If it notices that the actual routine has aspects that the language requires an explicit interface for, such as OPTIONAL or deferred-shape dummy arguments, it will complain. The compiler will also compare any INTERFACE block you have against generated interfaces to make sure they match.

Note again that generated interfaces are only for error checking - they do NOT replace explicit interfaces where the language requires them.

Order of compilation is important - if the call is compiled before the caller, there's no interface to check. (If the call and caller are in the same source file, though, it does check even if the call is first.)

Now, over the years we have had some bugs in the area. Sometimes the compiler inappropriately used the information in the generated interface to supply details where the language requires an interface. And sometimes just enabling this feature triggers other errors due to the extra pass through the code it makes. That said, it's pretty solid nowadays, though nothing is perfect, so examples of problems are always welcome.

There is not such an option, but these are created in the module output folder and you could delete them all with a simple rule if needed. There would also be the same number of .mod files. One way to reduce these is to not rely on implicit interfaces!

Well.. I need new glasses, or fingers. The genmod.f90 oddity above aside, the reason I was seeing "Fool! You need an interface!!" kind of erors is becase I cannott spel when typping the procdure name in the intrface blck. I'll fish an example for the ICE out another day, my head is too sore at the moment from banging it on my desk in penance.