[Bug c++/80534] [7/8 Regression] 7.1 RC - internal compiler error: in finish_member_declaration, at cp/semantics.c:2963

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80534

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm afraid I have absolutely no idea what is going on and why my patch would
change anything on that.
What I see is that instantiate_class_template self-recurses:
#0  instantiate_class_template_1 (type=<record_type 0x7fffefc4ebd0 B>) at
../../gcc/cp/pt.c:10217
#1  0x0000000000821901 in instantiate_class_template (type=<record_type
0x7fffefc4ebd0 B>) at ../../gcc/cp/pt.c:10798
#2  0x0000000000948dcd in complete_type (type=<record_type 0x7fffefc4ebd0 B>)
at ../../gcc/cp/typeck.c:133
#3  0x00000000009a5cf1 in lookup_member (xbasetype=<tree 0x0>,
name=<identifier_node 0x7fffefc48a80 B>, protect=2, want_type=true, complain=3)
    at ../../gcc/cp/search.c:1274
#4  0x0000000000a2ec79 in get_class_binding (name=<identifier_node
0x7fffefc48a80 B>, scope=0x7fffefade3f0) at ../../gcc/cp/name-lookup.c:3135
#5  0x0000000000a2f40b in push_class_level_binding_1 (name=<identifier_node
0x7fffefc48a80 B>, x=<type_decl 0x7fffefc54098 B>)
    at ../../gcc/cp/name-lookup.c:3263
#6  0x0000000000a2f92a in push_class_level_binding (name=<identifier_node
0x7fffefc48a80 B>, x=<type_decl 0x7fffefc54098 B>)
    at ../../gcc/cp/name-lookup.c:3369
#7  0x0000000000a2e9b0 in pushdecl_class_level (x=<type_decl 0x7fffefc54098 B>)
at ../../gcc/cp/name-lookup.c:3094
#8  0x00000000009b65af in finish_member_declaration (decl=<type_decl
0x7fffefc54098 B>) at ../../gcc/cp/semantics.c:3023
#9  0x0000000000820ca5 in instantiate_class_template_1 (type=<record_type
0x7fffefc4ebd0 B>) at ../../gcc/cp/pt.c:10581
#10 0x0000000000821901 in instantiate_class_template (type=<record_type
0x7fffefc4ebd0 B>) at ../../gcc/cp/pt.c:10798
#11 0x0000000000948dcd in complete_type (type=<record_type 0x7fffefc4ec78
StorageUniquePointer>) at ../../gcc/cp/typeck.c:133

See how it is called on the same 0x7fffefc4ebd0 B and that the first time it is
processing the B TYPE_DECL there is indeed no DECL_CHAIN, but the second time
it does that there already is one, because
r = tsubst (t, args, tf_warning_or_error, NULL_TREE);
returns the already existing TYPE_DECL that is part of the chain.

Jason, could you please have a look?  Thanks.