[Bug c++/111094] New: Spurious Wuninitialized swapping underlying bytes of object representation in move constructor

[Bug c++/111094] New: Spurious Wuninitialized swapping underlying bytes of object representation in move constructor

[ed at catmur dot uk]

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

            Bug ID: 111094
           Summary: Spurious Wuninitialized swapping underlying bytes of
                    object representation in move constructor
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ed at catmur dot uk
  Target Milestone: ---

struct S { short x, y; };
struct A {
    A() {}
    A(A&& rhs) {
        auto p = reinterpret_cast<unsigned char*>(&s);
        auto q = reinterpret_cast<unsigned char*>(&rhs.s);
        for (int i = 0; i != sizeof s; ++i) {
            auto t = p[i];
            p[i] = q[i];
            q[i] = t;
        }
    }
    bool b = false;
    S s;
};
A f() {
    A a;
    A b = static_cast<A&&>(a);
    return b;
}

at -O3 -Wall:

In constructor 'A::A(A&&)',
    inlined from 'A f()' at <source>:18:29:
<source>:9:23: warning: '*(__vector(4) unsigned char*)((char*)&a + offsetof(A,
A::s.S::x))' is used uninitialized [-Wuninitialized]
    9 |             p[i] = q[i];
      |                    ~~~^
<source>: In function 'A f()':
<source>:17:7: note: 'a' declared here
   17 |     A a;
      |       ^

I'm reasonably sure that this usage of swapping underlying bytes is OK by
[basic.indet]/2.3.

(Motivation is e.g. optional with empty-on-move behavior and optimization for
trivial types.)

[Bug tree-optimization/111094] Spurious Wuninitialized swapping underlying bytes of object representation in move constructor

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |tree-optimization

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is what the IR looks like:

  a ={v} {CLOBBER};
  *b_2(D).b = 0;
  vect__14.11_28 = MEM <vector(4) unsigned char> [(unsigned char *)&a + 2B];
  MEM <vector(4) unsigned char> [(unsigned char *)b_2(D) + 2B] =
vect__14.11_28;
  a ={v} {CLOBBER(eol)};
  return b_2(D);

Which is copying the unitialized parts of a.S to b.S.

[Bug tree-optimization/111094] Spurious Wuninitialized swapping underlying bytes of object representation in move constructor

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
But that does not mean GCC should not warn about this. It just means it will
NOT be undefined behavior ...

[Bug tree-optimization/111094] Spurious Wuninitialized swapping underlying bytes of object representation in move constructor

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also I read 2.2 differently (https://eel.is/c++draft/basic.indet) .

Since the object which you are reading from is of type S and even though you
are using an `unsigned char` to read the value here, it will not just be an
Indeterminate but also will be undefined.

[Bug tree-optimization/111094] Spurious Wuninitialized swapping underlying bytes of object representation in move constructor

[ed at catmur dot uk]

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

Ed Catmur <ed at catmur dot uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Ed Catmur <ed at catmur dot uk> ---
Well, I feel like [basic.types.general] probably allows it.

But regardless, yeah, this is an opt-in diagnostic so it's fine if gcc warns on
things that are legal but dubious. We'll just have to be a bit smarter in how
we write this code. Thanks again.