Hi 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 bootstrap'. 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 produced. 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. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
