Porting glibc to Coldfire

[Richard Sandiford]

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.

The coldfire branch of gcc is careful to use the canonical NaN for
__builtin_nan(""), and there are actually tests in gcc.c-torture/execute/ieee
to ensure that it does.  The glibc values I'm overriding are the hard-coded
equivalent of __builtin_nan(""), and I'd like glibc to be consistent.

That said, I realise I made a stupid error; I called one of the files
u_remainder.c rather e_remainder.c ;(.  I must have been thinking of
the header file (urem.h) or something.

I hadn't realised that the 68881 had the same canonical NaN.  However,
it provides its own representation of the affected files, so I believe
they will already return the canonical forms.

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

Richard