Date: Tue, 28 Nov 2017 15:09:56 +0000 From: Taylor R Campbell <campbell+netbsd-source-change...@mumble.net> Message-ID: <20171128151435.9bbae60...@jupiter.mumble.net>
| Can you please put it back to an exact equality test and report the | mismatched values in the output, with %a rather than (or in addition | to) %g so that we can see the precise difference in their bits when | the test fails? OK, got my i386 test setup (a Xen DomU) built & running, the updated test failed (as it always failed on i386 before I added the epsilon test, which is #if 0'd out now) the results are ... strto: [0.002429s] Failed: /release/testing/src/tests/lib/libc/locale/t_sprintf.c:145: d != t->double_value: In en_US.UTF-8: d=strtod(t->double_input[-12345.678900], NULL)[-12345.6789 = -0x1.81cd6e631f8a1p+13] != t->double_value[-12345.6789 = -0x1.81cd6e631f8a1p+13]: diff=7.9492e-13 That is parsed as: strto: [0.002429s] Failed: /release/testing/src/tests/lib/libc/locale/t_sprintf.c:145 The subtest that failed, and where its source code came from on my system (and how long it took.) d != t->double_value the test was that d == t->double_value, and that was not true. In en_US.UTF-8 the locale that was being tested. d=strtod(t->double_input[-12345.678900], NULL) that's how d was calculated (the [...] is a %s of the input string). [-12345.6789 = -0x1.81cd6e631f8a1p+13] that is the value of d (strtod result), in %.12g and %a formats != t->double_value[-12345.6789 = -0x1.81cd6e631f8a1p+13] that's the compiler produced double value (again in %.12g and %a formats) diff=7.9492e-13 and that's the absolute value of the difference between the two, that is: fabs(d - t->double_value). Amazing. Note that the "d == t->double_value" test is not using this value, it is a simple comparison (buried in an ATF macro) of the values, so we cannot lay any blame on fabs() (or on the subtraction.) When I "force failed" it on amd64, the result was ... strto: [0.002187s] Failed: /release/testing/src/tests/lib/libc/locale/t_sprintf.c:145: d != t->double_value+1: In en_US.UTF-8: d=strtod(t->double_input[-12345.678900], NULL)[-12345.6789 = -0x1.81cd6e631f8a1p+13] != t->double_value[-12345.6789 = -0x1.81cd6e631f8a1p+13]: diff=0 (note the d != t->double_value+1 - that's why the test failed, the "+1" isn't in any of the other output, which is why it looks as if it should not have failed there (it wouldn't without that +1). I will leave it to someone else to explain why the double values look to be bit for bit identical, and yet apparently are not (they don't compare equal, and when subtracted, do not produce 0). Also remember that this is 100% consistent, it happens every time, so it is not some kind of context switch and floating values not being saved or restored properly issue. When you know what is happening, please file a PR if there is anything that can be done to fix this (perhaps it is just an artifact of i386 floating point?) If that doesn't happen, I'll assume that this is just the way it is, and remove the #if 0, so the "close enough" comparison is back (though now since I have seen how close, I will probably make the test >= 1e-12 rather than the 1e-7 that is there now) and retain my learned "never compare floats for equality" mantra from so many years ago! kre