On 2017-05-12 23:46:09 +0800, Liu Hao wrote:
> On 2017/5/12 18:48, Vincent Lefevre wrote:
> > It seems to be regarded as a NaN, not as a trap representation. On
> > Debian/unstable with an Intel(R) Xeon(R) CPU E5-2609 v3 (x86_64):
> >
> > ------------------------------------------------------------------
> > #include <stdio.h>
> >
> > int main (void)
> > {
> > long double ld = 0;
> > unsigned char data[10] = {
> > 0x5b, 0x01, 0x04, 0x5e, 0x85, 0x00, 0x00, 0x00, 0xd8, 0x59
> > };
> > __builtin_memcpy(&ld, data, 10);
> > ld += 1;
> > printf ("%Lg\n", ld);
> > return 0;
> > }
> > ------------------------------------------------------------------
> >
> > cventin:~> gcc-4.9 tst.c -o tst
> > cventin:~> ./tst
> > -nan
> >
> That is because floating point exceptions are masked by default. The trap
> can be observed by unmasking the IM mask in x87 control word:
[...]
But if you do this, you're out of scope of the standards.
Moreover, I suppose that you will also get a floating-point exception
on a signaling NaN, in which case, on this example, this isn't
distinguishable from a signaling NaN.
> > Or perhaps it's just for older processors? AFAIK, the Intel x87 80-bit
> > format is regarded as an extended precision format in IEEE 754-2008
> > (Section 3.7), and trap representations are not allowed since all
> > encodings must map to a floating-point datum (Section 3.2).
> ISO C does not enforce compliance to IEEE 754 or IEC 60559 of `long double`
> (see WG14 N1570 F.2, note that Annex F is normative). An IEC 60559 extended
> format is recommended, but not required.
But the goal of Intel's x87 80-bit format and the IEEE 754-1985 spec
was to regard this format as a conforming double-extended format.
And AFAIK, the intent of IEEE 754-2008 was not to break this.
> I don't think ISO C forbids existence of `trap representation` of
> `long double`.
Anyway, this is not a trap representation as shown above.
> > This encoding could either be interpreted like an unnormalized number
> > (but then transparently normalized) as suggested by IEEE 754-1985, or
> > it should encode a NaN.
> x87 doesn't normalize it but leaves it invalid after loading it. `FXAM`
> doesn't say it is a NaN, so it is not a NaN.
FXAM is neither an IEEE 754 operation, nor an ISO C operation.
Let's try ==, which corresponds to the IEEE 754 equality operator:
#include <stdio.h>
int main (void)
{
long double ld = 0;
unsigned char data[10] = {
0x5b, 0x01, 0x04, 0x5e, 0x85, 0x00, 0x00, 0x00, 0xd8, 0x59
};
__builtin_memcpy(&ld, data, 10);
printf ("NaN? %s\n", ld == ld ? "no" : "yes");
return 0;
}
This gives:
NaN? yes
So, it is regarded as a NaN.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
