https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #16 from CVS Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:90a4981e0951687056ec4735cfd3043b35a23502
commit r11-9109-g90a4981e0951687056ec4735cfd3043b35a23502
Author: Thomas Rodge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #15 from Jonathan Wakely ---
Backport to gcc-11 needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
H.J. Lu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #13 from CVS Commits ---
The master branch has been updated by Thomas Rodgers :
https://gcc.gnu.org/g:f9f1a6efaaeeec06d5c07378734cb8eb47b976a7
commit r12-3587-gf9f1a6efaaeeec06d5c07378734cb8eb47b976a7
Author: Thomas Rodgers
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #12 from Jonathan Wakely ---
(In reply to Thomas Rodgers from comment #11)
> Yes. I will submit a patch for this test shortly.
The a.wait(aa) to a.wait(va) change is pre-approved, please just push when it's
ready.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #11 from Thomas Rodgers ---
(In reply to Jonathan Wakely from comment #10)
> http://eel.is/c++draft/atomics#ref.generic.general-3.sentence-2
>
> "While any atomic_ref instances exist that reference the *ptr object, all
> accesses t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #10 from Jonathan Wakely ---
http://eel.is/c++draft/atomics#ref.generic.general-3.sentence-2
"While any atomic_ref instances exist that reference the *ptr object, all
accesses to that object shall exclusively occur through those at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #9 from Jonathan Wakely ---
My point is that *any* read of aa is undefined while there is an atomic_ref
using it, even in the absence of other threads.
It happens to cause the race you describe, because the value of aa is changing
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #8 from Jonathan Wakely ---
It's a test for std::atomic_ref, it has to use atomic_ref :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #7 from Florian Weimer ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Florian Weimer from comment #4)
> > a.wait(aa);
>
> This line is undefined and needs to be a.wait(va) anyway.
Yes, that's what I meant. O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #6 from Jonathan Wakely ---
(In reply to Florian Weimer from comment #4)
> a.wait(aa);
This line is undefined and needs to be a.wait(va) anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #5 from Thomas Rodgers ---
(In reply to Florian Weimer from comment #4)
> I think it's a test bug:
>
> std::atomic_ref a{ aa };
>
> std::thread t([&]
> {
> a.store(bb);
> a.notify_one();
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #3 from Thomas Rodgers ---
This appears to be the test case itself.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-08-04
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #2 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #0)
> 29_atomics/atomic_ref/wait_notify.cc in 64-bit on Skylake server:
>
> It happens about once a few weeks.
while true ; do ./a.out ; done
will hang immediately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
--- Comment #1 from Uroš Bizjak ---
Probably related to PR97936.
17 matches
Mail list logo
