Re: math-emu issue with fp divide
From: Kumar Gala
Date: Fri Jun 27 2008 - 10:16:26 EST
On Jun 12, 2008, at 11:24 PM, David Miller wrote:
From: Kumar Gala <galak@xxxxxxxxxxxxxxxxxxx>
Date: Thu, 5 Jun 2008 08:38:44 -0500 (CDT)
Now that I'm digging into this a bit I'm thinking my issue has to
do with
the fix you put in place from back in Aug 2007 (commit
405849610fd96b4f34cd1875c4c033228fea6c0f):
[MATH-EMU]: Fix underflow exception reporting.
2) we ended up rounding back up to normal (this is the case where
we set the exponent to 1 and set the fraction to zero), this
should set inexact too
...
Another example, "0x0.0000000000001p-1022 / 16.0", should signal
both
inexact and underflow. The cpu implementations and ieee1754
literature is very clear about this. This is case #2 above.
I'm not clear from your commit comment on what actual number
0x0.0....01p-1022 is?
I haven't been able to look closely at this yet but I think I
happened to stumble over the test case that lead me to that
changeset you are referencing here.
The "actual number" is exactly as listed "0x0.0000000000001p-1022",
I don't know what's so confusing about it :-)))
I think this was distilled by Jakub Jelinek from some glibc test case.
#include <float.h>
#include <fenv.h>
#include <stdio.h>
volatile double d = DBL_MIN;
volatile double e = 0x0.0000000000001p-1022;
volatile double f = 16.0;
int
main (void)
{
printf ("%x\n", fetestexcept (FE_UNDERFLOW));
d /= f;
printf ("%x\n", fetestexcept (FE_UNDERFLOW));
e /= f;
printf ("%x\n", fetestexcept (FE_UNDERFLOW));
return 0;
}
I tested this on PPC HW fp and kern emu w/my patch and get the same
results:
0
0
8000000
(8000000 is underflow in the PPC FP status register)
- k
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/