<div dir="ltr">All right. I am fine with the direction the original patch is going (ignore counter vars).<div><br></div><div>thanks,</div><div><br></div><div>David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 16, 2016 at 5:48 PM, Anna Zaks <span dir="ltr"><<a href="mailto:zaks.anna@gmail.com" target="_blank">zaks.anna@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">zaks.anna added a comment.<br>
<span class=""><br>
> Fine with that too if that is a must, but what is wrong with test configuration  modified to avoid this<br>
<br>
>  known limitation?<br>
<br>
>  According to Anna, the following configs are tested:<br>
<br>
<br>
</span>I was not talking about any specific test configurations. This is what compiler/tools users could choose to use. We (as compiler vendors) have no control over this.<br>
<br>
> - coverage + tsan<br>
<br>
> - coverage + asan .. If the motivation is to save build time (by merging intrumentations), How about just<br>
<br>
> - coverage + asan<br>
<span class=""><br>
> - tsan -... This is also faster.  There does not seem to be any value to repeatedly enable coverage.<br>
<br>
<br>
</span>We do not really control what the users of these tools choose to use in their workflow / CI. It is possible they want to use coverage and TSan and not care about ASan. Our choice is to either return an error when both coverage and tsan are requested or just to support this configuration. I think it would be very surprising to users to see that they cannot use coverage with TSan. Also, I do not see a reason why it should be disallowed.<br>
<br>
<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>