[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

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

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

--- Comment #56 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:4b1d3d8d732bea86c7b2aba46c2a437461020824

commit r12-5479-g4b1d3d8d732bea86c7b2aba46c2a437461020824
Author: Marek Polacek 
Date:   Fri Nov 19 14:22:10 2021 -0500

c++: -Wuninitialized for mem-inits and empty classes [PR19808]

This fixes a bogus -Wuninitialized warning: there's nothing to initialize
in empty classes, so don't add them into our uninitialized set.

PR c++/19808

gcc/cp/ChangeLog:

* init.c (emit_mem_initializers): Don't add is_really_empty_class
members into uninitialized.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wuninitialized-28.C: Make a class nonempty.
* g++.dg/warn/Wuninitialized-29.C: Likewise.
* g++.dg/warn/Wuninitialized-31.C: New test.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

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

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

--- Comment #55 from Marek Polacek  ---
Aah, I should check is_empty_class before issuing the warning I guess.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

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

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

--- Comment #54 from Jonathan Wakely  ---
Looks like it's missing a check for m_alloc having vacuous initialization, i.e.
not actually needing any initialization before it's usable.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #53 from David Binderman  ---
I am not sure if this belongs here or in a separate bug report,
but given this code:

class AllocatorWithCleanup {
public:
  int *allocate(int, void *);
};
class SecBlock {
  SecBlock() : m_ptr(m_alloc.allocate(0, nullptr)) {}
  AllocatorWithCleanup m_alloc;
  int *m_ptr;
};

Recent clang-14 thinks it is ok and new gcc trunk thinks it isn't.

$ /home/dcb/llvm/results/bin/clang++ -c -O2 -Wall bug774.cc
$ /home/dcb/llvm/results/bin/clang++ -v
clang version 14.0.0 (https://github.com/llvm/llvm-project.git
f95bd18b5faa6a5af4b5786312c373c5b2dce687)
$ /home/dcb/gcc/results/bin/gcc -c -O2 -Wall bug774.cc
bug774.cc: In constructor ‘SecBlock::SecBlock()’:
bug774.cc:6:22: warning: member ‘SecBlock::m_alloc’ is used uninitialized
[-Wuninitialized]
6 |   SecBlock() : m_ptr(m_alloc.allocate(0, nullptr)) {}
  |  ^~~
$ /home/dcb/gcc/results/bin/gcc -v
gcc version 12.0.0 2029 (experimental) (0e510ab53414430e) 
$

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #52 from David Binderman  ---
(In reply to Marek Polacek from comment #51)
> At last, implemented.

Marvellous. 

I will test it by compiling Fedora rawhide and report back
with any errors.

Nearly 17 years is quite a wait for a fix.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

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

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #51 from Marek Polacek  ---
At last, implemented.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

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

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

--- Comment #50 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:0790c8aacdfb4fd096aa580dae0fe49172c43ab2

commit r12-5391-g0790c8aacdfb4fd096aa580dae0fe49172c43ab2
Author: Marek Polacek 
Date:   Tue Nov 10 20:07:24 2020 -0500

c++: Implement -Wuninitialized for mem-initializers (redux) [PR19808]

2021 update: Last year I posted a version of this patch:

but it didn't make it in.  The main objection seemed to be that the
patch tried to do too much, and overlapped with the ME uninitialized
warnings.  Since the patch used walk_tree without any data flow info,
it issued false positives for things like a(0 ? b : 42) and similar.

I'll admit I've been dreading resurrecting this because of the lack
of clarity about where we should warn about what.  On the other hand,
I think we really should do something about this.  So I've simplified
the original patch as much as it seemed reasonable.  For instance, it
doesn't even attempt to handle cases like "a((b = 42)), c(b)" -- for
these I simply give up for the whole mem-initializer (but who writes
code like that, anyway?).  I also give up when a member is initialized
with a function call, because we don't know what the call could do.
See Wuninitialized-17.C, for which clang emits a false positive but
we don't.  I remember having a hard time dealing with initializer lists
in my previous patch, so now I only handle simple a{b} cases, but no
more.  It turned out that this abridged version still warns about 90%
cases where users would expect a warning.

More complicated cases are left for the ME, which, for unused inline
functions, will only warn with -fkeep-inline-functions, but so be it.
(This is bug 21678.)

This patch implements the long-desired -Wuninitialized warning for
member initializer lists, so that the front end can detect bugs like

  struct A {
int a;
int b;
A() : b(1), a(b) { }
  };

where the field 'b' is used uninitialized because the order of member
initializers in the member initializer list is irrelevant; what matters
is the order of declarations in the class definition.

I've implemented this by keeping a hash set holding fields that are not
initialized yet, so at first it will be {a, b}, and after initializing
'a' it will be {b} and so on.  Then I use walk_tree to walk the
initializer and if we see that an uninitialized object is used, we warn.
Of course, when we use the address of the object, we may not warn:

  struct B {
int 
int *p;
int a;
B() : r(a), p(), a(1) { } // ok
  };

Likewise, don't warn in unevaluated contexts such as sizeof.  Classes
without an explicit initializer may still be initialized by their
default constructors; whether or not something is considered initialized
is handled in perform_member_init, see member_initialized_p.

PR c++/19808
PR c++/96121

gcc/cp/ChangeLog:

* init.c (perform_member_init): Remove a forward declaration.
Walk the initializer using find_uninit_fields_r.  New parameter
to track uninitialized fields.  If a member is initialized,
remove it from the hash set.
(perform_target_ctor): Return the initializer.
(struct find_uninit_data): New class.
(find_uninit_fields_r): New function.
(find_uninit_fields): New function.
(emit_mem_initializers): Keep and initialize a set holding fields
that are not initialized.  When handling delegating constructors,
walk the constructor tree using find_uninit_fields_r.  Also when
initializing base clases.  Pass uninitialized down to
perform_member_init.

gcc/ChangeLog:

* doc/invoke.texi: Update documentation for -Wuninitialized.
* tree.c (stabilize_reference): Set location.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wuninitialized-14.C: New test.
* g++.dg/warn/Wuninitialized-15.C: New test.
* g++.dg/warn/Wuninitialized-16.C: New test.
* g++.dg/warn/Wuninitialized-17.C: New test.
* g++.dg/warn/Wuninitialized-18.C: New test.
* g++.dg/warn/Wuninitialized-19.C: New test.
* g++.dg/warn/Wuninitialized-20.C: New test.
* g++.dg/warn/Wuninitialized-21.C: New test.
* g++.dg/warn/Wuninitialized-22.C: New test.
* g++.dg/warn/Wuninitialized-23.C: New test.
* g++.dg/warn/Wuninitialized-24.C: New test.
* g++.dg/warn/Wuninitialized-25.C: New test.
* g++.dg/warn/Wuninitialized-26.C: New test.
* g++.dg/warn/Wuninitialized-27.C: New test.
  

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

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

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

--- Comment #49 from Marek Polacek  ---
Patch resurrected for GCC 12:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583544.html

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

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

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

Marek Polacek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #48 from Marek Polacek  ---
I have a patch that for this:

// PR c++/19808
// { dg-do compile { target c++11 } }
// { dg-options "-Wuninitialized" }

struct S {
  int i, j, k, l;
  S() : i(j), // { dg-warning "field .S::j. is uninitialized when used here" }
j(1),
k(l + 1), // { dg-warning "field .S::l. is uninitialized when used
here" }
l(2) { }
};

struct A {
  int a, b, c;
  A() : a(b // { dg-warning "field .A::b. is uninitialized when used here" }
  + c) { } // { dg-warning "field .A::c. is uninitialized when used
here" }
};

struct B {
  int 
  int *p;
  int a;
  B() : r(a), p(), a(1) { }
};

struct C {
  const int , 
  C () : r1(r2), // { dg-warning "reference .C::r2. is not yet bound to a value
when used here" }
 r2(r1) { }
};

struct D {
  int a = 1;
  int b = 2;
  D() : a(b + 1), b(a + 1) { } // { dg-warning "field .D::b. is uninitialized
when used here" }
};

struct E {
  int a = 1;
  E() : a(a + 1) { } // { dg-warning "field .E::a. is uninitialized when used
here" }
};

struct F {
  int a = 1;
  int b;
  F() : b(a + 1) { }
};

struct bar {
  bar() {}
  bar(bar&) {}
};

class foo {
  bar first;
  bar second;
public:
  foo() : first(second) {} // { dg-warning "field .foo::second. is
uninitialized when used here" }
};

does this:

$ ./cc1plus -quiet  -Wuninitialized  Wuninitialized-12.C
Wuninitialized-12.C: In constructor ‘S::S()’:
Wuninitialized-12.C:7:11: warning: field ‘S::j’ is uninitialized when used here
[-Wuninitialized]
7 |   S() : i(j), // { dg-warning "field .S::j. is uninitialized when used
here" }
  |   ^
Wuninitialized-12.C:9:11: warning: field ‘S::l’ is uninitialized when used here
[-Wuninitialized]
9 | k(l + 1), // { dg-warning "field .S::l. is uninitialized when
used here" }
  |   ^
Wuninitialized-12.C: In constructor ‘A::A()’:
Wuninitialized-12.C:15:11: warning: field ‘A::b’ is uninitialized when used
here [-Wuninitialized]
   15 |   A() : a(b // { dg-warning "field .A::b. is uninitialized when used
here" }
  |   ^
Wuninitialized-12.C:16:13: warning: field ‘A::c’ is uninitialized when used
here [-Wuninitialized]
   16 |   + c) { } // { dg-warning "field .A::c. is uninitialized when
used here" }
  | ^
Wuninitialized-12.C: In constructor ‘C::C()’:
Wuninitialized-12.C:28:13: warning: reference ‘C::r2’ is not yet bound to a
value when used here [-Wuninitialized]
   28 |   C () : r1(r2), // { dg-warning "reference .C::r2. is not yet bound to
a value when used here" }
  | ^~
Wuninitialized-12.C: In constructor ‘D::D()’:
Wuninitialized-12.C:35:11: warning: field ‘D::b’ is uninitialized when used
here [-Wuninitialized]
   35 |   D() : a(b + 1), b(a + 1) { } // { dg-warning "field .D::b. is
uninitialized when used here" }
  |   ^
Wuninitialized-12.C: In constructor ‘E::E()’:
Wuninitialized-12.C:40:11: warning: field ‘E::a’ is uninitialized when used
here [-Wuninitialized]
   40 |   E() : a(a + 1) { } // { dg-warning "field .E::a. is uninitialized
when used here" }
  |   ^
Wuninitialized-12.C: In constructor ‘foo::foo()’:
Wuninitialized-12.C:58:17: warning: field ‘foo::second’ is uninitialized when
used here [-Wuninitialized]
   58 |   foo() : first(second) {} // { dg-warning "field .foo::second. is
uninitialized when used here" }
  | ^~

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||smuccione at agisent dot com

--- Comment #47 from Marek Polacek  ---
*** Bug 97525 has been marked as a duplicate of this bug. ***

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||Hi-Angel at yandex dot ru

--- Comment #46 from Manuel López-Ibáñez  ---
*** Bug 89192 has been marked as a duplicate of this bug. ***

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #45 from Eric Gallager  ---
*** Bug 68301 has been marked as a duplicate of this bug. ***

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[rguenth at gcc dot gnu.org]

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

--- Comment #44 from Richard Biener  ---
(In reply to Jason Merrill from comment #40)
> (In reply to Richard Biener from comment #39)
> > so - how do I make X::X used and thus prevail?  It looks like it doesn't
> > really exist
> 
> True, for C++14 and up, "X x{};" does aggregate initialization rather than
> calling the constructor.  We ought to warn about this at function scope, but
> we clear the object first, so it isn't actually uninitialized.
> 
> As you found, removing the {} makes it use the constructor.
> 
> > OK, doing void foo() { X x; } shows
> > 
> > X::X (struct X * const this)
> > {
> >   _1 = this->x2;
> >   this->x1 = _1;
> >   this->x2 = 0;
> > }
> > 
> > foo ()
> > {
> >   struct X x;
> > 
> >   try
> > {
> >   X::X ();
> > }
> >   finally
> > {
> >   x = {CLOBBER};
> > }
> > }
> > 
> > warning would need inlining of the constructor which only happens after
> > the early warning pass, the late one isn't run at -O0 and with optimization
> > everything of course vanishes.
> 
> I was wondering about a maybe-uninitialized warning for the constructor
> without considering where it's called from; even if a particular object is
> zero-initialized when we enter the implicit constructor, the constructor
> shouldn't rely on that.  Basically, warn as if there were a clobber, without
> there actually being one.

Interesting suggestion but that's IMHO a bit too much information from
the outside to pack into the middle-end code.  That we're dealing with
accesses to *this and that we are inside a constructor.  You'd need to
add that here, tree-ssa-uninit.c:warn_uninitialized_vars

  /* Do not warn if it can be initialized outside this function.
 If we did not reach function entry then we found killing
 clobbers on all paths to entry.  */
  if (fentry_reached
  /* ???  We'd like to use ref_may_alias_global_p but that
 excludes global readonly memory and thus we get bougs
 warnings from p = cond ? "a" : "b" for example.  */
  && (!VAR_P (base)
  || is_global_var (base)))
continue;

given we have to constrain this to must-aliases of *this the easiest
check would be sth like

   && (!eligible-constructor (cfun)
   || TREE_CODE (base) != MEM_REF
   || TREE_OPERAND (base, 0) != default-def-of-this-parm))

and then elide the warning to maybe-uninit.  I guess we now have a flag
whether a function is a constructor and we also can get at the this
parm-decl so in theory "enhancing" the warning this way would be possible.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #43 from Manuel López-Ibáñez  ---
(In reply to Roger Weber from comment #42)
> I posted the latest duplicate of this bug, and I don't know anything about
> how gcc works. I am very grateful for the hard work you guys put into this,
> but just looking at the data. This bug was first reported 13 years ago - and
> I think it's a pretty important one as one can easily make a mistake with
> initialization.

GCC is very large and growing and the number of GCC developers is very very
small and not growing. There are thousands of open bugs, thus developers need
to prioritize. If something was truly pretty important, someone would have
stepped up (or paid someone) to fix it. There is a 60 lines patch that fixes
most of the testcases here and could serve as inspiration to solve the rest.
The person who produced the patch left the work unfinished. Someone needs to
finish it:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

It is a simple as that.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[roger at rankedgaming dot com]

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

--- Comment #42 from Roger Weber  ---
I posted the latest duplicate of this bug, and I don't know anything about how
gcc works. I am very grateful for the hard work you guys put into this, but
just looking at the data. This bug was first reported 13 years ago - and I
think it's a pretty important one as one can easily make a mistake with
initialization.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[lopezibanez at gmail dot com]

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

--- Comment #41 from Manuel López-Ibáñez  ---
All these cases can be handled perfectly by the FE and there's a patch
above.

Why complicate it by expecting the ME to understand C++ mem-initializer
semantics?

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[jason at gcc dot gnu.org]

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

--- Comment #40 from Jason Merrill  ---
(In reply to Richard Biener from comment #39)
> so - how do I make X::X used and thus prevail?  It looks like it doesn't
> really exist

True, for C++14 and up, "X x{};" does aggregate initialization rather than
calling the constructor.  We ought to warn about this at function scope, but we
clear the object first, so it isn't actually uninitialized.

As you found, removing the {} makes it use the constructor.

> OK, doing void foo() { X x; } shows
> 
> X::X (struct X * const this)
> {
>   _1 = this->x2;
>   this->x1 = _1;
>   this->x2 = 0;
> }
> 
> foo ()
> {
>   struct X x;
> 
>   try
> {
>   X::X ();
> }
>   finally
> {
>   x = {CLOBBER};
> }
> }
> 
> warning would need inlining of the constructor which only happens after
> the early warning pass, the late one isn't run at -O0 and with optimization
> everything of course vanishes.

I was wondering about a maybe-uninitialized warning for the constructor without
considering where it's called from; even if a particular object is
zero-initialized when we enter the implicit constructor, the constructor
shouldn't rely on that.  Basically, warn as if there were a clobber, without
there actually being one.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[rguenth at gcc dot gnu.org]

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

--- Comment #39 from Richard Biener  ---
(In reply to Jason Merrill from comment #38)
> (In reply to Jonathan Wakely from comment #37)
> 
> If you add a
> 
> Y y{};
> 
> GCC warns about the Y constructor.
> 
> We don't warn about the implicit X constructor because we don't clobber the
> object at the beginning of an implicit constructor, because
> value-initialization zero-initializes the object before calling the implicit
> constructor, and we mustn't clobber that initialization (bug 68006).  The
> middle end relies on the clobber to know what's uninitialized, so we don't
> get the warning here.
> 
> It would be appropriate to give a maybe-uninitialized warning here, though. 
> I don't know how complicated it would be to do that using the existing
> mechanisms.

These case are difficult because they involve exported globals which GCC
thinks are always initialized.  For the testcase only the initializer
of x prevails, the constructor of y is discarded before we run the
warning machinery.  The initializer of x prevails in
__static_initialization_and_destruction_0 like

  _1 = x.x2;
  x.x1 = _1;

which has the aforementioned issue.  So for a proper testcase we need
calls to the constructors (where we should warn in?) and the constructors
prevail.

Adding

Y y{};

makes Y::Y prevail and as you said we warn about it.  IL:

Y::Y (struct Y * const this)
{
  int _1;

   :
  MEM[(struct  &)this_3(D)] ={v} {CLOBBER};
  _1 = this_3(D)->y2;
  this_3(D)->y1 = _1;
  this_3(D)->y2 = 0;
  return;


so - how do I make X::X used and thus prevail?  It looks like it doesn't
really exist and the C++ FE even for

void foo() { X x{}; }

just outputs

;; Function void foo() (null)
;; enabled by -tree-original


{
  struct X x = {.x2=0};

  <>;
  <;
}

which ends up as

foo ()
{
  struct X x;

  try
{
  x = {};
  _1 = x.x2;
  x.x1 = _1;
}
  finally
{
  x = {CLOBBER};
}
}

so there is no uninitialized use.

OK, doing void foo() { X x; } shows

X::X (struct X * const this)
{
  _1 = this->x2;
  this->x1 = _1;
  this->x2 = 0;
}

foo ()
{
  struct X x;

  try
{
  X::X ();
}
  finally
{
  x = {CLOBBER};
}
}

warning would need inlining of the constructor which only happens after
the early warning pass, the late one isn't run at -O0 and with optimization
everything of course vanishes.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #38 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #37)

If you add a

Y y{};

GCC warns about the Y constructor.

We don't warn about the implicit X constructor because we don't clobber the
object at the beginning of an implicit constructor, because
value-initialization zero-initializes the object before calling the implicit
constructor, and we mustn't clobber that initialization (bug 68006).  The
middle end relies on the clobber to know what's uninitialized, so we don't get
the warning here.

It would be appropriate to give a maybe-uninitialized warning here, though.  I
don't know how complicated it would be to do that using the existing
mechanisms.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[redi at gcc dot gnu.org]

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

--- Comment #37 from Jonathan Wakely  ---
N.B. we should also warn using uninitialized members in default member
initializers, e.g. both of these should produce a warning:

struct X {
  int x1 = x2;
  int x2 = 0;
};

X x{};  // causes definition of default constructor

struct Y {
  int y1 = y2;
  int y2;
  Y() : y2(0) { }
};

Clang warns about both:

defmeminit.cc:2:12: warning: field 'x2' is uninitialized when used here
[-Wuninitialized]
  int x1 = x2;
   ^
defmeminit.cc:6:3: note: in implicit default constructor for 'X' first required
here
X x{};
  ^
defmeminit.cc:1:8: note: during field initialization in the implicit default
constructor
struct X {
   ^
defmeminit.cc:9:12: warning: field 'y2' is uninitialized when used here
[-Wuninitialized]
  int y1 = y2;
   ^
defmeminit.cc:11:3: note: during field initialization in this constructor
  Y() : y2(0) { }
  ^
2 warnings generated.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||roger at rankedgaming dot com

--- Comment #36 from Jonathan Wakely  ---
*** Bug 85691 has been marked as a duplicate of this bug. ***

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||s-beyer at gmx dot net

--- Comment #35 from Manuel López-Ibáñez  ---
*** Bug 82552 has been marked as a duplicate of this bug. ***

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[manu at gcc dot gnu.org]

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

--- Comment #34 from Manuel López-Ibáñez  ---
(In reply to Richard Biener from comment #33)
> I have a fix for PR2972 and it also correctly handles this case so why is it
> "conceptually different"?

Because to detect uninitialized member usage in member initializer list one
only needs to traverse the member initializer list and keep track of what has
been initialized so far, so there is no need for ME support and there is no
room for false positives/negatives and location info can be perfect.

My understanding is that the consensus has always been to warn in the FE and
avoid ME warnings as much as possible because they tend to be less reliable.
But if you have a patch that works as well as the FE warning, then that is
excellent and I'm happy to see both bugs fixed in one stroke.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[rguenth at gcc dot gnu.org]

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

--- Comment #33 from Richard Biener  ---
(In reply to Manuel López-Ibáñez from comment #32)
> (In reply to Richard Biener from comment #31)
> > This is really a dup of PR2972.
> > 
> > *** This bug has been marked as a duplicate of bug 2972 ***
> 
> No, it is  not. The difference is explained by Jason in comment #22 and the
> existing bug by me in comment #23.
> 
> There is not only a conceptual difference but a difference in difficulty.
> This bug can be solved entirely by the C++ FE (and this is what the patch in
> comment #29 does) while PR2972 needs middle-end support.

I have a fix for PR2972 and it also correctly handles this case so why is it
"conceptually different"?

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|DUPLICATE   |---

--- Comment #32 from Manuel López-Ibáñez  ---
(In reply to Richard Biener from comment #31)
> This is really a dup of PR2972.
> 
> *** This bug has been marked as a duplicate of bug 2972 ***

No, it is  not. The difference is explained by Jason in comment #22 and the
existing bug by me in comment #23.

There is not only a conceptual difference but a difference in difficulty. This
bug can be solved entirely by the C++ FE (and this is what the patch in comment
#29 does) while PR2972 needs middle-end support.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #31 from Richard Biener  ---
This is really a dup of PR2972.

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

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||matt at godbolt dot org

--- Comment #30 from Manuel López-Ibáñez  ---
*** Bug 70647 has been marked as a duplicate of this bug. ***

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[anthony.brandon at gmail dot com]

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

Anthony Brandon  changed:

   What|Removed |Added

  Attachment #36706|0   |1
is obsolete||

--- Comment #29 from Anthony Brandon  ---
Created attachment 36851
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36851=edit
Updated patch for PR19808.

I updated my patch to include a testcase, and I also fixed the case for
anonymous unions.
Things not working right (as far as i know) in this patch yet are:
* references
* pointers
* multiple uninitialized values being used to initialize a single field. (I'm
also not sure how to test for this in the testsuite)

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[manu at gcc dot gnu.org]

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

--- Comment #28 from Manuel López-Ibáñez  ---
Hi Anthony, adding testcases to the patch will help clarify what is working and
what you expect to work but it isn't:
https://gcc.gnu.org/wiki/HowToPrepareATestcase

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[anthony.brandon at gmail dot com]

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

--- Comment #27 from Anthony Brandon  ---
Created attachment 36706
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36706=edit
First version of patch for PR19808

This is the current version of my patch.
It still needs some work.
The Wuninitialized part should be combined with the Winit_self part,
and it should be made to detect multiple uninitialized values in a single
initializer.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez manu at gcc dot gnu.org changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #26 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
*** Bug 65301 has been marked as a duplicate of this bug. ***

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[anthony.brandon at gmail dot com]

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

--- Comment #25 from Anthony Brandon anthony.brandon at gmail dot com ---
Never mind the second question, I found walk_tree.

[Bug c++/19808] miss a warning about uninitialized member usage in member initializer list in constructor

[anthony.brandon at gmail dot com]

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

Anthony Brandon anthony.brandon at gmail dot com changed:

   What|Removed |Added

 CC||anthony.brandon at gmail dot 
com

--- Comment #24 from Anthony Brandon anthony.brandon at gmail dot com ---
Hi,

 It could be done specifically for uses in mem-initializers by walking the
 initializer in perform_mem_init to look for any references to members that
 haven't been marked yet.

I've been working on this using this approach.
At the moment I can detect and give a warning for something like:

struct S 
{ 
int i, j; 
S() : i(j), j(1) {} 
}; 

However it doesn't cover cases like i(j+1), and in the case of i(i) there would
currently be two warnings (due to -Winit-self).
Lastly, the warning is given like so:
a.cpp:8:2: warning: ‘S::i’ is initialized with uninitialized field ‘S::j’
[-Wuninitialized]
  S() : i(j), j(b) {}
  ^

So I have a couple of questions:
* How to get the right location for the mark. In other words:
  S() : i(j), j(b) {}
  ^
* Is there a function to traverse a tree structure looking for a particular
tree (or some other way to get things like i(j+1) to work)?

* Should this give a warning in the case of i(i)?