public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/5768: sh codegen leaves stuff on stack
@ 2002-03-25 14:06 rth
0 siblings, 0 replies; 8+ messages in thread
From: rth @ 2002-03-25 14:06 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, marcus, 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/5768: sh codegen leaves stuff on stack
@ 2002-03-27 14:20 rth
0 siblings, 0 replies; 8+ messages in thread
From: rth @ 2002-03-27 14:20 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, marcus, 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/5768: sh codegen leaves stuff on stack
@ 2002-03-27 14:16 Marcus Comstedt
0 siblings, 0 replies; 8+ messages in thread
From: Marcus Comstedt @ 2002-03-27 14:16 UTC (permalink / raw)
To: rth; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/5768: sh codegen leaves stuff on stack
@ 2002-03-25 10:10 rth
0 siblings, 0 replies; 8+ messages in thread
From: rth @ 2002-03-25 10:10 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, marcus, nobody, 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/5768: sh codegen leaves stuff on stack
@ 2002-03-07 8:06 Marcus Comstedt
0 siblings, 0 replies; 8+ messages in thread
From: Marcus Comstedt @ 2002-03-07 8:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: optimization/5768: sh codegen leaves stuff on stack
@ 2002-03-06 21:36 Arati Dikey
0 siblings, 0 replies; 8+ messages in thread
From: Arati Dikey @ 2002-03-06 21:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: optimization/5768: sh codegen leaves stuff on stack
@ 2002-03-06 15:06 Marcus Comstedt
0 siblings, 0 replies; 8+ messages in thread
From: Marcus Comstedt @ 2002-03-06 15:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* optimization/5768: sh codegen leaves stuff on stack
@ 2002-02-23 21:47 marcus
0 siblings, 0 replies; 8+ messages in thread
From: marcus @ 2002-02-23 21:47 UTC (permalink / raw)
To: gcc-gnats
>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:
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-03-27 22:20 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-25 14:06 optimization/5768: sh codegen leaves stuff on stack rth
-- strict thread matches above, loose matches on Subject: below --
2002-03-27 14:20 rth
2002-03-27 14:16 Marcus Comstedt
2002-03-25 10:10 rth
2002-03-07 8:06 Marcus Comstedt
2002-03-06 21:36 Arati Dikey
2002-03-06 15:06 Marcus Comstedt
2002-02-23 21:47 marcus
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).