Date: Sat, 14 Jan 2012 16:12:40 -0700 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: David Schultz <das@freebsd.org> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: fenv.h fixes for softfloat Message-ID: <1326582760.1678.64.camel@revolution.hippie.lan> In-Reply-To: <20120114211039.GA18310@zim.MIT.EDU> 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> <20120114211039.GA18310@zim.MIT.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2012-01-14 at 16:10 -0500, David Schultz wrote:
> 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.
Woohoo! We have success on the long double printf trouble. I found
that a patch for the problem had been posted to this list almost two
years ago, but apparently never got commited:
http://lists.freebsd.org/pipermail/freebsd-arm/2010-April/002334.html
After applying it and your changes from r230114 the printfloat test now
runs cleanly. Now I'll go see what the full suite of lib/msun tests
does.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1326582760.1678.64.camel>