TIP_GCC_4.0_Testing_Tips

Statement of Intent

Statement of Intent: Even though GCC 4.0 is still being tested, there has not been a diminished interest for some to fool around with it. Perhaps these individuals will write their own bug reports or patches to help speed up the migration process once it comes. In any case, the problem is that there is not very much good or consolidated information available online; and if it does exist, it is very disjointed not well maintained. These things have prompted the creation of this article.

Forewarning

Having the aforementioned state of GCC 4.0 testing in mind, one must know there are several risks to using GCC 4.0. Someone else who is more qualified or who has had direct experience with some incident would be the most qualified to write this section.

Setup

As of february 08, 2006, Portage no longer provides gcc 4.0.1 and 4.0.0. To begin testing with GCC 4.0.2, you will need the following:

• an up-to-date, stable and consistent system. A chroot can be used.
• seriously. emerge --sync && emerge -e world with USE="-O2 -march=yourarch -pipe" first.
• and no LDFLAGS. ;)

Unmask required packages:

 ~sys-libs/timezone-data-2006a ~amd64
 ~sys-libs/glibc-2.3.6-r2 ~amd64
 ~dev-libs/gmp-4.1.4-r3 ~amd64
 ~dev-libs/mpfr-2.2.0_p8 ~amd64
 ~sys-devel/gcc-4.0.2 -*
 

You should be able to do it in a few simple steps:

• emerge --oneshot glibc && emerge -e world
• gcc-config -l
  • This will list all gcc versions available. Choose the right number for the next command:
• gcc-config 6
• source /etc/profile
• emerge -e world
  • The last command will re-compile your system using gcc 4.0.2. If want to compile your system with a gcc 4.0 which was compiled by another gcc 4.0, you may do this instead:
• emerge -e system && emerge -e world

Archs on which this procedure worked:

• AMD64 (2006.0) [64 bit]
• AMD64 (2006.0) [32 bit]
• AMD64 (2005.1-r1)
• Owners of other archs are welcome to test and add to this list.

Additional Packages

If you are adventurous enough to try a stage1 Gentoo install you can bump into several packages which need newer versions, otherwise your emerge system installation step will fail. You will need at least the following package versions (or newer ones):

• sys-libs/libstdc++-v3-3.3.4
• sys-libs/pam-0.78-r2
• sys-fs/e2fsprogs-1.37-r1
• sys-libs/ss-1.37 (e2fsprogs dependency)
• sys-libs/com_err-1.37 (e2fsprogs dependency)
• sys-apps/module-init-tools-3.1-r1

[libstdc++-v3 was introduced as a way to ease the transition from GCC 3.3 to 3.4 which had incompatible c++ libs. it shouldn't be needed at all for GCC 4.0, which include again a different C++ library. there must be a reason it's listed here though, so i'll leave it as is.]

[The comment about libstdc++-v3 is incorrect: there was an ABI transition between gcc 3.3 c++ library and gcc 3.4, so we had to rely on libstdc++-v3; the ABI will remain compatible for transition from 3.4 series to 4.0 series, so no real issue here; alas, the compatibility needs remain]

Building the toolchain

• Use gcc-config to switch to the most current compiler you have on your system. Make sure you're not using a hardened (ssp or pie) variation.
• Set your C(XX)FLAGS to "-O2 -march=yourarch -pipe".
• Unmask (if necessary) and emerge linux-headers
• Add the following to /etc/portage/package.use:

 sys-libs/glibc nomalloccheck nptl nptlonly pic userlocales

I'm assuming you have /etc/locales.build set up. You can omit nptlonly if you like, which will cause glibc to be compiled with support for linuxthreads. This takes twice as long to build, but gives you a fallback in case you run into an odd package that doesn't work with NPTL (i don't know of any).

• Decide if you want to build glibc with frame pointers or not. When you specify -fomit-frame-pointer when building glibc, two sets of libraries are built - one with and one without debugging information. This doubles the compile time and disk footprint of glibc, but results in marginally better performance. Removing -fomit-frame-pointer from your CFLAGS will build a single set. I haven't noticed any difference in performance between them.
• Unmask and emerge glibc
• Add the following to /etc/portage/package.use:

 sys-devel/binutils multislot

This causes any upgrade of binutils to be installed in a SLOT, rather than replacing a previously installed version. This comes in handy because you can then use binutils-config to switch between any number of binutils versions when trying to nail down a bug.

• Unmask and emerge binutils
• use binutils-config to switch to your new version of binutils, and run env-update && source /etc/profile as it instructs.
• Add the following to /etc/portage/package.use:

 sys-devel/gcc multislot

Same deal as above. You don't really need it since 4.0 will get installed into it's own slot anyways, but it doesn't hurt. You can also add the fortran flag for F95 support, gcj to build the java compiler, or objc for objective c.

• Unmask and emerge gcc
• You're done. Next step is emerge -e system. Don't forget to switch to the new compiler with gcc-config first. Keep your CFLAGS sane, don't use -m options other than -march, and do not submit bugs to the Bugzilla unless they're accompanied with patches that fix the problem.

Have fun. ;)

Known Problems

• "-ftree-loop-linear uses the dependence analyzer which has a number of issues where it will claim things are legal that are not."

http://article.gmane.org/gmane.comp.gcc.devel/66099

• There are reported problems with -Os creating larger C++ code with GCC 4.0. It ranges from reports of 40% increases compared to GCC 3.4, to one test case I had that produced code 120% larger and 280% slower than using -O2. (note: this may have been fixed as of 08/05/05)

• -fweb produces very slow code on gcc 4.0.0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20743

• -floop-optimize2 has been known to produce less than optimal code.

http://gcc.gnu.org/ml/gcc/2005-06/msg00159.html

• -fforce-addr and -fforce-mem have been depreciated in 4.1 as they've been rendered obsolete by the tree-based optimization framework. it's unclear whether this also applies to 4.0.

Also see GCC Wiki - Regressions

External Resources

• Part one of a very long discussion
• Part two of a very long discussion
• A small list of Gentoo GCC 4.0 tips