<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 5, 2012, at 10:50 AM, Kostya Serebryany wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Thu, Apr 5, 2012 at 10:37 AM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On Apr 5, 2012, at 9:43 AM, Kostya Serebryany wrote:<br>
<br>
> Hello,<br>
><br>
> Please review the following patch:<br>
> ThreadSanitizer instrumentation relies on TBAA for correctness, so we need to generate TBAA at "-O0 -fthread-sanitizer".<br>
<br>
</div></div>This is close, but not the right solution. TBAA can cause a semantic change when enabled (though I admit it is unlikely given that nearly all of the optimizers are disabled at -O0).<br>
<br>
The right fix is for TSAN to generate *vtable* TBAA info, but not other TBAA info.<br></blockquote><div><br></div><div>Ok... </div><div>Do you mean that we need to check "CodeGenOpts.OptimizationLevel > 0" inside CodeGenTBAA methods? </div>
<div>Or pass a flag to CodeGenTBAA::CodeGenTBAA saying that we need only vtable TBAA?</div></div></blockquote><br></div><div>The former is probably the right way.</div><div><br></div><div>-Chris</div><br></body></html>