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

[msebor at gcc dot gnu.org via Gcc-bugs]

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