This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: soft-fp: support after-rounding tininess detection
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: <libc-alpha at sourceware dot org>, Richard Henderson <rth at redhat dot com>
- Date: Wed, 12 Feb 2014 15:27:11 +0000
- Subject: Re: soft-fp: support after-rounding tininess detection
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1402030023100 dot 7179 at digraph dot polyomino dot org dot uk> <52FA97E6 dot 6020000 at twiddle dot net> <Pine dot LNX dot 4 dot 64 dot 1402112217080 dot 11759 at digraph dot polyomino dot org dot uk> <52FB8992 dot 1010601 at twiddle dot net>
On Wed, 12 Feb 2014, Richard Henderson wrote:
> But it still makes no sense to me. E.g. rounding up,
>
> X_f = 111...1100
>
> with the shift sees no carry into OVERFLOW, but then the subsequent
> "real" rounding does see carry into (OVERFLOW>>1). So now we have
> underflow signaled for a result that's not subnormal.
Yes, that's correct: for both before-rounding and after-rounding tininess
detection you get underflow signaled for some cases where the final result
is not subnormal or zero. For example, the following on x86_64 (an
after-rounding architecture), converting to double a long double value
that's tiny when rounded to normal precision but where the final result is
not subnormal:
#include <fenv.h>
#include <stdio.h>
volatile long double ld = 0x1.fffffffffffffp-1023L;
volatile double d;
int
main (void)
{
d = ld;
printf ("%d\n", fetestexcept (FE_UNDERFLOW));
printf ("%a\n", d);
return 0;
}
produces output
16
0x1p-1022
i.e. underflow (FE_UNDERFLOW == 16) has been signaled but the final result
is the least normal value. In the x86 manual I have to hand (Intel 64 and
IA-32 Architectures Software Developer's Manual Combined Volumes: 1, 2A,
2B, 2C, 3A, 3B and 3C Order Number: 325462-047US June 2013), this is
described in "4.9.1.5 Numeric Underflow Exception (#U)" (presumably also
at similar locations in other versions of the manuals).
--
Joseph S. Myers
joseph@codesourcery.com