dblaikie added a comment.
Yeah, this is working around a more fundamental representational issue.
Like member function templates, member variable templates shouldn't be
pre-emptively built or ever appear in the "members" list of the type (because
that list isn't closed - we don't know what instantiations would be needed when
the type is built so member template instantiations never appear in the member
list, but instead the type appears as the scope of the member template
instantiation and are added as member DIEs during DWARF emission lazily (eg: if
a member function template instantiation gets optimized away, nothing of it
remains and no member function template declaration of that instantiation will
appear in as a child of the type DIE))
For instance, it seems creating two instantiations of a member variable
template seems to get messed up by having a member list with the same
instantiation twice:
!9 = !DIDerivedType(tag: DW_TAG_member, name: "variable", scope: !10, file:
!3, line: 3, baseType: !12, flags: DIFlagStaticMember, extraData: i32 0)
!10 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "type",
file: !3, line: 1, size: 8, flags: DIFlagTypePassByValue, elements: !11,
identifier: "_ZTS4type")
!11 = !{!9, !9}
Even though !7 is another member variable template instantiation.
(here's the source:
struct type {
template <typename T>
inline static auto variable = T();
};
int main() {
type t;
int i = type::variable<int>;
float f = type::variable<float>;
}
So clearly something is modifying the "members" list (since it'd be created
empty after the "type t;" line, then a member variable template for the
variable<int> would be added to the member list, then when it goes to add
"variable<float>" it gets messed up and adds another copy of !9)
Oh... both variable<int> and variable<float> definitions share a single
declaration DIDerivedType... that's no good.
I'm also generally wondering if variable template instantiations should have
the template parameters in their name, same as function templates - currently
they don't in LLVM's output at least. Building GCC 9.2 to compare there.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D70537/new/
https://reviews.llvm.org/D70537
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
