Re: [PATCH] Fix rounding bug in emulation for double float operating

Re: [PATCH] Fix rounding bug in emulation for double float operating

[David Gibson]

On Mon, Dec 10, 2007 at 01:00:52PM +0800, Liu Yu wrote:
> 
> This patch fixes rounding bug in emulation for double float operating on PowerPC platform.
> 
> When pack double float operand, it need to truncate the tail due to the limited precision.
> If the truncated part is not zero, the last bit of work bit (totally 3 bits) need to '|' 1.
> 
> This patch is completed in _FP_FRAC_SRS_2(X,N,sz) (arch/powerpc/math-emu/op-2.h).
> Originally the code leftwards rotates the operand to just keep the truncated part,
> then check whether it is zero. However, the number it rotates is not correct when
> N is not smaller than _FP_W_TYPE_SIZE, and it will cause the work bit '|' 1 in the improper case.
> 
> This patch fixes this issue.
> 
> Signed-off-by: Liu Yu <b13201@freescale.com>

Wow someone deciphered the hideous macro hell of the math emulation
code enough to fix a bug.  I don't suppose you'd care to fix the
millions of warnings that the math-emu code generates...?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[PATCH] Fix rounding bug in emulation for double float operating

[Liu Yu]

This patch fixes rounding bug in emulation for double float operating on PowerPC platform.

When pack double float operand, it need to truncate the tail due to the limited precision.
If the truncated part is not zero, the last bit of work bit (totally 3 bits) need to '|' 1.

This patch is completed in _FP_FRAC_SRS_2(X,N,sz) (arch/powerpc/math-emu/op-2.h).
Originally the code leftwards rotates the operand to just keep the truncated part,
then check whether it is zero. However, the number it rotates is not correct when
N is not smaller than _FP_W_TYPE_SIZE, and it will cause the work bit '|' 1 in the improper case.

This patch fixes this issue.

Signed-off-by: Liu Yu <b13201@freescale.com>

---
 arch/powerpc/math-emu/op-2.h |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/math-emu/op-2.h b/arch/powerpc/math-emu/op-2.h
