> If it aborts, as in calling abort, rather than segfaulting, then it's
> not a flipped base/index in a memory reference -- those almost always
> segfault. This is the case that most worries me about Andrew's patch.
Sorry I wasn't clearer, it is a segfault. Running under gdb:
Program received signal SIGSEGV, Segmentation fault
si_code: 0 - SEGV_UNKNOWN - Unknown Error.
0x40000000000e61e4 in life_analysis (f=<not available>, nregs=1680)
at flow.c:1166
1166 basic_block_live_at_end[i][j] |= x;
>From disassembly:
;;; 1166 basic_block_live_at_end[i][j] |= x;
0x40000000000e61e0 <life_analysis+0xe88>: ldd,s %ret0(%r20),%r19
0x40000000000e61e4 <life_analysis+0xe8c>: ldw %r19(%r8),%r31
0x40000000000e61e8 <life_analysis+0xe90>: add,l %r19,%r8,%r19
0x40000000000e61ec <life_analysis+0xe94>: or %r31,%r6,%r31
(gdb) i r
flags: 2f000041
r3: 800003ffbfff9600 r4: 8000000100017c80
r5: 80000000 r6: 0
r7: 800003ffbffff790 r8: 0
r9: 800000010001bec8 r10: 0
r11: 800000010001be10 r12: 800003ffbfe8a000
r13: 800000010001c2ec r14: 800003ffbfffda90
r15: 800003ffbfe89fc0 r16: 690
r17: 4000000000033b94 r18: 4000000000033bb8
arg7/r19: 8000000100220438 arg6/r20: 800003ffbfffcc30
arg5/r21: 0 arg4/r22: 800003ffbfe9c748
arg3/r23: 800003ffbfff9610 arg2/r24: 0
arg1/r25: 800003ffbfff9608 arg0/r26: 1ac
dp/gp/r27: 8000000100017c80 ret0/r28: 1ac
ret1/ap/r29: 800003ffbffff790 sp/r30: 800003ffbffff7c0
mrp/r31: 0 sar/cr11: 3c
If I am reading things right, the use of r8 and r19 in the ldw
instruction are switched around. And in fact, when I created an
assembly language file, swapped them around by hand, and then assembled
the result and built an executable, everything seemed to work OK (I did
not get a segfault).
Steve Ellcey
[EMAIL PROTECTED]
