Bugzilla – Bug 97562
python miscompiled on ppc64
Last modified: 2007-06-05 12:39:06 UTC
python is somehow miscompiled on ppc64. the test_long testcase fails in the log10 test After build, do: cd /usr/src/packages/BUILD/Python-2.4.1 echo "test_long" > /tmp/pynexttest LD_LIBRARY_PATH=/usr/src/packages/BUILD/Python-2.4.1: ./python -E -tt ./Lib/test/regrtest.py -s -v -v ... log10 is 9.0 , exp is 9 verified log is 20.7232658369 verified log10 is 18.7219011707 , exp is 100 test test_long failed -- test failed so soemthing in log10 or exp is broken. I did not investigate deeper.
Without testcase this could either be glibc or gcc, or anything else. Assigning to ppc for stripping down.
LSB Python (which is Python 2.3.3 compiled only with LSB libraries) has the same problem on ppc64. I think this could be a bug in the Python itself. I have added a bug report to the Python developer bugzilla; you can find it at http://sourceforge.net/tracker/index.php?func=detail&aid=1245381&group_id=5470&atid=105470
assiging to package maintainer
new maintainer
i'm not sure if this should be still open - the bug is caused by gcc's incorrect optimization, and in our package that is already disabled, so it compiles fine
no, broken optimization concern us, -O0 is just a workaround. Can you extract a standalone testcase for this miscompilation? If you cannot, either the Architecture Team or the Compiler Team should do it.
i cannot, i don't have access to any ppc64 machine to test it on
I have borrowed papaya.suse.de for LSB testing, you can test it there; it happens there, I see it in the tests.
ok, i'm working on it
if you have a testcase, or just which file needs the -O0, we want to hear it.
Created attachment 53970 [details] gcc testcase the file is Modules/mathmodule.c and the optimization is definitely playing havoc in there. attached is a stripped down version of that file - as far as i could get. it's not a standalone testcase, you still need the rest of python to use it, and it only works for the following test: import math; print math.log (10**40, 10) should print out something very close to 40 (I lost precision when replacing some result with a constant), and usually prints 21.9382011462 on gcc 3.3.x it works all right, bug appears on gcc 4.0.2 the part that gets optimized out is x = func(x) + (e * (double)SHIFT) * func(2.0); which is reduced to x = func(x);
maybe this should be reassigned to the gcc team now?
yes, if -O$smallnum works and -O$bignum doesnt, its likely a gcc bug.
that's exactly the case. assigning back to michael matz
however the gcc team needs a standalone testcase I guess
Indeed. If you know already the place where you think GCC does some misoptimization (as indicated in comment #11), it shouldn't be difficult to generate a single-file testcase. Please provide one here.
hopefully, the bug seems to have disappeared by now and compilation on ppc64 is OK. marcus, can you please confirm?
(sorry about the status change, I meant to do this)
its gone now, yes. curre