Repository navigation
Lift unnecessary restriction on CAS failure ordering #68464
Description
Activity
Blocked on https://bugs.llvm.org/show_bug.cgi?id=33332. The cmpxchg release acquire is accepted by LLVM but miscompiled on AArch64.
I split it in a PR that renames the intrinsics first, and a separate PR for exposing the new ordering combinations afterwards.
Looks like llvm 12 doesn't support this: #98383 (comment)
Can we make things conditionally fall back to a stronger ordering depending on the llvm version? I don't think we do anything like that in the library right now, but maybe the compiler already does things differently for different llvm versions?
Ah yes, some code checks
llvm_util::get_version() < (13, 0, 0). I suppose Builder::atomic_cmpxchg could check the same, and upgrade the ordering if necessary in that case.To do:
- Add codegen test. Test codegen of atomic compare-exchange with additional memory orderings #99409
- Publicly expose the new orderings. Remove restrictions on compare-exchange memory ordering. #98383
- Update memory order lint to accept the new orderings. Update invalid atomic ordering lint #99410
- added 4 commits that reference this issue
on Jun 26, 2022 - added a commit that references this issue
on Sep 15, 2022
Currently
compare_exchangerequires the failure ordering to "be equivalent toor weaker than a success ordering". On the other hand C11/C++11 requires only
that "failure shall be no stronger than the success", which arguably means that
one can write e.g.
compare_exchange(..., Release, Acquire)in C/C++ but not in Rust.Arguably, because neither C11 standard nor C++11 standard defines what it means
for an ordering to be stronger from another. When the issue was raised in
LWG2445, the proposed and accepted resolution was to lift those restrictions
altogether, leaving only requirement that "the failure argument shall not be
memory_order_releasenormemory_order_acq_rel".It would be beneficial to remove success/failure ordering restrictions for
reasons described in C++ proposal P0418r2.
EDIT: Restrictions were lifted in clang & LLVM: