On 2/22/24 14:28, Marek Polacek wrote:
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.
Fair enough, the patch is OK.
Jason
