This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran] PR 85599: warn about short-circuiting of logical expressions for non-pure functions



> Le 12 juil. 2018 à 16:12, Janus Weil <janus@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 <dominiq@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
>> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]