Re: optimization/5768: sh codegen leaves stuff on stack

Re: optimization/5768: sh codegen leaves stuff on stack

[rth]

Synopsis: sh codegen leaves stuff on stack

Responsible-Changed-From-To: unassigned->rth
Responsible-Changed-By: rth
Responsible-Changed-When: Mon Mar 25 10:10:24 2002
Responsible-Changed-Why:
    .

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5768

Re: optimization/5768: sh codegen leaves stuff on stack

[rth]

Synopsis: sh codegen leaves stuff on stack

State-Changed-From-To: feedback->closed
State-Changed-By: rth
State-Changed-When: Wed Mar 27 14:20:46 2002
State-Changed-Why:
    Reported fixed.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5768

Re: 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: rth@gcc.gnu.org
Cc: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
	rth@gcc.gnu.org
Subject: Re: optimization/5768: sh codegen leaves stuff on stack
Date: 27 Mar 2002 23:12:05 +0100

 rth@gcc.gnu.org writes:
 
 > Synopsis: sh codegen leaves stuff on stack
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: rth
 > State-Changed-When: Mon Mar 25 14:06:20 2002
 > State-Changed-Why:
 >     This appears to have been fixed for gcc 3.1.  Would you mind
 >     checking the prerelease snapshots to verify this for your
 >     real application as opposed to merely the test case?
 
 I have now compiled my application with the 20020325 snapshot, and
 both code inspection and test runs indicate that correct code is now
 indeed generated.
 
 
   // Marcus
 
 

Re: optimization/5768: sh codegen leaves stuff on stack

[rth]

Synopsis: sh codegen leaves stuff on stack

State-Changed-From-To: open->feedback
State-Changed-By: rth
State-Changed-When: Mon Mar 25 14:06:20 2002
State-Changed-Why:
    This appears to have been fixed for gcc 3.1.  Would you mind
    checking the prerelease snapshots to verify this for your
    real application as opposed to merely the test case?
    
    For the last test in this thread, I see r8 being restored
    in the delay slot of the jump, like so:
    
            jmp     @r4
            mov.l   @r15+,r8

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5768

Re: 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
 
 

RE: optimization/5768: sh codegen leaves stuff on stack

[Arati Dikey]

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

From: "Arati Dikey" <AratiD@kpit.com>
To: "Marcus Comstedt" <marcus@mc.pp.se>
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: Thu, 7 Mar 2002 10:54:23 +0530

 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.
 
 
 thanks in advance
 Arati Dikey
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Free download of GNUSH tool chain for Hitachi's SH Series.
 The following site also offers free support to European customers.
 Read more at http://www.kpit.com/products/support.htm.
 Latest version of GNUSH is released on Jan 1, 2002.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
 
 
 "Arati Dikey" <AratiD@kpit.com> writes:
 
 > hi !
 > 
 > This problem is caused by the following patch.
 > http://gcc.gnu.org/ml/gcc-cvs/2001-09/msg00359.html
 > 
 > If you reverse it and rebuild the tool chain,the problem disappears.
 
 A follow up:
 
 Yes, this problem disappears, but other problems appear instead.
 The program (not the minimal testcase in the PR, but my real program)
 now crashes in other places instead.
 
 So just reversing this patch is not a complete solution.
 
 
   // Marcus
 
 
 

Re: 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>
Subject: Re: optimization/5768: sh codegen leaves stuff on stack
Date: 06 Mar 2002 23:56:44 +0100

 "Arati Dikey" <AratiD@kpit.com> writes:
 
 > hi !
 > 
 > This problem is caused by the following patch.
 > http://gcc.gnu.org/ml/gcc-cvs/2001-09/msg00359.html
 > 
 > If you reverse it and rebuild the tool chain,the problem disappears.
 
 A follow up:
 
 Yes, this problem disappears, but other problems appear instead.
 The program (not the minimal testcase in the PR, but my real program)
 now crashes in other places instead.
 
 So just reversing this patch is not a complete solution.
 
 
   // Marcus
 
 

optimization/5768: sh codegen leaves stuff on stack

[marcus]

>Number:         5768
>Category:       optimization
>Synopsis:       sh codegen leaves stuff on stack
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Sat Feb 23 19:36:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Marcus Comstedt
>Release:        3.0.4
>Organization:
>Environment:
System: SunOS continuity 5.8 Generic_108528-10 sun4m sparc SUNW,SPARCstation-10
Architecture: sun4

	
host: sparc-sun-solaris2.8
build: sparc-sun-solaris2.8
target: sh-unknown-elf
configured with: ../configure --target=sh-elf --with-newlib
>Description:
	When using enough optimization options, the SuperH backend
	can produce code that chains to another function without
	removing its own stackframe.

	Needless to say, this causes the program to go haywire.

	Well, source code should go into the next section, so not
	much more to say here, except that the problem exists in both
	3.0.3 and 3.0.4.

>How-To-Repeat:

	Example program:

	---8<--- foo.c ---8<---

	int x[2];

	void foo()
	{
	  int i;
	  for(i = 0; i<2; i++ )
	    if(x[i]) {
	      bar();
	      return;
	    }
	}
 
	---8<---

	Compile with

	sh-elf-gcc -S -O2 -fomit-frame-pointer -funroll-loops foo.c -o foo.s

	and this is the result:

	---8<--- foo.s ---8<---

		.file	"foo.c"
		.text
		.align 2
		.global	_foo
		.type	_foo,@function
	_foo:
		mov.l	.L17,r1
		mov.l	@r1+,r2
		sts.l	pr,@-r15
		tst	r2,r2
		mov.l	.L18,r3
		bf	.L15
		mov.l	@r1,r2
		tst	r2,r2
		bf	.L16
		lds.l	@r15+,pr
		rts	
		nop
		.align 2
	.L15:
		jmp	@r3
		nop
		.align 2
	.L16:
		jmp	@r3
		nop
	.L19:
		.align 2
	.L17:
		.long	_x
	.L18:
		.long	_bar
	.Lfe1:
		.size	_foo,.Lfe1-_foo
		.comm	_x,8,4
		.ident	"GCC: (GNU) 3.0.4"

	---8<---

	The code at .L15 and .L16 is obviously faulty, as it never
	removes the saved value of pr from the stack.

>Fix:
	Compile with less optimization.  :-6
>Release-Note:
>Audit-Trail:
>Unformatted: