[Bug target/44606] Wrong SPE floating point during computation

[Bug target/44606] Wrong SPE floating point during computation

[dvdkhlng at gmx dot de]

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

--- Comment #10 from David Kühling <dvdkhlng at gmx dot de> 2010-11-02 14:39:12 UTC ---
I can reproduce this bug with gcc-4_4-branch SVN HEAD, compiling gcc in
cross-compile mode and running the resulting executable with qemu-ppc. 
Instructions to reproduce everything without any PPC hardware involved (tested
on Ubuntu Maverick/AMD64):

Get a powerpcspe sysroot:

 apt-cross -a powerpcspe -S sid -m http://ftp.de.debian.org/debian-ports \
        libdb1-compat libdb4.8 libc6 libc6-dev linux-libc-dev \
    zlib1g zlib1g-dev libmpfr-dev
 apt-cross -a powerpcspe -S unreleased -m http://ftp.de.debian.org/debian-ports
\
        libdb1-compat libdb4.8 libc6 libc6-dev linux-libc-dev \
    zlib1g zlib1g-dev libmpfr-dev

(repeat a few times until all dependencies resolved)

get Debian SID binutils source, then compile&install in cross-compile mode:

 dpkg-source -x binutils_*.dsc
 cd binutils-* && \
        TARGET=powerpcspe fakeroot debian/rules binary-cross
 dpkg -i binutils-powepc-linux-gnuspe-*.deb

Get GCC from SVN and compile minimal C-only version:

 svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch
 mkdir -p build
    cd build && ../gcc-4_4-branch/configure \
        --target=powerpc-linux-gnuspe \
        -with-cpu=8548 --enable-e500_double --with-long-double-128 \
        --enable-languages=c --disable-multilib \
        --prefix=/usr --with-headers=/usr/powerpc-linux-gnuspe/include \
        --with-libs=/usr/powerpc-linux-gnuspe/lib 
    make -C build -j5

Compile test-cases available as attachments to this bug, i.e. test.c:

 build/gcc/xgcc \
    -B./build/gcc/ -B/usr/powerpc-linux-gnuspe/bin/ \
    -B/usr/powerpc-linux-gnuspe/lib/ \
    -isystem /usr/powerpc-linux-gnuspe/include \
    -isystem /usr/powerpc-linux-gnuspe/sys-include \
    -fverbose-asm -dA -O2 -o test test.c

Use Ubuntu's qemu user-space emulation to run resulting executable:

 rootfs=/usr/powerpc-linux-gnuspe
 /usr/bin/qemu-ppc -cpu 'MPC8548E_v21' \
        -E LD_LIBRARY_PATH=$rootfs/lib/ $rootfs/lib/ld.so.1 \
        ./test

Repeat the same with -O0 and note the difference.  This test fails for all the
3 .c files attached here.  Output for tc-resize.c matches the output documented
by Sebastian, so I'd say qemu is doing it right.

[Bug target/44606] Wrong SPE floating point during computation

[froydnj at gcc dot gnu.org]

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

--- Comment #11 from Nathan Froyd <froydnj at gcc dot gnu.org> 2010-12-30 15:47:46 UTC ---
Author: froydnj
Date: Thu Dec 30 15:47:43 2010
New Revision: 168347

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168347
Log:
gcc/
        PR target/44606
        * reload1.c (choose_reload_regs): Don't look for equivalences for
        output reloads of constant loads.

gcc/testsuite/
        PR target/44606
        * gcc.dg/pr44606.c: New test.


Added:
    trunk/gcc/testsuite/gcc.dg/pr44606.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/reload1.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/44606] Wrong SPE floating point during computation

[dvdkhlng at gmx dot de]

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

--- Comment #12 from David Kühling <dvdkhlng at gmx dot de> 2011-01-21 15:17:34 UTC ---
Ok, looks like the change to reload1.c introduced by GCC revision 168347
(author froydnj):

