<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 17, 2016 at 1:31 AM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</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">dvyukov added a comment.<br>
<span class=""><br>
> yes -- C++ memory model does not allow speculative store motion. However in that example,  The compiler can do the following to remove the memory access of x in loop:<br>
<br>
<br>
</span>I don't see how it relates. Races still lead to undefined behavior.<br></blockquote><div><br></div><div>I think this is already assuming that the original program is race free (i.e., plain load/stores are atomic,). Otherwise the behavior of the original program would also be undefined.</div><div><br></div><div> </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">
<span class=""><br>
> DSE won't happen with monotonic used (as below) -- I am not sure if that is a bug.<br>
<br>
<br>
</span>DSE is permitted by C/C++ standards in this case. So, yes, this is a bug.<br>
<br></blockquote><div><br></div><div><br></div><div>Do you have a reference? Assuming monotonic maps to 'memory_order_relaxed', then we have this specified:</div><div><br></div><div>"Atomic operations tagged memory_order_relaxed are not synchronization operations, they do not order memory. They only guarantee atomicity and modification order consistency."<br></div><div><br></div><div>Notice the mentioning of 'modification order consistency' there.  For modification order, we have:</div><div><br></div><div><div>"Modification order</div><div>All modifications to any particular atomic variable occur in a total order that is specific to this one atomic variable.</div><div>The following four requirements are guaranteed for all atomic operations:</div><div>1) Write-write coherence: If evaluation A that modifies some atomic M (a write) happens-before evaluation B that modifies M, then A appears earlier than B in the modification order of M</div></div><div>...</div><div>"</div><div><br></div><div>Would DSE change the modification order?</div><div><br></div><div>I checked with GCC -- it does not do DSE for this case either.</div><div><br></div><div>Besides, if 'monotonic' is considered completely 'no-op' (for x86) such as optimizer should not be imposed with any constraints, why Tsan behaves differently here (on x86)? </div><div><br></div><div>atomic_store(p, atomic_load(p,relaxed) + 1, relaxed)  <--- no warning<br></div><div>store(p, load(p) + 1)  <--- warning</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div><br></div><div><br></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">
<br>
<a href="http://reviews.llvm.org/D18164" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18164</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>