https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110000
--- Comment #13 from Louis Dionne <ldionne.2 at gmail dot com> ---
Nikolas already answered some, but just to expand on this:
> But on the topic of this enhancement request, I don't see why functions
> should be excluded from explicit instantiation if they're already abi-tagged.
> Do you want to be able to change these functions in ABI-incompatible ways
> between major revisions of the library?
What we're trying to avoid here is that if a user has an explicit instantiation
*declaration*, we don't want their code to start depending on the fact that
some-implementation-detail-member-function exists in the class. So for example,
if we have:
template <class T>
class vector {
public:
iterator begin() { ... }
iterator end() { ... }
void __push_back_helper(T const&) { ... }
};
If the user has something like this in their code:
extern template class vector<Foo>;
The compiler will then assume that the following methods are defined elsewhere
(presumably where the explicit instantiation actually happens):
iterator vector<Foo>::begin();
iterator vector<Foo>::end();
void vector<Foo>::__push_back_helper(Foo const&);
Whether those methods are ABI-tagged or not doesn't matter, the compiler will
still emit code that contains external references to those methods. That's fine
if we're OK with committing to these methods in the long term, but if we want
to keep the flexibility of removing or changing these methods in arbitrary
ways, what we really want here is for the compiler not to assume that the
explicit instantiation includes these methods, and instead emit its own
linkonce_odr copy in the TU (which then gets deduplicated across TUs in case
the same function was defined elsewher too).
Does this make sense?
Regarding ABI tags, like Nikolas explained, the idea is that in most cases,
users actually have a single version of libc++ in their whole program, so all
the symbols from libc++ have the same ABI tag, and the linker will deduplicate
everything. In case a users happens to mix versions of libc++ in different TUs,
then the right thing will happen: functions with different ABI tags won't be
deduplicated as-if they were token-for-token equivalent and only the functions
that don't have an ABI tag will be deduplicated cause they're the same across
all TUs (but we do commit to stability for those symbols).
