optimization/3227: ICE compiling X code on mips-linux

[wesolows@foobazco.org]

>Number:         3227
>Category:       optimization
>Synopsis:       ICE compiling X code on mips-linux
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          ice-on-legal-code
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 18 08:56:02 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Keith M Wesolowski
>Release:        gcc version 3.0
>Organization:
>Environment:
sparc-sun-linux hosting mips-linux.  Compiler compiled with:

Configured with: /home/wesolows/buildme/src/gcc/configure --prefix=/q/crossdev/mips-linux --with-newlib --disable-shared --enable-languages=c --target=mips-linux --srcdir=/home/wesolows/buildme/src/gcc

Problem also exists on a compiler compiled with threads and full glibc support.

>Description:
For minimal (yes, it really is minimal) test case attached, output is as follows:

[wesolows@galt:~]$ mips-linux-gcc -c -v -O kboom.i
Reading specs from /q/crossdev/mips-linux/lib/gcc-lib/mips-linux/3.0/specs
Configured with: /home/wesolows/buildme/src/gcc/configure --prefix=/q/crossdev/mips-linux --with-newlib --disable-shared --enable-languages=c --target=mips-linux --srcdir=/home/wesolows/buildme/src/gcc
Thread model: single
gcc version 3.0
 /q/crossdev/mips-linux/lib/gcc-lib/mips-linux/3.0/cc1 -fpreprocessed kboom.i -quiet -dumpbase kboom.i -O -version -o /tmp/ccdYLENh.s
GNU CPP version 3.0 (cpplib) (MIPS GNU/Linux with ELF)
GNU C version 3.0 (mips-linux)
        compiled by GNU C version 2.95.4 20010319 (Debian prerelease).
kboom.i: In function `cfbFillPoly1RectGeneral':
kboom.i:44: Internal compiler error in gen_add2_insn, at optabs.c:3741
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL: http://www.gnu.org/software/gcc/bugs.html > for instructions.

The code compiles with -O2, -O0, -Os, -O3, and fails with -O.  gcc 2.95.3 on sparc does not exhibit the problem, but that probably means nothing.  The 65536 in the test case can be any power of 2 greater than or equal to 65536, but if it is less, then the bug does not appear.
>How-To-Repeat:
int f();
void cfbFillPoly1RectGeneral ()
{
    long  *addr;
    int origin;
    int c;
    int x1, x2;
    int dx2;
    int e2;
    int step2;
    int sign2;
    int l;
    long mask;
    long rrop_and, rrop_xor;
        int my;
    origin =origin / 65536;
        my=f();
    for (;;)
    {
                if (x1 =  c - 1){
                        if (x1 >= 1){
                                sign2 = 1;
                        }else{
                                sign2 = -1;
                                step2 = x1;
                                dx2 = x1;
                        }
                }
                x2 += origin;
        x2 += step2;
                x2 += sign2;
        l = x2;
        c = l;
        *addr = *addr & rrop_and | mask;
        *addr = *addr & rrop_and ^ rrop_xor;
                addr++;
        mask = x1 + 1;
        *addr = *addr & rrop_and | mask;
        x2 += step2;
                if ((e2 += dx2) > 0){
                        x2 += sign2;
                }
    }
}
>Fix:
None currently known.  There are many possible workarounds; the code for example can be modified in ways that will make the problem disappear without changing the meaning.  Still, it is a bug.
>Release-Note:
>Audit-Trail:
>Unformatted: