From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9AA703857034; Thu, 1 Jun 2023 18:00:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9AA703857034 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1685642420; bh=39f+7XZsfrxWx9KYntaSLt9AHjLW4ZXm54lxedYGUu8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=siwPqSDAxP9cbQn1bOo5UCdOX/YKizj49kD8qJ9RWGyuZA0oFKXiBPhOdVM4dZVku BKj7J7KQMpdmsHCUVZsNsdXPUX1o/5lhG992ukyshrG8dTjPIPNfJeqW7aUd97eon1 VaViqAUpFbf6CnIpjVPXhd2NlMpEcDqzMxBilTcQ= From: "ldionne.2 at gmail dot com" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ldionne.2 at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110000 --- Comment #13 from Louis Dionne --- Nikolas already answered some, but just to expand on this: > But on the topic of this enhancement request, I don't see why functions s= hould 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 instantia= tion *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 exam= ple, if we have: template 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; The compiler will then assume that the following methods are defined elsewh= ere (presumably where the explicit instantiation actually happens): iterator vector::begin(); iterator vector::end(); void vector::__push_back_helper(Foo const&); Whether those methods are ABI-tagged or not doesn't matter, the compiler wi= ll 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 wa= nt 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 a= ll the symbols from libc++ have the same ABI tag, and the linker will deduplic= ate 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 functi= ons that don't have an ABI tag will be deduplicated cause they're the same acro= ss all TUs (but we do commit to stability for those symbols).=