lkail added a comment. > The GCC builtins paint the ABI into a corner. They accept > non-`_Atomic`-qualified types (the C11 spec guarantees only that these > operations work on `_Atomic` types). The goal of the original C++ > specification was to allow implementations to use atomic operations for > register-sized chunks and fall back to an implementation with an inline lock > for larger types, so `std::atomic<T>` would either have a single field of `T` > or a `std::atomic_flag` field and a `T` field, depending on the size of `T`. > The goal of the C11 import was to allow `_Atomic(T)` to be ABI-compatible > with `std::atomic<T>`. Implementing this requires that `_Atomic(T)` be > allowed to have a different representation to `T`. GCC messed this up and > defined builtins that took a `T*`, not an `_Atomic(T*)`, which forced all > GCC-compatible ABIs to have the same representation for `T` and `_Atomic(T)`. > This, in turn, meant that the atomics support library couldn't use inline > locks, and had to maintain a pool of locks to use for different types. This, > in turn, means that `_Atomic(T)` silently fails in surprising ways in shared > memory, some of the time, depending on the target CPU. This is a horrible > mess and I would like to ensure that we always provide builtins that allow > target ABIs to do the right thing, even if Linux and *BSD are trapped in a > broken ABI by GCC and legacy compatibility.
Good to know, thanks for your detailed explanation! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D112400/new/ https://reviews.llvm.org/D112400 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
