On Fri, Sep 17, 2010 at 06:05, Tom Browder <tom.browder@xxxxxxxxx> wrote:
> The subject says it all. The build works with released gcc version
> 4.5.1. The Python folks say that a pyc file gets corrupted somehow.
>
> I don't think I've updated the trunk since the build but I can't
> guarantee it. Currently I show revision 163997.
I updated to trunk revision 164365, configured, built, and tested c and c++.
Configure:
../gcc-trunk-svn/configure --disable-nls --disable-multilib
--enable-languages=c,c++ --enable-version-specific-runtime-libs
--disable-libgomp --prefix=/disk3/gcc-r164365
Test was okay I think (based on previous builds, looking at the tests,
and past discussions on gcc mailing lists). grepping ^FAIL: on the
sum files yields:
FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors)
FAIL: gcc.dg/cproj-fails-with-broken-glibc.c execution test
./gcc/testsuite/gcc/gcc.sum
FAIL: libmudflap.c/pass49-frag.c execution test
FAIL: libmudflap.c/pass49-frag.c output pattern test
FAIL: libmudflap.c/pass49-frag.c execution test
FAIL: libmudflap.c/pass49-frag.c output pattern test
FAIL: libmudflap.c/pass49-frag.c (-static) execution test
FAIL: libmudflap.c/pass49-frag.c (-static) output pattern test
FAIL: libmudflap.c/pass49-frag.c (-static) execution test
FAIL: libmudflap.c/pass49-frag.c (-static) output pattern test
FAIL: libmudflap.c/pass49-frag.c (-O2) execution test
FAIL: libmudflap.c/pass49-frag.c (-O2) output pattern test
FAIL: libmudflap.c/pass49-frag.c (-O2) execution test
FAIL: libmudflap.c/pass49-frag.c (-O2) output pattern test
FAIL: libmudflap.c/pass49-frag.c (-O3) execution test
FAIL: libmudflap.c/pass49-frag.c (-O3) output pattern test
FAIL: libmudflap.c/pass49-frag.c (-O3) execution test
FAIL: libmudflap.c/pass49-frag.c (-O3) output pattern test
FAIL: libmudflap.c++/pass41-frag.cxx execution test
FAIL: libmudflap.c++/pass55-frag.cxx execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-static) execution test
FAIL: libmudflap.c++/pass55-frag.cxx (-static) execution test
FAIL: libmudflap.c++/pass55-frag.cxx ( -O) execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-O2) execution test
FAIL: libmudflap.c++/pass55-frag.cxx (-O2) execution test
FAIL: libmudflap.c++/pass41-frag.cxx (-O3) execution test
FAIL: libmudflap.c++/pass55-frag.cxx (-O3) execution test
./x86_64-unknown-linux-gnu/libmudflap/testsuite/libmudflap.sum
FAIL: libstdc++-abi/abi_check
FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
./x86_64-unknown-linux-gnu/libstdc++-v3/testsuite/libstdc++.s
I then tried to build Python 2.7 with that gcc but the build failed
with an error from the new executable python. Last lines show:
stdout:
/disk3/gcc-r164365/bin/x86_64-unknown-linux-gnu-gcc-4.6.0 -pthread
-Xlinker -export-dynamic -o python \
Modules/python.o \
libpython2.7.a -lpthread -ldl -lutil -lm
stderr:
XXX lineno: 743, opcode: 0
Traceback (most recent call last):
File "/disk3/extsrc/python-2.7.maint-svn/Lib/site.py", line 62, in <module>
import os
File "/disk3/extsrc/python-2.7.maint-svn/Lib/os.py", line 743, in <module>
def urandom(n):
SystemError: unknown opcode
make: *** [sharedmods] Error 1
The error actually shows up when the compiled python is executed.
So there seems to be a problem there somewhere, and the Python folks
think it is with gcc: miscompiled byte code.
Looking for ideas...and who owns the bug, if there is a legitimate bug?
Have I provided enough information for an educated guess?
Thanks,
-Tom
Thomas M. Browder, Jr.
Niceville, Florida
USA
