[Bug c++/98158] New: Gcc generates warning about its own generated move assignment operator

[Bug c++/98158] New: Gcc generates warning about its own generated move assignment operator

[darklythinking at yahoo dot com]

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

            Bug ID: 98158
           Summary: Gcc generates warning about its own generated move
                    assignment operator
           Product: gcc
           Version: 10.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: darklythinking at yahoo dot com
  Target Milestone: ---

Version:
$ gcc --version
gcc (Gentoo 10.2.0-r3 p4) 10.2.0

System:
The bug doesn't happen if no arch is specified but with -march=skylake or
-march=znver2 the warning appears(and probably others but those are the 2 I
tested)

Code:
#include <string>
#include <cstdint>

struct test
{
        std::string a;
        std::uint8_t b[16];
        std::uint8_t c[16];
};

test function(test blah)
{
        blah = {};
        return blah;
}

int main(int argc, char *argv[])
{
        return 0;
}

Output:
$ g++ -O3 -march=skylake test.cpp
In member function ‘test& test::operator=(test&&)’,
    inlined from ‘test function(test)’ at test.cpp:13:10:
test.cpp:4:8: warning: writing 32 bytes into a region of size 16
[-Wstringop-overflow=]
    4 | struct test
      |        ^~~~
test.cpp: In function ‘test function(test)’:
test.cpp:7:15: note: at offset 0 to object ‘test::b’ with size 16 declared here
    7 |  std::uint8_t b[16];
      |               ^


Note that the warning actually happens in a move assignment operator generated
by gcc itself.

The warning also appears if std::vector is used instead of the std::string but
I wasn't able to replace it with a struct or static array of any size and
reproduce the bug that way.

[Bug c++/98158] [10/11 Regression] Gcc generates warning about its own generated move assignment operator since r10-3657-gdaa94de24b9afdf2

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-12-06
      Known to work|                            |9.3.0
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |msebor at gcc dot gnu.org
            Summary|Gcc generates warning about |[10/11 Regression] Gcc
                   |its own generated move      |generates warning about its
                   |assignment operator         |own generated move
                   |                            |assignment operator since
                   |                            |r10-3657-gdaa94de24b9afdf2
             Status|UNCONFIRMED                 |NEW
      Known to fail|                            |10.2.0, 11.0

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r10-3657-gdaa94de24b9afdf2.

[Bug c++/98158] [10/11 Regression] Gcc generates warning about its own generated move assignment operator since r10-3657-gdaa94de24b9afdf2

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |diagnostic
         Resolution|---                         |DUPLICATE

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning works as designed.  It's based on the GIMPLE below
(-fdump-tree-strlen) where GCC synthesizes a single store to clear the two
consecutive members.  There's code in the warning that tries to deal with this
but a better solution would be to emit IL that c orresponds to valid code
instead of IL that's indistinguishable from a buffer overflow.  I.e., instead
of writing the 32 bytes into b write them into (char*)&blah + offsetof (test,
b).

pr96963 already tracks the same problem so I'm going to resolve this as its
duplicate.

  <bb 4> [local count: 1073741824]:
  # prephitmp_60 = PHI <&MEM[(struct basic_string
*)&D.33188].D.24959._M_local_buf(2), pretmp_59(3)>
  MEM[(struct basic_string *)&D.33188]._M_string_length = 0;
  MEM[(char_type &)prephitmp_60] = 0;
  _37 = &blah_3(D)->b;   <<< address of b
  vect__39.58_74 = MEM <vector(2) __int128 unsigned> [(char *
{ref-all})&D.33188 + 32B];
  _39 = MEM <__int128 unsigned> [(char * {ref-all})&D.33188 + 32B];
  _46 = &blah_3(D)->c;
  _41 = MEM <__int128 unsigned> [(char * {ref-all})&D.33188 + 48B];
  MEM <vector(2) __int128 unsigned> [(char * {ref-all})_37] = vect__39.58_74;  
<<< warning: writing 2 __int128's into b with size 16
  _13 = MEM[(const struct basic_string *)&D.33188]._M_dataplus._M_p;
  if (&MEM[(const struct basic_string *)&D.33188].D.24959._M_local_buf != _13)
    goto <bb 5>; [53.47%]
  else
    goto <bb 6>; [46.53%]

*** This bug has been marked as a duplicate of bug 96963 ***