[Bug c++/92475] [8/9/10 Regression] incorrect code with optimization

[rguenth at gcc dot gnu.org]

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.