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?). How are such tests supposed to signal success or failure, since all the tests currently there seem to exit with status 0 unconditionally? 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. -- Joseph S. Myers jos...@codesourcery.com
