|
Bugzilla – Full Text Bug Listing |
| Summary: | python miscompiled on ppc64 | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Marcus Meissner <meissner> |
| Component: | Development | Assignee: | Michael Matz <matz> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | jmatejek, matz |
| Version: | Stable Snapshot 2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | gcc testcase | ||
|
Description
Marcus Meissner
2005-07-21 08:33:43 UTC
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 |