https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105142

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> Hmm, I think the error happens earlier already when we simplify
> 
> _2 < _16 && (_4 > _2) to _2 < _4
> 
> I do have a patch to do the rewrite into defined overflow which definitely
> fixes a latent issue but not this bug.

Which happens through

Applying pattern match.pd:6775, gimple-match.cc:54944
Applying pattern match.pd:3153, gimple-match.cc:177685

_2 < _16 & _2 < _4

match.pd:6775 -> _2 < min (_16, _4)

and

min (_16, _16 + 5713568809962283044)

match.pd:3153 -> _16 + 5713568809962283044 (aka _4)

which is all "nice" and validates that we can replace the inner condition
with itself but it ignores that it only subsumes the outer condition if
the outer condition is true.

That's a real tough nut to crack.  It basically means that we cannot
really combine two conditions if the definition chain of the inner
condition is under the outer condition (and involves undefined overflow),
unless we somehow can decide whether the outer condition tests for overflow
of any of the guarded stmts.  In practice this means not simplifying
interesting cases I guess and likely fold-const.cc code is susceptible
to the very same issue.

A "simple" workaround would pass in context BBs to maybe_fold_and_comparisons
and adjust maybe_fold_comparisons_from_match_pd with a custom
follow_all_ssa_edges variant, disallowing (signed) operation expansion from
the inner BB.  I will experiment with that to see what the fallout would be.
Note combining will have similar issues with using flow-sensitive range info
from inner BB defined stmts constrained by the outer check.

Reply via email to