On 2017-05-13 11:06:06 +0800, Liu Hao wrote:
> On 2017/5/13 10:25, Vincent Lefevre wrote:
> > On 2017-05-12 23:46:09 +0800, Liu Hao wrote:
> > 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.
^^^^^^^^^
> A QNaN doesn't generate an exception regardless of the x87 control word.
I'm not talking about QNaN (quiet NaN), but signaling NaN (SNaN).
> > 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.
> It does generate an exception so why do you think it is not a trap
> representation?
It isn't because the value doesn't generate a trap. FP exceptions
are a different notion. They are generated by operations, not by
reading values.
> Let's try `=` which corresponds to the IEEE 754 equality operator too:
No, in C, '=' is an assignment operator.
> -------------------------------------------------------
> lh_mouse@lhmouse-dev:~$ cat test.c
> #include <stdio.h>
> #include <math.h>
>
> int main (void)
> {
> unsigned short fcw;
> __asm__ volatile (
> "fstcw %0; "
> "andw $-2, %0; "
> "fldcw %0; "
> : "=m"(fcw)
> );
> long double ld = 0;
> unsigned char data[10] = {
> 0x5b, 0x01, 0x04, 0x5e, 0x85, 0x00, 0x00, 0x00, 0xd8, 0x59
> };
> __builtin_memcpy(&ld, data, 10);
> long double y = 1;
> y = ld;
> printf ("%Lg\n", y);
> return 0;
> }
> lh_mouse@lhmouse-dev:~$ gcc test.c -Wall -Wextra -pedantic -std=c99
> lh_mouse@lhmouse-dev:~$ ./a.out
> 5.11212e+1984
> -------------------------------------------------------
The printf is not a processor instruction. I would see this as a bug
in the C library. Otherwise there's a clear contradiction with the
behavior of ==, which directly corresponds to an x86 instruction.
But they might also see this as undefined behavior, in which case
long double mustn't be documented as being the x86 double-extended
format.
--
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)
