[Bug target/44606] Wrong SPE floating point during computation
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
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
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=gccview=revrev=169452 Log: gcc/ Backport from mainline: 2010-12-30 Nathan Froyd froy...@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 froy...@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
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=gccview=revrev=169465 Log: gcc/ Backport from mainline: 2010-12-30 Nathan Froyd froy...@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 froy...@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
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
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=168347r2=168346pathrev=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
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=gccview=revrev=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
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 compileinstall 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
--- 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
--- 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
--- 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
--- 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=21605action=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
--- 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=21606action=view) Makefile for test.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
[Bug target/44606] Wrong SPE floating point during computation
--- 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.00 .21 2700.00 .23 2916.00 .24 3132.00 .26 3348.00 - .7 954.00 .8 1050.00 .9 1146.00 .10 1242.00 .10 1338.00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606
