https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830
--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
I've only looked at the first warning so far. It's issued for the access in bb
8:
<bb 5> [local count: 4057510040]:
pos.80_31 = pos;
if (pos.80_31 <= 1023)
goto <bb 8>; [96.34%]
else
goto <bb 6>; [3.66%]
<bb 8> [local count: 256307115]:
# pos.80_21 = PHI <pos.80_81(36)>
_1 = linebuf[pos.80_21]; <<< -Warray-bounds
...
The index is in the range [1024, INT_MAX] so the warning is correct given the
IL. There isn't much I see that could be improved about the diagnostic except
mentioning the range of the subscript rather than just its lower bound. This
instance of the warning or its phrasing also haven't changed in years. It's
not the result of a recent enhancement or a questionable heuristic but simply
reflects a change in the IL, and it's always been phrased as "is out of
bounds". No "may be out of bounds" form exists, never has, and adding one
wouldn't help in this instance.
That said, since pos is a global variable, the test in safe_inc_pos() that
would otherwise constrain its value only has that effect in the absence of
intervening statements that might overwrite it. You might get a better result
with a pair of "setter" and "getter" functions where the latter asserted the
range via __builtin_unreachable() before returning the variable. Otherwise,
the test is what likely is used by the backward threader to introduce the
unreachable branch which isn't eliminated because GCC can't prove the variable
isn't incremented beyond its upper limit. (Aldy is in a much better position
to explain this.)
