GCC 4.6 Ebuild

[Evilguru]

Hi all,

I wish to test the upcoming 4.6 release of GCC to see if it breaks any of the projects I maintain. However, I can not seem to find a pre-release ebuild for it. Does anyone know where I can find one?

I am not interested in switching my system GCC over to 4.6 -- that would be foolhardy -- just having it available locally would be sufficient.

Regards, Freddie.

[skellr]

Hi,

Sounds like fun.

There are some in the Toolchain Overlay..

[Evilguru]

[skellr]

For missing keywords they use ** in package.keywords.

[dirtyepic]

package.keywords

[hedmo]

Evilguru

and i think you need to set :


I_PROMISE_TO_SUPPLY_PATCHES_WITH_BUGS=1




in make.conf to



dirtyepic

is this the SVN

sys-devel/gcc-4.6.0_pre9999

[ssteinberg]

And don't cross your fingers...

[dirtyepic]

[cruzki123]

Are you testing -lto?

[hedmo]

cruzki123 wrote:

Are you testing -lto?

jepp no problem so far

[wolf550e]

On otherwise ~amd64 system, with this toolchain:

[hedmo]

zen-sources did not work for me

[Ormaaj]

[wolf550e]

With binutils 2.21.51.0.7.20110306 (in portage, missing keywords), the plugin is built correctly.

libtool link tool removes flags, thus using LTO, when code is generated during link phase instead of compile phase, optimizations are not applied. Need to either patch libtool or define CC and CXX to include CFLAGS and CXXFLAGS.

pciutils miscompiles because it uses asm(".symver"). A workaround is to use -flto-partition=none which keeps those commands next to the relevant function.

[billydv]

Sure would like to see this in portage since I have an I7, hopefully with a lot fewer bugs by then!!!
_________________
Billy DeVincentis

[Dark Foo]

gcc 4.6 is officially out now so i think it should turn up in the ~arch branches soon
_________________
I know 43 ways to kill with a SKITTLE, so taste my rainbow bitch.

[Ormaaj]

Ah so essentially LTO never works if GCC is called with -c and the build system handles linking separately? I'm not too familiar with libtool I'll have to read up a bit.

[wolf550e]

@Ormaaj: libtool just generates flags for gcc and calls gcc.

WARNING: This explanation is very simplified and inaccurate at places, but it serves to convey a point.

Suppose you have CFLAGS="-O2 -fPIC" LDFLAGS="-Wl,-O1" and file.c and you're building a shared library. Then these commands will be run:
gcc $(CFLAGS) -c -o file.o file.c
file is parsed, optimized, assembly generated, assembled into machine code and that saved in object file on per-function basis.
gcc $(LDFLAGS) -shared -o libfile.so file.o
all the code for all the functions in all the object files is concatenated into shared lib. compiler not used.

With LTO, you want to have: CFLAGS="-O2 -fPIC -flto" LDFLAGS="-Wl,-O1 -Wl,-flto"
so you get this:
gcc -O2 -fPIC -flto -c -o file.o file.c
-O2 is not used here. The file is parsed and some form of the tree is saved into the object file for later use.
gcc -Wl,-O1 -Wl,-flto -shared -o libfile.so file.o
Here all the parsed code is loaded and compiler optimizes it with the knowledge of function calls, able to inline across different c files and the like. better optimization is possible, in effect this is like first concatenating all the code into a single c file and compiling that (though, of course, different source files were compiled with different #defines, perhaps even from different languages).

This work can be divided into different processes to use multiple cores, but that makes the result less optimized and can lead to a bug like in pciutils.

The problem here is that this doesn't just call the linker to concatenate machine code. This calls the compiler to generate machine code. But where are the CFLAGS? They are not specified! So which -O level is used by the compiler? Why,-O0! Instead of better optimizations, you get no optimizations.

What you actually wanted the last command to be was:

gcc $(CFLAGS) $(LDFLAGS) -shared -o libfile.so file.o

This would have worked. This is what GCC thinks you should do. But that's not what libtool runs.

So you might think: "I know, I'll set LDFLAGS to include CFLAGS!" but libtool will strip the flags for the compiler from LDFLAGS and that doesn't work. Libtool manual says you can specify CFLAGS in the LDFLAGS if you use -Wc,-O2 but if you specify flags like that configure scripts choke on them.

What I have found to work is to specify CC. set CC="gcc -flto -O2" and libtool will do the right thing and you'll get LTO and fast binaries.

Of course, for C++ code replace CC with CXX and CFLAGS with CXXFLAGS.

[justXi]

I tried the gcc 4.6.0 ebuild which is available in portage now, but I got many errors "no space left on device" from tar.
I have 1.8 GByte space free on root. Other packages compile fine. Any ideas what I could check?

[XavierMiller]

[justXi]

I have all directories on the same partition, but I run out of inodes.
I removed some kernel-sources an now gcc 4.6 unpacks and is compiling.

[ecko]

I just tried the gcc 4.6.0 ebuild now in portage, on amd64.

[cruzki123]

is lto enable in the 4.6 ebuild from portage? I'am currently rebuilding system to test 4.6 and my the next move I want to take is using lto globally.

[Ormaaj]

@wolf550e Thank you for the informative post!

[justXi]

Hi,

While compiling gcc 4.6 on two computers I get the same following error: