<div dir="ltr">On Mon, Jun 17, 2013 at 3:32 PM, Jeffrey Walton <span dir="ltr"><<a href="mailto:noloader@gmail.com" target="_blank">noloader@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<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"><div class=""><div class="h5">On Mon, Jun 17, 2013 at 6:23 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>

> On Mon, Jun 17, 2013 at 10:29 AM, Jeffrey Walton <<a href="mailto:noloader@gmail.com">noloader@gmail.com</a>> wrote:<br>
>> First is to ensure dead-writes are not removed. For example, a<br>
>> function that zeroizes or wipes memory is subject to removal during<br>
>> optimization. I often have to look at program's disassembly to ensure<br>
>> the memset is not removed by the optimizer.<br>
><br>
> Appropriate use of `volatile` is probably sufficient for this use case.<br>
</div></div>That brings up a good point. As I understand it, volatile is<br>
essentially implementation defined. What is Clang/LLVM's<br>
interpretation?<br>
<br>
Here's what I know. Microsoft's interpretation allows me to use<br>
volatile for the situation under MSVC++ [1]. GCC's interpretation of<br>
volatile is for memory mapped hardware, so it does not allow me to use<br>
the qualifier to tame the optimizer [2].<br><br></blockquote><div><br></div><div>clang doesn't treat volatile loads/stores as aquire/release barriers, if that's what you're asking.</div><div><br></div><div>Actually, if you look at the 2012 version of the docs "<a href="http://msdn.microsoft.com/en-us/library/vstudio/12a04hfd(v=vs.110).aspx">http://msdn.microsoft.com/en-us/library/vstudio/12a04hfd(v=vs.110).aspx</a>", you can see Microsoft was forced to change its own rules so as to not completely screw over performance on non-X86 platforms.</div>
<div><br></div><div>-Eli</div></div></div></div>