i386 floating point expertise needed

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

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)