[Patch, Fortran] PR 57160: short-circuit IF only with -ffrontend-optimize

[Janus Weil]

2018-07-24 22:14 GMT+02:00 Janus Weil <janus@gcc.gnu.org>:
> 2018-07-24 21:49 GMT+02:00 Thomas Koenig <tkoenig@netcologne.de>:
>> If you want to enforce either short-circuit evaluation or
>> forced evaluation, please use a dedicated option.
>
> I don't want to enforce any of that. gfortran is enforcing
> short-circuiting right now (with any option), and I want to change
> that.

To expand on that point: I really don't see why a dedicated option is
needed. Short-circuiting of logical expressions is certainly an
"optimization" (which is allowed but not required by the Fortran
standard), and it is done in the Fortran front end, thus enabling it
with -ffrontend-optimize makes perfect sense to me. Actually I don't
really care which one of the plenty optimization flags of GCC turns it
on, but I do think that, as all other optimizations, it should
certainly be disabled at -O0.

In fact the the idea put forward by Joost in PR57160 (which I'm
implementing here) coincides with the policy proposed by Jakub in
https://gcc.gnu.org/ml/fortran/2018-06/msg00215.html:

> So for -O0 at least always use
> TRUTH_{AND,OR}_EXPR, so that people can actually make sure that their
> programs are valid Fortran and can also step into those functions when
> debugging.  For -O1 and higher perhaps use temporarily the *IF_EXPR, or
> better, as I said in another mail, let's add an attribute that will optimize
> all the calls that can be optimized, not just one special case.


> 2018-07-24 21:49 GMT+02:00 Thomas Koenig <tkoenig@netcologne.de>:
>> I don't think it is a good idea to have
>>
>> if (allocated(x) .and. any(x>0))
>>
>> crash on -O0 and not crash on -O.
>
> I actually do. The code is invalid. Crashing it is good, because it
> draws the user's attention to that fact.

What would be even better than a hard crash (segfault) would be a
proper runtime error that gives more information about the nature of
the problem. -fcheck=all may already catch some of the situations
mentioned in the beginning of this thread, but it clearly needs
improvement/extension, which could be tackled as a follow-up.

If there is further constructive criticism regarding v3 of the patch,
as posted at https://gcc.gnu.org/ml/fortran/2018-07/msg00103.html,
I'll be happy to deal with that. If not, I'd like to commit it by the
weekend.

Cheers,
Janus