https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92475
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
So while we clear range info from _5 when
Setting value number of g_16 to _5 (changed)
clearing range info of _5
we're not clearing range info from all defs leading to it and since
# RANGE [0, 7] NONZERO 7
c.6_1 = (sizetype) c_7;
# RANGE [1, 8] NONZERO 15
_5 = c.6_1 + 1
we end up simplifying g_16 != 0 to c.6_1 != -1U which we resolve via
/* X == C (or X & Z == Y | C) is impossible if ~nonzero(X) & C != 0. */
(for cmp (eq ne)
(simplify
(cmp:c (with_possible_nonzero_bits2 @0) (with_certain_nonzero_bits2 @1))
(if (wi::bit_and_not (wi::to_wide (@1), get_nonzero_bits (@0)) != 0)
{ constant_boolean_node (cmp == NE_EXPR, type); })))
The solution for this kind of bugs was indeed the VN rewrite which avoids
simplifying expressions with names that are not available (and thus may
be from a different loop iteration invocation).
The solution we employed for the old VN is inherently fragile and I
don't see any easy workaround besides trying to add some kind of global
flag invalidating all range information (but it's points-to as well for
the cases of PTA disambiguation and that info is quite valuable).
So I fear that WONTFIX is the solution we'll end up with here.
