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.)