Steve Ellcey wrote:
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).
OK. Thanks. Nearly 100% certain we've got a flipped base/index.
And just to be certain, we've used a recent GCC trunk to compile an old
rev of gcc (2.7 era?), which is then segfaulting when it's trying to
compile code, right?
Assuming that's the case, I'd start by identifying the pseudos
corresponding to %r19 and %r8 and verify that the one associated with
%r8 has REG_POINTER set and %r19 is not yet. Then work backwards to
find out how REG_POINTER on the pseudo associated with %r8 was set.
Also be careful that tail merging hasn't merged two threads of control
which it thought were identical, but where in one thread of control
you've got %r8/%r19 as the base/index and in the other thread of control
you've got %r19/%r8 as the base/index (they are identical in
functionality on any sane target :-). I fixed that eons ago, but it's
always possible it's reared its ugly head again.
Jeff
