> On Sun, Mar 29, 2015 at 07:47:18AM +0200, Jan Hubicka wrote:
> > Hi,
> > I actually got idea how to make partitioning safe for named labels w/o
> > going the difficult
> > route of makeing them part of symbol table. Will look into that tonight or
> > tomorrow.
> > > Also there's a juicy ICE with that worked around:
> > >
> > > /home/andi/lsrc/linux/drivers/scsi/bfa/bfa_ioc.c: In function
> > > 'bfa_ioc_download_fw.constprop':
> > > /home/andi/lsrc/linux/drivers/scsi/bfa/bfa_ioc.c:1871:0: internal
> > > compiler error: Segmentation fault
> > > bfa_ioc_download_fw(struct bfa_ioc_s *ioc, u32 boot_type,
> > > ^
> > > 0x9753a7 crash_signal
> > > ../../gcc/gcc/toplev.c:383
> > > 0x76d7f2 maybe_remove_unused_call_args(function*, gimple_statement_base*)
> > > ../../gcc/gcc/gimple.c:2963
> > > 0x677bde cgraph_edge::redirect_call_stmt_to_callee()
> > > ../../gcc/gcc/cgraph.c:1478
> > > 0xedac5c inline_transform(cgraph_node*)
> > > ../../gcc/gcc/ipa-inline-transform.c:533
> >
> > This one looks odd though. Can you possibly looks for reason of the
> > segfault? I suppose
> > one of the pointers is NULL but don't quite see which one.
> > Is the call statemnt indirect? (try debug_gimple_stmt (stmt) and debug_tree
> > (decl))
>
> I only have a core dump. It is hard to catch LTO processes in a debugger.
Well, for small testcases easy way is to use --save-temps --verbose
and then restart the failing lto1 invocation with gdb --args
For long compilations one can also use gdb's attach but then all the stderr is
going
into the buffer (I hope we will eventually fix that - now it is not only anoying
but it also makes warnings to come out without highlighting)
>
> stmt seems to be an error node:
>
> $3 = {code = GIMPLE_ERROR_MARK, no_warning = 0, visited = 0, nontemporal_move
> = 0, plf = 0,
> modified = 0, has_volatile_ops = 0, pad = 0, subcode = 0, uid = 0, location
> = 2389971584,
> num_ops = 11155, bb = 0x2b92fed33c30, next = 0x2b92fed36cb8, prev =
> 0x2b92fed36d10}
Hmm, this indeed looks bogus. My guess is that the statement is removed?
If you run it in gdb, you can probably easy watchpoint to see who drops it to
GIMPLE_ERROR_MARK.
I believe it is just a conicidence it is error mark, because it is gimple code
0.
>
> decl appears NULL, not surprising for an error node:
>
> (gdb) p *(tree *)$rbx
> $6 = (tree) 0x0
>
>
> Also the compiler thinks the code is unreachable:
>
> 0x000000000076d7e2 <+114>: nopw 0x0(%rax,%rax,1)
> 0x000000000076d7e8 <+120>: mov 0x18(%rbx),%rax
> 0x000000000076d7ec <+124>: cmpw $0x7d,(%rax) <--- I think that's the
> check for void_type_node
> 0x000000000076d7f0 <+128>: je 0x76d830
> <maybe_remove_unused_call_args(function*, gimple_statement_base*)+192>
> => 0x000000000076d7f2 <+130>: mov 0x8,%rax <------- segfault on
> this
> 0x000000000076d7fa <+138>: ud2
>
> There was no earlier error printed though:
Hmm, it should not...
> (BTW it would be good to clean up the variable names in
> redirect_call_stmt_to_callee,
> there are two shadowing definitions of "new_stmt")
>
> p *e->call_stmt
> $9 = {<gimple_statement_with_memory_ops_base> =
> {<gimple_statement_with_ops_base> = {<gimple_statement_base> = {code =
> GIMPLE_ERROR_MARK, no_warning = 0, visited = 0, nontemporal_move = 0,
> plf = 0, modified = 0, has_volatile_ops = 0, pad = 0, subcode = 0,
> uid = 0,
> location = 2389971584, num_ops = 11155, bb = 0x2b92fed33c30, next =
> 0x2b92fed36cb8,
> prev = 0x2b92fed36d10}, use_ops = 0x0}, vdef = 0x0, vuse = 0x0},
> call_used = {
> anything = 0, nonlocal = 0, escaped = 0, ipa_escaped = 0, null = 0,
> vars_contains_nonlocal = 1, vars_contains_escaped = 1,
> vars_contains_escaped_heap = 1,
> vars = 0x2b935340f690}, call_clobbered = {anything = 0, nonlocal = 1,
> escaped = 1,
> ipa_escaped = 0, null = 0, vars_contains_nonlocal = 0,
> vars_contains_escaped = 0,
> vars_contains_escaped_heap = 0, vars = 0x280013bba}, u = {fntype =
> 0x2b92fed33d68,
> internal_fn = 4275256680}, op = {0x2b92fed3a1b8}}
>
> Wasn't able to find out how the error mark got into the cgraph without an
> error.
Yep, it looks like someone frogto to update call edge after replacing the
statement....
Putting the watchpoint will probably let us know who.
Honza
