> On 11 Apr 2024, at 18:33, Ville Voutilainen <ville.voutilai...@gmail.com>
> wrote:
>
> 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.
I think clang-19 will branch after gcc-14 (so the urgency is more on the GCC
side - or making a decision to back out of the clang change.
>>
>> 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.
In the case of interaction between modules and items not identified in
the std, the only solution is to get agreement between the ‘vendors’.
If we emit the symbols, then that gets baked into the libstdc++ ABI, right?
Is there an alternate solution that we can propose? (there is a modules
implementer’s group that meets bi-weekly, including next Tuesday -
this includes representation from GCC, clang, MSVC and usually some
of the larger players like google… it could be a topic of discussion if
there is some tidier proposal we could make.
Iain