http://gcc.gnu.org/viewcvs/trunk/gcc/reload1.c?r1=168347&r2=168346&pathrev=168347

fixes the problem for me.  I just took that patch and applied it to a checkout
of the GCC 4.4 branch, now my test-case for this floating point bug passes!

[Bug target/44606] Wrong SPE floating point during computation

[froydnj at gcc dot gnu.org]

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

--- Comment #13 from Nathan Froyd <froydnj at gcc dot gnu.org> 2011-01-31 21:53:15 UTC ---
Author: froydnj
Date: Mon Jan 31 21:53:12 2011
New Revision: 169452

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169452
Log:
gcc/
    Backport from mainline:
    2010-12-30  Nathan Froyd  <froydnj@codesourcery.com>

        PR target/44606
        * reload1.c (choose_reload_regs): Don't look for equivalences for
        output reloads of constant loads.

gcc/testsuite/
    Backport from mainline:
    2010-12-30  Nathan Froyd  <froydnj@codesourcery.com>

        PR target/44606
        * gcc.dg/pr44606.c: New test.


Added:
    branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr44606.c
Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/reload1.c
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug target/44606] Wrong SPE floating point during computation

[froydnj at gcc dot gnu.org]

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

--- Comment #14 from Nathan Froyd <froydnj at gcc dot gnu.org> 2011-02-01 02:11:57 UTC ---
Author: froydnj
Date: Tue Feb  1 02:11:54 2011
New Revision: 169465

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169465
Log:
gcc/
    Backport from mainline:
    2010-12-30  Nathan Froyd  <froydnj@codesourcery.com>

        PR target/44606
        * reload1.c (choose_reload_regs): Don't look for equivalences for
        output reloads of constant loads.

gcc/testsuite/
    Backport from mainline:
    2010-12-30  Nathan Froyd  <froydnj@codesourcery.com>

        PR target/44606
        * gcc.dg/pr44606.c: New test.


Added:
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr44606.c
Modified:
    branches/gcc-4_4-branch/gcc/ChangeLog
    branches/gcc-4_4-branch/gcc/reload1.c
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog

[Bug target/44606] Wrong SPE floating point during computation

[froydnj at gcc dot gnu.org]

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

Nathan Froyd <froydnj at gcc dot gnu.org> changed:

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

--- Comment #15 from Nathan Froyd <froydnj at gcc dot gnu.org> 2011-02-01 02:12:33 UTC ---
Fixed everywhere.

[Bug target/44606] Wrong SPE floating point during computation

[bernds at gcc dot gnu.org]

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

Bernd Schmidt <bernds at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernds at gcc dot gnu.org

--- Comment #16 from Bernd Schmidt <bernds at gcc dot gnu.org> 2011-03-16 22:47:15 UTC ---
Does the testcase still test for the problem if you replace the declarations of
stderr etc. with "#include <stdio.h>"? This fails with link errors of the
"unresolved reference to stderr" variety on newlib targets.

[Bug target/44606] Wrong SPE floating point during computation

[gcc at breakpoint dot cc]

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

--- Comment #17 from Sebastian Andrzej Siewior <gcc at breakpoint dot cc> 2011-03-17 13:02:58 UTC ---
(In reply to comment #16)
> Does the testcase still test for the problem if you replace the declarations of
> stderr etc. with "#include <stdio.h>"? This fails with link errors of the
> "unresolved reference to stderr" variety on newlib targets.

As long as your stdio.h does not optimize fprintf away it should work :)

[Bug target/44606] Wrong SPE floating point during computation

[wd at denx dot de]

------- Comment #9 from wd at denx dot de  2010-09-22 18:50 -------
Known to work: 4.2.2 (from ELDK 4.2)
Known to fail: 4.4.1 (from CodeSourcery G++ Lite 4.4-254)


-- 


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

[Bug target/44606] Wrong SPE floating point during computation

