Evading intent(in)

I am surprised by Beliavsky’s example because increment is visible in the module compilation unit. The compilers can see that increment changes its argument.

In the situation where sub-programs are separately compiled, analyses of several large programs (e.g. WRF and TELEMAC) show about a 2% error rate in INTENT(IN) specifications. We experimented with removing all of the INTENT specifications and found absolutely no change in the program outputs. However I think that compilers do use INTENT in determining whether to input or output arrays in some circumstances. We found that INTENT is always checked within the routine where it is specified, but not when an INTENT(IN) argument is passed down into other routines.

fpt (http://simconglobal.com) will catch errors like this because it reads all of the routines in a program and analyses the uses. However this is not trivial. In particular it is difficult to catch INTENT(OUT) violations because this involves tracing all control paths through the code to prove that an INTENT(OUT) argument is always assigned. We are revising our handling of this at the moment.

Best wishes,

John

4 Likes

Thanks for the information. Does fpt have the ability to analyze a Fortran-77-style code without INTENTs and rewrite the code, adding INTENTs, while giving the same results as the original code? Adding intents manually is one of the first things I do when trying to understand an old code.

1 Like

INTENT(INOUT) requires that the associated actual argument is definable. This is not the same as the rules for no intent specified. The first sentence is why you cannot use an INTENT(IN) argument as an actual argument corresponding to a dummy with INTENT(INOUT).

2 Likes

Yes, fpt will handle legacy FORTRAN 77 with all the VMS, MPX and most other extensions. It will change the code to free format and re-program many of the extensions.

The current version of fpt checks INTENT declarations and reports possible violations, but it does not add INTENT declarations. We have already been asked to do this and the code is close to completion. We have two flags - IN means that the variable can be read before it is assigned, OUT means that it is assigned in reachable code. fpt does a complete control flow analysis so checking IN is easy. We just have to find a path from the entry to a read. Checking OUT is also easy, we have to find a path from the entry to the write and a path from the write to the return. The difficulty is in proving INTENT(OUT) which requires that any read of any part of the object takes place after that part has been written.

A further complication is that fpt necessarily has more intents that IN, OUT and INOUT. The others are NONE (the argument is unused), ATTRIB (the attributes, array bounds, allocation status, presence etc. are used but not the data), function formal argument, subroutine formal argument and label reference (either executable or format). I wonder whether these would be useful in the language, but that is another issue.

Look out for an fpt which will add INTENT specifications in the next month.

Best wishes,

John

2 Likes

Makes me curious how the stdlib efforts would fair if run through fpt! Sounds like it handles a lot of the issues often posted on Fortran forums about migrating to more modern syntax, making code more portable, etc. Interesting.