https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119797
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2025-04-15
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Christoph Rüthing from comment #3)
> @Andrew, thank you for checking. You mean in case r >= 16 we hit the
> dedicated path where "if (r >= 16)" is true and in this branch we know that
> we will access out of bounds and thus issue the warning?
Yes.
> When further thinking about this it makes sense like this, still it is a
> little bit unintuitive for a user to see this. Especially, since the warning
> goes away when changing the ordering. With
>
> const uint32_t ce = BUG[r];
>
> const uint32_t s = Test<0U>(r);
> const uint32_t e = Test<1U>(r);
>
> const uint32_t cs = BUG[r];
>
> the warning goes away.
Here 'cs' is CSEd to 'ce' and thus the access is before the if()s which
means that jump threading does not isolate the case of BUG[r] when r
is known >= 16.
Jump threading basically results in array-bound warnings that are given
because you don't constrain the index to the size of the array. Similar
as to if we were to diagnose
uint32_t Bug(unt8_r r)
{
return BUG[r];
}
with a "warning: BUG[r] might access BUG out-of-bounds" which wouldn't
be very useful. In your case you do indirectly constrain the index,
and in one path you constrain it to be always out-of-bounds which is
why we warn.
We just fail to give you this extra information ...
So confirmed, but I'd say it's a duplicate of other instances of this kind.
