<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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><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>
Jeff<br>
<br>
[1] <a href="http://msdn.microsoft.com/en-us/library/vstudio/12a04hfd%28v=vs.90%29.aspx" target="_blank">http://msdn.microsoft.com/en-us/library/vstudio/12a04hfd%28v=vs.90%29.aspx</a><br>
[2] <a href="http://gcc.gnu.org/ml/gcc-help/2012-03/msg00242.html" target="_blank">http://gcc.gnu.org/ml/gcc-help/2012-03/msg00242.html</a></blockquote><div><br></div><div style>`volatile` roughly means "this memory access may have side effects beyond those of regular memory". Since the compiler can't reason about these memory accesses, it is forced to carry them down to the assembly "as written" without tampering with them. AFAIK `volatile` is sufficient for making loads and stores unelidable (which was your original use case).</div>
</div><br></div></div>