Tested x86_64-pc-linux-gnu, committed to master, backported to gcc-11.
On Wed, Feb 9, 2022 at 9:14 AM Jonathan Wakely wrote:
> On Wed, 9 Feb 2022 at 17:10, Thomas Rodgers wrote:
> >
> > Updated patch. I reverted the memory order change (and will submit that
> as another patch) and fixed some spe
On Wed, 9 Feb 2022 at 17:10, Thomas Rodgers wrote:
>
> Updated patch. I reverted the memory order change (and will submit that as
> another patch) and fixed some spelling and grammar errors.
OK for trunk and gcc-11, thanks.
d in exactly one
> place, so could just be inlined into _M_do_spin_v, couldn't it?)
>
>
From b39283d5100305e7a95d59324059de9952d3a858 Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Tue, 8 Feb 2022 16:33:36 -0800
Subject: [PATCH] libstdc++: Fix deadlock in atomic wait [PR104442]
Excessively enthusiastic refactoring. I expect to rewrite most of this as
part of the work I'm starting now for GCC13 stage1.
On Wed, Feb 9, 2022 at 2:43 AM Jonathan Wakely wrote:
> On Wed, 9 Feb 2022 at 00:57, Thomas Rodgers via Libstdc++
> wrote:
> >
> > This issue was observed as a deadloack
On Wed, 9 Feb 2022 at 00:57, Thomas Rodgers via Libstdc++
wrote:
>
> This issue was observed as a deadloack in
> 29_atomics/atomic/wait_notify/100334.cc on vxworks. When a wait is
> "laundered" (e.g. type T* does not suffice as a waitable address for the
> platform's native waiting primitive), the
Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Tue, 8 Feb 2022 16:33:36 -0800
Subject: [PATCH] libstdc++: Fix deadlock in atomic wait [PR104442]
This issue was observed as a deadloack in
29_atomics/atomic/wait_notify/100334.cc on vxworks. When a wait is
"laundered" (e.g. type T* does no
