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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
