From: "François Dumont" <frs.dumont@gmail.com>
To: Jonathan Wakely <jwakely.gcc@gmail.com>,
Iain Sandoe <idsandoe@googlemail.com>
Cc: libstdc++ <libstdc++@gcc.gnu.org>, GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: Fix gnu versioned namespace mode 00/03
Date: Wed, 15 May 2024 19:37:58 +0200 [thread overview]
Message-ID: <4d7ac2a8-b0e5-419e-b81d-7bb8d1b4c8e5@gmail.com> (raw)
In-Reply-To: <CAH6eHdT5prCdoezPTRJeEb0dRmwi3bRsmjqWGRt9vcUv=9f63Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3930 bytes --]
On 13/05/2024 10:34, Jonathan Wakely wrote:
>
>
> On Mon, 13 May 2024, 07:30 Iain Sandoe, <idsandoe@googlemail.com> wrote:
>
>
>
> > On 13 May 2024, at 06:06, François Dumont <frs.dumont@gmail.com>
> wrote:
> >
> >
> > On 07/05/2024 18:15, Iain Sandoe wrote:
> >> Hi François
> >>
> >>> On 4 May 2024, at 22:11, François Dumont
> <frs.dumont@gmail.com> wrote:
> >>>
> >>> Here is the list of patches to restore gnu versioned namespace
> mode.
> >>>
> >>> 1/3: Bump gnu version namespace
> >>>
> >>> This is important to be done first so that once build of gnu
> versioned namespace is fixed there is no chance to have another
> build of '__8' version with a different abi than last successful
> '__8' build.
>
>
>
> The versioned namespace build is not expected to be ABI compatible
> though, so nobody should be expecting compatibility with previous
> builds. Especially not on the gcc-15 trunk, a week or two after
> entering stage 1!
Ok, I really thought that we needed to preserve ABI for a given version,
'__8' at the moment.
> >>>
> >>> 2/3: Fix build using cxx11 abi for versioned namespace
> >>>
> >>> 3/3: Proposal to default to "new" abi when dual abi is
> disabled and accept any default-libstdcxx-abi either dual abi is
> enabled or not.
> >>>
> >>> All testsuite run for following configs:
> >>>
> >>> - dual abi
> >>>
> >>> - gcc4-compatible only abi
> >>>
> >>> - new only abi
> >>>
> >>> - versioned namespace abi
> >> At the risk of delaying this (a bit) - I think we should also
> consider items like once_call that have broken impls.
> > Do you have any pointer to this once_call problem, sorry I'm not
> aware about it (apart from your messages).
>
> (although this mentions one specific target, it applies more widely).
>
>
> I've removed the "on ppc64le" part from the summary.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
>
Thanks for the ref, I'll have a look but I fear that I won't be of any
help here.
>
> Also, AFAICT, any nested once_call is a problem (not just exceptions).
>
>
> Could you update the bug with that info please?
>
>
> >> in the current library - and at least get proposed
> replacements available behind the versioned namespace; rather than
> using up a namespace version with the current broken code.
> >
> > I'm not proposing to fix all library bugs on all platforms with
> this patch, just fix the versioned namespace mode.
>
> Sorry, I was not intending to suggest that (although perhaps my
> comments read that way).
>
> I was trying to suggest that, in the case where we have proposed
> fixes that are blocked because they are ABI breaks, that those
> could be put behind the versioned namspace (it was not an
> intention to suggest that such additions should be part of this
> patch series).
>
> > As to do so I also need to adopt cxx11 abi in versioned mode it
> already justify a bump of version.
>
> I see - it’s just a bit strange that we are bumping a version for
> a mode that does not currently work; however, i guess someone
> might have deployed it even so.
>
>
> It does work though, doesn't it?
> It's known to fail on powerpc64 due to conflicts with the ieee128
> stuff, but it should work elsewhere.
> It doesn't work with --with-default-libstdcxx-abi=cxx11 but that's
> just a "this doesn't work and isn't supported" limitation.
>
> The point of the patch series is to change it so the versioned
> namespace always uses the cxx11 ABI, which does seem worth bumping the
> version (even though the versioned namespace is explicitly not a
> stable ABI and not backwards compatible).
So I just need to wait for proper review, right ?
This is what I plan to do on this subject for the moment.
prev parent reply other threads:[~2024-05-15 17:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-04 21:11 François Dumont
2024-05-07 16:15 ` Iain Sandoe
2024-05-13 5:06 ` François Dumont
2024-05-13 6:29 ` Iain Sandoe
2024-05-13 8:34 ` Jonathan Wakely
2024-05-15 17:37 ` François Dumont [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=4d7ac2a8-b0e5-419e-b81d-7bb8d1b4c8e5@gmail.com \
--to=frs.dumont@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=idsandoe@googlemail.com \
--cc=jwakely.gcc@gmail.com \
--cc=libstdc++@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).