Date: Sat, 14 Jan 2012 16:10:39 -0500 From: David Schultz <das@freebsd.org> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: fenv.h fixes for softfloat Message-ID: <20120114211039.GA18310@zim.MIT.EDU> In-Reply-To: <1326568038.1678.43.camel@revolution.hippie.lan> References: <1326144525.2199.32.camel@revolution.hippie.lan> <20120111052634.GA96534@zim.MIT.EDU> <20120111101833.GA88428@ci0.org> <1326291254.2419.55.camel@revolution.hippie.lan> <20120111175516.GA99475@zim.MIT.EDU> <1326509894.48691.100.camel@revolution.hippie.lan> <20120114081214.GA14925@zim.MIT.EDU> <1326563626.1678.34.camel@revolution.hippie.lan> <20120114182933.GA17739@zim.MIT.EDU> <1326568038.1678.43.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120114211039.GA18310>