index b9b06b4..7d6f17c 100644
--- a/arch/powerpc/math-emu/op-2.h
+++ b/arch/powerpc/math-emu/op-2.h
@@ -59,7 +59,8 @@
     else								\
       {									\
 	X##_f0 = (X##_f1 >> ((N) - _FP_W_TYPE_SIZE) |			\
-	          (((X##_f1 << (sz - (N))) | X##_f0) != 0));		\
+	          (((X##_f1 << (2 * _FP_W_TYPE_SIZE - (N))) |		\
+		   X##_f0) != 0));					\
 	X##_f1 = 0;							\
       }									\
   } while (0)
-- 
1.5.2

RE: [PATCH] Fix rounding bug in emulation for double floatoperating

[Liu Yu]

=20

> -----Original Message-----
> From: David Gibson [mailto:david@gibson.dropbear.id.au]=20
> Sent: Monday, December 10, 2007 12:56 PM
> To: Liu Yu
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Fix rounding bug in emulation for double=20
> floatoperating
>=20
>=20
> On Mon, Dec 10, 2007 at 01:00:52PM +0800, Liu Yu wrote:
> >=20
> > This patch fixes rounding bug in emulation for double float=20
> operating on PowerPC platform.
> >=20
> > When pack double float operand, it need to truncate the=20
> tail due to the limited precision.
> > If the truncated part is not zero, the last bit of work bit=20
> (totally 3 bits) need to '|' 1.
> >=20
> > This patch is completed in _FP_FRAC_SRS_2(X,N,sz)=20
> (arch/powerpc/math-emu/op-2.h).
> > Originally the code leftwards rotates the operand to just keep the=20
> > truncated part, then check whether it is zero. However, the=20
> number it=20
> > rotates is not correct when N is not smaller than=20
> _FP_W_TYPE_SIZE, and it will cause the work bit '|' 1 in the=20
> improper case.
> >=20
> > This patch fixes this issue.
> >=20
> > Signed-off-by: Liu Yu <b13201@freescale.com>
>=20
> Wow someone deciphered the hideous macro hell of the math=20
> emulation code enough to fix a bug.  I don't suppose you'd=20
> care to fix the millions of warnings that the math-emu code=20
> generates...?

Oh, I don't like macro define either. But it's really a bug...

Re: [PATCH] Fix rounding bug in emulation for double floatoperating

[Kumar Gala]

On Dec 9, 2007, at 11:25 PM, Liu Yu wrote:

>
>
>
>
>
>> -----Original Message-----
>> From: David Gibson [mailto:david@gibson.dropbear.id.au]
>> Sent: Monday, December 10, 2007 12:56 PM
>> To: Liu Yu
>> Cc: linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH] Fix rounding bug in emulation for double
>> floatoperating
>>
>>
>> On Mon, Dec 10, 2007 at 01:00:52PM +0800, Liu Yu wrote:
>>>
>>> This patch fixes rounding bug in emulation for double float
>> operating on PowerPC platform.
>>>
>>> When pack double float operand, it need to truncate the
>> tail due to the limited precision.
>>> If the truncated part is not zero, the last bit of work bit
>> (totally 3 bits) need to '|' 1.
>>>
>>> This patch is completed in _FP_FRAC_SRS_2(X,N,sz)
>> (arch/powerpc/math-emu/op-2.h).
>>> Originally the code leftwards rotates the operand to just keep the
>>> truncated part, then check whether it is zero. However, the
>> number it
>>> rotates is not correct when N is not smaller than
>> _FP_W_TYPE_SIZE, and it will cause the work bit '|' 1 in the
>> improper case.
>>>
>>> This patch fixes this issue.
>>>
>>> Signed-off-by: Liu Yu <b13201@freescale.com>
>>
>> Wow someone deciphered the hideous macro hell of the math
>> emulation code enough to fix a bug.  I don't suppose you'd
>> care to fix the millions of warnings that the math-emu code
>> generates...?
>
> Oh, I don't like macro define either. But it's really a bug...


how did you find this?

- k

RE: [PATCH] Fix rounding bug in emulation for double floatoperating

[Liu Yu]

> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Monday, December 10, 2007 11:01 PM
> To: Liu Yu
> Cc: David Gibson; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Fix rounding bug in emulation for double=20
> floatoperating
>=20
>=20
> On Dec 9, 2007, at 11:25 PM, Liu Yu wrote:
> >> -----Original Message-----
> >> From: David Gibson [mailto:david@gibson.dropbear.id.au]
> >> Sent: Monday, December 10, 2007 12:56 PM
> >> To: Liu Yu
> >> Cc: linuxppc-dev@ozlabs.org
> >> Subject: Re: [PATCH] Fix rounding bug in emulation for double=20
> >> floatoperating
> >>
> >>
> >> On Mon, Dec 10, 2007 at 01:00:52PM +0800, Liu Yu wrote:
> >>>
> >>> This patch fixes rounding bug in emulation for double float
> >> operating on PowerPC platform.
> >>>
> >>> When pack double float operand, it need to truncate the
> >> tail due to the limited precision.
> >>> If the truncated part is not zero, the last bit of work bit
> >> (totally 3 bits) need to '|' 1.
> >>>
> >>> This patch is completed in _FP_FRAC_SRS_2(X,N,sz)
> >> (arch/powerpc/math-emu/op-2.h).
> >>> Originally the code leftwards rotates the operand to just=20
> keep the=20
> >>> truncated part, then check whether it is zero. However, the
> >> number it
> >>> rotates is not correct when N is not smaller than
> >> _FP_W_TYPE_SIZE, and it will cause the work bit '|' 1 in=20
> the improper=20
> >> case.
> >>>
> >>> This patch fixes this issue.
> >>>
> >>> Signed-off-by: Liu Yu <b13201@freescale.com>
> >>
> >> Wow someone deciphered the hideous macro hell of the math=20
> emulation=20
> >> code enough to fix a bug.  I don't suppose you'd care to fix the=20
> >> millions of warnings that the math-emu code generates...?
> >
> > Oh, I don't like macro define either. But it's really a bug...
>=20
>=20
> how did you find this?

Well, when divide the min positive number by 2, you will get the work
bit "101" which is supposed to be "100".
And the wrong result will influent the succedent rounding operation.

In fact, the similar macro _FP_FRAC_SRS_1 and _FP_FRAC_SRS_4 are
correct. This bug just exists in _FP_FRAC_SRS_2.

>=20
> - k
>=20

Re: [PATCH] Fix rounding bug in emulation for double floatoperating

[Zang Roy-r61911]

On Mon, 2007-12-10 at 23:00, Kumar Gala wrote:
> On Dec 9, 2007, at 11:25 PM, Liu Yu wrote:
> >
> >> -----Original Message-----
> >> From: David Gibson [mailto:david@gibson.dropbear.id.au]
> >> Sent: Monday, December 10, 2007 12:56 PM
> >> To: Liu Yu
> >> Cc: linuxppc-dev@ozlabs.org
> >> Subject: Re: [PATCH] Fix rounding bug in emulation for double
> >> floatoperating
> >>
> >>
> >> On Mon, Dec 10, 2007 at 01:00:52PM +0800, Liu Yu wrote:
> >>>
> >>> This patch fixes rounding bug in emulation for double float
> >> operating on PowerPC platform.
> >>>
> >>> When pack double float operand, it need to truncate the
> >> tail due to the limited precision.
> >>> If the truncated part is not zero, the last bit of work bit
> >> (totally 3 bits) need to '|' 1.
> >>>
> >>> This patch is completed in _FP_FRAC_SRS_2(X,N,sz)
> >> (arch/powerpc/math-emu/op-2.h).
> >>> Originally the code leftwards rotates the operand to just keep the
> >>> truncated part, then check whether it is zero. However, the
> >> number it
> >>> rotates is not correct when N is not smaller than
> >> _FP_W_TYPE_SIZE, and it will cause the work bit '|' 1 in the
> >> improper case.
> >>>
> >>> This patch fixes this issue.
> >>>
> >>> Signed-off-by: Liu Yu <b13201@freescale.com>
> >>
> >> Wow someone deciphered the hideous macro hell of the math
> >> emulation code enough to fix a bug.  I don't suppose you'd
> >> care to fix the millions of warnings that the math-emu code
> >> generates...?
> >
> > Oh, I don't like macro define either. But it's really a bug...
> 
> 
> how did you find this?
> 
It supposed to run the following test case on a powerpc platform.
Yu's patch fixes the issue.
Could you help to merge this patch in your tree?
---
#include <stdio.h>
#include <math.h>
#include <bits/nan.h>
#ifdef __SPE__
#include <spe.h>
int
getSPEFSCR()
{
    return __builtin_spe_mfspefscr();
}

void
setSPEFSCR(int i)
{
    __builtin_spe_mtspefscr(i);
}
#else
int
getSPEFSCR()
{
    return 0;
}

void
setSPEFSCR(int i)
{
}
#endif

void
dmul(double d, double d1, double expected)
{
    double d2;
    int before, after;

    before = getSPEFSCR();
    d2 = d * d1;
    after = getSPEFSCR();

    printf("dmul %llx * %llx = %llx expected %llx %s [0x%x 0x%x]\n", d, d1, d2, expected,
           (d2 == expected) ? "(PASS)" : "(FAIL)", before, after);
}

void
ddiv(double d, double d1, double expected)
{
    register double d2;
    int before, after;

    before = getSPEFSCR();
    d2 = d / d1;
    after = getSPEFSCR();

    printf("ddiv %llx / %llx = %llx expected %llx %s [0x%x 0x%x]\n", d, d1, d2, expected,
           (d2 == expected) ? "(PASS)" : "(FAIL)", before, after);
}

main()
{
    const double min_double = 4.9406564584124654e-324L;

    printf("\n");
    dmul(0.5L, min_double, 0.0L);
    dmul(-0.5L, min_double, 0.0L);
    dmul(-min_double, -0.5L, 0.0L);
    printf("\n");
    ddiv(min_double, 2.0L, 0.0L);
}

Re: [PATCH] Fix rounding bug in emulation for double floatoperating

[Kumar Gala]

>>
>> how did you find this?
>>
> It supposed to run the following test case on a powerpc platform.
> Yu's patch fixes the issue.
> Could you help to merge this patch in your tree?
> ---
> #include <stdio.h>
> #include <math.h>
> #include <bits/nan.h>
> #ifdef __SPE__
> #include <spe.h>
> int
> getSPEFSCR()
> {
>    return __builtin_spe_mfspefscr();
> }
>
> void
> setSPEFSCR(int i)
> {
>    __builtin_spe_mtspefscr(i);
> }
> #else
> int
> getSPEFSCR()
> {
>    return 0;
> }
>
> void
> setSPEFSCR(int i)
> {
> }
> #endif
>
> void
> dmul(double d, double d1, double expected)
> {
>    double d2;
>    int before, after;
>
>    before = getSPEFSCR();
>    d2 = d * d1;
>    after = getSPEFSCR();
>
>    printf("dmul %llx * %llx = %llx expected %llx %s [0x%x 0x%x]\n",  
> d, d1, d2, expected,
>           (d2 == expected) ? "(PASS)" : "(FAIL)", before, after);
> }
>
> void
> ddiv(double d, double d1, double expected)
> {
>    register double d2;
>    int before, after;
>
>    before = getSPEFSCR();
>    d2 = d / d1;
>    after = getSPEFSCR();
>
>    printf("ddiv %llx / %llx = %llx expected %llx %s [0x%x 0x%x]\n",  
> d, d1, d2, expected,
>           (d2 == expected) ? "(PASS)" : "(FAIL)", before, after);
> }
>
> main()
> {
>    const double min_double = 4.9406564584124654e-324L;
>
>    printf("\n");
>    dmul(0.5L, min_double, 0.0L);
>    dmul(-0.5L, min_double, 0.0L);
>    dmul(-min_double, -0.5L, 0.0L);
>    printf("\n");
>    ddiv(min_double, 2.0L, 0.0L);
> }

When I run this on a G5 (w/HW FP) I get:

dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)

ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)

and on the 85xx w/FP emu:

dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)

ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)

Maybe I'm missing where the error is.

- k

Re: [PATCH] Fix rounding bug in emulation for double floatoperating

[Zang Roy-r61911]

On Tue, 2007-12-11 at 23:26, Kumar Gala wrote:
> >>
> >> how did you find this?
> >>
> > It supposed to run the following test case on a powerpc platform.
> > Yu's patch fixes the issue.
> > Could you help to merge this patch in your tree?
> > ---
> > #include <stdio.h>
> > #include <math.h>
> > #include <bits/nan.h>
> > #ifdef __SPE__
> > #include <spe.h>
> > int
> > getSPEFSCR()
> > {
> >    return __builtin_spe_mfspefscr();
> > }
> >
> > void
> > setSPEFSCR(int i)
> > {
> >    __builtin_spe_mtspefscr(i);
> > }
> > #else
> > int
> > getSPEFSCR()
> > {
> >    return 0;
> > }
> >
> > void
> > setSPEFSCR(int i)
> > {
> > }
> > #endif
> >
> > void
> > dmul(double d, double d1, double expected)
> > {
> >    double d2;
> >    int before, after;
> >
> >    before = getSPEFSCR();
> >    d2 = d * d1;
> >    after = getSPEFSCR();
> >
> >    printf("dmul %llx * %llx = %llx expected %llx %s [0x%x 0x%x]\n", 
> > d, d1, d2, expected,
> >           (d2 == expected) ? "(PASS)" : "(FAIL)", before, after);
> > }
> >
> > void
> > ddiv(double d, double d1, double expected)
> > {
> >    register double d2;
> >    int before, after;
> >
> >    before = getSPEFSCR();
> >    d2 = d / d1;
> >    after = getSPEFSCR();
> >
> >    printf("ddiv %llx / %llx = %llx expected %llx %s [0x%x 0x%x]\n", 
> > d, d1, d2, expected,
> >           (d2 == expected) ? "(PASS)" : "(FAIL)", before, after);
> > }
> >
> > main()
> > {
> >    const double min_double = 4.9406564584124654e-324L;
> >
> >    printf("\n");
> >    dmul(0.5L, min_double, 0.0L);
> >    dmul(-0.5L, min_double, 0.0L);
> >    dmul(-min_double, -0.5L, 0.0L);
> >    printf("\n");
> >    ddiv(min_double, 2.0L, 0.0L);
> > }
> 
> When I run this on a G5 (w/HW FP) I get:
> 
> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
> 
> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
> 
> and on the 85xx w/FP emu:
> 
> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
> 
> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
> 
> Maybe I'm missing where the error is.
I am missing ...
It is supposed to run based on previous IEEE 754 patch.
http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031351.html
Roy

