https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
Martin Sebor <msebor at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|c++ |middle-end Keywords| |missed-optimization CC| |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> --- The warning is only issued at -O1. It's based on the statement in the IL and the values or ranges of its arguments. In this case the IL and the argument values are below: =========== BB 6 ============ Imports: _1 d_6(D) Exports: _1 d_6(D) _1 sizetype [0, 0][2, 15] <bb 6> [local count: 362271902]: if (_1 == 0) goto <bb 8>; [100.00%] else goto <bb 7>; [0.00%] 6->8 (T) _1 : sizetype [0, 0] 6->7 (F) _1 : sizetype [2, 15] >>> _1 > 1 =========== BB 7 ============ <bb 7> [local count: 346397698]: # _2 = PHI <&s.D.26133._M_local_buf(6), _19(3)> __builtin_memcpy (_2, &buffer, _1); <<< -Wstringop-overread The memcpy() call reads between 2 and 15 bytes from the one-byte buffer. So the warning code is working as designed. The problem is that at -O1 the code isn't optimized sufficiently to discover that the memcpy call only reads 1 byte (the function call isn't inlined and so the constant argument isn't propagated into the call). GCC 11 doesn't warn because it's unable to determine the range of the last memcpy() argument. Thanks to the Ranger improvements GCC 12 is able to do better. In some cases this should improve the S/N ratio of the middle end diagnostics that depend on ranges. Unfortunately, in others like this one where other optimizations are disabled it can make things worse.