From 4988bbfc07e8a621596dc9cc69b77aa1b58acdd8 Mon Sep 17 00:00:00 2001 From: vlefevre Date: Thu, 12 Mar 2020 00:44:26 +0000 Subject: [acinclude.m4] Added a FIXME: in case of cross-compiling, the guess "DPD" can be wrong, e.g. for the build with MinGW under Linux. One does not get a failure just because of other issues in the code, forcing the portable implementation of the decimal functions. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13778 280ebfd0-de03-0410-8827-d642c229c3f4 --- acinclude.m4 | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/acinclude.m4 b/acinclude.m4 index fc98848f9..9ef16bd98 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -648,6 +648,15 @@ dnl 3. Use uint64_t (or unsigned long long, though this type might not be dnl on 64 bits) instead of or in addition to the test on double. dnl 4. Use an array of 8 unsigned char's instead of or in addition to the dnl test on double, considering the 2 practical cases of endianness. +dnl FIXME: In case of cross-compiling, the guess "DPD" can be wrong, e.g. +dnl for the build with MinGW under Linux. There should be a way to choose +dnl between BID, DPD and unknown, and in the latter case, select the +dnl portable implementation of the decimal functions. Currently, the +dnl portable implementation is selected just because of the ugliness of +dnl the MPFR code, which depends on the binary formats (!!!) and because +dnl the check of the "double" format also uses AC_RUN_IFELSE (contrary to +dnl the "long double" test), thus the "double" format is unknown, and only +dnl the portable implementation can be used. if test "$enable_decimal_float" != no; then AC_MSG_CHECKING(if compiler knows _Decimal64) AC_COMPILE_IFELSE( -- cgit v1.2.1