[kyle at moffetthome dot net]

------- Comment #8 from kyle at moffetthome dot net  2010-09-11 15:06 -------
Is there anything else that any of us can do (dumps, testcases, etc) to help
get this bug tracked down and fixed?  If access to a native SPE system would
help I can set you up with remote access credentials to one of ours.

Cheers,
Kyle Moffett


-- 

kyle at moffetthome dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kyle at moffetthome dot net


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

[Bug target/44606] Wrong SPE floating point during computation

[froydnj at gcc dot gnu dot org]

------- Comment #7 from froydnj at gcc dot gnu dot org  2010-09-09 15:28 -------
The problem is in the register allocator.  What happens is that after register
allocation, we have something like:

  r27:DF = [r11:SI]
  ...
  r27:SI = 0
  ...

and then the first def gets deleted because it's obviously dead code.  I don't
know why the register allocator chooses r27 for the SImode pseudo.

Scheduling is necessary to trigger the bug, but it's not the problem.


-- 

froydnj at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |froydnj at gcc dot gnu dot
                   |                            |org


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

[Bug target/44606] Wrong SPE floating point during computation

[Kyle dot D dot Moffett at boeing dot com]

------- Comment #6 from Kyle dot D dot Moffett at boeing dot com  2010-08-31 14:04 -------
Created an attachment (id=21606)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21606&action=view)
Makefile for "test.c"


-- 


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

[Bug target/44606] Wrong SPE floating point during computation

[Kyle dot D dot Moffett at boeing dot com]

------- Comment #5 from Kyle dot D dot Moffett at boeing dot com  2010-08-31 14:03 -------
Created an attachment (id=21605)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21605&action=view)
Further stripped testcase with problematic section identified

Ok, I've spent a bit more time fiddling with this testcase, and I believe I can
display exactly where the bug happens.  In the attached "test.c" file, you can
see a section like this:

  saved_r = total_r;
  saved_g = total_g;
  saved_b = total_b;
  Minify(2*x + 10, 15.0);
  save2_r = total_r;
  save2_g = total_g;
  save2_b = total_b;

The "Minify()" macro is supposed to add nonzero values to total_[rgb] but when
compiled with -O2 (or -O1 and a few extra optimizations) the values of
save2_[rgb] are the same as those of saved_[rgb].

I'm also attaching a Makefile I used while testing this program.  In the
Makefile I enable -O1 and then turn off every optimization pass that is not
strictly necessary to reproduce the bug.  The Makefile simply builds 2 copies
of the program, one with -O0 and one with -O2, then runs them and compares
their output.

Some kind of loop optimization or unrolling seems to be involved.  The specific
optimizations which are mandatory for the bug to show up are below, if any of
these is turned off the bug seems to go away:
  -fdce
  -fguess-branch-probability
  -fschedule-insns
  -ftree-ch
  -ftree-dominator-opts
  -ftree-loop-optimize

Cheers,
Kyle Moffett


-- 


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

[Bug target/44606] Wrong SPE floating point during computation

[Kyle dot D dot Moffett at boeing dot com]

------- Comment #4 from Kyle dot D dot Moffett at boeing dot com  2010-07-16 18:48 -------
(In reply to comment #0)
> I attached two testcase which is stripped down graphicsmagick code.
> tc-resize2.c has a few instructions more than tc-resize.c. I belive the bug is 
> the same.

I was able to get similarly erroneous results with just "-O1 -fschedule-insns":
gcc -o tc0 -O0 -Wall -Wextra tc-resize.c
gcc -o tc1x -O1 -fschedule-insns -Wall -Wextra tc-resize.c
( ./tc0 ; echo "-"; ./tc1x; )
.19 2484.000000
.21 2700.000000
.23 2916.000000
.24 3132.000000
.26 3348.000000
-
.7 954.000000
.8 1050.000000
.9 1146.000000
.10 1242.000000
.10 1338.000000


-- 


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