GCC 6.1 Compiler Officially Released With OpenMP 4.5, C++14 Default & Much More

[cj.wijtmans]

In my opinion, upgrading a Gentoo system from GCC 4.9 to GCC 5.x or 6.x will make the upgraded system incompatible with 3rd party C++ binaries.

The only solution I was able to come up with is to have two roots in the Gentoo system: one compiled with GCC 4.9, and the other one compiled with GCC 5.x or 6.x. The home directory, and some other directories, are shared between the two. sys-fs/unionfs-fuse is an efficient solution to this in terms of disk space usage, but it isn't efficient in terms of MB/s.

If somebody has an idea of how to avoid the two roots, please let me know about it.

uhm cant you slot GCC and make a sandbox or whatever.

[Brane215]

In my opinion, upgrading a Gentoo system from GCC 4.9 to GCC 5.x or 6.x will make the upgraded system incompatible with 3rd party C++ binaries.

The only solution I was able to come up with is to have two roots in the Gentoo system: one compiled with GCC 4.9, and the other one compiled with GCC 5.x or 6.x. The home directory, and some other directories, are shared between the two. sys-fs/unionfs-fuse is an efficient solution to this in terms of disk space usage, but it isn't efficient in terms of MB/s.

If somebody has an idea of how to avoid the two roots, please let me know about it.

Gentoo allows slotting of compilers and toher tools and for some time I have 4.9.x and 5.3.0 and now also 6.1.0.
I can easily switch amongst them with gcc-config.

That still leaves a problem that stuff expects availability ov libstdc++ that was used when compiling.
gcc-config manipulates ld.so.conf table so that usually that problems can be patched over in many cases.

But even so, I just need gcc-6.1.0 to compile occasional thing or two and see performance difference and try new options. I plan to use 5.3.0 for most stuff...
But still, I'd feel better if all gentoo standard patches were available, which might come handy especially with non-native platforms and multilib.

[pipe13]

There were unavoidable libstdc++ ABI breakages going to -std=c++11 in GCC 5.0. Discussion at http://developers.redhat.com/blog/20...d-the-c11-abi/

[tajjada]

In my opinion, upgrading a Gentoo system from GCC 4.9 to GCC 5.x or 6.x will make the upgraded system incompatible with 3rd party C++ binaries.

The only solution I was able to come up with is to have two roots in the Gentoo system: one compiled with GCC 4.9, and the other one compiled with GCC 5.x or 6.x. The home directory, and some other directories, are shared between the two. sys-fs/unionfs-fuse is an efficient solution to this in terms of disk space usage, but it isn't efficient in terms of MB/s.

If somebody has an idea of how to avoid the two roots, please let me know about it.

Well, some of us don't need 3rd party C++ binaries. I don't use any proprietary crap like that, and I am perfectly happy using 5.3 system-wide on all my systems. I am looking forward to installing 6.1 in another slot, for experimenting with it, but it will not be my default compiler any time soon (until things stop breaking ... so a few months, hopefully).

I am particularly excited about musl libc support in upsteam gcc6. This means no more patching for musl, and as soon as the ebuild is available, I'll be playing with that a lot.

Oh, and the LTO stuff is nice too. I have some codebases that might benefit somewhat from it. I want to see how much better performance I can get with it. (oh, and btw currently I am compiling my whole gentoo system with LTO, too, but as I said, it will be a few months until gcc6 becomes my default compiler).

[mlau]

I am not there yet. I am compiling just a few selected Gentoo packages with LTO.

me too. there are a ton of packages that either hit an ICE or just plain don't link when built with LTO.
and a tiny few that do build, but exhibit strange runtime bugs (like, Qt5).

[carewolf]

I will describe the problem in more detail:

Let BIN be a C++ application that uses library LIB and uses C++ strings. Let LIB be a C++ library that uses C++ strings. Let C++ strings be passed between BIN and LIB in both directions (the directions are: as a parameter, as a return value).

1. Compiling BIN with GCC >=5.x forces recompilation of LIB with GCC >=5.x, because the std::string representation is incompatible between GCC <=4.9 and GCC >=5.x.

2. Compiling LIB with GCC >=5.x forces recompilation of all C++ applications and libraries using LIB. Lets designate these by BIN2 and LIB2.

3. Compiling BIN2 with GCC >=5.x forces recompilation of all C++ libraries used by BIN2. Why all? Because the user does not want to spend time examining and splitting the set of C++ libraries used by BIN2 into two subsets: the 1st subset are those which are binary compatible between GCC 4.9 and GCC 5.x, the 2nd subset are those which are incompatible between those two GCC versions.

