[issue20342] Endianness not detected correctly due to AC_RUN_IFELSE macros

[Gregory P. Smith]

Gregory P. Smith  added the comment:

I'll leave it open, nothing about this should be ppc64 vs ppc64el specific. Our 
cross compilation story has historically been not great.  

Building for a target of one endianness from a build host of other 
endianness... sounds like exactly one of many kinds of thing that we might have 
a mess with until someone can confirm.  (I'm not setup with a big endian 
toolchain to build for a qemu target right now so I can't easily confirm)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20342] Endianness not detected correctly due to AC_RUN_IFELSE macros

[Yury V. Zaytsev]

Yury V. Zaytsev  added the comment:

Well, the machine that I had the problem on does no longer exist and I'm not 
sure whether this is a generic POWER issue.

The problem was that I had to cross-compile Python on one generation of POWER 
machines for another POWER chip using its own special toolchain. I can't tell 
whether Python build system was doing something wrong, or else whether it was a 
problem with the toolchain. In theory, both are valid options.

Also, I can't test whether the current version of Python has this problem or 
not with this particular chip / toolchain anymore. Maybe someone who has 
interest in POWER could try to cross-compile from AMD64 to POWER and check 
whether the result is still subtly broken... this should be much easier, and if 
there is a genuine problem with Python build system, it will probably expose it 
just as well.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20342] Endianness not detected correctly due to AC_RUN_IFELSE macros

[Gregory P. Smith]

Gregory P. Smith  added the comment:

any idea if this is still relevant?

--
components: +Cross-Build
nosy: +Alex.Willmer, gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20342] Endianness not detected correctly due to AC_RUN_IFELSE macros

[Yury V. Zaytsev]

Yury V. Zaytsev added the comment:

I've re-named the issue to reflect the problem.

One possible solution that I can see is to use AC_C_BIGENDIAN macro, either 
exclusively, or only when cross-compiling.

In the latest autoconf sources, this macro seems to try to detect the 
endianness from various macros, and then by grepping the produced object files, 
so it's safe to use during cross-compilation.

Additionally, it allows to set the endianness by hand, if it can't be detected 
automatically.

Any thoughts?

--
nosy: +doko
title: Float rounding issues on Red Hat 6.4 / PPC64 / GCC 4.4.6 - Endianness 
not detected correctly due to AC_RUN_IFELSE macros

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20342
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20342] Endianness not detected correctly due to AC_RUN_IFELSE macros

[STINNER Victor]

STINNER Victor added the comment:

doko One possible solution that I can see is to use AC_C_BIGENDIAN
macro, either exclusively, or only when cross-compiling.

This is wrong. The macro is not used to check the endian but to check
the IEEE 754 implementation. The check is important to decide if David
M. Gay's algorithm for short float representation can be used. See
pyport.h:

/* If we can't guarantee 53-bit precision, don't use the code
   in Python/dtoa.c, but fall back to standard code.  This
   means that repr of a float will be long (17 sig digits).

   Realistically, there are two things that could go wrong:

   (1) doubles aren't IEEE 754 doubles, or
   (2) we're on x86 with the rounding precision set to 64-bits
   (extended precision), and we don't know how to change
   the rounding precision.
 */

#if !defined(DOUBLE_IS_LITTLE_ENDIAN_IEEE754)  \
!defined(DOUBLE_IS_BIG_ENDIAN_IEEE754)  \
!defined(DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754)
#define PY_NO_SHORT_FLOAT_REPR
#endif

/* double rounding is symptomatic of use of extended precision on x86.  If
   we're seeing double rounding, and we don't have any mechanism available for
   changing the FPU rounding precision, then don't use Python/dtoa.c. */
#if defined(X87_DOUBLE_ROUNDING)  !defined(HAVE_PY_SET_53BIT_PRECISION)
#define PY_NO_SHORT_FLOAT_REPR
#endif

--

Python 3.4 already uses AC_C_BIGENDIAN in configure.ac, see how it is
used in pyport.h.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20342
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com