<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">[Note previous discussion that occurred on the (otherwise unrelated) <a href="http://reviews.llvm.org/D17950" target="_blank">http://reviews.llvm.org/D17950</a>.]</div><div><br></div><div class="gmail_quote">On Mon, Apr 4, 2016 at 9:58 AM, Craig, Ben via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The C11 standard permits sizeof(_Atomic char) to be different from sizeof(char).  Are there any targets where this freedom is taken? </blockquote><div><br></div><div>No, it doesn't do that for primitive integer types, only for non-power-of-two sized types. (ASTContext.cpp:1822)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Is there currently a TargetInfo member or chunk of a DataLayoutString that indicates the size of the various atomics?<br></blockquote><div><br></div><div>Nope.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I did some source searches, and didn't find anything.  I've made some initial attempts at adding such support, but I've hit some non-trivial front-end crashes, so I figured I'd ask around before digging any deeper</blockquote><div></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">As I said before, I don't think that this is really a good idea. Unless (as you brought up) there's an architecture which actually uses byte-granularity memory protection AND has a single-byte load/store BUT is missing a single-byte version of the ll/sc or cmpxchg instructions (having only a 4byte version, say), thus making it truly impossible to implement a lock-free atomic char. (Such an architecture would seem pretty broken to me. It should really be fixed)</div><div class="gmail_extra"><br></div><div class="gmail_extra">In other cases, where it is possible to implement atomic char, by using a word-sized cmpxchg on the containing aligned word, I think it's probably best to just do that. Despite the approximately 15 extra instructions needed to do the masking/shifting of the values.</div><div class="gmail_extra"><br></div></div>