Compile the attached test files with: m68k-elf-gcc -O2 -fno-common -ffixed-a2 -m5200 -S -o yy.s yy.c -dp -da And in the ouptut of yy.c.21.greg, you'll find: (insn 492 283 284 (set (reg:SI 1 %d1) (const_int 1 [0x1])) 30 {*m68k.md:993} (nil) (nil)) (insn 284 492 285 (set (mem:SI (plus:SI (reg/f:SI 14 %a6) (const_int -40 [0xffffffd8])) [26 rotate S4 A16]) (plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6) (const_int -40 [0xffffffd8])) [26 rotate S4 A16]) (reg:SI 1 %d1))) 99 {*addsi3_5200} (nil) (nil)) But the 'rotate' variable is a *short*, so the 'set(mem:SI' will overwrite the adjacent variable on the stack. In fact the statement *increments* the 'fs' varaible which is at offset -38 from the frame... Release: gcc-3.2 Environment: --target=m68k-elf How-To-Repeat: m68k-elf-gcc -O2 -fno-common -ffixed-a2 -m5200 -S -o yy.s yy.c -dp -da
From: Peter Barada <pbarada@mail.wm.sps.mot.com> To: gcc-gnats@gcc.gnu.org Cc: Peter.Barada@motorola.com Subject: Re: target/8309:m68k-elf-gcc -m5200 produces erroneous SImode set of short varaible on stack Date: Tue, 29 Oct 2002 18:49:50 -0500 I've culled a much smaller testcase that fails on the trunk and the 3.2 branch. I'm backsearching the trunk to see when this bug was introduced, and have found the bug existed back at 2000/02/01, but doesn't show itself at 1999/01/01, so I'll try to narrow it down. #define SMALLER_TESTCASE /* make the testcase *very* small */ extern void foo(); void foo(a,b,c,d,e,f,g,h,i,j,k,l) short a,b,c,d,e,f,g,h,i,j,k,l; { short m,n,o,p,q,r,s #ifndef SMALLER_TESTCASE ,t,u,v #endif ; for (m=0; m<a; ++m) { for (n=m; n<b; ++n) { for (o=n; o<c; ++o) { for (p=o; p<d; ++p) { for (q=p; q<e; ++q) { for (r=q; r<f; ++r) { for (s=r; s<g; ++s) { #ifndef SMALLER_TESTCASE for (t=s; t<h; ++t) { for (u=t; u<i; ++u) { for (v=u; v<j; ++v) { #endif foo2(m,n,o,p,q ,r,s #ifndef SMALLER_TESTCASE ,t,u,v #endif ); } } #ifndef SMALLER_TESTCASE } } } #endif } } } } } }
From: Dara Hazeghi <dhazeghi@yahoo.com> To: gcc-gnats@gcc.gnu.org, Peter.Barada@motorola.com Cc: Subject: Re: target/8309: [3.2/? regression][m68k] m68k-elf-gcc -m5200 produces erroneous SImode set of short varaible on stack Date: Fri, 9 May 2003 16:37:33 -0700 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- trail&database=gcc&pr=8309 Hello, you reported this bug about 6 months ago. Can you confirm whether it's still present in 3.3 branch and mainline today? Thanks, Dara
State-Changed-From-To: open->feedback State-Changed-Why: See Dara's question.
From: Peter Barada <pbarada@mail.wm.sps.mot.com> To: giovannibajo@libero.it, Peter.Barada@motorola.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Subject: Re: target/8309: [3.2/? regression][m68k] m68k-elf-gcc -m5200 produces erroneous SImode set of short varaible on stack Date: Mon, 12 May 2003 11:48:55 -0400 >you reported this bug about 6 months ago. Can you confirm whether it's >still present in 3.3 branch and mainline today? Thanks, Ok, I pulled out the prerelease of gcc-3.3 and I still see this problem: [pbarada: /tmp] > /tmp/m68k-elf-3.3/bin/m68k-elf-gcc -v Reading specs from /tmp/m68k-elf-3.3/lib/gcc-lib/m68k-elf/3.3/specs Configured with: /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.3-20030508/configure --target=m68k-elf --prefix=/tmp/m68k-elf-3.3 --enable-languages=c --with-local-prefix=/tmp/m68k-elf-3.3/m68k-elf --without-headers --with-newlib --disable-shared --verbose Thread model: single gcc version 3.3 20030509 (prerelease) [pbarada: /tmp] > /tmp/m68k-elf-3.3/bin/m68k-elf-gcc -O2 -fno-common -ffixed-a2 -m5200 -S -o yy.s yy.c -dp -da yy.c.11.gcse: (insn 230 228 231 9 0x4001f420 (set (reg:SI 94) (plus:SI (subreg:SI (reg/v:HI 40) 0) (const_int 1 [0x1]))) 100 {*addsi3_5200} (nil) (nil)) (insn 231 230 232 9 0x4001f420 (set (reg/v:HI 40) (subreg:HI (reg:SI 94) 2)) 33 {*m68k.md:1024} (nil) (nil)) yy.c.23.lreg: (insn 231 230 232 10 0x4001f420 (set (subreg:SI (reg/v:HI 40) 0) (plus:SI (subreg:SI (reg/v:HI 40) 0) (const_int 1 [0x1]))) 100 {*addsi3_5200} (nil) (nil)) (insn 232 231 235 10 0x4001f420 (set (reg/f:SI 15 %sp) (plus:SI (reg/f:SI 15 %sp) (const_int 8 [0x8]))) 100 {*addsi3_5200} (nil) (nil)) yy.c.24.greg: (note 230 228 371 10 NOTE_INSN_DELETED) (insn 371 230 231 10 (nil) (set (reg:SI 1 %d1) (const_int 1 [0x1])) 30 {*m68k.md:993} (nil) (nil)) (insn 231 371 232 10 0x4001f420 (set (mem:SI (plus:SI (reg/f:SI 14 %a6) (const_int -38 [0xffffffda])) [23 rotate S4 A16]) (plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6) (const_int -38 [0xffffffda])) [23 rotate S4 A16]) (reg:SI 1 %d1))) 100 {*addsi3_5200} (nil) (nil)) Note that in yy.c.11.gcse insn 231 was (set (mem:HI...)), and in yy.c.24.greg is (set (mem:SI...))
From: Peter Barada <pbarada@mail.wm.sps.mot.com> To: giovannibajo@libero.it, Peter.Barada@motorola.com, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Subject: Re: target/8309: [3.2/? regression][m68k] m68k-elf-gcc -m5200 produces erroneous SImode set of short varaible on stack Date: Mon, 12 May 2003 15:51:26 -0400 Ist still broken on the mainline: [pbarada: /tmp] > /home/mylocal/uberbaum-m68k-elf/bin/m68k-elf-gcc -v Reading specs from /home/mylocal/uberbaum-m68k-elf/lib/gcc-lib/m68k-elf/3.4/specs Configured with: /home/pbarada/work/cvs-gnu/uberbaum/configure --target=m68k-elf --prefix=/home/mylocal/uberbaum-m68k-elf --with-gcc-version-trigger=/home/pbarada/work/cvs-gnu/uberbaum/gcc/version.c : (reconfigured) : (reconfigured) /home/pbarada/work/cvs-gnu/uberbaum/configure --target=m68k-elf --prefix=/home/mylocal/uberbaum-m68k-elf --with-gcc-version-trigger=/home/pbarada/work/cvs-gnu/uberbaum/gcc/version.c --enable-languages=c Thread model: single gcc version 3.4 20030512 (experimental) [pbarada: /tmp] > /home/mylocal/uberbaum-m68k-elf/bin/m68k-elf-gcc -O2 -fno-common -ffixed-a2 -m5200 -S -o yy.s yy.c -dp -da yy.c.25.lreg: (insn 230 229 231 10 0x4009486c (set (subreg:SI (reg/v:HI 40 [ rotate ]) 0) (plus:SI (subreg:SI (reg/v:HI 40 [ rotate ]) 0) (const_int 1 [0x1]))) 100 {*addsi3_5200} (nil) (nil)) yy.c.26.greg: (insn 374 229 230 10 (nil) (set (reg:SI 1 %d1) (const_int 1 [0x1])) 30 {*m68k.md:993} (nil) (nil)) (insn 230 374 231 10 0x4009486c (set (mem:SI (plus:SI (reg/f:SI 14 %a6) (const_int -38 [0xffffffda])) [23 rotate+0 S4 A16]) (plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6) (const_int -38 [0xffffffda])) [23 rotate+0 S4 A16]) (reg:SI 1 %d1))) 100 {*addsi3_5200} (nil) (nil))
State-Changed-From-To: feedback->analyzed State-Changed-Why: With small testcase
see comments for why I changed this to a regression.
Maybe it's just me, but just from looking at the RTL I'm not certain there's a bug here. Just writing to a short stack slot in SI mode looks just fine to me, since shorts are padded to 4 bytes on the stack on m68k, or it might be the result of store merging (except that we don't do that). So is there any test case with observably wrong behaviour? Falk
Postoned until GCC 3.3.2; m68k is not a primary platform.
Dunno why this is in waiting, but it shouldn't be. Should be...
Unconfirmed.
Dara the reason why this was in waiting was this question: "So is there any test case with observably wrong behaviour?" So the question still stands.
No feedback in 3 months (T-16 days).
We are using rtems-4.6.0, opt "rtems-4.6" with GNU gcc compiler 3.2.3 on MCF5272 target and we encountered again a problem that seems PR 8309. This problem is very critical because all the code generated for coldfire family is unreliable and to find the cause of possible malfunction is very hard. Here a short description of we encountered: We compile with -O4 -fno-force-mem and a local variable declared as byte is managed in wrong mode. Here we show the C-code and the assembler generated by compiler: pInfo->InfoHw[0].Offset = offset+ p->Reg; move.b -0x0B(a6),d0 ; offset(a6),d0 move.b d0,-0x0F(a6) ; d0,-15(a6) ;ok <Offset> is a Byte move.b 0x1(a2),d6 ; 1(a2),d6 ext.w d6 add.l -0x10(a6),d6 ;add.w doesn't exist in coldfire move.w d6,0x6(a1) ;and using add.l it gets values ;stored from -0x10(a6) to -0x0d(a6) If we change the declaration of the local variable <offset>, from byte to short, the code becomes: pInfo->InfoHw[0].Offset = offset+p->Reg move.b 0x1(a2),d7 ; 1(a2),d7 ext.w d7 add.l a5,d7 ; offset,d7 move.w d7,0x6(a1) ; d7,EXTENDSFDF(a1) In this case compiler uses a register for the local variable <offset> and then the problem disappear.
Could you post a preprocessed testcase if it's not one of those that are mentioned in this PR? Thanks,
Reopened since still present on mainline: http://gcc.gnu.org/ml/gcc/2004-05/msg01264.html Proposed patch: http://gcc.gnu.org/ml/gcc/2004-05/msg01357.html
Retargeting to 3.4.1, being a regression on that release branch. Mark, there is a pending patch for this.
I'm not comfortable approving this patch, given that changes to reload have such great potential for causing problems on other targets. However, if someone more comfortable with reload approves the patch -- and tests it on at least one other target where the chnage would apply -- it's OK for 3.4.1.
*** Bug 13312 has been marked as a duplicate of this bug. ***
Fixed on mainline and 3.4-branch.
Fixed by: http://gcc.gnu.org/ml/gcc-cvs/2004-06/msg00463.html http://gcc.gnu.org/ml/gcc-cvs/2004-06/msg00464.html Bernie, you forgot mentioning the PR number in the ChangeLog. Can you please fix that?