https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123810
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Nathan, any ideas about this?
Previously (and with the patch without -freflection) in cases like that
typedef struct { int m; } M;
struct S { M m; };
or
struct T { typedef struct { int m; } M; };
there is one TYPE_DECL with IDENTIFIER_ANON_P (DECL_NAME (decl)) whose
TREE_TYPE (decl) has as TYPE_NAME another TYPE_DECL with normal IDENTIFIER_NODE
M DECL_NAME.
I think modules.cc streams the latter TYPE_DECL as MK_named and the former as
MK_field (in the T case) or MK_unique (or for unscoped enums as MK_enum).
Now, with -freflection this changes with the patch, instead there are two
TYPE_DECLs with the same DECL_NAME (decl) (IDENTIFIER_NODE M), both have
TYPE_DECL_FOR_LINKAGE_PURPOSES_P flag set, the first one has also
DECL_IMPLICIT_TYPEDEF_P flag set and its TREE_TYPE is the formerly unnamed
record/union/enum type and then one without DECL_IMPLICIT_TYPEDEF_P with
TREE_TYPE which has DECL_ORIGINAL_TYPE pointing to the first type.
Right now I think both are streamed as MK_named, dunno if already the stream
out code is partly upset that there are two entities with the same name in the
same context (but isn't that normally the case e.g. for placeholder names?
struct U { int _, _, _; long _, _, _; }; ?
Anyway, the error comes during streaming in.
Do you think the TYPE_DECL_NAMED_FOR_LINKAGE_PURPOSES_P TYPE_DECLs should be
merged using say some new MK_something kind?
In any cases, those TYPE_DECLs are meant to be ignored during name lookup.