4. And so on ...

A) You don't have to. You can stick to the old ABI if you want, even with the new libstdc++,

B) If you statically link libstc++ it only applies if you have a public interface between them using std::string.

[Brane215]

I am not there yet. I am compiling just a few selected Gentoo packages with LTO.

I did that for a while, but then reverted back. it's not worth the hassle system-wide. But for selected packages and libraries, sure.
I used to have listed exceptions to LTO in /etc/portage/env.d., now compile everything with simple -O3 and use per package tweaks just for those few packages where it's nice to have LTO.

I just recompiled codelite-9.1 with gcc-6.1 with LTO on my system. It compiles and works without a problem. I never bothered to measure performance, but LTO version sure looks significantly faster.

[Brane215]

Other combination, where LTO might work really well, is with VTK+Opencascade+Salome+FreeCad combo, probablw with Mesa + Qt-OpenGL, but libraries should probably be compiled as static and if I figure how to automate it, with profile generation.

Libraries are deep and interdependent, so LTO could come on it own.

I played it with for a while, but had to drop it, since I haven't found a way to compile latest Opencascade against latest VTK, amongst other problems.

[tajjada]

me too. there are a ton of packages that either hit an ICE or just plain don't link when built with LTO.
and a tiny few that do build, but exhibit strange runtime bugs (like, Qt5).

I did that for a while, but then reverted back. it's not worth the hassle system-wide. But for selected packages and libraries, sure.
I used to have listed exceptions to LTO in /etc/portage/env.d., now compile everything with simple -O3 and use per package tweaks just for those few packages where it's nice to have LTO.

I just recompiled codelite-9.1 with gcc-6.1 with LTO on my system. It compiles and works without a problem. I never bothered to measure performance, but LTO version sure looks significantly faster.

I have the opposite experience. For me, pretty much everything seems to work. I feel like you guys just haven't configured things correctly (maybe I should actually put in the time to write a gentoo wiki page to help other people). With my make.conf, virtually everything builds flawlessly. Only had a few things break (about 5-6 packages on my entire system, and I have 700+ packages total, virtually everything LTO, including big things like libreoffice, chromium (USE="custom-cflags"), and LLVM, all built with LTO). I just use package.env for those few things that don't build with LTO.

Here is how to do it:

Just put this in your make.conf:

RANLIB="gcc-ranlib"
AR="gcc-ar"
NM="gcc-nm"

# add this in addition to whatever other CFLAGS you want to have
CFLAGS="-flto -ffat-lto-objects -fuse-linker-plugin"


Here follows a detailed explanation, which you can ignore if you don't care about the reasons why you should set the stuff above:

Basically, first set RANLIB, AR, and NM, to handle LTO objects. Not setting these will cause problems with a lot of packages, and I suspect that might be the case on your systems.

Most packages will honour these variables, but a few won't, and it will likely cause problems with those. This is why you also add -ffat-lto-objects to CFLAGS. It tells the compiler to build object files that have both LTO and non-LTO versions of the code, so that, at the linking stage, the linker can silently fall back to making a non-LTO build (rather than failing), which will be what happens to those few packages whose build scripts/systems don't honour your settings for whatever reason. The drawback to -ffat-lto-objects is somewhat-slower build times, but since you are using gentoo, you are probably fine with waiting a little more.

It is also important to add -fuse-linker-plugin to CFLAGS (or LDFLAGS, but virtually all build systems append CFLAGS at the linking stage as well, and I personally prefer not to touch LDFLAGS). This allows programs that are written in a modular way and link against static libraries (lots of them do it internally, even if you don't have static libs installed on your system) to make proper use of LTO. Without setting this, you won't get the full benefit of LTO (but things will likely not break, because you have -ffat-lto-objects (you do, right?). if you don't have -ffat-lto-objects, not setting -fuse-linker-plugin will cause breakage).


I'll get around to writing a wiki article about this someday. Hope you found this useful, and enjoy!

[Brane215]

that's one of the first things I did. Old news. And with earlier versions of gcc there were also some tricks like -flto-partition=none etc that were needed with codeblocks, for example.

Don't worry about the problems. You are sure to encounter them, only questions is whether you will attribute them correctly to LTO.

And, as I said, most of the time, it's not worth the effort. LTO works just up to the border of dynamic linking. With programs fragmented in small bits and pieces that are dynamically loaded, there is nothing linker can do. And stuff like de/coders are already optimised, so there again extra Link Time optimisation has tied hands.

besides fat layers of C/C++ code this only leaves stuff like gzip/bzip2, which is not that important, at least for me.