
These issues are on HEAD. There might be some others I missed. With cc there are at least 2 issues: * test_file causes interpreter exit due to sys.stdin.seek(-1) * test_pty fails apparently due to whitespace differences http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/18... Should we skip the test for an invalid seek on stdin on osf1? I haven't investigated the test_pty failure further. With gcc, there are also several issues: * test_float and test_struct fail due to NaN handling * test_long fails * test_ctypes The question is how to fix these. test_float and test_struct fail due to a Floating Point Exception signal (SIGFPE). test_long fails due to float(shuge) raising a ValueError. There is a comment: # XXX Perhaps float(shuge) can raise OverflowError on some box? # The comparison should not. Note: it raises value error, not OverflowError. Should I just wrap the float(shuge) in a try/except and skip the test if an exception is raised? The patches below fix the float and struct problems. I'm not sure if we should ignore SIGFPE in test_float. I'm also not sure if the change to floatobject.c should be made. It's possible there is a compiler flag that would help. I tried -mieee and a few others, but none seemed to make a difference for gcc. test_ctypes fails because _findLib() doesn't seem to work properly on OSF1. Note: libc.so => /usr/shlib/libc.so ERROR: test_find (ctypes.test.test_loading.LoaderTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/test/test_loading.py", line 40, in test_find cdll.find(name) File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/_loader.py", line 205, in find raise OSError("Library %r not found" % name) OSError: Library 'c' not found ====================================================================== ERROR: test_load (ctypes.test.test_loading.LoaderTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/test/test_loading.py", line 25, in test_load cdll.load(name) File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/_loader.py", line 112, in load return self._load(libname, mode) File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/_loader.py", line 124, in load_library return self._dlltype(libname, mode) File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/__init__.py", line 292, in __init__ self._handle = _dlopen(self._name, mode) OSError: dlopen: Cannot map library libc.so.6 ====================================================================== Below are the patches. Index: Objects/floatobject.c =================================================================== --- Objects/floatobject.c (revision 43416) +++ Objects/floatobject.c (working copy) @@ -1430,10 +1430,19 @@ return -1; } else { - float y = (float)x; + float y; const char *s = (char*)&y; int i, incr = 1; + /* The conversion of x to a float causes a floating exception + on some platforms (at least OSF1 v5.1 gcc-4.0.1) + */ +#ifndef MAXFLOAT +#define MAXFLOAT ((float)3.40282346638528860e+38) +#endif + if (x > MAXFLOAT || x < -MAXFLOAT) + goto Overflow; + y = (float)x; if ((float_format == ieee_little_endian_format && !le) || (float_format == ieee_big_endian_format && le)) { p += 3; Index: Lib/test/test_float.py =================================================================== --- Lib/test/test_float.py (revision 43416) +++ Lib/test/test_float.py (working copy) @@ -1,4 +1,5 @@ +import signal import unittest, struct from test import test_support @@ -83,6 +84,12 @@ # is accident (today). class IEEEFormatTestCase(unittest.TestCase): + def setUp(self): + signal.signal(signal.SIGFPE, signal.SIG_IGN) + + def tearDown(self): + signal.signal(signal.SIGFPE, signal.SIG_DFL) + if float.__getformat__("double").startswith("IEEE"): def test_double_specials_do_unpack(self): for fmt, data in [('>d', BE_DOUBLE_INF), Index: Lib/test/test_file.py =================================================================== --- Lib/test/test_file.py (revision 43416) +++ Lib/test/test_file.py (working copy) @@ -100,12 +100,14 @@ print "writelines accepted sequence of non-string objects" f.close() -try: - sys.stdin.seek(-1) -except IOError: - pass -else: - print "should not be able to seek on sys.stdin" +# This causes the interpreter to exit on OSF1 v5.1. +if sys.platform != 'osf1V5': + try: + sys.stdin.seek(-1) + except IOError: + pass + else: + print "should not be able to seek on sys.stdin" try: sys.stdin.truncate() Index: Lib/test/test_long.py =================================================================== --- Lib/test/test_long.py (revision 43416) +++ Lib/test/test_long.py (working copy) @@ -372,10 +372,15 @@ self.assertRaises(OverflowError, eval, test, namespace) - # XXX Perhaps float(shuge) can raise OverflowError on some box? - # The comparison should not. - self.assertNotEqual(float(shuge), int(shuge), - "float(shuge) should not equal int(shuge)") + # float(shuge) can raise OverflowError on an Alpha built with gcc. + try: + fshuge = float(shuge) + except ValueError: + pass + else: + # The comparison should not. + self.assertNotEqual(fshuge, int(shuge), + "float(shuge) should not equal int(shuge)") def test_logs(self): import math Index: Lib/test/test_struct.py =================================================================== --- Lib/test/test_struct.py (revision 43416) +++ Lib/test/test_struct.py (working copy) @@ -429,11 +429,12 @@ # The same, but tack on a 1 bit so it rounds up to infinity. big = (1 << 25) - 1 big = math.ldexp(big, 127 - 24) - try: - packed = struct.pack(">f", big) - except OverflowError: - pass - else: - TestFailed("expected OverflowError") + for value in (big, -big): + try: + packed = struct.pack(">f", value) + except OverflowError: + pass + else: + TestFailed("expected OverflowError") test_705836()

Neal Norwitz wrote:
The question is how to fix these. test_float and test_struct fail due to a Floating Point Exception signal (SIGFPE).
I would hope that there is some way to control the floating point error mode of the CPU (*). Changing it would be one option; Tim hopefully can tell us whether it's a good idea to do so. Regards, Martin (*) I believe you use some #pragma for that in C99; before, there might be some libc or libm API to manipulate the error mode.

