https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110807
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Component|tree-optimization |libstdc++
Known to fail| |14.0
Last reconfirmed| |2023-07-26
Keywords| |missed-optimization
Status|UNCONFIRMED |NEW
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. We're diagnosing the sequence
<bb 2> [local count: 1073741824]:
D.26106[0] = 1;
_7 = byCallSpread.D.26008._M_impl.D.25481._M_start.D.16802._M_p;
_8 = MEM[(const struct _Bit_iterator &)&byCallSpread + 16].D.16802._M_offset;
_9 = MEM[(const struct _Bit_iterator &)&byCallSpread + 16].D.16802._M_p;
_10 = _9 - _7;
_11 = _10 * 8;
_12 = (long int) _8;
_13 = _11 + _12;
_14 = (long unsigned int) _13;
if (_14 > 1)
goto <bb 3>; [50.00%]
else
goto <bb 4>; [50.00%]
<bb 4> [local count: 536870913]:
if (_13 == 1)
goto <bb 5>; [89.00%]
else
goto <bb 9>; [11.00%]
<bb 9> [local count: 375809640]:
__result ={v} {CLOBBER(eol)};
_118 = MEM[(const struct _Bvector_impl
*)&byCallSpread].D.25481._M_end_of_storage;
if (_7 != _118)
goto <bb 10>; [50.00%]
else
goto <bb 14>; [50.00%]
<bb 14> [local count: 187904820]:
_316 = operator new (8);
_138 = byCallSpread.D.26008._M_impl.D.25481._M_start.D.16802._M_p;
_339 = _9 - _138;
_775 = (long unsigned int) _339;
if (_339 > 8)
goto <bb 15>; [90.00%]
else
goto <bb 16>; [10.00%]
<bb 15> [local count: 169114338]:
__builtin_memmove (_316, _138, _775);
the memmove call in BB 15 is diagnosed, it goes to storage of size 8
and obviously the guarding test just checked we will write more than 8 bytes
here.
I'm just guessing this is a missed optimization (this code must be
unreachable), but possibly again the standard library implementation
might make it impossible for the compiler to prove that given it isn't
able to second-guess constraints in the standard library.
Disclaimer: I didn't try to decipher the shitload of code we generate for
this simple function ;)
