2013/4/12 Tobias Burnus <bur...@net-b.de>: > 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.
Ok, that's what the patch does now: Always error for wrong result type, then do the full interface check, but only give a warning with -std=gnu and -std=legacy, and an error otherwise. Will do another regtest now. Are you okay with this version? Cheers, Janus
pr56261_v8.diff
Description: Binary data
