Re: ia64-hpux crash in alias.c

[Jan Hubicka <jh at suse dot cz>]

> 
> Bootstrapping HEAD this morning I get
> 
> ...
> stage1/xgcc -Bstage1/ ... c-decl.c
> c-decl.c: In function `c_init_decl_processing':
> c-decl.c:2237: internal compiler error: Segmentation fault
> 
> GNU C version 3.5.0 20040126 (experimental) (ia64-hp-hpux11.23)
>         compiled by GNU C version 3.3.
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> 
> Program received signal SIGSEGV, Segmentation fault (si_code: 1).
> 0x43f3870:0 in get_addr (x=0x40364fb8)
>     at /home/zack/src/gcc/HEAD/vanilla/gcc/alias.c:1506
> 1506        if (CONSTANT_P (l->loc))
> (gdb) bt
> #0  0x43f3870:0 in get_addr (x=0x40364fb8)
>     at /home/zack/src/gcc/HEAD/vanilla/gcc/alias.c:1506
> #1  0x43ff170:0 in write_dependence_p (mem=0x78e500c0, x=0x78e501e0, writep=0, 
>     constp=1) at /home/zack/src/gcc/HEAD/vanilla/gcc/alias.c:2253
> #2  0x43ff7d0:0 in anti_dependence (mem=0x78e500c0, x=0x78e501e0)
>     at /home/zack/src/gcc/HEAD/vanilla/gcc/alias.c:2288
> #3  0x4fdfb10:0 in sched_analyze_1 (deps=0x7fffefc0, x=0x78dfbcc0, 
>     insn=0x78df57b0) at /home/zack/src/gcc/HEAD/vanilla/gcc/sched-deps.c:567
> #4  0x4fe1a10:0 in sched_analyze_insn (deps=0x7fffefc0, x=0x78dfbcc0, 
>     insn=0x78df57b0, loop_notes=0x0)
>     at /home/zack/src/gcc/HEAD/vanilla/gcc/sched-deps.c:820
> #5  0x4fe7120:0 in sched_analyze (deps=0x7fffefc0, head=0x78ea3d50, 
>     tail=0x78ea3f90) at /home/zack/src/gcc/HEAD/vanilla/gcc/sched-deps.c:1181
> #6  0x4fec500:0 in schedule_ebb (head=0x78ea3d50, tail=0x78ea3f90)
>     at /home/zack/src/gcc/HEAD/vanilla/gcc/sched-ebb.c:493
> #7  0x4fed280:0 in schedule_ebbs (dump_file=0x0)
>     at /home/zack/src/gcc/HEAD/vanilla/gcc/sched-ebb.c:622
> #8  0x4dda6f0:0 in ia64_reorg ()
>     at /home/zack/src/gcc/HEAD/vanilla/gcc/config/ia64/ia64.c:7500
> #9  0x4c9ef90:0 in rest_of_handle_machine_reorg (decl=0x792d1900, 
>     insns=0x78d5ab70) at /home/zack/src/gcc/HEAD/vanilla/gcc/toplev.c:2152
> (gdb) p l
> $1 = (struct elt_loc_list *) 0xafafafaf
> (gdb) p *v
> $4 = {value = 0x403d31c0, u = {val_rtx = 0xafafafaf, next_free = 0xafafafaf}, 
>   locs = 0xafafafaf, addr_list = 0xafafafaf, next_containing_mem = 0xafafafaf}
> (gdb) p x
> $6 = 0x40364fb8
> (gdb) up
> #1  0x43ff170:0 in write_dependence_p (mem=0x78e500c0, x=0x78e501e0, writep=0, 
>     constp=1) at /home/zack/src/gcc/HEAD/vanilla/gcc/alias.c:2253
> 2253      mem_addr = get_addr (XEXP (mem, 0));
> (gdb) p mem
> $8 = 0x78e500c0
> (gdb) pr
> (mem/s:SI (value:DI) [4 <variable>.names_last+0 S4 A32])
> 
> Any ideas?
See discussion with Andreas, there is latent problem in scheduler and
cselib iteration that got exposed by my checking code recently.
If you have the tree built is would be nice to know whether the attached
patch is enough to fix the problem.  Jakub has more involved sollution
but I am not quite sure it is needed.  If I understand it right, alias
analysis can use values that appears to be useless to cselib (since they
don't seem to be in any existing register/memory) to compute base
addresses.
I think that my patch would not make alias.c to be more conservative
than it used to be but I am not 100% sure this can't be improved - some
kind of saving information about how the value can be computed can be
usefull.  This is apparently what Jakub patch is doing, but I didn't had
time to look into it deeper yet.

Index: cselib.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cselib.c,v
retrieving revision 1.36
diff -c -3 -p -r1.36 cselib.c
*** cselib.c	24 Jan 2004 00:38:50 -0000	1.36
--- cselib.c	26 Jan 2004 19:04:44 -0000
*************** discard_useless_values (void **x, void *
*** 332,337 ****
--- 332,338 ----
  
    if (v->locs == 0)
      {
+       CSELIB_VAL_PTR (v->u.val_rtx) = NULL;
        htab_clear_slot (hash_table, x);
        unchain_one_value (v);
        n_useless_values--;