Re: CVS commit: src/tests/lib/libc/locale

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 28 Nov 2017 15:09:56 +0000
    From:        Taylor R Campbell <campbell+netbsd-source-changes-d%mumble.net@localhost>
    Message-ID:  <20171128151435.9BBAE60B5D%jupiter.mumble.net@localhost>

  | 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