[Bug optimization/11683] New: SH Optimizer creates incorrect code

[Bug optimization/11683] New: SH Optimizer creates incorrect code

[schwartz_m_ at hotmail dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11683

           Summary: SH Optimizer creates incorrect code
           Product: gcc
           Version: 3.2.2
            Status: UNCONFIRMED
          Severity: critical
          Priority: P1
         Component: optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: schwartz_m_ at hotmail dot com
                CC: gcc-bugs at gcc dot gnu dot org,schwartz_m_ at hotmail
                    dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh-hitachi-hms

The following is an example of how the SH4 optimizer creates incorrect 
optimized code which results in a memory overrun. The bug is recreated using 
the following simple program:

------------------------ bug.cc -----------------------------

void bar( int x );

int foo( void )
{
  int x[50];
  int y, z;

  while( true ) {
    asm volatile( " \n" : : : "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", 
		  "r8", "r9", "r10", "r11", "r12", "r13" );
    y -= z;
    bar( y );
  }
}

-------------------- Compiler command -----------------------

sh-hitachi-hms-gcc -g "-Wa,-ahl" -Wall -ansi -m4-nofpu -O2 -fno-common -pipe -
fcheck-new -fmessage-length=0 -Wno-non-template-friend -fno-exceptions -fno-
rtti -c -o bug.o bug.cc -save-temps -v > bug.lst

-------------------- Compiler output (with -v) --------------

sh-hitachi-hms-gcc: warning: -pipe ignored because -save-temps specified
Reading specs from /home/users/gnu/gcc-3.2.2/installation/sh/lib/gcc-lib/sh-
hitachi-hms/3.2.2/specs
Configured with: ../gcc-3.2.2/configure --target=sh-hitachi-hms --
prefix=/home/users/gnu/gcc-3.2.2/installation/sh --with-gnu-as --with-gnu-ld --
with-headers=/home/users/gnu/gcc-3.2.2/include/madan-orig --enable-
languages=c,c++
Thread model: single
gcc version 3.2.2
 /home/users/gnu/gcc-3.2.2/installation/sh/lib/gcc-lib/sh-hitachi-
hms/3.2.2/cpp0 -lang-c++ -D__GNUG__=3 -D__DEPRECATED -D__STRICT_ANSI__ -
trigraphs -$ -v -D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=2 -
D__GXX_ABI_VERSION=102 -D__sh__ -Acpu=sh -Amachine=sh -D__OPTIMIZE__ -
D__STDC_HOSTED__=1 -D__sh3__ -D__SH4_NOFPU__ -D__SIZE_TYPE__=unsigned int -
D__PTRDIFF_TYPE__=int bug.cc -Wall -Wno-non-template-friend bug.ii
GNU CPP version 3.2.2 (cpplib) (Hitachi SH)
ignoring nonexistent directory "/home/users/gnu/gcc-3.2.2/installation/sh/sh-
hitachi-hms/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/users/gnu/gcc-3.2.2/installation/sh/include/c++/3.2.2
 /home/users/gnu/gcc-3.2.2/installation/sh/include/c++/3.2.2/sh-hitachi-hms
 /home/users/gnu/gcc-3.2.2/installation/sh/include/c++/3.2.2/backward
 /home/users/gnu/gcc-3.2.2/installation/sh/include
 /home/users/gnu/gcc-3.2.2/installation/sh/lib/gcc-lib/sh-hitachi-
hms/3.2.2/include
 /home/users/gnu/gcc-3.2.2/installation/sh/sh-hitachi-hms/sys-include
End of search list.
 /home/users/gnu/gcc-3.2.2/installation/sh/lib/gcc-lib/sh-hitachi-
hms/3.2.2/cc1plus -fpreprocessed bug.ii -trigraphs -$ -quiet -dumpbase bug.cc -
m4-nofpu -ansi -g -O2 -Wall -Wno-non-template-friend -ansi -version -fno-
common -fcheck-new -fmessage-length=0 -fno-exceptions -fno-rtti -o bug.s
GNU CPP version 3.2.2 (cpplib) (Hitachi SH)
GNU C++ version 3.2.2 (sh-hitachi-hms)
        compiled by GNU C version 3.2.2.
bug.cc: In function `int foo()':
bug.cc:5: warning: unused variable `int x[50]'
bug.cc:6: warning: `int y' might be used uninitialized in this function
bug.cc:6: warning: `int z' might be used uninitialized in this function
 /home/users/gnu/gcc-3.2.2/installation/sh/lib/gcc-lib/sh-hitachi-
hms/3.2.2/../../../../sh-hitachi-hms/bin/as -ahl -o bug.o bug.s

------------------------ bug.lst (partial) ------------------

  11:bug.cc        ****     y -= z;
  27              		.ln	8
  28 0016 900B     		mov.w	L6,r0
  29 0018 6103     		mov	r0,r1
  30 001a 31EC     		add	r14,r1
  31 001c 5213     		mov.l	@(12,r1),r2
  32 001e 5114     		mov.l	@(16,r1),r1
  33 0020 3218     		sub	r1,r2
  34 0022 1123     		mov.l	r2,@(12,r1)

  42              		.align 1
  43              	L6:
  44 0030 00BC     		.short	188

Note that in line 32, register r1 is clobbered, while in line 34 it is used as 
if it was not clobbered. This causes a memory overrun.

The following is also known about the bug:
1) It also happens in .c files.
2) It also happens with -O1. In fact, I couldn't find a specific optimization, 
which when removed, causes the bug to disappear.
3) This also happens in gcc 3.2.3.
4) The bug won't happen when the stack is used with less than 128 bytes.

