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.
