Matt, as maintainer of the GCC4 branch you should be aware of an issue
affecting the GCC4 build on x86. Some folks may consider this minor but I
believe it is important.

The issue arises as a side effect of the build method. To be precise, only
GCC Pass1 is run as `make bootstrap'. The other 2 builds of GCC are run as
just plain old `make'.

In a nutshell, if you build x86 GCC4 with `make bootstrap' you end up with a
compiler that was itself compiled with `-O2 -g -fomit-frame-pointer'. If you
build x86 GCC4 with plain old `make' you end up with a compiler that was
itself compiled with `-O2 -g'. Notice the lack of `-fomit-frame-pointer'.

This is because a "host Makefile fragment" was added to x86 to "speed up the
compiler". Please look at `config/mh-x86omitfp' and note that it sets
BOOT_CFLAGS. Then realize that BOOT_CFLAGS only take effect during `make

The upshot is that you end up with a subtly different (and slower?) compiler
depending on whether you built it with `make bootstrap' or `make'. This
behavior differs from GCC-3.x where identical (byte-for-byte) compilers are

Apparently, `-fomit-frame-pointer' on x86 makes more difference on GCC4 than
it does with older compilers.. hence why they added it as a build tweak. I
don't know about you, but I certainly want my final GCC to be built as per
the wishes of the GCC developers.

One obvious way to address the issue would be to run `make bootstrap' for
each pass. But this is effectively building GCC 9 times. Not only is this
unnecessary and ridiculously time consuming (GCC4 bootstraps are MUCH slower
than GCC-3.x), it demonstrates a lack of understanding of the GCC build
process. I've opted for a different method, by taking advantage of an unused
GCC Makefile variable `XCFLAGS'. Something like the following sed (ONLY for
GCC Pass2 and Ch 6 GCC) achieves the desired effect for me:

  sed -i '/^XCFLAGS/s/$/ -fomit-frame-pointer/' gcc/Makefile.in

Not sure how you're going to address it, or if you even want to address it
at all. But folks should certainly be made aware of the issue IMHO. Arriving
at a slower compiler than intended is not good. I suppose benchmarking could
be done to determine how much difference it really makes, but personally I
couldn't be bothered doing all that work when a simple solution exists.

FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to