aboutsummaryrefslogtreecommitdiff
path: root/include/math-emu
AgeCommit message (Collapse)Author
2008-10-22math-emu: Fix thinko in _FP_DIVDavid S. Miller
In commit 48d6c64311ddb6417b901639530ccbc47bdc7635 ("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: David S. Miller <davem@davemloft.net>
2008-10-22math-emu: Fix signalling of underflow and inexact while packing result.Kumar Gala
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 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. 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: David S. Miller <davem@davemloft.net>
2008-09-16math-emu: Add support for reporting exact invalid exceptionKumar Gala
Some architectures (like powerpc) provide status information on the exact type of invalid exception. This is pretty straight forward as we already report invalid exceptions via FP_SET_EXCEPTION. We add new flags (FP_EX_INVALID_*) the architecture code can define if it wants the exact invalid exception reported. We had to split out the INF/INF and 0/0 cases for divide to allow reporting the two invalid forms properly. Signed-off-by: Kumar Gala <galak@kernel.crashing.org> Acked-by: David S. Miller <davem@davemloft.net>
2008-09-16math-emu: Fix compiler warningsKumar Gala
Fix warnings of the form: arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f1' may be used uninitialized in this function arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f0' may be used uninitialized in this function Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2007-08-18Fix <math-emu/soft-fp.h> tpyoAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-08-16[MATH-EMU]: Fix underflow exception reporting.David S. Miller
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: David S. Miller <davem@davemloft.net>
2007-05-08Delete unused header file math-emu/extended.hRobert P. J. Day
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
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!