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>