https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91343
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
CC| |jason at gcc dot gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The reason we are warning is a C++ FE one - the C++ FE emits the warning during
the parsing of func() at which point it has not yet placed a field for 'Parent'
in Child.
But for some reason it _did_ lay out the type already (TYPE_SIZE is zero,
not NULL_TREE).
This also causes wrong-code since we set TYPE_ALIAS_SET too early and
fail to record all subsets.
OK, it doesn't call layout_type but
Old value = <tree 0x0>
New value = <integer_cst 0x2aaaac0a1f00>
finish_struct (t=<record_type 0x2aaaac2063f0 Child>, attributes=<tree 0x0>)
at /space/rguenther/src/gcc/gcc/cp/class.c:7456
7456 TYPE_SIZE_UNIT (t) = size_zero_node;
(gdb) l
7451 DECL_ARTIFICIAL (ass_op) = true;
7452 DECL_CHAIN (ass_op) = TYPE_FIELDS (t);
7453 TYPE_FIELDS (t) = ass_op;
7454
7455 TYPE_SIZE (t) = bitsize_zero_node;
7456 TYPE_SIZE_UNIT (t) = size_zero_node;
7457 /* COMPLETE_TYPE_P is now true. */
and that size is never changed. Guess that's because it's a template.
Maybe we should fend off this diagnostic based on processing_template_decl?
We don't warn when it's not a template and the explicit instantiation
isn't necessary. The function in question is static but 'Child'
in this context is dependent? (does it inherit the template param? I guess
so?)
Anyhow, a fix could be put, for example, in C++ get_alias_set langhook
as well. Not sure if we ever end up calling get_alias_set on a type
that isn't complete but was marked as such like
struct Foo {
int i;
void bar() { Foo *p; *p; }
float j;
};
as said this can result in bougs alias-set subset representation.
C++ FE folks, please have a look.
