2018-07-12 16:35 GMT+02:00 Dominique d'Humières <domi...@lps.ens.fr>: > >>>> after the dust of the heated discussion around this PR has settled a >>>> bit, here is another attempt to implement at least some basic warnings >>>> about compiler-dependent behavior concerning the short-circuiting of >>>> logical expressions. … >>> >>> IMO your patch is missing the only point I agree with you on this issue, >>> i.e., >> >> So you don't agree that it's a good idea to warn about non-portable code? > > Wel, as you might guess I don’t like warnings in general: too much false > positives > and missed targets (see recent bootstrap breakage).
So then: Do you have a better solution for the problem at hand? The cleaner approach would certainly be to avoid short-circuiting of impure functions altogether. If we can all agree that this is a good idea, I'll be happy to submit a patch in that direction. But recent discussions have shown that there is a broad opposition of hardliners who favor optimization to portability. I don't really have the nerves and the time to continue this endless fight, so for now I would be satisfied if we at least had the warnings. >>> What to do with >>> >>> if(x>0 .and. sort(x)<10.0*log(x)) … >>> >>> which is not portable to compilers computing the two expressions? >> >> That's one of the typical cases that the patch should be able to >> handle. If 'sort' is impure, this should trigger a warning with the >> patch. If it is pure, it doesn't matter whether the rhs of the .and. >> operator is executed (since there are no side effects). Or am I >> missing something? > > I meant ‘sqrt’ (changed behind my back by the stupid spell-checker). sqrt and log are both elemental, thus pure, so there will be no warning. Cheers, Janus
