public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/110000] GCC should implement exclude_from_explicit_instantiation Date: Wed, 31 May 2023 16:48:22 +0000 [thread overview] Message-ID: <bug-110000-4-Dbhte6SEuY@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 Jonathan Wakely <redi at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement --- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> --- Using always_inline on everything is simply wrong: GCC will refuse to inline some functions and the user gets an error that they cannot avoid. There's no command-line option or pragma that can be used to compile the code anyway, it's just un-compilable. I don't really understand the aim here. You're trying to avoid the user's program ever containing a symbol generated from any libc++ code? So that they can't ever have a dependency on those symbols, and the definitions can change? Honestly, the cure seems worse than the disease. Just because code is inlined, it doesn't mean it's immune from ABI incompatibilities (it avoids some kinds of problems, but doesn't help with others). And if all libc++ functions have an abi_tag courtesy of the HIDE_FROM_ABI macro, why does it matter whether explicit instantiations include them anyway? Your include/__config says: The symbol is given an ABI tag that changes with each version of libc++. This ensures that no ODR violation can arise from mixing two TUs compiled with different versions of libc++ where we would have changed the definition of a symbol. If the symbols shared the same name, the ODR would require that their definitions be token-by-token equivalent, which basically prevents us from being able to make any change to any function in our headers. Again, the cure seems worse than the disease. Your compiler and/or linker and/or dynamic loader can define what happens here, so the ODR violation doesn't lead to nasal demons. If your definitions are not token-by-token identical then what happens in practice is that you get two definitions emitted in different TUs and the linker picks one. There's no actual UB here. Applying this to every single function in the library just in case you want to change it some day seems like major overkill. 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?
next prev parent reply other threads:[~2023-05-31 16:48 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 [this message] 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
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-Dbhte6SEuY@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: linkBe 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).