Re: [PATCH] Fix rounding bug in emulation for double floatoperating

[Kumar Gala]

>> When I run this on a G5 (w/HW FP) I get:
>>
>> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
>> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
>> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
>>
>> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
>>
>> and on the 85xx w/FP emu:
>>
>> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
>> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
>> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
>>
>> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
>>
>> Maybe I'm missing where the error is.
> I am missing ...
> It is supposed to run based on previous IEEE 754 patch.
> http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031351.html

Ok, but the test case should care if we are doing full "classic"  
emulation or fixup of e500 FP.

- k

Re: [PATCH] Fix rounding bug in emulation for double float operating

[Kumar Gala]

On Dec 9, 2007, at 11:00 PM, Liu Yu wrote:

>
> This patch fixes rounding bug in emulation for double float  
> operating on PowerPC platform.
>
> When pack double float operand, it need to truncate the tail due to  
> the limited precision.
> If the truncated part is not zero, the last bit of work bit (totally  
> 3 bits) need to '|' 1.
>
> This patch is completed in _FP_FRAC_SRS_2(X,N,sz) (arch/powerpc/math- 
> emu/op-2.h).
> Originally the code leftwards rotates the operand to just keep the  
> truncated part,
> then check whether it is zero. However, the number it rotates is not  
> correct when
> N is not smaller than _FP_W_TYPE_SIZE, and it will cause the work  
> bit '|' 1 in the improper case.
>
> This patch fixes this issue.
>
> Signed-off-by: Liu Yu <b13201@freescale.com>
>
> ---
> arch/powerpc/math-emu/op-2.h |    3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)

