[PATCH] Make some asan builtins tm_pure (PR sanitizer/55508)

Torvald Riegel triegel@redhat.com
Fri Dec 14 13:43:00 GMT 2012

On Thu, 2012-12-13 at 10:40 +0400, Dmitry Vyukov wrote:
> On Thu, Dec 13, 2012 at 1:58 AM, Richard Henderson <rth@redhat.com> wrote:
> > On 12/12/2012 11:50 AM, Jakub Jelinek wrote:
> >> 2012-12-12  Jakub Jelinek  <jakub@redhat.com>
> >>
> >>       PR sanitizer/55508
> >>       * builtin-attrs.def (ATTR_TMPURE_NOTHROW_LEAF_LIST,
> >>       * asan.c (ATTR_TMPURE_NOTHROW_LEAF_LIST,
> >>       * sanitizer.def: Make __asan_report_* and __asan_handle_no_return
> >>       builtins tm pure.
> >
> > Ok.
> >
> > Agreed about we need another solution for tsan + tm.
> What type of bugs do you expect tsan catch in transactional setting?
> Are we talking about data races between transactional and
> non-transactional code?

Right.  And it would be good if TSAN can detect these cases.

I don't think we need TSAN to detect races in the TM runtime library
implementation itself, which would probably need a lot of special cases
because of (restricted, see my other post) speculative execution by the

> Does atomic transactions permitted by gcc? I mean can I use mutexes
> and atomics inside of transactions to synchronize with
> non-transactional code?

Such operations, called "unsafe code", are not allowed in atomic
transactions (currently--that choice is determined by several factors
such as likely runtime overheads and intrusiveness of TM
implementations).  But they are allowed in relaxed transactions.  Before
relaxed transactions execute such unsafe code, they will switch to
serial execution of transactions, which we could make visible to TSAN if
that would help.


More information about the Gcc-patches mailing list