https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103215
Martin Sebor <msebor at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |56456 --- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> --- The warning follows the type_3 pointer to determine the object it points to. That leads it to either name_and_type or name_and_type + OFFSET where OFFSET is in [1, 254]. Between those two, it conservatively picks the former because it has more space (this is done to avoid false positives for stores). What it neglects to do is adjust the bounds of the offset to reflect that of the other. So the code ends up determining that type_43 points to name_and_type with a zero offset when it should instead arrive at name_and_type with an offset in [0, 254]. (If the code also considered the ASSERT_EXPR conditions it should end up with an offset in [1, 254].) <bb 4> [local count: 1073741824]: extract (&name_and_type); type_7 = __builtin_strrchr (&name_and_type, 95); if (type_7 != 0B) goto <bb 5>; [70.00%] else goto <bb 6>; [30.00%] <bb 5> [local count: 751619281]: type_9 = type_7 + 1; <bb 6> [local count: 1073741824]: # type_3 = PHI <type_9(5), &name_and_type(4)> _1 = __builtin_strcmp ("hot", type_3); if (_1 == 0) goto <bb 7>; [50.00%] else goto <bb 3>; [50.00%] <bb 7> [local count: 536870913]: type_10 = type_3 + 18446744073709551615; if (&name_and_type == type_3) goto <bb 3>; [17.43%] else goto <bb 8>; [82.57%] <bb 8> [local count: 443294313]: type_11 = &MEM <char> [(void *)type_3 + -2B]; if (&name_and_type == type_10) goto <bb 3>; [17.43%] else goto <bb 9>; [82.57%] Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds