[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
[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=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
--- 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 rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #5 from Kyle dot D dot Moffett at boeing dot com 2010-05-20
04:53 ---
I am not able to reproduce this with a cross-compiling GCC 4.4.3 or 4.4.4 built
from Debian sources. Configuration parameters for GCC 4.4.4 were:
-v
--with-pkgversion='Debian 4.4.4-2'
--with-bugurl='file:///usr/share/doc/gcc-4.4/README.Bugs'
--prefix=/usr
--enable-shared
--enable-multiarch
--enable-linker-build-id
--with-system-zlib
--libexecdir=/usr/lib
--without-included-gettext
--enable-threads=posix
--with-gxx-include-dir=/usr/powerpc-linux-gnuspe/include/c++/4.4.4
--program-suffix=-4.4
--enable-nls
--enable-clocale=gnu
--enable-libstdcxx-debug
--enable-objc-gc
--with-cpu=8548
--enable-e500_double
--with-long-double-128
--disable-multilib
--enable-checking=release
--program-prefix=powerpc-linux-gnuspe-
--includedir=/usr/powerpc-linux-gnuspe/include
--with-headers=/usr/powerpc-linux-gnuspe/include
--with-libs=/usr/powerpc-linux-gnuspe/lib
--build=x86_64-linux-gnu
--host=x86_64-linux-gnu
--target=powerpc-linux-gnuspe
CC=gcc
build_alias=x86_64-linux-gnu
host_alias=x86_64-linux-gnu
target_alias=powerpc-linux-gnuspe
--enable-languages=c,c++,fortran,objc,obj-c++
Versions are:
powerpc-linux-gnuspe-gcc-4.3 (Debian 4.3.4-10 with a patch to debian/rules)
4.3.4
powerpc-linux-gnuspe-gcc-4.4 (Debian 4.4.4-2 with a patch to debian/rules)
4.4.4
The C file was compiled as follows in both cases:
powerpc-linux-gnuspe-gcc -Werror -pthread -ftls-model=initial-exec -O2
-pthread -fPIC -DPIC tc.c -o tc.S -S -mcpu=8540 -O1 -fdump-rtl-all -c
I'm not very familiar with the RTL passes, but if somebody can tell me what
else to look for or test I'll go scrounge around to see if I can find what's
hiding the problem for me.
Cheers,
Kyle Moffett
--
Kyle dot D dot Moffett at boeing dot com changed:
What|Removed |Added
CC| |Kyle dot D dot Moffett at
| |boeing dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #7 from Kyle dot D dot Moffett at boeing dot com 2010-05-20 12:17 --- Created an attachment (id=20707) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20707&action=view) Assembled tc.c output from Debian-built powerpc-linux-gnuspe-gcc 4.3.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #8 from Kyle dot D dot Moffett at boeing dot com 2010-05-20 12:19 --- Created an attachment (id=20708) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20708&action=view) Assembled tc.c output from Debian-built powerpc-linux-gnuspe-gcc 4.4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #9 from Kyle dot D dot Moffett at boeing dot com 2010-05-20 12:29 --- Created an attachment (id=20710) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20710&action=view) Assembled tc.c output from Debian-built powerpc-linux-gnuspe-gcc 4.4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug rtl-optimization/44169] Wrong code while generating TLS offsets
--- Comment #10 from Kyle dot D dot Moffett at boeing dot com 2010-05-20 12:37 --- Ok, it looks like the bug was introduced in the 4.4 branch between 4.4.2 and 4.4.4, because my old GCC 4.4.2 compiler works, but the 4.4.4 I built yesterday after I noticed this report does not. If needed I can spend some time to track down exactly which optimization flag(s) cause the problem, but hopefully we've narrowed down the versions closely enough for it to be easy to find. :-D Cheers, Kyle Moffett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44169
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #3 from Kyle dot D dot Moffett at boeing dot com 2010-06-03 19:26 --- (In reply to comment #0) > So after looking at the code I saw now the following: > 1c24 <__floatdidf>: > 1c6c: 11 23 1a 2c evmergehi r9,r3,r3 > > This function is touching the complete 64bit r9 register > The code which calls it: > > 1a40: 91 21 00 20 stw r9,32(r1) > 1a44: 4e 80 04 21 bctrl # tell function which in turn calls > floatdidf > > 1a7c: 81 21 00 20 lwz r9,32(r1) > 1a80: 38 60 00 00 li r3,0 > 1a84: 7e 33 8b 78 mr r19,r17 > 1a88: 12 49 92 e1 efdsub r18,r9,r18 > 1a8c: 10 80 92 fa efdctsiz r4,r18 > 1a90: 12 49 4a 17 evmrr18,r9 > > So we just save the lower 32bit of r9 before calling the function and the > upper > 32bit are overwritten by efdsub. Ok, here's the e500 ABI user guide: http://www.freescale.com/files/32bit/doc/ref_manual/E500ABIUG.pdf According to that guide, we have the following usage of GPRs: Dedicated: r1 r2 r13 Nonvolatile: r14-r31 Volatile: r0 r3-r12 Then: Before a function changes the value in the upper word of any nonvolatile general register, rn, it shall save the 64-bit value in rn in the 64-bit general register save area 8*(32-n) bytes below the CR save area (plus any required padding). The 64-bit general save area shall have 8-byte alignment. And: Before a function changes the value in the lower word of any nonvolatile general register, rn, that has not already been saved in the 64-bit general register save area, it shall save the value in the lower word of rn in the word in the 32-bit general register save area 4*(32-n) bytes before the back chain word of the previous frame. So clearly the caller's assembly is wrong; it should be saving all 64-bits of r9 (volatile gpr) first. Cheers, Kyle Moffett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #4 from Kyle dot D dot Moffett at boeing dot com 2010-06-03 20:09 --- Ok, I have a trivial 19-line testcase that triggers the bug on my native Debian GCC 4.4.4-2+powerpcspe1 (with PR44169 fix) with -O0 and -O3. The compiler was built with: --with-cpu=8548 --enable-e500_double --with-long-double-128 In order to make it work on -O3 I had to split the "double z", "void problem()" and "int main()" into 3 separate files to prevent GCC from inlining everything. Compiled with: gcc -Wall -Wextra -Werror -ggdb3 -O0 -o testall testall.c Output (the two "main: a" lines should read the same): main: a = 78.463000 problem: a = 39.231500 main: a = 39.231476 Or with: gcc -Wall -Wextra -Werror -ggdb3 -O3 -o test.o -c test.c gcc -Wall -Wextra -Werror -ggdb3 -O3 -o test2.o -c test2.c gcc -Wall -Wextra -Werror -ggdb3 -O3 -o test3.o -c test3.c gcc -Wall -Wextra -Werror -ggdb3 -O3 -o test test.o test2.o test3.o Output: (again, "main" lines should be identical) main: a = 78.463000 problem: a = 39.231500 main: a = 78.462952 As you might imagine, a bug this bad triggers testsuite failures in MPFR, GMP, PostgreSQL, lapack, and basically everything else with a comprehensive floating-point test-suite. Cheers, Kyle Moffett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #6 from Kyle dot D dot Moffett at boeing dot com 2010-06-03 20:21 --- Created an attachment (id=20823) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20823&action=view) Combined trivial testcase (For -O0) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #7 from Kyle dot D dot Moffett at boeing dot com 2010-06-03 20:22 --- Created an attachment (id=20824) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20824&action=view) Multipart trivial testcase (For -O3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #8 from Kyle dot D dot Moffett at boeing dot com 2010-06-03 20:22 --- Created an attachment (id=20825) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20825&action=view) Multipart trivial testcase (For -O3) part 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #9 from Kyle dot D dot Moffett at boeing dot com 2010-06-03 20:22 --- Created an attachment (id=20826) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20826&action=view) Multipart trivial testcase (For -O3) part 3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #10 from Kyle dot D dot Moffett at boeing dot com 2010-06-03 20:26 --- Created an attachment (id=20827) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20827&action=view) Multipart trivial testcase objdump result (Built with -O0) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #11 from Kyle dot D dot Moffett at boeing dot com 2010-06-03 20:26 --- Created an attachment (id=20828) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20828&action=view) Multipart trivial testcase objdump result (Built with -O3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #12 from Kyle dot D dot Moffett at boeing dot com 2010-06-03 23:18 --- (From update of attachment 20823) Scratch my test cases... "register asm(...)" doesn't work the way I thought it did... Sebastian's test case is the only one that I've found that works. -- Kyle dot D dot Moffett at boeing dot com changed: What|Removed |Added Attachment #20823|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #13 from Kyle dot D dot Moffett at boeing dot com 2010-06-04 01:37 --- Created an attachment (id=20829) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20829&action=view) Updated tc-lossings-floats.c I sat down with GCC and vim for a couple hours narrowing down Sebastian's testcase. This file of ~100 lines exhibits the exact same problem as the original testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #14 from Kyle dot D dot Moffett at boeing dot com 2010-06-04 01:37 --- Created an attachment (id=20830) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20830&action=view) Updated tc-lossings-floats.objdump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #15 from Kyle dot D dot Moffett at boeing dot com 2010-06-04 02:17 --- Created an attachment (id=20831) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20831&action=view) Even tinier tc-lossings-floats.c Spent a bit more time on the testcase and made it even smaller. The bug goes away if I make any of the following changes: (1) Make "counter" a nonstatic local variable or "iter" a static global (2) Call dotell() directly instead of through a function pointer (3) Eliminate the references to frq_out->buf_start or prx_out->buf_start, even though they are always zero. -- Kyle dot D dot Moffett at boeing dot com changed: What|Removed |Added Attachment #20829|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #16 from Kyle dot D dot Moffett at boeing dot com 2010-06-04 02:17 --- Created an attachment (id=20832) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20832&action=view) Even tinier tc-lossings-floats.objdump -- Kyle dot D dot Moffett at boeing dot com changed: What|Removed |Added Attachment #20830|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #17 from Kyle dot D dot Moffett at boeing dot com 2010-06-04 17:24 --- Created an attachment (id=20840) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20840&action=view) Minimal test with -O1 I've managed to shrink this down to a 44-line testcase that fails with the options listed below. The code is the same but the failure mode is different; Specifically, I get this output: |RESET: 252.00 | 4294967296.00 |RESET: 504.00 | 4294967296.00 |RESET: 756.00 | 4294967296.00 |RESET: 1008.00 | 4294967296.00 |RESET: 1260.00 | 4294967296.00 |RESET: 1512.00 | 4294967296.00 |RESET: 1764.00 | 4294967296.00 |RESET: 2016.00 | 4294967296.00 |RESET: 2268.00 | 4294967296.00 => 2268.00 |RESET: 2520.00 | 4294967296.00 |RESET: 2772.00 | 4294967296.00 >From the code, the second floating point value on each line should be equal to the first float from the previous line. If I change the first "(unsigned long long)" cast to a "(long long)" cast, the bug goes away and I see the following (correct) output: |RESET: 252.00 | 0.00 |RESET: 504.00 | 252.00 |RESET: 756.00 | 504.00 |RESET: 1008.00 | 756.00 |RESET: 1260.00 | 1008.00 |RESET: 1512.00 | 1260.00 |RESET: 1764.00 | 1512.00 |RESET: 2016.00 | 1764.00 |RESET: 2268.00 | 2016.00 => 2268.00 |RESET: 2520.00 | 2268.00 |RESET: 2772.00 | 2520.00 The full list of compile options: -pipe \ -g \ -Wall \ -fmove-loop-invariants \ -fcaller-saves \ --param max-aliased-vops=100 \ --param avg-aliased-vops=1 \ --param max-fields-for-field-sensitive=0 \ --param loop-invariant-max-bbs-in-loop=1000 \ -O \ -fno-web \ -fno-rename-registers \ -fno-unroll-loops \ -fno-peel-loops \ -fno-split-ivs-in-unroller \ -fno-peephole \ -fno-dce \ -fno-dse \ -fno-unit-at-a-time \ -fno-omit-frame-pointer \ -fno-auto-inc-dec \ -fno-cprop-registers \ -fno-dce \ -fno-defer-pop \ -fno-delayed-branch \ -fno-dse \ -fno-guess-branch-probability \ -fno-if-conversion2 \ -fno-if-conversion \ -fno-inline-small-functions \ -fno-inline-functions-called-once \ -fno-early-inlining \ -fno-ipa-pure-const \ -fno-ipa-reference \ -fno-merge-constants \ -fno-split-wide-types \ -fno-tree-builtin-call-dce \ -fno-tree-ccp \ -fno-tree-ch \ -fno-tree-copyrename \ -fno-tree-dce \ -fno-tree-dominator-opts \ -fno-tree-dse \ -fno-tree-fre \ -fno-tree-sra \ -fno-tree-ter \ -fno-merge-constants \ -fno-branch-count-reg \ -fno-function-cse \ -fno-thread-jumps \ -fno-gcse \ -fno-rerun-cse-after-loop \ -fno-cse-skip-blocks \ -fno-cse-follow-jumps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #18 from Kyle dot D dot Moffett at boeing dot com 2010-06-04 17:24 --- Created an attachment (id=20841) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20841&action=view) Minimal test objdump with -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #21 from Kyle dot D dot Moffett at boeing dot com 2010-06-06 15:37 --- I was trying to strip down the testcase and try to see which optimization flags caused it. I started from -O2 and tried to see which -O2 flags (in addition to O1) were needed to cause the problem. From there I simplified the testcase as small as I could get it and turned off as many other optimizations as possible. As far as I can tell, it seems to be a combination of -fcaller-saves and the minimal CSE that -O1 always turns on (regardless of other -fno-* options). Part of the reason for the extra -fno-* compiler options was to prevent the compiler from moving registers around so much as I fiddled with the testcase, since the bug is only triggered when it allocates one of the 2 doubles in a register that is reused by one of the libgcc functions it calls. Other than that, I'm just grasping at straws... If somebody can debug this and fix both testcases before FreeScale gets back to us with a fix I'll ship them a case or two of their favorite beer (or whatever other beverage they'd prefer). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #23 from Kyle dot D dot Moffett at boeing dot com 2010-06-07 05:36 --- (In reply to comment #22) > Adding the following to config/rs6000/e500.h will likely fix the bug. > Testing.. Oh, very nice! Thanks for the speedy assistance on this! I've got my own test compiler building now; I'll let you know what the result is as soon as its done! Cheers, Kyle Moffett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #24 from Kyle dot D dot Moffett at boeing dot com 2010-06-07 05:44 --- Hmm, unfortunately in my preliminary testing this does not seem to fix either testcase. Cheers, Kyle Moffett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #27 from Kyle dot D dot Moffett at boeing dot com 2010-06-07 12:49 --- (In reply to comment #25) > Yes it seems the patch is not sufficient on 4.4. On mainline the code looks > good by inspection. (I don't have e500 hardware to run tests on.) If you'd like login access to one of our protoboards, just post an SSH public key on bugzilla and we'll set up port-forwarded access to one of our Debian buildd servers. We're thankful for all the assistance you've been able to provide. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #29 from Kyle dot D dot Moffett at boeing dot com 2010-06-07 18:28 --- Awesome!!! Both of our testcases that were failing pass with this patch applied! I'm not going to call it a 100% victory yet, I want to rebuild our native compilers and build-and-run the PostgreSQL, GMP and MPFR testsuites first. Here's hoping though! *crosses fingers* -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #30 from Kyle dot D dot Moffett at boeing dot com 2010-06-07 18:56 --- Ok, the cross-compiler built with this patch fails to build a native GCC for the target with the following ICE: ../../../src/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd128': ../../../src/libgcc/../libdecnumber/decLibrary.c:71: error: unrecognizable insn: (insn 6 5 7 2 ../../../src/libgcc/../libdecnumber/decLibrary.c:68 (set (subreg:TI (reg:TD 122 [ arg ]) 0) (reg:TI 123)) -1 (nil)) ../../../src/libgcc/../libdecnumber/decLibrary.c:71: internal compiler error: in extract_insn, at recog.c:2001 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #31 from Kyle dot D dot Moffett at boeing dot com 2010-06-08 04:24 --- Alan, Now that I've corrected all of my compiler issues, your first patch (the one quoted below) works like a charm. I still need to do the extensive archive-rebuild and testsuite run to verify that it completely works, but that will take a couple days. Looking good! Cheers, Kyle Moffett (In reply to comment #28) > /* When setting up caller-save slots (MODE == VOIDmode) ensure we >allocate space for DFmode. Save gprs in the correct mode too. */ > #define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \ > (TARGET_E500_DOUBLE && ((MODE) == VOIDmode || (MODE) == DFmode) \ >? DFmode \ >: choose_hard_reg_mode ((REGNO), (NREGS), false)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #32 from Kyle dot D dot Moffett at boeing dot com 2010-06-08 05:07 --- The first working patch (VOIDmode||DFmode) just successfully passed full GMP and MPFR testsuites on the e500 boards. PPL and EGLIBC are currently rebuilding. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #33 from Kyle dot D dot Moffett at boeing dot com 2010-06-08 06:48 --- EGLIBC and PPL are still building; I'm heading to sleep and I'll check on them later this morning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #35 from Kyle dot D dot Moffett at boeing dot com 2010-06-08 15:23 --- Hrm, well PPL still seems to be failing the "interval1" test, but I'm not sure that one's related as the part that fails is "test01". More info to come shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #36 from Kyle dot D dot Moffett at boeing dot com 2010-06-08 20:34 --- Ok, I'm pretty sure this is unrelated to this bug, but I still get one test-failure with PPL 0.10.2. The "interval1" test fails due to the "test01" subtest, apparently due to very slightly excessive "float" rounding errors (after 100 rounds of the equivalent of "x = (x + (2/x)) / 2" it approximates ~0.02% past the maximum acceptable error bounds). The "double" testcase passes just fine (although with the same error bounds and extra precision that seems perfectly reasonable). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #47 from Kyle dot D dot Moffett at boeing dot com 2010-06-21 15:55 --- (In reply to comment #41) > Created an attachment (id=20877) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877&action=view) [edit] > e500.h and caller-save.c patch > > The ICE in #38 is due to a bug in caller-save.c We've basically rebuilt everything in the PowerPCSPE Debian port now, and as far as I can tell all of the test-cases affected by this bug are fixed by your attachment 20877 (pr44364.diff). Now that we've gotten further, Sebastian has identified a new floating point bug (PR44606), but I believe we can call this one closed. Again, many thanks for all your help! Cheers, Kyle Moffett -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
