<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 30, 2018, at 1:10 PM, James Y Knight <<a href="mailto:jyknight@google.com" class="">jyknight@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Nov 30, 2018 at 4:06 PM JF Bastien <<a href="mailto:jfbastien@apple.com" class="">jfbastien@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Nov 30, 2018, at 12:39 PM, Casey Carter via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_7992430258116840163Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none" class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Fri, Nov 30, 2018 at 12:35 PM James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="auto" class=""><div class="gmail_quote"><div dir="ltr" class="">On Thu, Nov 29, 2018, 9:53 PM Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><span class="m_7992430258116840163Apple-converted-space"> </span>wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">* P0528R3 Atomic Compare-And-Exchange With Padding Bits<br class="">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 class=""></blockquote><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">void __builtin_clear_padding(T *ptr)</div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Yes; see P0582R3 "The Curious Case of Padding Bits" (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0528r3.html" target="_blank" class="">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></div></blockquote><br class=""></div><div class="">I think you rather want to zero out padding bits in the atomic, not in the value, and you want to do it after storing into the atomic (unless you’re doing zeroing, and then copying the non-padding elements one at a time, in which case you could just memset instead of having a builtin).</div></div></blockquote><div class=""><br class=""></div><div class="">Errr...certainly you can't do additional stores into an atomic after storing a new value into it, that would kinda ruin the "atomic" part.</div></div></div>
</div></blockquote></div><br class=""><div class="">Haha yeah you’re totally right! Ignore me, no idea what I was thinking.</div></body></html>