On Thu, Nov 3, 2011 at 6:31 AM, <dvyu...@google.com> wrote:
> On 2011/11/01 16:59:04, davidxl wrote:
>>
>> that means some existing bugs get exposed.
>
> It is quite likely.
>
>> Your previous version
>> simply skipped the target mem refs.
>
> Hummm... how can non-handling of some expressions lead to crashes? I
> would expect that it just leads to non 100% memory access coverage...
Likely the way the memop is instrumented is buggy.
>
>> You will need to debug the
>> problem a little more.
>
> What I have is a tree with no type. I have no idea why it happens.
>
> (gdb) print t->common.typed->type
> $48 = (tree) 0x0
> (gdb) print t->common.typed
> $47 = {base = {code = SSA_NAME, side_effects_flag = 0, constant_flag =
> 0, addressable_flag = 0, volatile_flag = 0, readonly_flag = 0,
> unsigned_flag = 0, asm_written_flag = 0, nowarning_flag = 0, used_flag =
> 0, nothrow_flag = 1,
> static_flag = 0, public_flag = 0, private_flag = 0, protected_flag =
> 0, deprecated_flag = 0, saturating_flag = 0, default_def_flag = 0,
> lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0,
> lang_flag_4 = 0,
> lang_flag_5 = 0, lang_flag_6 = 0, visited = 0, packed_flag = 0,
> user_align = 0, nameless_flag = 0, expr_folded_flag = 0, spare = 0,
> address_space = 0}, type = 0x0}
For debugging purpose, you should use debug print functions in
tree-print.c and tree-pretty-print.c such as debug_tree,
debug_generic_expr, debug_generic_stmt etc to dump trees instead of
using raw gdb print. Here you have a SSA name without type -- it may
be created by the tsan instrumentation code.
David
>
>
>
>
>> David
>
>> On Tue, Nov 1, 2011 at 5:26 AM, <mailto:dvyu...@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/
>> >
>
>
>
> http://codereview.appspot.com/5303083/
>
