Date: Wed, 11 Jan 2012 00:26:34 -0500 From: David Schultz <das@freebsd.org> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: freebsd-arm@freebsd.org Subject: Re: fenv.h fixes for softfloat Message-ID: <20120111052634.GA96534@zim.MIT.EDU> In-Reply-To: <1326144525.2199.32.camel@revolution.hippie.lan> References: <20120108183605.GA36775@zim.MIT.EDU> <1326144525.2199.32.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the detailed report! Some replies below... On Mon, Jan 09, 2012, Ian Lepore wrote: > On Sun, 2012-01-08 at 13:36 -0500, David Schultz wrote: > > The patch below should make the fenv.h functions work on ARM chips > > without an FPU. (Hardware FPU support is missing anyway, and > > what's in fenv.h right now is probably wrong.) > > > > It would be great if someone could test this, because I don't have > > the hardware. The regression tests in tools/regression/lib/msun, > > particularly test-fenv.c, should provide some idea of what's > > working and what isn't. > > Right now the most recent FreeBSD version I can conveniently build and > test with on ARM is 8.2. Your patches applied cleanly to that code. > > The compiler whined about missing definition of __fenv_static, so I > added "#define __fenv_static static" in arm/fenv.h, that allowed the > library compile to complete. That's fine. The #define you were missing is in HEAD but not 8.2. > Here's a run with the stock/unpatched 8.2 math lib: > tflex# /tmp/test-fenv > 1..8 > ok 1 - fenv > Assertion failed: (fetestexcept(std_except_sets[i]) == 0), function test_fetestclearexcept, file test-fenv.c, line 150. > Abort (core dumped) > > And here with your patches applied: > tflex# /tmp/test-fenv > 1..8 > ok 1 - fenv > ok 2 - fenv > Assertion failed: (fetestexcept(ALL_STD_EXCEPT) == (ALL_STD_EXCEPT ^ excepts)), function test_fegsetexceptflag, file test-fenv.c, line 193. > Abort (core dumped) > > That looks like progress, if not complete success. :) > > My first attempts at this yesterday yielded confusing results. I had > copied test-fenv.c into our product-build environment for convenience, > and I forgot that environment puts -DNDEBUG on the command line by > default. Man, does that ever lead to confusing output... lots of tests > that didn't work appeared to, then test 6 appeared to fail in a > completely confusing way (well, confusing until I realized all those > asserts in the source expanded to nothing). Given how heavily the test > suite code relies on assert() expanding to actual code, it might not be > a bad idea to put something in each test-whatever.c along the lines of > > #ifdef NDEBUG > #error This code will not work with NDEBUG defined > #endif Small progress! My apologies for the hastily written regression test. Its main purpose in life is to blow up when something breaks, so it uses assert() and doesn't include the extra mechanics to report exactly what went wrong. Debugging it without hardware could be tedious, and I don't actually have the time to dedicate to ARM development. But it's encouraging that all the symbols resolve and nothing bad seems to happen. Perhaps I can commit the softfloat bindings and one of the ARM developers can track down the (hopefully simple) bugs in softfloat or the bindings that prevent fenv.h from working. It's bound to be better than the no-ops we have now, in any case.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120111052634.GA96534>