<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 18, 2016 at 7:30 AM, Craig, Ben via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 3/18/2016 1:50 AM, Joerg Sonnenberger via cfe-commits wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Mar 17, 2016 at 05:56:17PM +0000, JF Bastien via cfe-commits wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
C++ atomics are explicitly designed to avoid problems with touching<br>
adjacent bytes: if `atomic<T>` where `sizeof(T) == 1` requires a 4-byte<br>
`cmpxchg` then it's up to the frontend to make sure `sizeof<atomic<T>> >= 4`<br>
(or something equivalent such as making it non-lock-free).<br>
</blockquote>
That's not completely relevant for the code at hand. At least the<br>
__sync_* builtins only ever required appropiate alignment of the base<br>
type, not necessarily extra alignment to avoid padding for stupid<br>
codegen. I also believe that access to extra data is completely harmless<br>
for all but one use case. If you are directly accessing memory mapped<br>
devices using compiler atomics, you should really know what you are<br>
doing. That's about the only case where it matters.<br></blockquote></span></blockquote><div><br></div><div>volatile atomic is different from straight atomic, and should be handled accordingly by the target backend.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></span>
Some architectures support byte granularity memory protection. Accessing unsolicited bytes can cause a trap on those architectures.<br>
<br>
I think it makes sense for atomic<char> and Atomic<char> to get turned into the 4 byte __atomic intrinsics.  Those 4 byte __atomic intrinsics can then get lowered to efficient inlined code. If someone has a regular char, and they use the __atomic or __sync intrinsics directly, I'm fine with that going to a lib call.  The lib call can then either use the global lock shard, or access extra data, depending on what is reasonable for that platform.</blockquote><div><br></div><div>That all sounds like something the frontend has to decide on based on what the target is. </div></div></div></div>