[cfe-dev] [ubsan] Add -fsanitize-warn-once, only emit runtime error once per check

[Alexey Samsonov]

On Thu, Dec 13, 2012 at 6:26 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> Have you measured the code size overhead from this extra flag? Did you
> consider implementing this in the runtime library instead (by
> suppressing duplicates based on return address or SourceLocation)?
>

+1. ThreadSanitizer has to solve the same problem - we want to report
each data race (pair of stack traces) exactly once. TSan runtime stores the
stacks of printed reports (as a sequence of PCs) to do this de-duplication.


> On Thu, Dec 13, 2012 at 11:51 AM, Will Dietz <willdtz at gmail.com> wrote:
> > On Thu, Dec 13, 2012 at 12:05 PM, Dmitri Gribenko <gribozavr at gmail.com>
> wrote:
> >> On Thu, Dec 13, 2012 at 7:33 PM, Will Dietz <willdtz at gmail.com> wrote:
> >>> This flag causes clang to emit a byte for each check that is used by
> the
> >>> runtime to track whether we've already printed an error for that check.
> >>>
> >>>  Often failed checks are triggered many times dynamically, but a user
> >>>  is only interested in which checks failed (with example dynamic values
> >>>  to aid in debugging).  This flag lets the user make such runs much
> >>>  more efficient and generate more manageable output.
> >>
> >> Hi Will,
> >>
> >> +  if (Checked) {
> >> +    if (*Checked) return;
> >> +    *Checked = true;
> >> +  }
> >>
> >> Does it make sense to do the store atomically?  The user's program is
> >> already buggy, but introducing a possible data race is unfortunate.
> >>
> >> Dmitri
> >>
> >
> > Hi Dmitri,
> >
> > Glad you brought this up.  I wasn't sure which way to go on this and
> > erred on simplicity.  Attached is an updated compiler-rt patch using
> > __sync_val_compare_and_swap, which also simplifies the code a bit.  If
> > this builtin is sufficiently portable (architectures and compiler
> > recognition) then I would prefer this for the reasons you mention.
> >
> > Thanks!
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>



-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121213/389d54d1/attachment.html>