On Thu, 11 Apr 2024 at 20:22, Jonathan Wakely <jwak...@redhat.com> wrote: > > I'm considering this late patch for gcc-14 to workaround an issue > discovered by a recent Clang change. > > I'm not yet sure if Clang is right to require these symbols. It's not > really clear, because always_inline isn't part of the standard so it's > not clear how it should interact with explicit instantiations and > modules. Exporting these four extra symbols doesn't hurt, even if Clang > ends up reverting or revising its change that requires them. > > Another way to fix it would be to suppress the explicit instantiation > declarations in <bits/allocator.h> for C++20, so that the compiler > always instantiates them implicitly as needed. We do similar things for > the explicit instantiations of std::string etc. so that new member > functions that aren't in the .so are implicitly instantiated as needed. > > That would look like this instead: > > --- a/libstdc++-v3/include/bits/allocator.h > +++ b/libstdc++-v3/include/bits/allocator.h > @@ -281,7 +281,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > > // Inhibit implicit instantiations for required instantiations, > // which are defined via explicit instantiations elsewhere. > -#if _GLIBCXX_EXTERN_TEMPLATE > +#if _GLIBCXX_EXTERN_TEMPLATE && __cplusplus <= 201703L > extern template class allocator<char>; > extern template class allocator<wchar_t>; > #endif > > But we might want to export the new functions from the library > eventually anyway, so doing it now (before Clang 19 is released) might > be the best option. > > Thoughts?
I think the symbol export is a fine solution. Both of these solutions work, so I don't have a strong preference, I have a minor preference for not suppressing explicit instantiations that are otherwise already there, but that is indeed not a strong preference.
