Re: Porting glibc to Coldfire

[Richard Sandiford <richard at codesourcery dot com>]

Andreas Schwab <schwab@suse.de> writes:
> 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.)

Well, I agree it's not a nice implementation, but I think the only
clean fix would be to change upstream sources, and it's very unlikely
that any such changes would be accepted for the sake of m68k.
We're constrained by what would be allowed upstream.

Also, ports tend to need fairly regular TLC anyway if they're going to
keep pace with upstream changes.  The generic m68k changes are examples
of this.  I'm not sure these three files are any worse.  However...

> I'd rather leave it alone.

OK.  I've noted my objections, and it's your call to make.

>> What were you thoughts on the rest of the patch?  Did it look
>> OK otherwise?
>
> How did you handle the lack of TLS support?

A few local hacks to the libc/ tree, I'm afraid.  From that point of view,
you could argue that there's not much point applying the patch.  But the
same problem affects the current m68k port too, and I hope the patch is
strict improvement.

Richard