Some of you might have been following the discussion on source-changed-d about a test (of locales) that was failing on i386, and which I "fixed" in a way that apparently should not be needed.
More diagnosis of the problem makes it appear to be an i386 floating point, or compiler code generation to use it, issue. It boils down to the comparison of 2 double variables (which are bit for bit identical in value) failing (they do not compare equal, and if one is subtracted from the other, zero is not the answer.) When run on amd64, for comparison, everything is fine. You can look at Martin Husemann's gdb analysis of the issue in http://mail-index.netbsd.org/source-changes-d/2017/11/29/msg009647.html (And you can go back and forward in that thread in the archives to see some more discussion.) We need someone with i386 floating point knowledge (and I mean, deep down low, what every instruction is supposed to do, and how it is supposed to be used, including all the surrounding support flags words and whatever) to have a look at this, and work out what the problem is. It might be a compiler error, or it might be an error in the way we set up the floating point unit, or it might be ... Help! A solution is not necessarily required - a PR indicating a problem in some area, with an analysis, and "how to demonstrate" would be a big help. kre ps: no real point in specifically including me in any replies, not that I mind, but x86 hardware/compiler issues are way out of my depth. Best would be to keep this discussion, if there needs to be one, on port-i386@ so please respect the Reply-To if you can (that means, don't cc tech-userlevel)
