public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: marcus@mc.pp.se
To: gcc-gnats@gcc.gnu.org
Subject: optimization/5768: sh codegen leaves stuff on stack
Date: Sat, 23 Feb 2002 21:47:00 -0000	[thread overview]
Message-ID: <20020224033018.E78E5C8@continuity.mc.pp.se> (raw)


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


             reply	other threads:[~2002-02-24  3:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-23 21:47 marcus [this message]
2002-03-06 15:06 Marcus Comstedt
2002-03-06 21:36 Arati Dikey
2002-03-07  8:06 Marcus Comstedt
2002-03-25 10:10 rth
2002-03-25 14:06 rth
2002-03-27 14:16 Marcus Comstedt
2002-03-27 14:20 rth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020224033018.E78E5C8@continuity.mc.pp.se \
    --to=marcus@mc.pp.se \
    --cc=gcc-gnats@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).