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?


> 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


> 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).


> 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?

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
>

Reply via email to