This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/24924] nptl/tst-rwlock9 and nptl/tst-rwlock18 fail on aarch64
- From: "pinskia at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 27 Nov 2019 07:22:20 +0000
- Subject: [Bug nptl/24924] nptl/tst-rwlock9 and nptl/tst-rwlock18 fail on aarch64
- Auto-submitted: auto-generated
- References: <bug-24924-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=24924
--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #10)
> This issue does not occur when pthread_rwlock_clockwrlock is compiled with
> gcc 8. With gcc 8, atomic_fetch_add_relaxed in pthread_rwlock_clockwrlock
> (pthread_rwlock_common.c:636) uses ldaxr, whereas gcc 9 uses ldxr.
> Simarily, the expansion of atomic_compare_exchange_weak_acquire
> (pthread_rwlock_common.c:747) has stlxr vs stxr.
I need to read through the source/comments to understand if the memory model
usages are correct. I really have a suspicion there is one that is messed up.
One thing that both OcteonTX2 and ThunderX1 (and OcteonTX1) do is they reorder
stores more than most other aarch64 cores and if the barriers are not 100%
correct, there is a write which could be much earlier on, you would run into an
issue like this. E.g. ThunderX1 (and OcteonTX1) have a 3k write buffer which
means stores don't go out until the needed case.
--
You are receiving this mail because:
You are on the CC list for the bug.