[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0806050837230.24924@blarg.am.freescale.net>
Date: Thu, 5 Jun 2008 08:38:44 -0500 (CDT)
From: Kumar Gala <galak@...nel.crashing.org>
To: David Miller <davem@...emloft.net>
cc: joseph@...esourcery.com, linux-kernel@...r.kernel.org,
libc-alpha@...rceware.org
Subject: Re: math-emu issue with fp divide
On Wed, 4 Jun 2008, David Miller wrote:
> From: "Joseph S. Myers" <joseph@...esourcery.com>
> Date: Wed, 4 Jun 2008 21:42:55 +0000 (UTC)
>
> > On Wed, 4 Jun 2008, Kumar Gala wrote:
> >
> > > I'm trying to move the powerpc math-emu
> > > code to use the include/math-emu bits.
> >
> > I'd like to remind people that the include/math-emu code is based on an
> > old, buggy version of the soft-fp code in glibc. RTH previously noted
> > <http://sourceware.org/ml/libc-alpha/2006-02/msg00075.html> that the fixes
> > should go in the kernel, when approving a patch of mine fixing various
> > bugs and speeding up soft-fp, and several more bugs have been fixed since
> > then in the course of GCC work on soft-float for Power and __float128
> > support for x86_64.
> >
> > So it may be better than the old code you're replacing, but it might still
> > be a good idea to merge things with the current glibc code, as a matter of
> > both correctness and performance. (And there may well still be bugs left
> > in the code.)
>
> Once the GCC folks started looking into using the soft-fp bits I knew
> this situation would develop. The kernel side would have some set of
> fixes and the glibc/gcc side would have yet another set.
>
> To be honest this doesn't surprise me...
>
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?
It looks like the case I have we are exact before rounding, but think it
looks like the rounding case since it appears as if "overflow is set".
000.FFFFFFFFFFFFF / 3FE.FFFFFFFFFFFFE = 001.0000000000000
I think the following adds the check for my case and still works for the
issue your commit was trying to resolve. Take a look any and all comments
are welcome since this code is pretty complicated:
- k
diff --git a/include/math-emu/op-common.h b/include/math-emu/op-common.h
index cc1ec39..bc50aa0 100644
--- a/include/math-emu/op-common.h
+++ b/include/math-emu/op-common.h
@@ -139,18 +139,27 @@ do { \
if (X##_e <= _FP_WFRACBITS_##fs) \
{ \
_FP_FRAC_SRS_##wc(X, X##_e, _FP_WFRACBITS_##fs); \
- _FP_ROUND(wc, X); \
if (_FP_FRAC_HIGH_##fs(X) \
& (_FP_OVERFLOW_##fs >> 1)) \
{ \
X##_e = 1; \
_FP_FRAC_SET_##wc(X, _FP_ZEROFRAC_##wc); \
- FP_SET_EXCEPTION(FP_EX_INEXACT); \
} \
else \
{ \
- X##_e = 0; \
- _FP_FRAC_SRL_##wc(X, _FP_WORKBITS); \
+ _FP_ROUND(wc, X); \
+ if (_FP_FRAC_HIGH_##fs(X) \
+ & (_FP_OVERFLOW_##fs >> 1)) \
+ { \
+ X##_e = 1; \
+ _FP_FRAC_SET_##wc(X, _FP_ZEROFRAC_##wc); \
+ FP_SET_EXCEPTION(FP_EX_INEXACT); \
+ } \
+ else \
+ { \
+ X##_e = 0; \
+ _FP_FRAC_SRL_##wc(X, _FP_WORKBITS); \
+ } \
} \
if ((FP_CUR_EXCEPTIONS & FP_EX_INEXACT) || \
(FP_TRAPPING_EXCEPTIONS & FP_EX_UNDERFLOW)) \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists