[Bug tree-optimization/92131] incorrect assumption that (ao >= 0) is always false

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The testcase is not very good because it is missing main and calling the
function with some arguments that will trigger the miscompilation.
Anyway, at least at -O2 it seems to be a VRP bug to me:
ao_31 = ASSERT_EXPR <ao_23, (unsigned long) ao_23 <= 18446744073709551608>;
Intersecting
  long int ~[-7, -1]  EQUIVALENCES: { ao_23 } (1 elements)
and
  long int [-INF, e.7_8 + 9223372036854775806]  EQUIVALENCES: { } (0 elements)
to
  long int [-INF, -8]  EQUIVALENCES: { ao_23 } (1 elements)
where e.7_8 is VARYING and am_13 is too.
  am_28 = ASSERT_EXPR <am_13, am_13 < e.7_8>;
  b.9_11 = b;
  ao_23 = b.9_11 + am_28;
  ao_31 = ASSERT_EXPR <ao_23, (unsigned long) ao_23 <= 18446744073709551608>;
ao_31 is the ao value at the see_me_here call.
There is
  if (am >= 0)
    b = -am;
  ao = am + b;
  f = ao & 7;
  if (f == 0)
so if am is non-negative, then ao is 0, but if am is negative, then a VARYING
long is added to it and all we know is that am < e (am_13 < e.7_8) for a
VARYING e.7_8.  The 9223372036854775806 is 0x7ffffffffffffffe and that looks
wrong to me.
>From the (unsigned long) ao_23 <= 18446744073709551608 assertion we know that
the low 3 bits are 0, e.g. ~[-7, -1], but where the  + 9223372036854775806
comes from is unclear.  I'd think that for ao_23 we should have [-INF, e.7_8-1]
range or so.