User account creation filtered due to spam.

Bug 8309 - [3.3/3.4/4.0 regression][m68k] m68k-elf-gcc -m5200 produces erroneous SImode set of short varaible on stack
Summary: [3.3/3.4/4.0 regression][m68k] m68k-elf-gcc -m5200 produces erroneous SImode ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.2
: P3 normal
Target Milestone: 3.4.1
Assignee: Not yet assigned to anyone
URL:
Keywords: patch, wrong-code
: 13312 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-10-22 11:46 UTC by peter.barada
Modified: 2004-09-13 14:15 UTC (History)
4 users (show)

See Also:
Host:
Target: m68k-elf
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
yy.c (1.19 KB, text/plain)
2003-05-21 15:17 UTC, peter.barada
Details

Note You need to log in before you can comment on or make changes to this bug.
Description peter.barada 2002-10-22 11:46:00 UTC
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
Comment 1 pbarada 2002-10-29 18:49:50 UTC
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
           }
         }
       }
     }
   }
 }

Comment 2 Dara Hazeghi 2003-05-09 16:37:33 UTC
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
 
Comment 3 Giovanni Bajo 2003-05-10 07:48:19 UTC
State-Changed-From-To: open->feedback
State-Changed-Why: See Dara's question.
Comment 4 pbarada 2003-05-12 11:48:55 UTC
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...))

Comment 5 pbarada 2003-05-12 15:51:26 UTC
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))
 
 
Comment 6 Steven Bosscher 2003-05-13 06:21:31 UTC
State-Changed-From-To: feedback->analyzed
State-Changed-Why: With small testcase
Comment 7 Andrew Pinski 2003-05-26 01:32:58 UTC
see comments for why I changed this to a regression.
Comment 8 Falk Hueffner 2003-06-21 11:07:39 UTC
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
Comment 9 Mark Mitchell 2003-07-11 23:01:12 UTC
Postoned until GCC 3.3.2; m68k is not a primary platform.
Comment 10 Dara Hazeghi 2003-08-24 18:20:31 UTC
Dunno why this is in waiting, but it shouldn't be. Should be...
Comment 11 Dara Hazeghi 2003-08-24 18:20:52 UTC
Unconfirmed.
Comment 12 Andrew Pinski 2003-08-24 18:23:14 UTC
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.
Comment 13 Andrew Pinski 2003-09-05 01:51:56 UTC
No feedback in 3 months (T-16 days).
Comment 14 Fabrizio Pirovano 2004-03-08 15:57:10 UTC
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.

Comment 15 Kazu Hirata 2004-03-08 16:06:53 UTC
Could you post a preprocessed testcase if it's not one of those that are
mentioned in this PR?

Thanks,
Comment 16 Bernardo Innocenti 2004-05-28 17:08:08 UTC
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 
 
Comment 17 Giovanni Bajo 2004-06-06 03:44:35 UTC
Retargeting to 3.4.1, being a regression on that release branch.
Mark, there is a pending patch for this.
Comment 18 Mark Mitchell 2004-06-07 14:18:36 UTC
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.
Comment 19 Bernardo Innocenti 2004-06-10 08:03:20 UTC
*** Bug 13312 has been marked as a duplicate of this bug. ***
Comment 20 Bernardo Innocenti 2004-06-12 01:15:51 UTC
Fixed on mainline and 3.4-branch. 
 
Comment 21 Giovanni Bajo 2004-06-12 11:52:33 UTC
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?