<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Nov 30, 2018 at 12:35 PM James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="auto"><div class="gmail_quote"><div dir="ltr">On Thu, Nov 29, 2018, 9:53 PM Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">* P0528R3 Atomic Compare-And-Exchange With Padding Bits<br>
We need compiler magic here, in some form. Billy O'Neal wrote to the C1XX team: "To implement the new atomic_ref as well as the change to compare the value representation of atomics only, the library needs a way to zero out the padding in arbitrary T, which we can't discover with library tech alone. We would like an intrinsic that accepts a trivially-copyable T and produces a copy with the padding zeroed, or takes a T* and zeros the padding inside that T, or similar."<br></blockquote><div><br></div><div>I think this should be done in-place in memory; producing a copy has the problem that you're passing around a value of type T, and that might permit the padding bits to become undefined again.</div><div><br></div><div>void __builtin_clear_padding(T *ptr)</div><div>Effects: Set to zero all bits that are padding bits in the representation of every value of type T.</div></div></div></div></blockquote><div><br></div><div>Is the intent here that every value stored into a std::atomic (e.g. via store, exchange, or compare_exchange) would be passed through __builtin_clear_padding first, before being stored into the atomic object? And presumably the same would need to occur implicitly for C-style `_Atomic T`?</div></div></div></div></blockquote><div><br></div><div>Yes; see P0582R3 "The Curious Case of Padding Bits" (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0528r3.html">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0528r3.html</a>) for details. The intent is to make compare-exchange work for types with padding bits by zeroing those padding bits before storing a value in an atomic or comparing with the value stored in an atomic.</div></div></div></div>