This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, fortran] Handling of .and. and .or. expressions
Am 13.06.2018 um 14:20 schrieb Janus Weil:
Hi Thomas,
the attached patch introduces the following changes:
thanks a lot for working on this!
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.
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.
Also ASSOCIATED (and ALLOCATED) are pure, so normally I would
not warn on these.
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).
And of course, the compiler can always reverse the order...
Regards
Thomas