| msg101929 - (view) |
Author: Florent Xicluna (flox) *  |
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) * |
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) * |
Date: 2010-03-30 17:19 |
| Matthias, can you please take a look? |
|
|
| msg101954 - (view) |
Author: Matthias Klose (doko) * |
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) * |
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) * |
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) * |
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) * |
Date: 2010-06-24 17:14 |
| New issue for the Solaris failure opened: issue 9069. |
|
|
| msg110658 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
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) * |
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) * |
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) * |
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? |
|
|