From owner-freebsd-arm@FreeBSD.ORG Sat Jan 14 17:53:50 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 384881065672 for ; Sat, 14 Jan 2012 17:53:50 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id BAF9C8FC14 for ; Sat, 14 Jan 2012 17:53:49 +0000 (UTC) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta07.emeryville.ca.mail.comcast.net with comcast id MVsx1i0080x6nqcA7Vtp9S; Sat, 14 Jan 2012 17:53:49 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta12.emeryville.ca.mail.comcast.net with comcast id MVto1i00V4NgCEG8YVtoml; Sat, 14 Jan 2012 17:53:49 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q0EHrkeS002095; Sat, 14 Jan 2012 10:53:46 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: freebsd-arm In-Reply-To: <20120114081214.GA14925@zim.MIT.EDU> 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> Content-Type: text/plain Date: Sat, 14 Jan 2012 10:53:46 -0700 Message-Id: <1326563626.1678.34.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: David Schultz Subject: Re: fenv.h fixes for softfloat X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 17:53:50 -0000 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. 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. There definitely isn't anything drastically wrong with our 8.2 floating point environment, even with the patched backported -current stuff, because in addition to the test suite, I'm also running our regular app on this platform linked against the same libraries. It's steering an atomic clock, keeping it within a few nanos of UTC(GPS), and I'm measuring its performance against another unit here running older code and they're performing comparably. There could be little glitches in non-critical things like printf, but nothing like wrong-endianess. 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. -- Ian