[Bug tree-optimization/44606] New: Wrong SPE floating point during computation

[Bug tree-optimization/44606] New: Wrong SPE floating point during computation

[gcc at breakpoint dot cc]

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.
 gcc -o tc2 -O0 -Wall -Wextra tc-resize.c
 gcc -o tc2 -O2 -Wall -Wextra tc-resize.c
 ( ./tc0 ; echo "-"; ./tc2 )
 .19 2484.000000
 .21 2700.000000
 .23 2916.000000
 .24 3132.000000
 .26 3348.000000
 -
 .0 2484.000000
 .0 2700.000000
 .0 2916.000000
 .0 3132.000000
 .0 3348.000000

 gcc -o tc20 -O0 -Wall -Wextra tc-resize2.c
 gcc -o tc22 -O2 -Wall -Wextra tc-resize2.c
 ( ./tc20 ; echo "-"; ./tc22 )
 .26 3264.000000
 .28 3520.000000
 .30 3776.000000
 .32 4032.000000
 .34 4288.000000
 -
 .14 1734.000000
 .15 1870.000000
 .16 2006.000000
 .17 2142.000000
 .18 2278.000000

 Now here is stripped down output of the assembly file:

 MinifyImage:
         evstdd 26,88(11)
 .L9:
         li 26,0

         stw 26,64(1)
 .L11:
  #APP
  # 105 "tc-resize.c" 1
         nop
  # 0 "" 2
 #NO_APP
         lis 19,.LC5@ha
         efdmul 5,9,26           r26 should be 0.0078125 but is 0
                                 r26 bits 32..63 are, dunno about 0..31    
         la 19,.LC5@l(19)
         evldd 19,0(19)          r19 is 0.5
         efdadd 5,5,19           r5 is expected to be .5
         efdctuiz 5,5            r5 is 0
         rlwinm 5,5,0,0xff

 #APP
  # 107 "tc-resize.c" 1
         nop
  # 0 "" 2
 #NO_APP
         evmergehi 6,9,9
         mr 7,9
         mr 8,7
         mr 7,6

         crxor 6,6,6     that should be 9,9,9 but is a different issue :)
         bl fprintf      # r5 int (bad), r6 pad, r7 & r8 double

r26 is zero and that is wrong. I belive 1/128.0 gets replaced by 0.0 and
optimized.

Sebastian


-- 
           Summary: Wrong SPE floating point during computation
           Product: gcc
           Version: 4.4.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gcc at breakpoint dot cc
 GCC build triplet: powerpc-linux-gnuspe
  GCC host triplet: powerpc-linux-gnuspe
GCC target triplet: powerpc-linux-gnuspe


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

[Bug tree-optimization/44606] Wrong SPE floating point during computation

[gcc at breakpoint dot cc]

------- Comment #1 from gcc at breakpoint dot cc  2010-06-21 09:10 -------
Created an attachment (id=20950)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20950&action=view)
testcase


-- 


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

[Bug tree-optimization/44606] Wrong SPE floating point during computation

[gcc at breakpoint dot cc]

------- Comment #3 from gcc at breakpoint dot cc  2010-06-21 09:11 -------
Created an attachment (id=20952)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20952&action=view)
-S output of the first tc


-- 


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

[Bug tree-optimization/44606] Wrong SPE floating point during computation

[gcc at breakpoint dot cc]

------- Comment #2 from gcc at breakpoint dot cc  2010-06-21 09:10 -------
Created an attachment (id=20951)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20951&action=view)
slightly extended tc


-- 


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

[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

[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 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

[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