fenv.h fixes for softfloat

[David Schultz]

On Sat, Jan 14, 2012, Ian Lepore wrote:
> 66: printf("%13LE", 1.0L) ==> [ 0.000000E+00], expected [ 1.000000E+00]
> 66: wprintf("%13LE", 1.0L) ==> [ 0.000000E+00], expected [ 1.000000E+00]
> 67: printf("%13Lf", 1.0L) ==> [     0.000000], expected [     1.000000]
> 67: wprintf("%13Lf", 1.0L) ==> [     0.000000], expected [     1.000000]
> 68: printf("%13LG", 1.0L) ==> [            0], expected [            1]
> 68: wprintf("%13LG", 1.0L) ==> [            0], expected [            1]
> 75: printf("%Le", 1234567.8L) ==> [1.859918e+05], expected [1.234568e+06]
> 75: wprintf("%Le", 1234567.8L) ==> [1.859918e+05], expected [1.234568e+06]
> 76: printf("%Lf", 1234567.8L) ==> [185991.800000], expected [1234567.800000]
> 76: wprintf("%Lf", 1234567.8L) ==> [185991.800000], expected [1234567.800000]
> 77: printf("%LG", 1234567.8L) ==> [185992], expected [1.23457E+06]
> 77: wprintf("%LG", 1234567.8L) ==> [185992], expected [1.23457E+06]
[...]
> 221: printf("%.3Lf", 4.4375L) ==> [0.437], expected [4.437]
> 221: wprintf("%.3Lf", 4.4375L) ==> [0.437], expected [4.437]
> 222: printf("%.3Lf", -4.4375L) ==> [-0.438], expected [-4.438]
> 222: wprintf("%.3Lf", -4.4375L) ==> [-0.438], expected [-4.438]
> 227: printf("%.3Lf", 4.4375L) ==> [0.438], expected [4.438]
> 227: wprintf("%.3Lf", 4.4375L) ==> [0.438], expected [4.438]
> 228: printf("%.3Lf", -4.4375L) ==> [-0.437], expected [-4.437]
> 228: wprintf("%.3Lf", -4.4375L) ==> [-0.437], expected [-4.437]
> 233: printf("%.3Lf", 4.4375L) ==> [0.437], expected [4.437]
> 233: wprintf("%.3Lf", 4.4375L) ==> [0.437], expected [4.437]
> 234: printf("%.3Lf", -4.4375L) ==> [-0.437], expected [-4.437]
> 234: wprintf("%.3Lf", -4.4375L) ==> [-0.437], expected [-4.437]
> 239: printf("%.3Lf", 4.4375L) ==> [0.438], expected [4.438]
> 239: wprintf("%.3Lf", 4.4375L) ==> [0.438], expected [4.438]
> 240: printf("%.3Lf", -4.4375L) ==> [-0.438], expected [-4.438]
> 240: wprintf("%.3Lf", -4.4375L) ==> [-0.438], expected [-4.438]

These issues all indicate something wrong with the way gdtoa is
set up for your chip.  ARM is a bit strange because some versions
use a floating-point format where the high and low words are
reversed from the normal order (in addition to the usual
endianness issues).

Suitable definitions in libc/arm/arith.h (and possibly
libc/arm/_fpmath.h) will probably fix the problem.  Could you try
swapping the sense of the #if in arith.h, and also removing the
Sudden_Underflow #define?  If the definitions are wrong, it might
screw up doubles as well, but it provides some insight into the
problem regardles.  The other place to check is the definition of
_IEEE_WORD_ORDER in libc/arm/_fpmath.h.

> 273: printf("%La", 0x3.243f6a8885a31p0L) ==> [0x1.921fb54442d18p+1], expected [0xc.90fdaa22168cp-2]
> 273: wprintf("%La", 0x3.243f6a8885a31p0L) ==> [0x1.921fb54442d18p+1], expected [0xc.90fdaa22168cp-2]
> 274: printf("%La", 0x1p-1074L) ==> [0x1p-1074], expected [0x8p-1077]
> 274: wprintf("%La", 0x1p-1074L) ==> [0x1p-1074], expected [0x8p-1077]
> 275: printf("%La", 0x9.8765p-1024L) ==> [0x1.30ecap-1021], expected [0x9.8765p-1024]
> 275: wprintf("%La", 0x9.8765p-1024L) ==> [0x1.30ecap-1021], expected [0x9.8765p-1024]

These failures are bugs in the tests.  There are three equally
valid ways to print a number in the hex format, and I changed the
implementation to use a different one a few years ago.  It looks
like I neglected to update the tests that apply to ARM.  Fixed in
r230114.