[Bug middle-end/97931] New: missing -Wuninitialized initializing an aggregate member with itself

[Bug middle-end/97931] New: missing -Wuninitialized initializing an aggregate member with itself

[msebor at gcc dot gnu.org]

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

            Bug ID: 97931
           Summary: missing -Wuninitialized initializing an aggregate
                    member with itself
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Quoting from my reply to
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559626.html:

> Martin, I notice that the middle-end warning doesn't currently catch this:
> 
> struct B { int i,j; };
> 
> struct A
> {
>    B b;
>    A(): b({b.i}) { }
> };
> 
> A a;
> 
> It does warn if B only has one member; adding the second wrongly 
> silences the warning.

The GIMPLE for A's ctor looks like this:

A::A (struct A * const this)
{
   *this = {CLOBBER};
   {
     this->b = {};
     _1 = this->b.i;
     this->b.i = _1;
   }
}

so the b member is cleared first before it's read from and there's
nothing to warn about.  This happens for C structs too:

void f (void*);

struct A { int i, j; };

void g (void)
{
   struct A a = { a.i };
   f (&a);
}

The uninitialized read is in the original dump (below) so the zero
initialization happens in the gimplifier and could be diagnosed
there.

;; enabled by -tree-original


{
   struct A a = {.i=a.i};

     struct A a = {.i=a.i};
   f ((void *) &a);
}

Martin

PS I think the C++ original dump (below) shows the same problem
despite the Unknown trees that obscure it:

;; Function A::A() (null)
;; enabled by -tree-original


<<cleanup_point <<< Unknown tree: expr_stmt
   *(struct A *) this = {CLOBBER} >>>>>;
{
   <<cleanup_point <<< Unknown tree: expr_stmt
   (void) (((struct A *) this)->b = TARGET_EXPR <D.2389, {.i=((struct A 
*) this)->b.i}>) >>>>>;
}

[Bug middle-end/97931] missing -Wuninitialized initializing an aggregate member with itself

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |11.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Probably because the FE emits a CONSTRUCTOR node were missing elements are
implicitely zero in GENERIC semantics, unless CONSTRUCTOR_NO_CLEARING is set.

[Bug middle-end/97931] missing -Wuninitialized initializing an aggregate member with itself

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager <egallager at gcc dot gnu.org> ---
Shouldn't this go under -Winit-self?

[Bug middle-end/97931] missing -Wuninitialized initializing an aggregate member with itself

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
-Winit-self isn't enabled by -Wall in C (to accommodate the 'int i = i;' hack)
so unless that changes I'd rather see it in -Wuninitialized (which is in -Wall
in all C languages).

[Bug c++/97931] missing -Wuninitialized initializing an aggregate member with itself

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |c++
   Last reconfirmed|                            |2021-08-25
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
There's nothing the middle end can do to warn because the front end emits code
to zero-initialize the struct/class first and only then to use the value of the
zero-initialized member to [re]initialize it.  The detection needs to happen in
the front ends (both C and C++).