This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: optimization/5768: sh codegen leaves stuff on stack
- From: Marcus Comstedt <marcus at mc dot pp dot se>
- To: "Arati Dikey" <AratiD at kpit dot com>
- Cc: <gcc-gnats at gcc dot gnu dot org>, <gcc-bugs at gcc dot gnu dot org>,<amylaar at gcc dot gnu dot org>, <amylaar at redhat dot com>, <aoliva at redhat dot com>
- Date: 07 Mar 2002 16:55:45 +0100
- Subject: Re: optimization/5768: sh codegen leaves stuff on stack
- References: <69595093233BB547BB70CF5E492B63F214B198@sohm.kpit.com>
"Arati Dikey" <AratiD@kpit.com> writes:
> hi !
>
> Can you please give the details of how/where your actual program crashes
> ?
> My sample program worked after reversing the patch. So, how can I
> reproduce the
> problem you are facing ?
>
> For e.g
> What options are you giving to gcc ?
> Where does your program crash ?
>
> and whatever other details you can think of to give some insight into
> the problem.
Ok, I have now analyzed the new problem, and it's virtually the same
as the old one. You need a slightly more complicated function to
trigger it though:
--8<--
int x[2], y[2], sz;
void foo()
{
int i, n = sz;
for(i = 0; i<n; i++)
if(x[i]==y[i]) {
bar();
return;
}
}
--8<--
Compile with the same flags as before (-O2 -fomit-frame-pointer
-funroll-loops) and it makes the same mistake, it chains to the bar()
function without removing the stack frame. Although in this case the
problem is worse, since it doesn't even restore the old value of r8.
Generated code:
--8<--
.file "foo.c"
.text
.align 2
.global _foo
.type _foo,@function
_foo:
mov.l r8,@-r15
mov #0,r7
mov.l .L42,r1
mov.l @r1,r5
cmp/ge r5,r7
bt .L8
mov #3,r1
mov r5,r2
and r1,r2
mov #1,r1
mov.l .L43,r8
mov #0,r0
mov.l .L44,r6
cmp/ge r5,r1
mov.l .L45,r4
bt .L11
tst r2,r2
bt .L10
cmp/gt r1,r2
bf .L11
mov #2,r1
cmp/gt r1,r2
bf .L12
mov.l @(r0,r8),r2
mov #1,r7
mov.l @r6,r1
mov #4,r0
cmp/eq r1,r2
bt .L35
.L12:
mov.l @(r0,r8),r2
add #1,r7
mov.l @(r0,r6),r1
add #4,r0
cmp/eq r1,r2
bt .L36
.L11:
mov.l @(r0,r8),r2
mov.l @(r0,r6),r1
cmp/eq r1,r2
bt .L37
add #1,r7
add #4,r0
cmp/ge r5,r7
bt .L8
.L10:
mov r0,r3
add r8,r3
.align 2
.L7:
mov.l @r3,r2
mov.l @(r0,r6),r1
cmp/eq r1,r2
bt .L38
add #4,r0
mov.l @(r0,r6),r1
mov.l @(4,r3),r2
add #-4,r0
cmp/eq r1,r2
bt .L39
add #8,r0
mov.l @(r0,r6),r1
mov.l @(8,r3),r2
add #-8,r0
cmp/eq r1,r2
bt .L40
add #12,r0
mov.l @(r0,r6),r1
mov.l @(12,r3),r2
add #-12,r0
cmp/eq r1,r2
bt .L41
add #4,r7
add #16,r3
add #16,r0
cmp/ge r5,r7
bf .L7
.L8:
rts
mov.l @r15+,r8
.align 2
.L35:
jmp @r4
nop
.align 2
.L36:
jmp @r4
nop
.align 2
.L37:
jmp @r4
nop
.align 2
.L38:
jmp @r4
nop
.align 2
.L39:
jmp @r4
nop
.align 2
.L40:
jmp @r4
nop
.align 2
.L41:
jmp @r4
nop
.L46:
.align 2
.L42:
.long _sz
.L43:
.long _x
.L44:
.long _y
.L45:
.long _bar
.Lfe1:
.size _foo,.Lfe1-_foo
.comm _x,8,4
.comm _y,8,4
.comm _sz,4,4
.ident "GCC: (GNU) 3.0.4"
--8<--
So it seems that the real problem remains, and the removal of the
patch only made the illusion of fixing the problem by reducing the
size of the stack frame to 0 in the more trivial test program.
// Marcus