This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix underflow and inexact signalling in soft-fp whenpacking.
On Fri, 25 May 2012, David Miller wrote:
> From: "Joseph S. Myers" <joseph@codesourcery.com>
> Date: Fri, 25 May 2012 22:53:52 +0000 (UTC)
>
> > On Fri, 25 May 2012, David Miller wrote:
> >
> >> @@ -220,7 +220,6 @@ do { \
> >> if (X##_e <= _FP_WFRACBITS_##fs) \
> >> { \
> >> _FP_FRAC_SRS_##wc(X, X##_e, _FP_WFRACBITS_##fs); \
> >> - _FP_ROUND(wc, X); \
> >> if (_FP_FRAC_HIGH_##fs(X) \
> >> & (_FP_OVERFLOW_##fs >> 1)) \
> >> { \
> >
> > Is this "if" case now possible, with the rounding no longer happening
> > here?
>
> Yes, it triggers, we've seen it happen in the Linux kernel copy
> of the soft-fp code.
For what operation on what inputs does it trigger? As I understand the
code, on entry to this macro (for a finite nonzero value) the exponent
should always be the correct exponent for an infinite-precision
calculation, and the mantissa should always be shifted so that the
overflow bit is not set but the bit to the right of it (the most
significant bits of the mantissa that's implicit in the actual
floating-point binary format) is set. So the patch seems overly
complicated to me without an explanation of where the above description
goes wrong.
> And I'm trying to make this code match as close as possible what we
> use there since this bug has been fixed in the Linux kernel copy for
> almost 5 years and that code has been rigorously tested against
> TestFloat by the powerpc folks.
Did the Linux kernel version ever get updated for all the performance
improvements and bug fixes I made in 2005-6? Unless it did, I'm not
convinced keeping the two in sync is very meaningful; those were pretty
substantial changes to a lot of the code.
--
Joseph S. Myers
joseph@codesourcery.com