[libcxx-commits] [clang] [compiler-rt] [libcxx] [Clang] Support atomic operations on _BitInt(N) (PR #204815)

[Xavier Roche via libcxx-commits]

xroche wrote:

> So I think this example, we can decide it always fails. What's the protocol? Do we mask padding bits after a load, or do we mask them when there's a store? The former is problematic because then native cmpxchg can't be used (unless we had hardware that did masking), we need to do load-linked / store-conditional type loops (with a mask). So IMO, on most platforms, it makes sense to mandate that store of a padded bitint also masks the non-representation bits. I'm effectively describing an ABI (hence my concern with GCC).
> 
> So if you go with mask at store time, your example would be expected to fail, always. A better test would then be to store to `b`, then to `a`, and then to do atomic operations. The store to `a` would have cleared the padding. Your example would just always fail as it is right now.

Agreed on mask-at-store, and Clang already seems to match it: every store, exchange, and RMW write-back sign/zero-extends the padding, and so does GCC-14 (I checked `sizeof`/`_Alignof`/lock-free class across widths 37-256 and they match). So the ABI you're describing already looks like the shared one.

One observation on the example: it's a `fetch_add`, and with the fix I pushed it converges (old 5, new 6) and writes the padding back canonical instead of looping; GCC-14 appears to do the same. `compare_exchange` on that same dirtied object does fail in both, since it's a single native `cmpxchg` over the whole word. The object is out-of-contract either way, so happy to go with whatever behavior you'd prefer to mandate here.

For the well-formed test I'll switch to your store-`b`-then-store-`a`-then-atomics shape.

Honest caveat: I'm near the edge of my understanding of the spec and the hardware here, so this part really wants more eyes before we settle it.


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