On Thu, Feb 22, 2024 at 08:34:45AM +0000, Jason Merrill wrote: > On 2/20/24 19:15, Marek Polacek wrote: > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > This PR asks that our -Wuninitialized for mem-initializers does > > not warn when binding a reference to an uninitialized data member. > > We already check !INDIRECT_TYPE_P in find_uninit_fields_r, but > > that won't catch binding a parameter of a reference type to an > > uninitialized field, as in: > > > > struct S { S (int&); }; > > struct T { > > T() : s(i) {} > > S s; > > int i; > > }; > > > > This patch adds a new function to handle this case. > > For type_build_ctor_call types like S, it's weird that we currently > find_uninit_fields before building the initialization. What if we move the > check after the build_aggr_init so we have the actual initializer instead of > just the expression?
Thanks. I've tried but unfortunately I'm not getting anywhere. One problem is that immediately after the find_uninit_fields call we may change the TREE_LIST in if (init && TREE_CODE (init) == TREE_LIST) //... so we'd have to cope with that somehow. Sinking find_uninit_fields into one of the conditions below looks like a complication. Another problem is that calling find_uninit_fields on the result of build_aggr_init call causes a bogus warning: we create something like E::E (&((struct F *) this)->e, ((struct F *) this)->a) and then warn that the this object is uninitialized. So I'm not sure if that fix would be simpler. Marek