Whenever Flint finds a call to a subroutine, or the source of a subroutine, it attempts to determine whether a subroutine argument is either input or output (this is called an arguments intent). Usually Flint will build up its knowledge of a particular routines arguments by analyzing many uses of the subroutine, and generate a warning whenever inconsistent use is noted.
Note that Flint expects an argument's intent to be either input or output or input/output. Some routines use an argument as input in some situations and output in others. Such routines may confuse Flint, and it may well generate spurious messages about the variable in the subroutine call being uninitialized or redundant, or that the arguments intent is inconsistent.
Normally Flint performs a single pass, analyzing files in the order that they are given on the command line. When analyzing the early part of the input source, Flints knowledge of argument intent is very poor. Thus some problems (uninitialized and redundant variables) may be missed. There are two recipes to partially avoid this. Firstly files on the command line should be ordered with the files containing low level subroutines first, and high level programs and application code last (generally interface definition libraries should go first). Additionally inside files, the lower level routines should be first, and higher level routines last. Secondly, the user can ask Flint to perform two passes of the input files, by using the -2 flag. Two passes will not necessarily correctly determine the intent of all arguments (in general N passes will always be enough for program with subroutine calls to a depth of N).
The following contrived example shows the worst case sort of behavior, where Flint builts up its knowledge of argument intent quite slowly.
subroutine a(x)
real x
call b(x)
end
subroutine b(x)
real x
call c(x)
end
subroutine c(x)
real x
write(*,*)x
end
It would require three passes for Flint to determine that the
intent of argument x in subroutine a was input
(the first pass would determine the intent of x in c, the
second would determine the intent of x in b). Usually
Flint determines argument intents by other means than just allowing information
to bubble up from the lowest level to the higher level routines. But in the
above example, none of these could be applied. One of the techniques is
derived from initialization checking (described under the -i flag).
When determining intent accurately is important, and if the initialization
checking algorithm is failing (i.e. producing spurious messages), then
initialization checking should be disabled.
Small changes can significantly change the number of passes needed to uncover all intent information. For instance, in the example above, if the ordering of the routines was reversed (i.e. c first and a last), or if a piece of code such as
call a(1.0)appeared before subroutine a, then Flint would require only one pass.