[Cc mpfr list] On 2018-05-02 13:45:30 +0200, Vincent Lefevre wrote: > and in the configure output: > > checking if compiler knows _Decimal64... no
Note that it is "yes" for kfreebsd-i386: https://buildd.debian.org/status/fetch.php?pkg=mpfr4&arch=kfreebsd-i386&ver=4.0.1-1&stamp=1523420566&raw=0 > It should have been "yes", unless it is known that _Decimal64 does not > work on FreeBSD. But the GCC manual does not mention OS related issues > for _Decimal64: > > https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html Well, I've looked at the test done by MPFR, and it is awkward: volatile _Decimal64 x = 1; union { double d; _Decimal64 d64; } y; if (x != x) return 83; y.d64 = 1234567890123456.0dd; return y.d == 0.14894469406741037E-123 ? 80 : y.d == 0.59075095508629822E-68 ? 81 : 82; If there is any issue related to double (such as the use of x87 extended precision), this may fail. Is this the reason for kfreebsd-amd64? I can see 3 solutions: 1. Still compare to double, but use the hex format for the double values to avoid any inexact base 10 to base 2 conversion. Note: IMHO, if _Decimal64 exists, one can safely assume that the hex format is supported. 2. Use uint64_t instead of double. Similarly, IMHO, if _Decimal64 exists, uint64_t probably exists too. 3. Use an array of 8 unsigned char instead of double, and consider the two possible cases of endianness that can occur nowadays. -- Vincent Lefèvre <vinc...@vinc17.net> - 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)