This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2
- From: "warren_baird at cimmetry dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 5 Sep 2003 22:10:33 -0000
- Subject: [Bug optimization/11753] %o7 register being used immediately in the delay slot before a call with -O2
- References: <20030731185137.11753.warren_baird@cimmetry.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
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?