On Wed, Nov 21, 2012 at 11:35 PM, Dmitry Vyukov <dvyu...@google.com> wrote:
> What percent of the memory accesses the following can skip?
>
> I just don't know what exactly they mean. ADDR_EXPR/COMPONENT_REF look like
> it can skip a lot.
>
It does not skip a lot.
>
> + /* TODO: handle other cases
> + (FIELD_DECL, ARRAY_RANGE_REF, TARGET_MEM_REF, ADDR_EXPR). */
The comment is not correct. The analysis should not care about
FIELD_DECL (covered by COMPONENT_REF), nor ADDR_EXPR. Due to the pass
ordering, target mem-ref is not seen either.
> + if (tcode != ARRAY_REF
> + && tcode != VAR_DECL
> + && tcode != COMPONENT_REF
> + && tcode != INDIRECT_REF
> + && tcode != MEM_REF)
> + return false;
>
The listed cases are handled.
David
>
>
> On Thu, Nov 22, 2012 at 11:29 AM, Dmitry Vyukov <dvyu...@google.com> wrote:
>>
>> +static bool
>> +tsan_gate (void)
>> +{
>> + return flag_tsan != 0
>> + && builtin_decl_implicit_p (BUILT_IN_TSAN_INIT);
>>
>>
>> What does it mean? Why builtin_decl_implicit_p (BUILT_IN_TSAN_INIT)?
>>
>> +}
>>
>>
>>
>> On Thu, Nov 22, 2012 at 11:22 AM, Wei Mi <w...@google.com> wrote:
>>>
>>> Hi,
>>>
>>> I update the tsan patch against trunk, and create libtsan patch.
>>> Please see if it is ok.
>>>
>>> gcc/ChangeLog:
>>> 2012-11-22 Dmitry Vyukov <dvyu...@google.com>
>>> Wei Mi <w...@google.com>
>>>
>>> * builtins.def (DEF_SANITIZER_BUILTIN): Define tsan builtins.
>>> * sanitizer.def: Ditto.
>>> * Makefile.in (tsan.o): Add tsan.o target.
>>> (BUILTINS_DEF): Add sanitizer.def.
>>> * passes.c (init_optimization_passes): Add tsan passes.
>>> * tree-pass.h (register_pass_info): Ditto.
>>> * toplev.c (compile_file): Ditto.
>>> * doc/invoke.texi: Document tsan related options.
>>> * gcc.c (LINK_COMMAND_SPEC): Add LIBTSAN_SPEC in link command
>>> if -fsanitize=thread.
>>> * tsan.c: New file about tsan.
>>> * tsan.h: Ditto.
>>> * common.opt: Add -fsanitize=thread.
>>>
>>> libsanitizer/ChangeLog:
>>> 2012-11-22 Wei Mi <w...@google.com>
>>>
>>> * tsan: New directory. Import tsan runtime from llvm.
>>> * configure.ac: Add 64 bits tsan build.
>>> * Makefile.am: Likewise.
>>> * configure: Regenerated.
>>> * Makefile.in: Likewise.
>>>
>>> Thanks,
>>> Wei.
>>>
>>> On Sun, Nov 18, 2012 at 10:52 AM, Konstantin Serebryany
>>> <konstantin.s.serebry...@gmail.com> wrote:
>>> > Just a comment about tsan.
>>> > Today, tsan works *only* on x86_64 linux (no 32-bits, no non-linux).
>>> > Other 64-bit platforms may be doable, but not as easy as for asan.
>>> > Non-linux is harder than non-x86_64 (need to support tons of libc
>>> > interceptors).
>>> > 32-bit platforms are very hard to port to, I would not bother for now.
>>> > (this probably includes x32, which has cheap atomic 64-bit
>>> > loads/stores, but has too small address space for tsan)
>>> >
>>> > Conclusion: when committing tsan code, please make sure it is enable
>>> > only on x86_64
>>> >
>>> > --kcc
>>> >
>>> > On Sat, Nov 17, 2012 at 3:13 AM, Wei Mi <w...@google.com> wrote:
>>> >> Hi,
>>> >>
>>> >> Is it ok for the trunk?
>>> >>
>>> >> Thanks,
>>> >> Wei.
>>> >>
>>> >> On Tue, Nov 13, 2012 at 5:06 PM, Wei Mi <w...@google.com> wrote:
>>> >>> Thanks for catching this. I update the patch.
>>> >>>
>>> >>> Regards,
>>> >>> Wei.
>>> >>>
>>> >>> On Tue, Nov 13, 2012 at 4:54 PM, Richard Henderson <r...@redhat.com>
>>> >>> wrote:
>>> >>>> On 11/13/2012 04:08 PM, Wei Mi wrote:
>>> >>>>> +extern void tsan_finish_file (void);
>>> >>>>> +
>>> >>>>> +#endif /* TREE_TSAN */
>>> >>>>> +/* ThreadSanitizer, a data race detector.
>>> >>>>> + Copyright (C) 2011 Free Software Foundation, Inc.
>>> >>>>> + Contributed by Dmitry Vyukov <dvyu...@google.com>
>>> >>>>
>>> >>>> Careful, you've got double applied patches there.
>>> >>>>
>>> >>>>
>>> >>>> r~
>>
>>
>
