Re: [PATCH] [BZ #2749] soft-fp fixes

[Steven Munroe <munroesj at us dot ibm dot com>]

Jakub Jelinek wrote:
> On Sun, Jan 14, 2007 at 05:05:33PM -0600, Steven Munroe wrote:
>   
>>> That's too high level picture.  Looking at ports CVS, on ppc nofpu x*x+x
>>> for x = NaN
>>> with some non-zero bits in the fraction is libc/soft-fp/mulsf3.c followed
>>> by libc/soft-fp/addsf3.c, right?
>>>       
>> The x*x+x was a read herring. The killer is truncdfsf2!
>>
>> Without this patch the soft-fp trunc[dfsf|tfsf|tfdf] functions fail for
>> NAN. In soft-fp a NAN has a "nonzero fraction" which is nominally all
>> "1"s. The FP_TRUNC(S,D,...); macro copies the high order 26 (23 plus 3
>> guard) bits of fraction from double and sets the exponent to MAX=255.
>> This results in nonzero guard bits being passed into FP_PACK_SEMIRAW.
>> The values are R_s=0, R_e=255, R_f=03ffffff.
>>     
>
> Then the right fix is IMNSHO to fix FP_TRUNC to never set work bits
> in semi-raw NaNs.  No other operation which works on semi-raw format
> sets them.
>   
If you insist. IMO FP_PACK_SEMIRAW is fragile and is too dependent on
the good behaviour of other macros and rounding a NaN/Inf is aways
wrong, even when it accidentally works in most cases.

But it is more important to get something that works commited to glibc
and gcc then to argue this. This has taken far too long as is.

I'll resubmit combining the patches.