This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]