Porting glibc to Coldfire

Andreas Schwab schwab@suse.de
Wed Aug 16 20:43:00 GMT 2006


Richard Sandiford <richard@codesourcery.com> writes:

> Andreas Schwab <schwab@suse.de> writes:
>> Richard Sandiford <richard@codesourcery.com> writes:
>>
>>>   - The canonical NaN has all significand bits set.
>>
>> This is not different to the 68881.  Since any non-zero bit pattern
>> qualifies as NaN that should not be a problem.
>
> Right, all nonzero significands do of course count as NaN.  But it
> depends what you mean by "problem".  I think it's worthwhile allowing
> users to assume that the NaNs of the same sign produced by one function
> will have the same bit pattern as NaNs produced by another.  In other
> words, it's a QoI issue.

I don't really like how it is implemented.  It depends on implementation
details of the shadowed files, which can change and silently break the
hack.  (Not that I expect it to change soon, but it already happened
once.)  I'd rather leave it alone.

> What were you thoughts on the rest of the patch?  Did it look
> OK otherwise?

How did you handle the lack of TLS support?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."



More information about the Libc-ports mailing list