Most functions in math.h do not use correct rounding. Example: //--- snip --- #include <math.h> #include <fenv.h> #include <assert.h> int main() { double x = 1.0; // 1.0 is exact fesetround(FE_DOWNWARD); double a = asin(x); fesetround(FE_UPWARD); double b = asin(x); // asin(1) == pi/2, which is not exactly representable // so, assuming correct rounding, a should be less than b assert(a < b); } //--- snap --- Compile with "gcc -lm" (or even "gcc -lm -ffloat-store -frounding-math"). Run the example: main: Assertion `a < b' failed. Similar results can be obtained with exp, cos, acos, atan, sinh, cosh, atanh, asinh and acosh. ------ Kernel version: 3.5.2-1.fc17 gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) GNU ld version 2.22.52.0.1-10.fc17 20120131
I'll use this as the general meta-bug for not-correctly-rounding functions (other than those with fully specified results such as sqrt and fma), as I suggested in <http://sourceware.org/ml/libc-alpha/2012-02/msg00392.html>, and mark other bugs for small ulps errors (say 1-10ulps) as duplicates of this one. SUSPENDED as correctly-rounding issues are generally known to be hard to fix and to need new implementations of functions in many cases, with detailed error analysis and exhaustive searches for worst cases for rounding.
*** Bug 1161 has been marked as a duplicate of this bug. ***
*** Bug 1163 has been marked as a duplicate of this bug. ***
*** Bug 2540 has been marked as a duplicate of this bug. ***
glibc accuracy goals are now documented in the manual and the FAQ and correct rounding is explicitly excluded - without ruling out the possibility that in future we could add correctly rounding functions under names such as crasin, or other functions with well-defined error bounds, probably automatically generated with tools such as metalibm.
*** Bug 16509 has been marked as a duplicate of this bug. ***