Quoting Kaz Kojima <kkoj...@rr.iij4u.or.jp>:
I've got some regressions with "make check" on sh4-unknown-linux-gnu.
It looks that all of them are failed with the undefined references to
__unorddf2/__unordsf2 when -mieee enabled.
That's a bug, then; we shouldn't use a library function there,
but the cmpordered[sd]f_t_4 patterns.
I'm trying the attached patch over sh-softfp-20100718-2131 patch.
All regressions go away with it on cross sh4-unknown-linux-gnu,
though the native bootstrap will take a few days more.
But it's really the instruction expansion that needs to be fixed.
BTW, it looks that softfp __unord?f2 routines check signaling NaNs
only. This makes __builtin_isnan return false for quiet NaNs for
which current fp-bit ones return true when -mieee enabled. Perhaps
that change of behavior might be OK for software FP.
The SH port so far has been using fp-bit.c, which does not actually
support floating point signals, and neither does this optimized software
floating point.
So in essence, we only have quit NaNs. We might as well choose a bit pattern
that is easy to process, to keep code size down and improve performance.
Having a mantissa bit set that is adjacent to the exponent makes for easier
testing.
There is precedence for having the signalling bit in different places and
with different values (i.e. some have 1 == signalling, others 0 ==
signalling).
So we could say that the bit two below the exponent is the signalling bit,
and is active-low. Thus a 0xffffffff in the high or only word is a quiet
NaN.
Tests that feed specific NaN hex values could be disabled or feed modified
values for the SH[123].
OTOH for unorddf / unordsf support with sh4, you would want to keep the
distinction between signalling / quiet NaNs.
(Although I doubt many use signalling support,considering the cost when
you take a trap on every floating point instruction).
The sh.md cmpordered* patterns should do the right thing there, we just
have to keep emitting them.
