This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix underflow and inexact signalling in soft-fp whenpacking.


From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Fri, 25 May 2012 23:43:18 +0000 (UTC)

> 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.

I think part of all of these problems is that things come out a little
bit differently from the FP_DIV macro.  For example, for double
operation:

    000.FFFFFFFFFFFFF / 3FE.FFFFFFFFFFFFE

FP_DIV generates:

    sign:         0
    mantissa: 01000000 00000000
    exp:         -1023 (0)

So we're exact before rounding.

There's a lot more information and discussion in the commit logs
messages of Linux kernel commits:

405849610fd96b4f34cd1875c4c033228fea6c0f

and

930cc144a043ff95e56b6888fa51c618b33f89e7

BTW, kernel commit f8324e20f8289dffc646d64366332e05eaacab25 fixes
another bug that we might have in the glibc and libgcc copies.  I
haven't looked more deeply at this yet, but it is on my TODO list.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]