https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|wrong-code |
Priority|P3 |P5
Component|middle-end |fortran
--- Comment #28 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> > This PR is now about a missed optimization in the middle-end.
>
> Well, that was absolutely not my intention when I opened this PR,
> and it still isn't. Quite the opposite: I don't think gfortran should apply
> more optimizations, but less. I'm changing the title and keyword again
> to reflect that.
Then I strongly opposed any change to the gfortran default behavior. Why should
we take a chance to break valid codes to allow invalid or at best questionable
ones? See Steve Lionel comment at
https://groups.google.com/forum/#!topic/comp.lang.fortran/fXP1c0u57So:
"All in all, functions that have side-effects are to be avoided."
> If an impure function is found (recursively) in the operands of an .AND.
> expression, issue a
>
> gfc_warning(OPT_Wsurprising, "Impure function %qs at %L may not be
> evaluated", ...)
>
> So,
>
> if (flag .and. f(x) > 0.)
>
> would also be warned about.
Why recursively? If this PR is going this way, pr57160 should be closed as a
duplicate.
