Date: Sat, 14 Jan 2012 13:29:33 -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: <20120114182933.GA17739@zim.MIT.EDU> In-Reply-To: <1326563626.1678.34.camel@revolution.hippie.lan> References: <20120108183605.GA36775@zim.MIT.EDU> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 14, 2012, Ian Lepore wrote: > On Sat, 2012-01-14 at 03:12 -0500, David Schultz wrote: > > On Fri, Jan 13, 2012, Ian Lepore wrote: > > > These are the results of running all the regression tests (except those > > > requiring complex number support) after applying the minor tweaks to > > > David's original patches. The build and run conditions are the same as > > > I mentioned earlier in the thread. > > > > Thanks! These are very helpful. Some of the failures are due to > > bugs that were fixed since 8.2-RELEASE. (Indeed, the regression > > tests were added because of the bugs.) Other failures are more > > mysterious. > > Well then, they're all mysterious. I wanted to avoid exactly this kind > of trouble of testing old code that had already been fixed after 8.2. I > did a "start over" a couple days ago where I pulled a fresh copy of our > 8.2 source (really 8-stable as of svn rev 223361, then with lots of our > own patches on top, but none in libc or libm), then I overlaid the > complete contents of lib/msun and tools/regression/lib/msun from > -current and got that building on 8.2 before applying your patches. The > snapshot of -current I pulled the math code from was Jan 4th or 5th (via > cvs, I haven't got an svn working environment here yet). > > My notes on backporting the -current code to 8.2 had this paragraph, > could this be part of the trouble... > > I also had to revert all the Symbol.map files that tried to mark > some of the new functions as available only in FSBD_1.3 lib > version, because the lib tool was unhappy with that. > > I didn't think that would be significant in terms of getting this > testing done. > > Also, I did not pull the complete libc from -current, could that be the > problem? The testing was with a stock 8.2 libc with only your patches > from this list applied. > > I just spot-checked the s_fma.c routine in my test chroot against the > svn log for r226371 and I've definitely got those changes, and I assume > that's true for the other things you mentioned as already-fixed. For historical reasons, modf() lives in libc, but otherwise the libc sources shouldn't matter. If you have the msun sources from HEAD and you're still getting those errors, there may be something wrong with fenv, softfloat, or printf. It would be interesting to see the results of the test-printfloat test in regression/lib/libc/stdio. > When it comes to the test-lrint failure, I'm very sure it was running > rint(), because I was debugging by sticking printf()s in the routine in > s_rint.c (I don't have a working gdb for 8.2 arm, so printf debugging is > my only option, but really I tend to prefer it to gdb anyway). It did > strike me as very odd that the test of rounding 1.0 was the one to fail > with FE_INVALID. This is a pretty basic failure, so if we can figure it out, it might explain some of the other bugs. A minimal test that reproduces the problem would be a good start. I still find it hard to believe that 1.0 is the value being passed to rint(). Printing the values of i0 and i1 in hex inside rint() would show you the bit pattern being passed in, and might explain why the wrong branch is being taken. The correct representation of 1.0 is 0x3ff0000000000000, with the all-zero word in i1. > I'll see if I can figure out whether there's anything environmental > going on here. I'm linking the tests with -static, my intent being that > I wanted to make sure I was running the code I think I am, not code from > some cached shared lib or something. Static linking is a thing that > doesn't get tested much anymore, and does sometimes lead to glitches you > don't see with dynamic linking. For example, I'm compiling the tests > with -O0 but I think the libs get compiled with -O1, and I've seen that > cause trouble with inline functions -- the linker will whine about > multiple definitions of an object having different sizes, although I > didn't see any such warnings in my test compiles. The tests are compiled with -O0 by default. The -fno-builtin flag (for both the tests and for libm itself) is also useful, since it rules out bugs due to bogus compiler builtins.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120114182933.GA17739>