[Bug middle-end/37608] [4.4 Regression] libgcc2.c:1981: ICE: vector VEC(m em_ref_p,base) index domain error, in create_vop_ref_mapping_loop at tree-ssa-lo op-im.c:1519

danglin at gcc dot gnu dot org gcc-bugzilla@gcc.gnu.org
Mon Sep 22 02:54:00 GMT 2008



------- Comment #1 from danglin at gcc dot gnu dot org  2008-09-22 02:52 -------
After looking at this a bit, the problem seems to be in the register
allocation for this bit of code:

0x40000000005da2a8 <tree_ssa_lim+2688>: ldo 1(r4),ret0
0x40000000005da2ac <tree_ssa_lim+2692>: extrd,u r17,62,63,r17
0x40000000005da2b0 <tree_ssa_lim+2696>: b,l 0x40000000005d9ee0
<tree_ssa_lim+1720>,r0
0x40000000005da2b4 <tree_ssa_lim+2700>: extrd,u ret0,63,32,r4

After the last extrd,u, we have

(gdb) p/x $ret0
$5 = 0x80000001000e7859
(gdb) p/x $r4
$7 = 0xe7859

The above code corresponds to

static inline void
bmp_iter_next (bitmap_iterator *bi, unsigned *bit_no)
{
  bi->bits >>= 1;
  *bit_no += 1;
}

The value in r4 is wrong. r4 is used to save and restore the PIC register
across function calls.  The PIC register value is

(gdb) p/x $dp  
$27 = 0x80000001000e7858

Looking back, the last call which isn't inlined is to bitmap_set_bit in
record_vop_access.

0x40000000005da034 <tree_ssa_lim+2060>: copy dp,r4
0x40000000005da038 <tree_ssa_lim+2064>: ldd 8(ret0),r15
0x40000000005da03c <tree_ssa_lim+2068>: copy r9,ret1
0x40000000005da040 <tree_ssa_lim+2072>: b,l 0x40000000002142c0
<bitmap_bit_p>,rp
0x40000000005da044 <tree_ssa_lim+2076>: ldd 10(r11),r26
0x40000000005da048 <tree_ssa_lim+2080>: copy r4,dp

r4 doesn't change value from this point to the ICE.

I believe r4 is initialized, but it is clobbered by a multitude of calls
after initialization.  So, the question is why r4 was used in the first
place.  This would seem like another clobber related issue.  The PIC
call patterns all use a clobber to reserve r4.  However, Richard's patch,
<http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01433.html>, didn't resolve
the issue.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37608



More information about the Gcc-bugs mailing list