https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
CC| |amacleod at redhat dot com
Component|c++ |tree-optimization
Status|UNCONFIRMED |NEW
Keywords| |diagnostic,
| |missed-optimization,
| |needs-bisection
Last reconfirmed| |2022-04-21
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It warns about
__builtin_memcpy (_140, _29, _28);
in
<bb 15> [local count: 14831835]:
__nleft_49 = (const size_type) _48;
__builtin_memcpy (_22, "5", __nleft_49);
_28 = 1 - __nleft_49;
_29 = _22 + 1;
_140 = _22 + __nleft_49;
__builtin_memcpy (_140, _29, _28);
pretmp_145 = MEM[(const struct basic_string *)s_2(D)]._M_dataplus._M_p;
goto <bb 19>; [100.00%]
the block is guarded with
if (_22 >= &MEM <const char[2]> [(void *)"5" + 1B])
goto <bb 10>; [50.00%]
else
goto <bb 11>; [50.00%]
if (_22 <= "5")
goto <bb 12>; [50.00%]
else
goto <bb 13>; [50.00%]
<bb 13> [local count: 22472477]:
_48 = _22 - "5";
if (_48 == 1)
goto <bb 14>; [34.00%]
else
goto <bb 15>; [66.00%]
so we're taking the path where "5" is not one character in size. We should
have somehow simplified this. It looks like a missed jump-threading,
not sure if we were able to catch this with the forward threader or the
old VRP.
