[PATCH v2] libstdc++: Make forward_list::sort exception-safe [PR124051]

[Odysseas Georgoudis]

Hi Jonathan,

Thanks for the review.

I used an LLM as an additional review tool, but I wrote both the
change and the test myself. I thought the added copyright
block was needed. I have removed it in v2 and added the
explicit return from main.

I was not expecting a measurable regression on the normal path, because
the added recovery code only runs when the comparator throws, but I
benchmarked it to confirm.  With the default comparator, the generated
code was identical and timings were within noise.  With an external
potentially-throwing comparator, the worst result was about 1.9% slower.

I kept the benchmark local, but I can send it if useful.

Outlook sent the v1 patch as application/octet-stream, so I have
attached v2 as PR124051-v2.patch.txt instead.

Thanks,
Odysseas



________________________________
From: Jonathan Wakely <jwakely@redhat.com>
Sent: 19 August 2026 12:19
To: Odysseas Georgoudis <odygrd@hotmail.com>
Cc: libstdc++@gcc.gnu.org <libstdc++@gcc.gnu.org>; gcc-patches@gcc.gnu.org <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] libstdc++: Make forward_list::sort exception-safe [PR124051]

On Sun, 16 Aug 2026 at 20:43 +0000, Odysseas Georgoudis wrote:
>If a comparison called by forward_list::sort throws, the current
>implementation can leave the list corrupted, which may cause a later
>crash.
>
>This patch restores valid links before allowing the same exception to
>continue.  The element order remains unspecified, as permitted by the
>standard, while iterators and references remain valid.
>
>Tested on x86_64-pc-linux-gnu.
>
>Thanks,
>Odysseas

Thanks for the patch to fix this.

Have you tested whether this affects performance of the sort function?
I hope it doesn't make much difference.

Please don't attach patches as application/octet-stream - patches are
plain text, not binary data. It makes it hard to review the patch by
replying inline.

Please read
https://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html#test.new_tests
and adjust the new test accordingly. Based on the copyright notice in
the test, it seems likely this was produced with the assistance of an
LLM, is that correct?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20260819/ca656379/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: PR124051-v2.patch.txt
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20260819/ca656379/attachment.txt>