This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Mainline bootstrap failure (Re: libstdc++ execute tests)
At 12:14 12.04.2001, Gabriel Dos Reis wrote:
>Alexandre Oliva <aoliva@redhat.com> writes:
>
>| With DJ's patch, the top-level CFLAGS probably stops overriding
>| STAGE1_CFLAGS, so you may get an optimized stage1.
>| If the bootstrap compiler mis-optimizes the code, stage1 may
>| simply crash. However, if you're lucky (and you seem to be!), it'll
>| just disable a few optimizations, so stage2 will work correctly, but
>| it will generate different code, because it won't miss the
>| optimizations. If this theory is correct, bootstrap4 should succeed.
>
>I don't know if the theory is incorrect but bootstrap4 doesn't
>succeed :-(
>
>Since the bootstrapping compiler is gcc-3.0, the problem is serious.
I suspect the gcc-3.0 you use for bootstrapping is broken at least for the
-O0 case.
>Note that I'm now able to bootstrap mainline WITHOUT DJ's patch.
>I can't remember what problem it is supposed to solve.
The original patch to pass down CFLAGS to the stage1_build is simply wrong,
so it was reverted as a first measure. It may even be that the original
patch caused the breakage of your current bootstrap compiler...
Overall I'm quite annoyed that nobody fixes up the build and test machinery
for 3.0, currently I get differing testsuite results (for the complete
compiler with the default languages enabled) for the following reasons:
- building on glibc-2.1 or glibc-2.2 (but libstdc++ test results
are not reported
for 3.0, so nobody notices)
- building with or without --enable-shared (objc is not libgcc_s
aware yet)
- building with or without an installed gcc-3.0 with matching
prefixes (again
objc)
Additionally libstdc++ installs a $prefix/lib/libstdc++.la which includes
the libstdc++ *build* directories in dependency_libs, with the result that
libtool aware applications like KDE2 use them for their -L flags during
linking...
Franz.