This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [google] ThreadSanitizer instrumentation pass (issue 5303083)
- From: Xinliang David Li <davidxl at google dot com>
- To: dvyukov at google dot com, gcc-patches at gcc dot gnu dot org, davidxl at google dot com, dnovillo at google dot com, kcc at google dot com, reply at codereview dot appspotmail dot com
- Date: Tue, 1 Nov 2011 09:59:03 -0700
- Subject: Re: [google] ThreadSanitizer instrumentation pass (issue 5303083)
- References: <20cf303f67c29b10f604b0ab767a@google.com>
that means some existing bugs get exposed. Your previous version
simply skipped the target mem refs. You will need to debug the
problem a little more.
David
On Tue, Nov 1, 2011 at 5:26 AM, <dvyukov@google.com> wrote:
> On 2011/10/31 06:08:34, davidxl wrote:
>>
>> http://codereview.appspot.com/5303083/diff/1/gcc/passes.c#newcode1423
>> gcc/passes.c:1423: NEXT_PASS (pass_tsan);
>> Move this to the same place as asan. Otherwise TARGET_MEM_REF won't be
>
> handled.
>
> After I moved the pass it started crashing:
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000718f94 in is_gimple_reg_type (t=0x7ffff771efa0)
> ? ?at gimple.c:2960
> 2960 ? ? ?return !AGGREGATE_TYPE_P (type);
> (gdb) bt
> #0 ?0x0000000000718f94 in is_gimple_reg_type (t=0x7ffff771efa0)
> ? ?at gimple.c:2960
> #1 ?is_gimple_val (t=0x7ffff771efa0) at gimple.c:3028
> #2 ?0x00000000008a5d20 in verify_types_in_gimple_reference
> (expr=0x7ffff76b74c0, require_lvalue=false)
> ? ?at tree-cfg.c:2934
> #3 ?0x00000000008b2d4f in verify_gimple_in_cfg (fn=0x7ffff77c67e0)
> ? ?at tree-cfg.c:4382
> #4 ?0x0000000000a061d6 in verify_ssa (check_modified_stmt=true)
> ? ?at tree-ssa.c:924
> #5 ?0x00000000007f755c in execute_function_todo (data=Unhandled dwarf
> expression opcode 0xf3
> )
> ? ?at passes.c:1727
> #6 ?0x00000000007f7e4d in execute_todo (flags=34854) at passes.c:1758
> #7 ?0x00000000007fafda in execute_one_pass (pass=0x122a900)
> ? ?at passes.c:2104
>
> The code seems to be (however I am not 100% sure):
> ?D.3617_33 = MEM[(const uint64_t *)ctx_11(D)].nhkey[D.3612_26]{lb:
> D.3810_279 sz: 8};
>
>
> http://codereview.appspot.com/5303083/
>