xroche wrote: > [P0528](https://wg21.link/P0528) is the bar for the C++ side: value bits are > what atomics observe, padding must not affect compare_exchange > success/failure, and RMWs must write a canonical representation. For padded > _BitInt, the CAS loop should carry the raw loaded representation as the > cmpxchg expected, compute at width N, and write a canonical desired value. > Otherwise an object with dirty padding can make the loop fail forever. Extra > fun if we allow unions of _BitInt.
The 1c87c99 fix reuses the existing `EmitAtomicUpdate` loop, which carries the raw loaded representation as `expected` and writes a canonical `desired` computed at width N. That is the P0528 protocol you describe. The protocol now, stated explicitly: - store, exchange, and the RMW desired write a canonical representation (signed: sign-extended padding; unsigned: zero padding). - load observes value bits only (truncated to N). - the RMW loop's cmpxchg expected is the raw loaded representation, so an object with dirty padding converges on the first iteration rather than spinning. Holds for both the inline cmpxchg and the `__atomic_compare_exchange` libcall (wide) paths. > So tests with dirty padding might be helpful? I wrote a single-threaded execution test (per-op correctness at a padded inline width and wide widths, plus dirty-padding convergence through a union for both the inline and libcall paths). I put it under `compiler-rt/test/builtins/Unit/`, following `atomic_test.c`. Is that the right location, and should it gate this PR or land alongside? A multi-threaded contention test seems like a good follow-up, but unsure if this desirable (flakiness and stuff). > Also, is GCC going to do the same? @jwakely might want to chime in. > And, I hope C and C++ will be compatible! On GCC and C-vs-C++: the change does not touch `_BitInt` size or alignment, so the representation matches what Clang already used (and GCC's `_BitInt`), and the C `_Atomic` path and C++ `std::atomic<_BitInt>` go through the same lowering. I can add a parity check if that is useful; the libstdc++ side is worth a confirmation from jwakely. https://github.com/llvm/llvm-project/pull/204815 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
