summaryrefslogtreecommitdiffstats
path: root/configure.in
diff options
context:
space:
mode:
authorMark Dickinson <dickinsm@gmail.com>2009-10-24 13:28:38 (GMT)
committerMark Dickinson <dickinsm@gmail.com>2009-10-24 13:28:38 (GMT)
commit1d6e2e1833864238b903325b37d05fef9b794393 (patch)
tree9ec5c642e19d7aacf9be92a08d28b9434f99b4f6 /configure.in
parent5e9f6676eaf911c9218549ea5f1e022f1ea95e32 (diff)
downloadcpython-1d6e2e1833864238b903325b37d05fef9b794393.zip
cpython-1d6e2e1833864238b903325b37d05fef9b794393.tar.gz
cpython-1d6e2e1833864238b903325b37d05fef9b794393.tar.bz2
Issue #7117 (backport py3k float repr) continued:
- add double endianness detection to configure script - add configure-time check to see whether we can use inline assembly to get and set x87 control word in configure script - add functions to get and set x87 control word in Python/pymath.c - add pyport.h logic to determine whether it's safe to use the short float repr or not
Diffstat (limited to 'configure.in')
-rw-r--r--configure.in112
1 files changed, 107 insertions, 5 deletions
diff --git a/configure.in b/configure.in
index 4713d57..28d0c80 100644
--- a/configure.in
+++ b/configure.in
@@ -3240,12 +3240,107 @@ else AC_MSG_ERROR([proper usage is --with-libc=STRING])
fi],
[AC_MSG_RESULT(default LIBC="$LIBC")])
-# ************************************
-# * Check for mathematical functions *
-# ************************************
+# **************************************************
+# * Check for various properties of floating point *
+# **************************************************
-LIBS_SAVE=$LIBS
-LIBS="$LIBS $LIBM"
+AC_MSG_CHECKING(whether C doubles are little-endian IEEE 754 binary64)
+AC_CACHE_VAL(ac_cv_little_endian_double, [
+AC_TRY_RUN([
+#include <string.h>
+int main() {
+ double x = 9006104071832581.0;
+ if (memcmp(&x, "\x05\x04\x03\x02\x01\xff\x3f\x43", 8) == 0)
+ return 0;
+ else
+ return 1;
+}
+],
+ac_cv_little_endian_double=yes,
+ac_cv_little_endian_double=no,
+ac_cv_little_endian_double=no)])
+AC_MSG_RESULT($ac_cv_little_endian_double)
+if test "$ac_cv_little_endian_double" = yes
+then
+ AC_DEFINE(DOUBLE_IS_LITTLE_ENDIAN_IEEE754, 1,
+ [Define if C doubles are 64-bit IEEE 754 binary format, stored
+ with the least significant byte first])
+fi
+
+AC_MSG_CHECKING(whether C doubles are big-endian IEEE 754 binary64)
+AC_CACHE_VAL(ac_cv_big_endian_double, [
+AC_TRY_RUN([
+#include <string.h>
+int main() {
+ double x = 9006104071832581.0;
+ if (memcmp(&x, "\x43\x3f\xff\x01\x02\x03\x04\x05", 8) == 0)
+ return 0;
+ else
+ return 1;
+}
+],
+ac_cv_big_endian_double=yes,
+ac_cv_big_endian_double=no,
+ac_cv_big_endian_double=no)])
+AC_MSG_RESULT($ac_cv_big_endian_double)
+if test "$ac_cv_big_endian_double" = yes
+then
+ AC_DEFINE(DOUBLE_IS_BIG_ENDIAN_IEEE754, 1,
+ [Define if C doubles are 64-bit IEEE 754 binary format, stored
+ with the most significant byte first])
+fi
+
+# Some ARM platforms use a mixed-endian representation for doubles.
+# While Python doesn't currently have full support for these platforms
+# (see e.g., issue 1762561), we can at least make sure that float <-> string
+# conversions work.
+AC_MSG_CHECKING(whether C doubles are ARM mixed-endian IEEE 754 binary64)
+AC_CACHE_VAL(ac_cv_mixed_endian_double, [
+AC_TRY_RUN([
+#include <string.h>
+int main() {
+ double x = 9006104071832581.0;
+ if (memcmp(&x, "\x01\xff\x3f\x43\x05\x04\x03\x02", 8) == 0)
+ return 0;
+ else
+ return 1;
+}
+],
+ac_cv_mixed_endian_double=yes,
+ac_cv_mixed_endian_double=no,
+ac_cv_mixed_endian_double=no)])
+AC_MSG_RESULT($ac_cv_mixed_endian_double)
+if test "$ac_cv_mixed_endian_double" = yes
+then
+ AC_DEFINE(DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754, 1,
+ [Define if C doubles are 64-bit IEEE 754 binary format, stored
+ in ARM mixed-endian order (byte order 45670123)])
+fi
+
+# The short float repr introduced in Python 3.1 requires the
+# correctly-rounded string <-> double conversion functions from
+# Python/dtoa.c, which in turn require that the FPU uses 53-bit
+# rounding; this is a problem on x86, where the x87 FPU has a default
+# rounding precision of 64 bits. For gcc/x86, we try to fix this by
+# using inline assembler to get and set the x87 FPU control word.
+if test "$GCC" = yes && test -n "`$CC -dM -E - </dev/null | grep i386`"
+then
+ # Check that it's okay to use gcc inline assembler to get and set
+ # x87 control word. It should be, but you never know...
+ AC_MSG_CHECKING(whether we can use gcc inline assembler to get and set x87 control word)
+ AC_TRY_COMPILE([], [
+ unsigned short cw;
+ __asm__ __volatile__ ("fnstcw %0" : "=m" (cw));
+ __asm__ __volatile__ ("fldcw %0" : : "m" (cw));
+ ],
+ [have_gcc_asm_for_x87=yes], [have_gcc_asm_for_x87=no])
+ AC_MSG_RESULT($have_gcc_asm_for_x87)
+ if test "$have_gcc_asm_for_x87" = yes
+ then
+ AC_DEFINE(HAVE_GCC_ASM_FOR_X87, 1,
+ [Define if we can use gcc inline assembler to get and set x87 control word])
+ fi
+fi
# Detect whether system arithmetic is subject to x87-style double
# rounding issues. The result of this test has little meaning on non
@@ -3284,6 +3379,13 @@ then
[Define if arithmetic is subject to x87-style double rounding issue])
fi
+# ************************************
+# * Check for mathematical functions *
+# ************************************
+
+LIBS_SAVE=$LIBS
+LIBS="$LIBS $LIBM"
+
# Multiprocessing check for broken sem_getvalue
AC_MSG_CHECKING(for broken sem_getvalue)
AC_CACHE_VAL(ac_cv_broken_sem_getvalue,