optimization/5768: sh codegen leaves stuff on stack

[Marcus Comstedt]

The following reply was made to PR optimization/5768; it has been noted by GNATS.

From: Marcus Comstedt <marcus@mc.pp.se>
To: "Arati Dikey" <AratiD@kpit.com>
Cc: <gcc-gnats@gcc.gnu.org>, <gcc-bugs@gcc.gnu.org>,
	<amylaar@gcc.gnu.org>, <amylaar@redhat.com>, <aoliva@redhat.com>
Subject: Re: optimization/5768: sh codegen leaves stuff on stack
Date: 07 Mar 2002 16:55:45 +0100

 "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