Joseph Myers <jos...@codesourcery.com> writes:
> On Fri, 1 May 2020, Alex Bennée wrote: > >> OK - so these only turn up in i386? > > Patch 1, silencing sNaN, is about generic semantics of IEEE floating-point > conversions (which are implemented correctly in various other cases in > QEMU), and would be equally applicable to m68k (I believe, without having > m68k hardware to test). > > Patches 2 and 3 are i386-specific (just like everything in the existing > softfloat code relating to floatx80 subnormals), because m68k interprets > biased exponent zero differently. > > Patch 4 would apply equally to m68k, because all that matters there is > that a certain representation is a small nonzero value, not exactly what > value it is. > > None of these apply to any other architectures supported by QEMU. > >> We have two tests currently (float_convs and float_madds) which >> currently exercise the various combinations of limits and NaN types >> using some common float_helpers.c support. Maybe extend it for have a >> table of the various ext80 types and write a i386 only test case to >> exercise the functions you fixed? > > It seems to me that appropriate tests would be entirely i386-specific (in > tests/tcg/i386?). Yes. > How are such tests supposed to signal success or > failure, since all the tests currently there seem to exit with status 0 > unconditionally? Non-zero exit. The float_convs and madds tests always pass but the second phase is a diff with a reference output which may fails. Whichever is easier for your test case. > I do have a test I'm using to check these fixes (in C code for convenience > of implementation, with only a little inline asm), but it's not suitable > for inclusion as-is, since it includes many tests that currently fail > (e.g. for exceptions generated, since the i386 floating-point support in > QEMU currently discards exceptions from the softfloat code; one of the > things I intend to fix but haven't yet). It also doesn't yet cover all > the problems I think I've found so far in the floating-point support in > the i386 port (at least ten such bugs beyond the ones fixed in the present > patch series). And it might well depend on details of compiler code > generation to test some of the bugs effectively. OK - we certainly want to include tests for fixed functionality as we add it. It's something we are trying to get better at since the big re-write a few years ago. -- Alex Bennée
