<div style="font-family: arial, helvetica, sans-serif; font-size: 10pt"><br><br><div class="gmail_quote">On Thu, Dec 13, 2012 at 6:26 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Have you measured the code size overhead from this extra flag? Did you<br>
consider implementing this in the runtime library instead (by<br>
suppressing duplicates based on return address or SourceLocation)?<br></blockquote><div><br></div><div>+1. ThreadSanitizer has to solve the same problem - we want to report</div><div>each data race (pair of stack traces) exactly once. TSan runtime stores the</div>
<div>stacks of printed reports (as a sequence of PCs) to do this de-duplication.</div><div><br></div><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 Thu, Dec 13, 2012 at 11:51 AM, Will Dietz <<a href="mailto:willdtz@gmail.com">willdtz@gmail.com</a>> wrote:<br>
> On Thu, Dec 13, 2012 at 12:05 PM, Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com">gribozavr@gmail.com</a>> wrote:<br>
>> On Thu, Dec 13, 2012 at 7:33 PM, Will Dietz <<a href="mailto:willdtz@gmail.com">willdtz@gmail.com</a>> wrote:<br>
>>> This flag causes clang to emit a byte for each check that is used by the<br>
>>> runtime to track whether we've already printed an error for that check.<br>
>>><br>
>>>  Often failed checks are triggered many times dynamically, but a user<br>
>>>  is only interested in which checks failed (with example dynamic values<br>
>>>  to aid in debugging).  This flag lets the user make such runs much<br>
>>>  more efficient and generate more manageable output.<br>
>><br>
>> Hi Will,<br>
>><br>
>> +  if (Checked) {<br>
>> +    if (*Checked) return;<br>
>> +    *Checked = true;<br>
>> +  }<br>
>><br>
>> Does it make sense to do the store atomically?  The user's program is<br>
>> already buggy, but introducing a possible data race is unfortunate.<br>
>><br>
>> Dmitri<br>
>><br>
><br>
> Hi Dmitri,<br>
><br>
> Glad you brought this up.  I wasn't sure which way to go on this and<br>
> erred on simplicity.  Attached is an updated compiler-rt patch using<br>
> __sync_val_compare_and_swap, which also simplifies the code a bit.  If<br>
> this builtin is sufficiently portable (architectures and compiler<br>
> recognition) then I would prefer this for the reasons you mention.<br>
><br>
> Thanks!<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div><br>
</div>