Re: i386 floating point expertise needed

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

    Date:        Thu, 30 Nov 2017 19:40:20 +0700
    From:        Robert Elz <kre%munnari.OZ.AU@localhost>
    Message-ID:  <21322.1512045620%andromeda.noi.kre.to@localhost>

  | This suggests (without seeing those sections, so guessing a bit)
  | that perhaps just sticking a (seemingly meaningless) "(double)" cast
  | on the value returned might force it to be reduced from 80 bits to 64

It doesn't, so either the unseen section did not say what I had thought
it might (that a cast should grarantee that the value is of the type named,
and not an extended precision form of that), or gcc simply doesn't
implement that...

I tried both
	d = (double)strtod(...)
and (effectively)
	if ((double)d != stored_value)

and neither had any effect (without -ffloat-store - with that neither
cast is needed.)

It is also worth noting that the test (my current copy) is still written
that way (so the extended diagnostic error report can be issued when it
fails), so it is effectively (or should be) storing the result of strtod()
in a double variable (d) and then comparing that variable with the expected
value (which is a 64 bit double).

gcc seems to be ignoring that store, optimising d away (which is reasonable
as it isn't really used for much) but also optimising away the reduction
from 80 to 64 bits which I would assume it should be doing.

Do we know what happens when this test is compiled with clang to, and, run on
i386?   That one would take me days to set up (if I can even work out all
the right magic to make it happen -- and note I build without an /etc/mk.conf
so putting settings in there is guaranteed useless.)

kre