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.
