Am 12.04.2013 00:17, schrieb Janus Weil:
Hmm, I think I'd prefer to have for the arguments only a warning with
-std=gnu - except for the function result value, which should always be an
error. And also the "requires an explicit interface" checks should always
use an error.
Why the distinction (apart from: NAG does it this way)?
Well, gfortran currently does likewise, as do g95 and crayftn. pathf95
and sunf95 only warns for both examples. PGI accepts both. Intel accepts
both, except with "-warn all" - then it prints an error.
In addition, results-variable types lead definitely to wrong code while
argument mismatches are effectively fine if one does not touch the
argument or one can play tricks by explicitly passing arguments of the
wrong size which has the same storage size. I concur that those tricks
are dirty.
The nice thing about the current patch is that it just relies on the
full machinery of "gfc_compare_interfaces". Making distinctions about
where to give an error or warning probably requires again a certain
amount of code-duplication from interface.c. Or do you see a
technically simple way to do this?
Well, the issue only occurs with the function result, i.e. just checking
the result type for the error should be simple. The rest - including the
string length - could then be left to gfc_compare_interfaces. With
string lengths not that much can go wrong - compared to wrong types+ranks.
However, if one goes for an error with -std=gnu, the error should explicitly
mention that "-std=legacy" disables the error. At least I do not recall all
the special flags which enable certain features, nor whether such a flag
exists at all. And I doubt that a normal user do.
That's right. Might be worth to add it. Although the folks which
operate such 'dirty' legacy codes hopefully know about the usefulness
of -std=legacy ...
Usually they don't. Typically such users just try to get some old code
running and have no idea about compilers and Fortran. While users of
modern code typically know Fortran and compilers better.
Tobias