applied.

- k

Re: [PATCH] Fix rounding bug in emulation for double floatoperating

[Kumar Gala]

>> When I run this on a G5 (w/HW FP) I get:
>>
>> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
>> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
>> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
>>
>> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
>>
>> and on the 85xx w/FP emu:
>>
>> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
>> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
>> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
>>
>> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
>>
>> Maybe I'm missing where the error is.
> I am missing ...
> It is supposed to run based on previous IEEE 754 patch.
> http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031351.html

I'd really like to see to see a testcase show the issue with "classic  
FP emu" on a 85xx system.

(seems like it should be pretty straight forward).

- k

Re: [PATCH] Fix rounding bug in emulation for double floatoperating

[Zang Roy-r61911]

On Fri, 2007-12-14 at 13:46, Kumar Gala wrote:
> >> When I run this on a G5 (w/HW FP) I get:
> >>
> >> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
> >> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
> >> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
> >>
> >> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
> >>
> >> and on the 85xx w/FP emu:
> >>
> >> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
> >> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
> >> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
> >>
> >> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
> >>
> >> Maybe I'm missing where the error is.
> > I am missing ...
> > It is supposed to run based on previous IEEE 754 patch.
> > http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031351.html
> 
> I'd really like to see to see a testcase show the issue with "classic 
> FP emu" on a 85xx system.
I can understand. 
You know, For a 85xx system without the previous patch or other
'classic' powerpc, it is hard to trigger this issue. Although I believe
it is a problem fixed up.
Do you have any idea?
Roy

Re: [PATCH] Fix rounding bug in emulation for double floatoperating

[Kumar Gala]

On Dec 14, 2007, at 12:06 AM, Zang Roy-r61911 wrote:

> On Fri, 2007-12-14 at 13:46, Kumar Gala wrote:
>>>> When I run this on a G5 (w/HW FP) I get:
>>>>
>>>> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
>>>> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
>>>> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
>>>>
>>>> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
>>>>
>>>> and on the 85xx w/FP emu:
>>>>
>>>> dmul 3fe0000000000000 * 1 = 0 expected 0 (PASS)
>>>> dmul bfe0000000000000 * 1 = 8000000000000000 expected 0 (PASS)
>>>> dmul 8000000000000001 * bfe0000000000000 = 0 expected 0 (PASS)
>>>>
>>>> ddiv 1 / 4000000000000000 = 0 expected 0 (PASS)
>>>>
>>>> Maybe I'm missing where the error is.
>>> I am missing ...
>>> It is supposed to run based on previous IEEE 754 patch.
>>> http://ozlabs.org/pipermail/linuxppc-dev/2007-February/031351.html
>>
>> I'd really like to see to see a testcase show the issue with "classic
>> FP emu" on a 85xx system.
> I can understand.
> You know, For a 85xx system without the previous patch or other
> 'classic' powerpc, it is hard to trigger this issue. Although I  
> believe
> it is a problem fixed up.
> Do you have any idea?

maybe I'm missing it, but can we not do the same operation w/classic  
FP that you are doing w/SPE fp?

is this in standard rounding mode, etc?

- k