[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2

[warren_baird at cimmetry dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From warren_baird at cimmetry dot com  2003-09-05 22:10 -------
The problem seems to be that the wrong number is added to the %o7 register.  

Here is the code as it looks inside gdb:

    0xfb3437ac <MyFunc+1468>:	mov  1, %i0
    0xfb3437b0 <MyFunc+1472>:	call  0xfb3a415c <__JCR_LIST__+4900>
    0xfb3437b4 <MyFunc+1476>:	add  %o7, -3904, %o7
    0xfb3437b8 <MyFunc+1480>:	fcmped  %f6, %f8
    0xfb3437bc <MyFunc+1484>:	nop 


when we get back from the call to free, we end up at 0xfb342878 - which is in
the middle of some other function: 


(gdb) x/5i 0xfb3437b0 - 3904 +8
0xfb342878 <SomeOtherFunction+5644>:     nop 
0xfb34287c <SomeOtherFunction+5648>:     fbl,a   0xfb342774 <SomeOtherFunction+5384>
0xfb342880 <SomeOtherFunction+5652>:     fsubd  %f10, %f12, %f10
0xfb342884 <SomeOtherFunction+5656>:     b  0xfb341f98 <SomeOtherFunction+3372>
0xfb342888 <SomeOtherFunction+5660>:     sll  %l3, 1, %l6

And we crash almost immediately.   However, it looks like too large a value is
being written into the offset.  If we assume that -3904 was intended to be a
positive value (8192 - 3904), we see the code we expect to see.

(gdb) x/5i 0xfb3437b0 + 8192 - 3904 +8
0xfb344878 <MyFunc+5768>:	nop 
0xfb34487c <MyFunc+5772>:	ret 
0xfb344880 <MyFunc+5776>:	restore 
0xfb344884 <AnotherFunc>:	save  %sp, -128, %sp
0xfb344888 <AnotherFunc+4>:	clr  %i4

so it looks like the value that is being used is too large...  The question is
--- what can we do about it?  the preprocessed source I provided contains the
entire source code for the function in question.  Is that enough to figure out
why the optimization is being used, even though the value is too large?