public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ldionne.2 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/110000] GCC should implement exclude_from_explicit_instantiation
Date: Thu, 01 Jun 2023 18:00:17 +0000	[thread overview]
Message-ID: <bug-110000-4-W4Vz8HtyIi@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-110000-4@http.gcc.gnu.org/bugzilla/>

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).

      parent reply	other threads:[~2023-06-01 18:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-26 20:25 [Bug c++/110000] New: " nikolasklauser at berlin dot de
2023-05-26 20:31 ` [Bug c++/110000] " ldionne.2 at gmail dot com
2023-05-26 20:33 ` pinskia at gcc dot gnu.org
2023-05-26 20:35 ` pinskia at gcc dot gnu.org
2023-05-26 20:42 ` nikolasklauser at berlin dot de
2023-05-27 10:39 ` fw at gcc dot gnu.org
2023-05-27 23:40 ` nikolasklauser at berlin dot de
2023-05-28  6:13 ` fw at gcc dot gnu.org
2023-05-28 14:31 ` nikolasklauser at berlin dot de
2023-05-31 15:40 ` ldionne.2 at gmail dot com
2023-05-31 16:48 ` redi at gcc dot gnu.org
2023-05-31 16:52 ` redi at gcc dot gnu.org
2023-05-31 17:33 ` nikolasklauser at berlin dot de
2023-06-01 18:00 ` ldionne.2 at gmail dot com [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-110000-4-W4Vz8HtyIi@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).