https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109717
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jwakely.gcc at gmail dot com,
| |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Component|tree-optimization |libstdc++
Last reconfirmed| |2023-05-04
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we see
<bb 6> [local count: 14986075]:
_60 = operator new (4);
_43 = MEM[(const struct buffer *)this_10(D)].size_;
_44 = _43 * 4;
_63 = (signed long) _44;
if (_63 > 4)
goto <bb 7>; [90.00%]
else
goto <bb 8>; [10.00%]
<bb 7> [local count: 12138721]:
__builtin_memmove (_60, pretmp_118, _44);
goto <bb 10>; [100.00%]
and if _63 > 4 then the memmove will write out of bounds of the allocated
storage. The stringop-overflow diagnostic is about the same thing.
There's eventually a missed optimization that we do not discover this
path as not taken, but I do not see any write to size_ in the function.
There's
<bb 5> [local count: 272474101]:
*pretmp_118 = 1;
if (pretmp_154 == 0)
goto <bb 6>; [50.00%]
else
goto <bb 12>; [50.00%]
and
<bb 4> [local count: 148083751]:
pretmp_118 = MEM[(struct buffer *)this_10(D)].ptr_;
pretmp_154 = MEM[(struct buffer *)this_10(D)].capacity_;
if (exp_6(D) == 0)
goto <bb 5>; [20.24%]
else
goto <bb 13>; [79.76%]
but given capacity is zero on this path size_ is probably zero as well
(but that's not visible here).
An assertion in the library that size_ <= capacity_ would maybe help.
To sum up, there's nothing the diagnostic code can do here - it simply
doesn't have sufficient information to prune this diagnostic.
