Re: math-emu issue with fp divide

[Kumar Gala]

On Wed, 4 Jun 2008, David Miller wrote:

> From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/