https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102228
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> I think there must be also a 1:1 correspondence to anon type and its single
> use FIELD_DECL thus building a back-chain via DECL_CONTEXT and a new
> ANON_AGGR_TYPE_FIELD should be possible.
>
> At least I failed to do sth like
>
> typedef struct { int i; } T;
> struct X {
> T;
> };
> struct Y {
> T;
> };
>
> aka use the same aggregate type anonymously from two contexts.
I (fool) proofed this with
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 8b78e89ce3a..16156e428be 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -136,6 +136,7 @@ struct GTY(()) deferred_access {
/* Data for deferred access checking. */
static GTY(()) vec<deferred_access, va_gc> *deferred_access_stack;
static GTY(()) unsigned deferred_access_no_check;
+static GTY(()) hash_map<tree, tree> *anon_aggr_field;
/* Save the current deferred access states and start deferred
access checking iff DEFER_P is true. */
@@ -3489,6 +3490,15 @@ finish_member_declaration (tree decl)
if (TREE_CODE (decl) != CONST_DECL)
DECL_CONTEXT (decl) = current_class_type;
+ if (TREE_CODE (decl) == FIELD_DECL
+ && ANON_AGGR_TYPE_P (TREE_TYPE (decl)))
+ {
+ if (!anon_aggr_field)
+ anon_aggr_field = hash_map<tree, tree>::create_ggc ();
+ if (anon_aggr_field->put (TREE_TYPE (decl), decl))
+ gcc_unreachable ();
+ }
+
if (TREE_CODE (decl) == USING_DECL)
/* For now, ignore class-scope USING_DECLS, so that debugging
backends do not see them. */
if you think the 1:1 relationship is sound then I can try finding an
unused field in lang_type to record the FIELD_DECL used for an
ANON_AGGR_TYPE_P. I guess any of the method/inheritance related
members could be re-purposed (typeinfo_var for example, accesses are
in suitably special places that shouldn't show up for ANON_AGGR_TYPE_P)
I did wonder if we'll have different FIELD_DECLs for as-base or other
weird record variants that somehow get automatically generated as
copies from the same type (and where the FIELD_DECL would be at different
offset). But at least test coverage showed up
nothing... and I don't know enough C++ to think of how to provoke it
to break.
So, mine if proceeding with adding a ANON_AGGR_TYPE_FIELD mapping to
lang_type->typeinfo_var and setting it in finish_member_declaration
plus ditching lookup_anon_field is OK.
Jason?
