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

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