Please adivse as to possible workarounds or patches.

Thanks,

Moshe Schwartz

[Bug optimization/11683] SH Optimizer creates incorrect code

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11683


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
             Status|UNCONFIRMED                 |WAITING
           Keywords|                            |wrong-code
           Priority|P1                          |P2
   Target Milestone|3.4                         |---


------- Additional Comments From pinskia at physics dot uc dot edu  2003-07-27 13:33 -------
On the mainline (20030718) and in 3.3.1 (20030714), gcc produces code where it looks 
like it does not clober used registers.
mainline:
.L2:
        mov.w   .L5,r1
        add     r14,r1
        mov.l   @(12,r1),r2
        mov.w   .L6,r0
        mov.l   @(16,r1),r1
        sub     r1,r2
        mov.l   r2,@(r0,r14)
        mov     r2,r4
        mov.l   .L7,r2
        jsr     @r2
3.3.1:
.L5:
         

        mov.w   .L6,r1
        add     r14,r1
        mov.l   @(12,r1),r2
        mov.w   .L7,r0
        mov.l   @(16,r1),r1
        sub     r1,r2
        mov.l   r2,@(r0,r14)
        mov     r2,r4
        mov.l   .L8,r2
        jsr     @r2

Can you try 3.3 or a snapshot of gcc to see if it is fixed for you?

[Bug optimization/11683] SH Optimizer creates incorrect code

[schwartz_m_ at hotmail dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11683



------- Additional Comments From schwartz_m_ at hotmail dot com  2003-07-29 16:34 -------
Thanks for the quick reply. I checked version 3.3 and it works fine. Since 3.3 
is a new branch (which has its risks), is there any patch or quick fix to be 
applied to the 3.2.2 or 3.2.3 which fixes this problem?

[Bug optimization/11683] SH Optimizer creates incorrect code

[schwartz_m_ at hotmail dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11683


schwartz_m_ at hotmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|                            |1

[Bug optimization/11683] SH Optimizer creates incorrect code

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11683


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


------- Additional Comments From pinskia at physics dot uc dot edu  2003-07-29 16:39 -------
None I know of, there have been many changes between 3.2.3 and 3.3 and we are no longer 
maintaining 3.2.x any more sorry.
Closing this as fixed since 3.2.x is no longer being maintained.