You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Clang fails and emits these with local linkage and non-standard mangling (if they are actually internal, that'd be fine)
GCC emits these names without using the member name in the mangling and a numbering that's not local to the member, or even local to the type (similar names in subsequent classes get numberings that differ depending on the previous class - despite the class name in the mangling) https://godbolt.org/z/7514cTh5o
struct A {
static constexpr auto x = [] {
return 1;
};
};
template <typename>
struct B {
static constexpr auto x = [] {
return 1;
};
};
template <typename T>
struct C {
static int x;
};
void side_effect();
template <typename T>
int C<T>::x = (side_effect(), [] { return 1; }());
template int C<int>::x;
void f() {
A::x();
B<int>::x();
}
I think both GCC and Clang gets C right, Clang gets B right (& GCC gets it wrong) and both Clang and GCC get A wrong for different reasons. (and it should be like Clang's B behavior).
The ABI already mostly covers this: we require a lambda to be numbered within the scope of the enclosing variable if the variable is inline or a variable template, but we missed the case where it's a non-inline static data member, eg:
template<typename T> int print_hello = (std::cout << "hello\n", 0);
structX {
// Should only print hello once, regardless of how many TUs this appears in.staticconstintptr_t n = (print_hello<decltype([]{})>, 0);
};
Clang fails and emits these with local linkage and non-standard mangling (if they are actually internal, that'd be fine)
GCC emits these names without using the member name in the mangling and a numbering that's not local to the member, or even local to the type (similar names in subsequent classes get numberings that differ depending on the previous class - despite the class name in the mangling)
https://godbolt.org/z/7514cTh5o
GCC produces these manglings:
Clang produces these manglings:
I think both GCC and Clang gets C right, Clang gets B right (& GCC gets it wrong) and both Clang and GCC get A wrong for different reasons. (and it should be like Clang's B behavior).
This is discussed in Clang (llvm/llvm-project#58819) and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107741)
The text was updated successfully, but these errors were encountered: