1. 04 Feb, 2010 1 commit
  2. 23 Oct, 2008 2 commits
    • David S. Miller's avatar
      math-emu: Fix thinko in _FP_DIV · 60b82673
      David S. Miller authored
      In commit 48d6c643 ("math-emu: Add
      support for reporting exact invalid exception") code was added to
      set the new FP_EX_INVALID_{IDI,ZDZ} exception flag bits.
      
      However there is a missing break statement for the
      _FP_CLS_COMBINE(FP_CLS_INF,FP_CLS_INF) switch case, the
      code just falls into _FP_CLS_COMBINE(FP_CLS_ZERO,FP_CLS_ZERO)
      which then proceeds to overwrite all of the settings.
      
      Fix by adding the missing break.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60b82673
    • 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
  3. 16 Sep, 2008 2 commits
  4. 19 Aug, 2007 1 commit
  5. 17 Aug, 2007 1 commit
    • David S. Miller's avatar
      [MATH-EMU]: Fix underflow exception reporting. · 40584961
      David S. Miller authored
      The underflow exception cases were wrong.
      
      This is one weird area of ieee1754 handling in that the underflow
      behavior changes based upon whether underflow is enabled in the trap
      enable mask of the FPU control register.  As a specific case the Sparc
      V9 manual gives us the following description:
      
      --------------------
      If UFM = 0:     Underflow occurs if a nonzero result is tiny and a
                      loss of accuracy occurs.  Tininess may be detected
                      before or after rounding.  Loss of accuracy may be
                      either a denormalization loss or an inexact result.
      
      If UFM = 1:     Underflow occurs if a nonzero result is tiny.
                      Tininess may be detected before or after rounding.
      --------------------
      
      What this amounts to in the packing case is if we go subnormal,
      we set underflow if any of the following are true:
      
      1) rounding sets inexact
      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
      3) underflow is set in FPU control register trap-enable mask
      
      The initially discovered example was "DBL_MIN / 16.0" which
      incorrectly generated an underflow.  It should not, unless underflow
      is set in the trap-enable mask of the FPU csr.
      
      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.
      
      However, if underflow is set in the trap enable mask, only underflow
      should be set and reported as a trap.  That is handled properly by the
      prioritization logic in
      
      arch/sparc{,64}/math-emu/math.c:record_exception().
      
      Based upon a report and test case from Jakub Jelinek.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40584961
  6. 08 May, 2007 1 commit
  7. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4