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

Same failure on trunk:
http://www.python.org/dev/buildbot/all/builders/ARM%20Linux%20EABI%20trunk/builds/12

Matthias, can you please take a look?

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.

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.

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?

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

David, thanks for the report.  This looks like a different issue to me, though.

New issue for the Solaris failure opened:  issue 9069.

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

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.

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'.

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?