From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZh98-0003ts-Ok for qemu-devel@nongnu.org; Fri, 25 Oct 2013 09:09:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZh93-0007yY-WF for qemu-devel@nongnu.org; Fri, 25 Oct 2013 09:09:46 -0400 References: <526947CA.4020504@gmail.com> <52694821.4040001@gmail.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: Date: Fri, 25 Oct 2013 14:09:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 01/19] Add New softfloat Routines for VSX List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Tom Musta , "qemu-ppc@nongnu.org" , QEMU Developers peter.maydell@linaro.org writes: > On 25 October 2013 12:34, Alex Bennée wrote: >> Is it worth adding some sort of test into make check to defend these >> softfloat functions against unintentional breakage? It would certainly >> be worthwhile as soon as multiple arches use these functions as float >> errors are often subtle and hard to track down. > > Ideally, but there's zero infrastructure for doing the kind > of serious including-edge-cases testing at the moment, so I'm > not really in favour of making it a gating condition for > accepting patches. I'm not proposing to halt inclusion for that I was just wondering aloud how it could be defended. For the soft-float routines themselves they could be tested within the existing tests/ stuff like tests/check-qfloat.c without having to worry about hooking into target arch specific test cases. > If somebody wanted to set up such infrastructure, there are > a couple of approaches that spring to mind: > (a) get risu (https://wiki.linaro.org/PeterMaydell/Risu) working > on more target architectures, add the "record-and-replay" feature > so it can be run without having target hardware, and then just > test softfloat by testing the actual target fp instructions Interesting. Funnily we spent a lot of time at Transitive fixing up translation failures that our random code generator threw up. It's also equally interesting how far you can get with fairly broken translation that no actual applications care about. I'll have a look once I've fixed up build machinery around the existing TCG tests. > (b) something involving wiring up IBM's IEEE test suite > vectors directly to our softfloat code: > https://www.research.ibm.com/cgi-bin/haifa/test_suite_download.pl?first=elenag&second=webmaster > (it's not clear to me what license the test vectors are > under) > > -- PMM -- Alex Bennée