This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug nptl/24924] nptl/tst-rwlock9 and nptl/tst-rwlock18 fail on aarch64


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]