diff options
author | Joseph Myers <joseph@codesourcery.com> | 2013-11-04 16:53:14 +0000 |
---|---|---|
committer | Scott Wood <scottwood@freescale.com> | 2014-01-07 18:33:48 -0600 |
commit | 28414a6def9dc00dcd0d0f3eea6911fda9a4a4e1 (patch) | |
tree | b47cad129a84f13e93086144c29b615012daeebe /block | |
parent | 640e922501103aaf2e0abb4cf4de5d49fa8342f7 (diff) | |
download | linux-stable-28414a6def9dc00dcd0d0f3eea6911fda9a4a4e1.tar.gz linux-stable-28414a6def9dc00dcd0d0f3eea6911fda9a4a4e1.tar.bz2 linux-stable-28414a6def9dc00dcd0d0f3eea6911fda9a4a4e1.zip |
powerpc: fix e500 SPE float rounding inexactness detection
The e500 SPE floating-point emulation code for the rounding modes
rounding to positive or negative infinity (which may not be
implemented in hardware) tries to avoid emulating rounding if the
result was inexact. However, it tests inexactness using the sticky
bit with the cumulative result of previous operations, rather than
with the non-sticky bits relating to the operation that generated the
interrupt. Furthermore, when a vector operation generates the
interrupt, it's possible that only one of the low and high parts is
inexact, and so only that part should have rounding emulated. This
results in incorrect rounding of exact results in these modes when the
sticky bit is set from a previous operation.
(I'm not sure why the rounding interrupts are generated at all when
the result is exact, but empirically the hardware does generate them.)
This patch checks for inexactness using the correct bits of SPEFSCR,
and ensures that rounding only occurs when the relevant part of the
result was actually inexact.
Signed-off-by: Joseph Myers <joseph@codesourcery.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
Diffstat (limited to 'block')
0 files changed, 0 insertions, 0 deletions