classification
Title: test_float fails on ARM Linux EABI with soft floating point
Type: behavior Stage: needs patch
Components: Interpreter Core Versions: Python 3.1, Python 3.2, Python 2.7, Python 2.6
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: doko, drkirkby, flox, haypo, loewis, mark.dickinson
Priority: normal Keywords: buildbot

Created on 2010-03-30 10:52 by flox, last changed 2010-09-02 16:45 by doko. This issue is now closed.

Messages (13)
msg101929 - (view) Author: Florent Xicluna (flox) * (Python committer) Date: 2010-03-30 10:52
All the ARM Linux EABI buildbots fail on the same test.

http://www.python.org/dev/buildbot/all/builders/ARM%20Linux%20EABI%202.6/builds/5

test_float
test test_float failed -- Traceback (most recent call last):
  File "/home/pybot/buildarea-armeabi/2.6.klose-linux-armeabi/build/Lib/test/test_float.py", line 665, in test_from_hex
    self.identical(fromHex('0x0.ffffffffffffd6p-1022'), MIN-3*TINY)
  File "/home/pybot/buildarea-armeabi/2.6.klose-linux-armeabi/build/Lib/test/test_float.py", line 375, in identical
    self.fail('%r not identical to %r' % (x, y))
AssertionError: 2.2250738585071999e-308 not identical to 2.2250738585071984e-308
msg101931 - (view) Author: Florent Xicluna (flox) * (Python committer) Date: 2010-03-30 10:55
Same failure on trunk:
http://www.python.org/dev/buildbot/all/builders/ARM%20Linux%20EABI%20trunk/builds/12
msg101949 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-03-30 17:19
Matthias, can you please take a look?
msg101954 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2010-03-30 20:14
the buildbot labeled "ARM Linux 3.x" is an ARM EABI as well, compiler defaults -march=armv7 -math=vfp -float-abi=softfp.

The failing test_float test is an ARM EABI, armv4, ARM mode, soft floating point. I never did see the test_float test suceed on this platform/configuration.
msg102135 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-04-01 21:34
From the values in the report, float.fromhex is giving the correct value here, but MIN-3*TINY is somehow coming out incorrectly.

Correct values (with Python 2.6, so old float repr; OS X 10.6.2):

Python 2.6.5+ (release26-maint:79559:79560, Apr  1 2010, 21:54:0) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> float.fromhex('0x0.ffffffffffffd6p-1022')
2.2250738585071999e-308
>>> MIN = float.fromhex('0x1p-1022')
>>> TINY = float.fromhex('0x0.0000000000001p-1022')
>>> MIN
2.2250738585072014e-308
>>> TINY
4.9406564584124654e-324
>>> 3*TINY
1.4821969375237396e-323
>>> MIN - 3*TINY
2.2250738585071999e-308
>>> from math import ldexp
>>> ldexp(1.0, -1074)
4.9406564584124654e-324

It would be helpful to see the corresponding ARM outputs.  I suspect a platform bug either in ldexp or in the multiplication or subtraction above.
msg102188 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-04-02 19:22
I made a couple of experimental checkins to the release26-maint branch (I didn't want to do a temporary checkin to the trunk with a release imminent):  see r79560 (which didn't work :) and its fix in r79601.  Results:

  MIN = 2.2250738585072014e-308
  TINY = 4.9406564584124654e-324
  3*TINY = 1.4821969375237396e-323
  MIN - 3*TINY = 2.2250738585071984e-308
  ldexp(1.0, -1074) = 4.9406564584124654e-324

The values for MIN, TINY and 3*TINY are correct; the value for MIN - 3*TINY (which should be an exact operation) is not:  it's giving something equal to MIN - 6*TINY instead.  This should be easily reproducible at the C level, since the Python subtraction is just a thin wrapper around the corresponding C operation.

So it looks as though the float emulation is buggy on this platform, and this bug should be reported upstream.  Matthias, can you take care of this?

For Python, I'm not sure what the appropriate action is, but I'd rather not skip the test, or otherwise completely silence the error.  Maybe some sort of "expected failure due to platform floating-point bug" output?
msg108530 - (view) Author: David Kirkby (drkirkby) Date: 2010-06-24 16:56
I'm seeing this failure on both Solaris 10 (SPARC processor) in 32-bit mode and OpenSolaris 06/2009 (Intel Xeon) in 64-bit mode using Python 2.6.4. So it is not just an ARM Linux issue. 

See 

http://trac.sagemath.org/sage_trac/ticket/9297
http://trac.sagemath.org/sage_trac/ticket/9299

Note, Solaris supports both a 32 and 64-bit ABI. Not  sure if that is relevant, but I see "ABI" in the title, so perhaps it might be. 

Dave
msg108531 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-24 17:06
David, thanks for the report.  This looks like a different issue to me, though.
msg108535 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-06-24 17:14
New issue for the Solaris failure opened:  issue 9069.
msg110658 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-18 15:39
The test_float failure is still extant.

Here's the output of gcc -v on this buildbot, for use in any gcc bug report:

Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-6' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.4.4 (Debian 4.4.4-6) 

and the relevant compilation line:

gcc -pthread -c  -g -O2 -g -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Objects/floatobject.o Objects/floatobject.c
msg110662 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-18 16:03
Added some test code to the configure script in r82957;  if the corresponding configure test fails, this snippet can be used in the gcc bug report.
msg110717 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-07-19 07:29
I notice (again) that these failures occur on the 2.6 and 3.1 buildslaves (where the debug build includes the -O2 compilation flag), but not the 2.7 or py3k buildslaves.  So again this looks like a compiler optimization bug.

This should really be reported upstream, but without direct access to the machine to produce a small failing example I don't think I can compose a decent bug report.

Closing this as 'won't fix'.
msg115395 - (view) Author: Matthias Klose (doko) * (Python committer) Date: 2010-09-02 16:45
I checked with gcc-4.4 from the 4.4 branch, and with a recent build from the trunk.  The check fails with -O0, and succeeds with -O1 and higher.

Is the testcode from r82957 really using the optimization flags?
History
Date User Action Args
2010-09-02 16:45:26dokosetmessages: + msg115395
2010-07-19 07:29:52mark.dickinsonsetstatus: open -> closed
resolution: wont fix
messages: + msg110717
2010-07-18 16:03:37mark.dickinsonsetmessages: + msg110662
2010-07-18 15:39:50mark.dickinsonsetmessages: + msg110658
2010-06-24 17:14:50mark.dickinsonsetmessages: + msg108535
2010-06-24 17:06:15mark.dickinsonsetmessages: + msg108531
2010-06-24 16:56:31drkirkbysetnosy: + drkirkby
messages: + msg108530
2010-04-18 22:33:06hayposetnosy: + haypo
2010-04-02 19:22:27mark.dickinsonsetmessages: + msg102188
2010-04-01 21:34:05mark.dickinsonsetmessages: + msg102135
2010-03-30 20:14:30dokosetmessages: + msg101954
title: test_float fails on ARM Linux EABI -> test_float fails on ARM Linux EABI with soft floating point
2010-03-30 17:19:08loewissetnosy: + doko, loewis
messages: + msg101949
2010-03-30 10:55:59floxsetmessages: + msg101931
2010-03-30 10:52:45floxcreate