------- 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
