public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
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.

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