https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108197
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Component|c++ |tree-optimization
Known to work| |11.3.1
Status|UNCONFIRMED |NEW
Summary|-Wstringop-overread emitted |[12/13 Regression]
|on simple boost |-Wstringop-overread emitted
|small_vector code |on simple boost
| |small_vector code
Keywords| |diagnostic
Blocks| |97048
Last reconfirmed| |2022-12-22
Target Milestone|--- |12.3
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. We have
<bb 6> [local count: 321929297]:
_58 = _43 * 4;
_40 = (signed long) _58;
_67 = _40 /[ex] 4;
sz_68 = (const size_type) _67;
if (_58 > 40)
goto <bb 7>; [51.12%]
else
goto <bb 16>; [48.88%]
<bb 7> [local count: 164570258]:
if (_58 > 9223372036854775804)
goto <bb 8>; [0.00%]
else
goto <bb 9>; [100.00%]
...
<bb 14> [local count: 133301908]:
__builtin_memcpy (_82, &MEM[(const struct small_vector_base
*)&pp].m_storage_start.data, _58);
so we get a constraint on _58, the lower bound causes us to warn. The
.data field is only 4 bytes in size, so the access is clearly out
of bounds. Maybe it is unreachable, the initialization seems to happen
in a function not inlined:
boost::container::expand_forward_and_insert_alloc.isra (&MEM[(struct
small_vector_base *)&pp].m_storage_start.data, &MEM[(struct small_vector_base
*)&pp].m_storage_start.data, 1);
_42 = MEM[(struct vector_alloc_holder *)&pp].m_size;
it looks like boost already uses always_inline a lot but it doesn't
forcefully expose the setting of m_size, so there's not much we can
do about this diagnostic.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048
[Bug 97048] [meta-bug] bogus/missing -Wstringop-overread warnings
