https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118521
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2025-01-16 00:00:00 |2025-01-17
Ever confirmed|0 |1
CC| |jakub at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Keywords| |needs-bisection
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> The deconstructor is not inlined into main.
That probably just makes it optimized away?
We diagnose
MEM[(char *)_97 + 2B] = 1;
which is on
_150 = operator new (4);
goto <bb 5>; [100.00%]
<bb 5> [local count: 131235112]:
_97 = _150 + 2;
...
_115 = _150 + 4;
if (__new_finish_106 != _115)
goto <bb 6>; [82.57%]
else
goto <bb 7>; [17.43%]
<bb 6> [local count: 108360832]:
MEM[(char *)_97 + 2B] = 1;
so I don't see how -Wstringop-overflow computes a size of 0 here.
Note the diagnostic is from tree-ssa-strlen.cc in this case. And yes,
at _150 + 2 we store a string of some length, but the length of a string
doesn't matter for a store to it?
My "reduced" testcase, avoiding main() and avoiding DSE of the whole vector:
#include <vector>
void bar(std::vector<char>);
int foo() {
std::vector<char> v{1, 2};
v.insert(v.end(), 2, 0);
v.push_back(1);
bar(v);
}