Neal Norwitz wrote:
These issues are on HEAD. There might be some others I missed.
With cc there are at least 2 issues: * test_file causes interpreter exit due to sys.stdin.seek(-1) * test_pty fails apparently due to whitespace differences
http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/18...
Should we skip the test for an invalid seek on stdin on osf1? I haven't investigated the test_pty failure further.
With gcc, there are also several issues: * test_float and test_struct fail due to NaN handling * test_long fails * test_ctypes
...
test_ctypes fails because _findLib() doesn't seem to work properly on OSF1. Note: libc.so => /usr/shlib/libc.so
ERROR: test_find (ctypes.test.test_loading.LoaderTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/test/test_loading.py", line 40, in test_find cdll.find(name) File "/net/ringneck/scratch1/nnorwitz/python/trunk/Lib/ctypes/_loader.py", line 205, in find raise OSError("Library %r not found" % name) OSError: Library 'c' not found
The ctypes findLib stuff for 'os.name == "posix"' was written by Andreas Degert, he used fancy calls to gcc, /sbin/ldconfig, and objdump to find the shared lib that would be used for the linker's -l<libname> flag. Apparently this only works on *some* systems. On OSX, Bob Ippolito's macholib is used. If someone could implement this for other systems it would be great, otherwise it would probably be best to enable this test only on linux . Thomas

Disabling a test on a platform is usually a bad thing, overall. The purpose of the test suite isn't to get a lot of green buildbot boxes <0.5 wink>, it's to determine whether Python works as expected. If a platform bug causes some test to fail, then that test _should_ fail on that platform -- it's not a Python bug, after all, and users on that platform aren't served by hiding that platform bugs cause Python tests to fail. If they try the same things in their programs they'll fail there too, and the test suite is supposed to warn them about that. If the primary goal here is really to "make the alpha Tru64 5.1 buildbot columns green", then maybe the Alpha needs a different test runner, to exclude the tests that are doomed to fail due to Alpha bugs.
... With gcc, there are also several issues: * test_float and test_struct fail due to NaN handling * test_long fails
Which version of gcc is in use? Alpha hardware has incomplete support for IEEE endcase semantics, and "it usually" requires a special compiler option to generate code that hides the HW limitations. That you didn't list the above as failures using the native cc strongly suggests that we're missing a necessary gcc Alpha trick. You can go to: http://gcc.gnu.org/onlinedocs/ pick the version of gcc, and drill down to the "DEC Alpha Options" chapter for that version to see the Alpha tricks available. Looks like compiling with -mieee would be an excellent idea for Python, and looks like we're not using that now. I've never used an Alpha, but I recall that this suggestion fixed other peoples' problems :-)

On 3/30/06, Tim Peters <tim.peters@gmail.com> wrote:
Disabling a test on a platform is usually a bad thing, overall. The
Agreed.
purpose of the test suite isn't to get a lot of green buildbot boxes <0.5 wink>, it's to determine whether Python works as expected. If a platform bug causes some test to fail, then that test _should_ fail on that platform -- it's not a Python bug, after all, and users on that platform aren't served by hiding that platform bugs cause Python tests to fail. If they try the same things in their programs they'll fail there too, and the test suite is supposed to warn them about that.
Fair enough. However, it's not just that the test fails. It's that Python exits. Hell, if I'm in bash, bash dies too! If I'm running python in gdb, gdb dies. I tried building a trace (supposedly like truss), but that crashes while python is starting up. So we can never get results on which tests failed, since we can never finish reasonably. When I single stepped in gdb, the code died when executing the equivalent of fseek(stdin, -1, 0); I tried to seek(-1) on a different file and that was ok. The test is meant to stress a failure condition, but fseek is expected to return. Upgrading the machine isn't an option (it's not mine), and I don't know that upgrading would fix the problem.
If the primary goal here is really to "make the alpha Tru64 5.1 buildbot columns green", then maybe the Alpha needs a different test runner, to exclude the tests that are doomed to fail due to Alpha bugs.
That's not my goal. I just want to get as much information as possible. I also don't want to skip all of test_file, only one test case.
... With gcc, there are also several issues: * test_float and test_struct fail due to NaN handling * test_long fails
Which version of gcc is in use? Alpha hardware has incomplete support
4.0.1.
Looks like compiling with
-mieee
would be an excellent idea for Python, and looks like we're not using that now. I've never used an Alpha, but I recall that this suggestion fixed other peoples' problems :-)
Since we are already using -ieee for the platform cc, I thought this was an excellent idea as well. I almost put in my message that I tried it along with a couple other options. But I guess I was on crack or something, cause I tried it again, being very careful (ie, not trying to do 4 things at once) and voila! it worked. Thanks Tim! It fixed the problem with test_float, test_long, and test_struct. The thing that seems really odd is that I was sure test_pty passed before with gcc, now it's failing. Given the problem with -mieee, I was probably just very confused when I did everything the first time. So now the failures with gcc are: test_file, test_pty, test_ctypes. I believe this is the same as with the platform cc. Additional ctypes failure info for Thomas: AssertionError: ('dlopen: Cannot map library libc.so.6', 'libc.so.6', ('posix', 'osf1V5')) Note: there is no version info on osf1, ie no 6. ldd python shows: libc.so => /usr/shlib/libc.so n
participants (4)
-
"Martin v. Löwis"
-
Neal Norwitz
-
Thomas Heller
-
Tim Peters