From b55b28e6574c215689e4656628b911788870de31 Mon Sep 17 00:00:00 2001 From: Joseph Myers Date: Thu, 10 Mar 2016 23:48:46 +0000 Subject: Allow spurious underflow / inexact for ldbl-128ibm. A large number of the test-ldouble failures seen for ldbl-128ibm are spurious "underflow" and "inexact" exceptions. These arise from such exceptions in the underlying arithmetic; unlike other spurious exceptions from that arithmetic, they do not in general relate to cases where the returned result is also substantially inaccurate, are not so readily avoidable by appropriately conditional libgcc patches, and are widespread enough to be hard to handle through individual XFAILing of the affected tests. Thus, this patch documents relaxed accuracy goals for libm functions for IBM long double and makes libm-test.inc reflect these spurious exceptions in ldbl-128ibm arithmetic and always allow them in ldbl-128ibm testing (while still not allowing these exceptions to be missing where required to be present). Tested for powerpc. * manual/math.texi (Errors in Math Functions): Document relaxed accuracy goals for IBM long double. * math/libm-test.inc (test_exceptions): Always allow spurious "underflow" and "inexact" exceptions for IBM long double. --- manual/math.texi | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'manual/math.texi') diff --git a/manual/math.texi b/manual/math.texi index 72f3fda0a3..5c9f7b9f1c 100644 --- a/manual/math.texi +++ b/manual/math.texi @@ -1326,6 +1326,16 @@ interpreted in terms of a fixed-precision 106-bit mantissa, but not necessarily the exact value actually passed with discontiguous mantissa bits. +@item +For the IBM @code{long double} format, functions whose results are +fully specified by reference to corresponding IEEE 754 floating-point +operations have the same accuracy goals as other functions, but with +the error bound being the same as that for division (3ulp). +Furthermore, ``inexact'' and ``underflow'' exceptions may be raised +for all functions for any inputs, even where such exceptions are +inconsistent with the returned value, since the underlying +floating-point arithmetic has that property. + @item Functions behave as if the infinite-precision result computed is zero, infinity or NaN if and only if that is the mathematically correct -- cgit 1.4.1