On 4 January 2011 16:11, Aurelien Jarno <aurel...@aurel32.net> wrote:
> On Tue, Jan 04, 2011 at 03:51:37PM +0000, Peter Maydell wrote:
>> > int float32_is_quiet_nan( float32 a1 )
>> > {
>> > float32u u;
>> > - uint64_t a;
>> > + bits32 a;
>> > u.f = a1;
>> > a = u.i;
>> > return ( 0xFF800000 < ( a<<1 ) );
>>
>> This change is actually changing the type: shouldn't it be bits64 ?
>
> Yes, I should have mentioned it in the changelog. For me this looks like
> a typo, as we are manipulating 32 bits values. Look at
> float32_is_signaling_nan().
Well, it does affect whether that left-shift of a loses the sign bit
or not. However having thought about it it doesn't make any
difference to the result of the comparison, so bits32 would be OK.
On the other hand, this should be a "<=" compare, not "<", I think.
0x7FC00000 is a valid QNaN but this function will return false for
it. Contrast the softfloat-specialize.h float32_is_quiet_nan()
implementation for !SNAN_BIT_IS_ONE, which does use <=.
(On the third hand if you're using softfloat-native then you
probably didn't care about the niceties of NaN usage :-))
-- PMM
