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 libstdc++/99058] Consider adding a note about std::optional ABI break to the C++17 status table Date: Wed, 10 Feb 2021 21:58:32 +0000 [thread overview] Message-ID: <bug-99058-4-CQKZgK0WM9@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99058-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058 --- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Brad Spencer from comment #3) > Ok. What's the right way for me to learn what version of GCC has stable > support for a C++ version? The release notes: https://gcc.gnu.org/gcc-9/changes.html#libstdcxx > I am under the (possibly mistaken) impression that the libstdc++ ABI (in a > given configuration) has been stable for a very long time, and that > generally integrators (such as Debian or Ubuntu, for example) provide > versions of libstdc++ that are ABI-compatible with code compiled against > previous versions. The shared library ABI is stable. There are no std::optional symbols in the shared library, so changes to std::optional do not affect the ABI of the shared library (only of user code compiled using the libstdc++ headers). > As per https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html this is > reflected in the long-standing .so major version of 6. I know there are > many caveats here, especially around the early introduction of > pre-standardized features, etc. Right, like std::optional. What matters is not whether the features has been standardized but whether it's considered stable in GCC. The features don't suddenly become complete and stable on the day that ISO publishes the next standard. > Is it correct to think that the _intention_ is that it is possible to > configure the library to remain ABI compatible into the future until a > conscious decision is made to introduce an ABI break? Only for parts of the library that are not considered experimental. Support for C++17 in GCC 7 and 8 is experimental, as noted in the release notes: https://gcc.gnu.org/gcc-7/changes.html#libstdcxx https://gcc.gnu.org/gcc-8/changes.html#libstdcxx It is declared no longer experimental in GCC 9: https://gcc.gnu.org/gcc-9/changes.html#libstdcxx If you use experimental pieces (like C++17 support in GCC 8, or C++20 support in GCC 10) then you are giving up the expectation of ABI stability between releases. https://stackoverflow.com/questions/46746878/is-it-safe-to-link-c17-c14-and-c11-objects/49119902#49119902
next prev parent reply other threads:[~2021-02-10 21:58 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-10 13:07 [Bug libstdc++/99058] New: " bspencer at blackberry dot com 2021-02-10 18:49 ` [Bug libstdc++/99058] " redi at gcc dot gnu.org 2021-02-10 18:49 ` redi at gcc dot gnu.org 2021-02-10 19:44 ` bspencer at blackberry dot com 2021-02-10 21:58 ` redi at gcc dot gnu.org [this message] 2021-02-10 22:06 ` redi at gcc dot gnu.org 2021-02-10 22:17 ` redi at gcc dot gnu.org 2021-02-10 22:19 ` redi at gcc dot gnu.org 2021-02-11 13:45 ` bspencer at blackberry dot com 2021-02-11 17:28 ` cvs-commit at gcc dot gnu.org 2021-02-12 14:49 ` redi at gcc dot gnu.org 2021-03-29 20:02 ` cvs-commit at gcc dot gnu.org 2021-04-19 9:05 ` cvs-commit at gcc dot gnu.org 2021-04-19 9:08 ` cvs-commit at gcc dot gnu.org 2021-04-19 9:08 ` redi at gcc dot gnu.org
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-99058-4-CQKZgK0WM9@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).