Re: Optimize lto location stremaing

[Jan Hubicka <hubicka at ucw dot cz>]

> 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