From owner-freebsd-arm@FreeBSD.ORG Mon Jan 9 21:28:49 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 30A7B1065673 for ; Mon, 9 Jan 2012 21:28:49 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 116C78FC15 for ; Mon, 9 Jan 2012 21:28:48 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta12.emeryville.ca.mail.comcast.net with comcast id KZSB1i0041vN32cACZUo5E; Mon, 09 Jan 2012 21:28:48 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta22.emeryville.ca.mail.comcast.net with comcast id KZUn1i00F4NgCEG8iZUn3b; Mon, 09 Jan 2012 21:28:48 +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 q09LSjUL025685; Mon, 9 Jan 2012 14:28:45 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: David Schultz In-Reply-To: <20120108183605.GA36775@zim.MIT.EDU> References: <20120108183605.GA36775@zim.MIT.EDU> Content-Type: text/plain Date: Mon, 09 Jan 2012 14:28:45 -0700 Message-Id: <1326144525.2199.32.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org 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: Mon, 09 Jan 2012 21:28:49 -0000 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. My hardware is an Atmel at91rm9200 (180mhz armv4, no fpu). I'm using this compiler: # gcc -v Using built-in specs. Target: arm-undermydesk-freebsd Configured with: FreeBSD/arm system compiler Thread model: posix gcc version 4.2.2 20070831 prerelease [FreeBSD] Building the test with this command in tools/regression/lib/msun: cc -pipe -O0 test-fenv.c -o test-fenv -static -lm Which results in this file: # file test-fenv test-fenv: ELF 32-bit LSB executable, ARM, version 1 (FreeBSD), statically linked, for FreeBSD 8.2 (802508), not stripped 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 Now that I've gotten past the workflow-glitches it'll be easy for me to re-test a new patch or generate more info for you. -- Ian