This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] ldbl-128ibm nexttowar[d/f/l] generates spurious inexact exception
- From: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Mon, 20 May 2013 15:55:04 -0300
- Subject: Re: [PATCH] ldbl-128ibm nexttowar[d/f/l] generates spurious inexact exception
- References: <519A2BBF dot 4030306 at linux dot vnet dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1305201424480 dot 10668 at digraph dot polyomino dot org dot uk>
On 05/20/2013 11:32 AM, Joseph S. Myers wrote:
> On Mon, 20 May 2013, Adhemerval Zanella wrote:
>
>> This is triggered by glibc testcase "nexttowar[d/f/l] (qNaN, 1.1)". The source
>> of the issue is sysdeps/ieee754/ldbl-128ibm/s_nexttoward.c,
>> sysdeps/ieee754/ldbl-128ibm/s_nextafterl.c, and sysdeps/ieee754/ldbl-128ibm/s_nexttowardf.c
>> all return 'x+y' as return if x or y is a NaN.
>>
>> This fix is to return __builtin_nan[f|l] instead. Ok to commit?
> No, that's wrong. x+y for x or y a NaN should never raise "inexact"; if
> it does, that's a bug in the libgcc implementation of addition. Your fix
> would lose the NaN payload and would fail to raise "invalid" if the NaN is
> signaling.
>
> There are, it seems, at least three libgcc problems needing fixing for IBM
> long double to avoid failures in glibc tests:
>
> * This one about spurious exceptions with NaNs.
>
> * Operations on long doubles that are in the normal range, but with
> discontiguous mantissa bits so the low parts of the long doubles are
> subnormal doubles, can raise spurious "underflow" exceptions even when the
> final result they return is within the normal long double range.
>
> * Division is inaccurate when subnormal values are involved (see
> <http://sourceware.org/bugzilla/show_bug.cgi?id=15396>).
>
> It would of course be desirable to get those fixes into all active GCC
> release branches so they are more likely to be available for glibc builds.
>
> Care will of course be needed to minimise performance impact of fixes for
> the common case where everything involved is a normal finite double.
>
> In directed rounding modes there is a fourth issue: overflow in
> FE_TOWARDZERO mode (at least) can produce an invalid long double value;
> see <http://sourceware.org/bugzilla/show_bug.cgi?id=13304#c38>.
>
Indeed I overlook it and I'd say the issue is within libgcc. Regarding the issue
with spurious inexact, I could fix it by using the patch:
--- libgcc/config/rs6000/ibm-ldouble.c (revision 199106)
+++ libgcc/config/rs6000/ibm-ldouble.c (working copy)
@@ -105,6 +105,8 @@
if (nonfinite (z))
{
+ if (z != inf())
+ return z;
z = cc + aa + c + a;
if (nonfinite (z))
return z;
I create a bug and ask what GCC guys think.