2018-06-27 8:15 GMT+02:00 Jakub Jelinek <ja...@redhat.com>:
> On Wed, Jun 27, 2018 at 07:52:59AM +0200, Janus Weil wrote:
>> >> with your patch, we would only warn about
>> >>
>> >> var .and. func()
>> >>
>> >> and not about
>> >>
>> >> func() .and. var.
>> >>
>> >> AFAIK, TRUTH_AND_EXPR does not guarantee that func() will
>> >> always be exectued, or if it does, I have not seen the
>> >> documentation; it just happens to match what we currently
>> >> see (which may be due to missed optimizatins in the back end,
>> >> or the lack of test cases exposing this).
>> >
>> > If you are talking about what the middle-end does, TRUTH_AND_EXPR
>> > always evaluates side-effects in both operands, while for
>> > TRUTH_ANDIF_EXPR it evaluates the second operand only if the first operand
>> > is not false.
>>
>> thanks for the comments. Looking into gfc_conv_expr_op, I see:
>>
>> case INTRINSIC_AND:
>> code = TRUTH_ANDIF_EXPR;
>> lop = 1;
>> break;
>>
>> case INTRINSIC_OR:
>> code = TRUTH_ORIF_EXPR;
>> lop = 1;
>> break;
>>
>> That seems to indicate that Fortran's logical .AND. operator is
>> translated into TRUTH_ANDIF_EXPR, right? Also the empirically observed
>> behavior matches Jakub's description of TRUTH_ANDIF_EXPR, where the
>> first operator is always evaluated and the second one only on demand.
>> Therefore I think my patch is correct in warning about an impure
>> function only if it occurs in the second operand of an and/or
>> operator.
>
> Is that what we want though?
Probably depends a bit on who "we" is ;)
See the discussion upthread and in PR85599.
> Are there in Fortran any ways to have
> side-effects in expressions other than function calls? E.g.
> VOLATILE variable reads?
Don't think so.
> Is it ok not to evaluate those on .and. or .or.
> expressions? I think best would be to change the above to
> code = TRUTH_AND_EXPR and code = TRUTH_OR_EXPR
I don't think it's ok to not evaluate expressions that have side
effects, and I would highly welcome a change to TRUTH_{AND,OR}_EXPR,
but there was quite some opposition to that position.
The Fortran standard unfortunately is somewhat agnostic of that matter
(and leaves quite some freedom to the compiler), which essentially is
the origin of all this discussion.
> and have some non-default aggressive
> optimization option that would optimize away in the FE impure function calls
IMHO an optimization to remove functions calls is unproblematic only
for pure functions, but as long as it is guarded by a non-default
optimization flag, I'm perfectly happy with optimizing away stuff with
side effects as well.
Cheers,
Janus
