From: "François Dumont" <frs.dumont@gmail.com>
To: 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: Mon, 13 May 2024 07:06:56 +0200 [thread overview]
Message-ID: <b3a47965-e6bd-4968-878f-3ec0d663a087@gmail.com> (raw)
In-Reply-To: <08F3F058-B58A-4FC2-B83E-A0B271791C39@googlemail.com>
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.
>>
>> 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).
> 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.
As to do so I also need to adopt cxx11 abi in versioned mode it already
justify a bump of version.
>
> I have a proposed once_call replacement (but I think Jonathan also has one or more alternatives there)
>
> Please can we try to identify any other similar blocked fixes?
How ? We can only count on bugzilla bug reports to do so, no ?
If we face another similar problem in the future, after gcc 15 release,
then we'll just have to bump again. Is it such a problem ?
The reason I'm proposing to integrate this patch this early in gcc 15
stage is to have time to integrate any other library fix/optimization
that could make use of it. I already have 1 on my side for the hashtable
implementation. I hope your once_call fix also have time to be ready for
gcc 15, no ?
François
next prev parent reply other threads:[~2024-05-13 5:06 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 [this message]
2024-05-13 6:29 ` Iain Sandoe
2024-05-13 8:34 ` Jonathan Wakely
2024-05-15 17:37 ` François Dumont
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=b3a47965-e6bd-4968-878f-3ec0d663a087@gmail.com \
--to=frs.dumont@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=idsandoe@googlemail.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).