• 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: default avatarDavid S. Miller <davem@davemloft.net>
    930cc144
Name
Last commit
Last update
Documentation Loading commit data...
arch Loading commit data...
block Loading commit data...
crypto Loading commit data...
drivers Loading commit data...
firmware Loading commit data...
fs Loading commit data...
include Loading commit data...
init Loading commit data...
ipc Loading commit data...
kernel Loading commit data...
lib Loading commit data...
mm Loading commit data...
net Loading commit data...
samples Loading commit data...
scripts Loading commit data...
security Loading commit data...
sound Loading commit data...
usr Loading commit data...
virt/kvm Loading commit data...
.gitignore Loading commit data...
.mailmap Loading commit data...
COPYING Loading commit data...
CREDITS Loading commit data...
Kbuild Loading commit data...
MAINTAINERS Loading commit data...
Makefile Loading commit data...
README Loading commit data...
REPORTING-BUGS Loading commit data...