[Bug tree-optimization/103332] [12 Regression] Spurious -Wstringop-overflow on string concatenation in libstdc++ tests

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103332

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=103534
            Summary|Spurious                    |[12 Regression] Spurious
                   |-Wstringop-overflow         |-Wstringop-overflow on
                   |warnings in libstdc++ tests |string concatenation in
                   |                            |libstdc++ tests
      Known to fail|                            |12.0

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
The first warning is for the invalid memcpy() call below:

  struct string D.35215;
  ...
  <bb 3> [local count: 1073312331]:
  D.35215._M_string_length = 16;
  _62 = D.35215._M_dataplus._M_p;
  MEM[(char_type &)_62 + 16] = 0;
  D.35222 ={v} {CLOBBER};
  MEM[(struct _Alloc_hider *)&D.35222] ={v} {CLOBBER};
  MEM[(struct _Alloc_hider *)&D.35222]._M_p = &D.35222.D.28102._M_local_buf;
  if (&MEM <const char[16]> [(void *)&D.35215 + 16B] == _62)
    goto <bb 4>; [30.00%]
  else
    goto <bb 5>; [70.00%]

  <bb 4> [local count: 157390518]:
  __builtin_memcpy (&D.35222.D.28102._M_local_buf, &MEM <const char[16]> [(void
*)&D.35215 + 16B], 17);
  goto <bb 6>; [100.00%]

sizeof std::string::_M_local_buf is 16 but the call writes 17 bytes into it, so
the call is invalid.

I only see the warning at -O1 (and with -D_GLIBCXX_DEBUG).  It also goes away
if I force std::string::_M_mutate to be inlined.  _M_mutate allocates the
dynamic string so with it inlined GCC can determine that the local buffer is no
longer used and eliminate the invalid call.  So as in the other cases we have
seen recently, this false positive is due to some optimizer limitations caused
by the combination of -O1 and a decision to throttle inlining.  The second
warning is due to the same issue.  It too goes away with more aggressive
inlining (on x86_64 setting -finline-limit=200 avoids it).