> Le 12 juil. 2018 à 16:12, Janus Weil <ja...@gcc.gnu.org> a écrit :
>
> Hi Dominique,
>
> thanks for the comments.
>
>>> 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).
>
>> the short-circuit evaluation and the related portability issues should be
>> documented.
>
> I fully agree. Documentation never hurts. Do you have a suggestion
> where this should go? There does not seem to be a particular chapter
> in the manual that deals with portability across compilers (probably
> because one usually assumes that sticking to the Fortran standard is
> sufficient for achieving portability). The best match might be the
> chapter on compiler characteristics:
>
> https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gfortran/Compiler-Characteristics.html
Why not? Anyway if your patch is accepted, the doc for -Wextra has to be
updated accordingly.
>
>> With your patch what happens if check() is an external function?
>
> Haven't tried, but I guess you would get a warning, since the compiler
> cannot tell whether 'check' is pure (unless you have an explicit
> interface block that contains the PURE attribute).
Much ado about nothing?
>
>> Your patch is focusing on pr85599 and ignore pr57160.
>
> Well, yes. PR 57160 is somewhat related, but orthogonal. It concerns
> essentially the same issue, namely short-circuiting with logical
> expressions, but proposes a different solution (making
> short-circuiting depend on the -ffrontend-optimize flag). I wouldn't
> say that's unreasonable, but independent of that I might still want to
> know that my code is not portable, thus a warning makes sense in any
> case (IMHO).
>
>
>> 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).
>
> Cheers,
> Janus
>
>
> 2018-07-12 13:16 GMT+02:00 Dominique d'Humières <domi...@lps.ens.fr>:
>> Hi Janus,
>>
>>> 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.,
>> the short-circuit evaluation and the related portability issues should be
>> documented.
>>
>> With your patch what happens if check() is an external function?
>>
>> Your patch is focusing on pr85599 and ignore pr57160.
>>
>> What to do with
>>
>> if(x>0 .and. sort(x)<10.0*log(x)) …
>>
>> which is not portable to compilers computing the two expressions?
>>
>> Cheers,
>>
>> Dominique
>>
