• Kumar Gala's avatar
    math-emu: Fix signalling of underflow and inexact while packing result. · 930cc144
    Kumar Gala authored
    I'm trying to move the powerpc math-emu code to use the include/math-emu bits.
    
    In doing so I've been using TestFloat to see how good or bad we are
    doing.  For the most part the current math-emu code that PPC uses has
    a number of issues that the code in include/math-emu seems to solve
    (plus bugs we've had for ever that no one every realized).
    
    Anyways, I've come across a case that we are flagging underflow and
    inexact because we think we have a denormalized result from a double
    precision divide:
    
    000.FFFFFFFFFFFFF / 3FE.FFFFFFFFFFFFE
    	soft: 001.0000000000000 .....  syst: 001.0000000000000 ...ux
    
    What it looks like is the results out of FP_DIV_D are:
    
    D:
    sign:	  0
    mantissa: 01000000 00000000
    exp:	 -1023 (0)
    
    The problem seems like we aren't normalizing the result and bumping the exp.
    
    Now that I'm digging into this a bit I'm thinking my issue has to do with
    the fix DaveM put in place from back in Aug 2007 (commit
    40584961):
    
    [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.
    
    Here is the distilled glibc test case from Jakub Jelinek which prompted that
    commit:
    
    --------------------
    #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;
    }
    --------------------
    
    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.
    Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
    930cc144
Name
Last commit
Last update
..
double.h Loading commit data...
op-1.h Loading commit data...
op-2.h Loading commit data...
op-4.h Loading commit data...
op-8.h Loading commit data...
op-common.h Loading commit data...
quad.h Loading commit data...
single.h Loading commit data...
soft-fp.h Loading commit data...