Dominique d'Humieres <dominiq at lps dot> changed:

           What    |Removed                     |Added
           Keywords|wrong-code                  |
           Priority|P3                          |P5
          Component|middle-end                  |fortran

--- Comment #28 from Dominique d'Humieres <dominiq at lps dot> ---
> > 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!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

Reply via email to