[libcxx-commits] [libcxx] [libc++] Implement C++20 atomic_ref (PR #76647)

[via libcxx-commits]

huixie90 wrote:

> > there are some weird downstream setup. IIRC, there is Fushia where it is Linux but without gcc installed (thus cannot -latomic).
> 
> That doesn't affect whether you can use the `__atomic_*` builtin functions.
> 
> > there is also Windows clang-cl which lacks of some builtins.
> 
> Fortunately, it doesn't lack these.
> 
> > On Mac, do we have the gcc builtin at all? At least, on my old laptop all the code path are going through the c11 branch.
> 
> Yep, they exist on all Clang.
> 
> > I’d also like to mention that I am working on several atomic related things, including making types with padding bytes in between member and/or after the tail works with atomic. (btw, does your atomic_ref compare_exchange_strong works for those types?) I don’t think we are allowed to touch the padding bits since atomic_ref does not own the object
> 
> This PR indeed does not implement that part of the spec yet. That'll need to wait until `__builtin_clear_padding` is implemented. I think it's fine to implement this type without that requirement, initially. (note that when the time comes, it will need to use a different implementation than std::atomic (and it'll be extremely inefficient, since it cannot assume the padding is cleared to start with!)
> 
> > and I don’t think breaking existing std::atomic ABI is feasible. even though we could Abi tag std::atomic, there is no way we could tag user defined classes that contain std::atomic and appear in Abi boundary.
> 
> Recall that long-term it's not only std::atomic whose ABI we need to change, but also C11 _Atomic. However, this PR no longer touches it, so that's moot for the purposes of this PR.

just to put some related in progress work I have:

- __builtin_clear_padding https://github.com/llvm/llvm-project/pull/75371
- atomic_base_impl  clear padding https://github.com/llvm/llvm-project/pull/76180
- bug in std::atomic with not-power-of-2 size  (see the comments I put in the end) https://github.com/llvm/llvm-project/issues/30023

I think your patch is orthogonal to all these bugs we have so we can try to land this one first.

https://github.com/llvm/llvm-project/pull/76647