On Thu, Dec 13, 2012 at 1:02 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> > Various TM tests ICE when built with -fgnu-tm -fsanitizer=address. >> > The problem is that asan.c pass adds calls to builtins that weren't there >> > before and TM is upset about it. The __asan_report* are all like >> > abort, in correctly written program they shouldn't have a user visible >> > effect, in bad program they will terminate the process, but in any case >> > it doesn't matter how many times they are retried as part of a transaction, >> > there is no state to roll back on transaction cancellation. >> > __asan_handle_no_return, while not being noreturn, just marks the stack as >> > unprotected, so again in correctly written application no effect, in bad >> > app >> > might result in some issues being undetected, but still, it can be done >> > many >> > times and isn't irreversible. >> >> I was only loosely following tm-languages discussions. Does gcc tm >> model guarantees strong consistency for all memory accesses? I mean >> there are tm implementations that allow transient inconsistencies, > > Will leave this to Torvald. > >> than are detected later and trx is restarted. Can't asan trigger false >> positives in this case? > > I can't imagine any. > >> Also, what is the order of instrumentation in tm+asan setting? I mean >> that neither tm must instrument asan instrumentation, nor asan must >> instrument tm instrumentation. Is it the case? There also can be >> conflicts related to ordering of instrumentation in the following >> case: >> asan_check(); >> speculative_load(); >> tm_check(); > > I'm not aware of TM having speculative loads, libgtm certainly doesn't > install a SIGSEGV handler (and testing whether some memory is > readable/writable without actually dereferencing would be terribly slow). > If a memory load or store segfaults, whether in a transaction or outside of > it, it is a program bug and it is right if asan terminates the program.
OK, thanks. AFAIR tl2 installs SIGSEGV and uses non-failing loads.
