Am 13. Juni 2018 22:39:38 MESZ schrieb Thomas Koenig <tkoe...@netcologne.de>:
>>> If a logical .and. or .or. expression contains a reference to a
>>> function
>>> which is impure and which also does not behave like a pure function
>>> (i.e. does not have the implicit_pure attribute set), it emits a
>>> warning with -Wsurprising that the function might not be evaluated.
>>> (-Wsurprising is enabled by -Wall).
>>
>> I think you are warning about too many cases here. Warning about an
>impure function as the *second* operand of the logical operators should
>be enough, I think. AFAICS there is no danger of the first operand not
>being evaluated, right?
>
>Not necessarily. The middle end, at the moment, may
>lack this optimization; at least nobody has so far come
>up with a test case that demonstrates otherwise. On the
>other hand, people who know the middle end extremely well have
>indicated that they expect optimiazations to happen with
>TRUTH_AND_EXPR, so I am far from certaint that this behavior
>will continue.
IIUC, TRUTH_AND_EXPR corresponds to C's && operator, which is inherently
assymetric and guaranteed to short-circuit. So I don't think the middle-end
would ever switch operands here. I hope your ominous "people who know the
middle end extremely well" will correct me if I'm wrong :)
>>> It special cases the idiom if (associated(m) .and. m%t) which
>>> people appear to use.
>>
>> I don't fully understand why you do this, but in any case it should
>not be necessary if you warn about the second operand only.
>
>Well, it is an easy mistake to make, and it is (as above) liable
>to break at any time.
You still haven't stated clearly the rationale for this warning. As I see it,
Fortran does not require the compiler to do short-circuiting, but gfortran
still does it. So AFAICS there is currently no reason to throw a warning on
this case, right?
I don't think we need warnings for hypothetical situations. In fact, ifort
might have reason to warn about this case, because it does not do
short-circuiting.
>>> And, if there is an expression like func() .and. flag , it
>>> reverses the test as an optimization.
>>
>> I really don't like this part. It actually introduces more problems
>of the sort that we're trying to warn about ...
>
>If we actually perform this operation, we will have warned about this
>before (with -Wsurprising).
But we do not perform this operation at present, and I really don't think we
should.
>And of course, the compiler can always reverse the order...
If you're talking about the middle-end here, I don't think it can (see
discussion above).
Cheers,
Janus
