Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Jan 2012 10:53:46 -0700
From:      Ian Lepore <freebsd@damnhippie.dyndns.org>
To:        freebsd-arm <freebsd-arm@freebsd.org>
Cc:        David Schultz <das@freebsd.org>
Subject:   Re: fenv.h fixes for softfloat
Message-ID:  <1326563626.1678.34.camel@revolution.hippie.lan>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1326563626.1678.34.camel>