Bug 8309

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?