Bug#897416: mpfr4: FTBFS on kfreebsd-amd64

[Vincent Lefevre <vincent@vinc17.net>]

[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 <vincent@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)