[Bug libstdc++/110807] [13/14 Regression] Copy list initialisation of a vector<bool> raises a warning with -O2

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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 ;)