peter.mayd...@linaro.org writes: > On 25 October 2013 12:34, Alex Bennée <alex.ben...@linaro.org> 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
