GCC 3.4

Message

robmoss · Post by **robmoss** » Sun Nov 23, 2003 5:16 pm

There doesn't appear to be a GCC 3.4 thread, so I thought it was probably time to start one.

I'm just about to head over to http://www.breakmygentoo.net/ and download the GCC 3.4 ebuilds and intend to have a go at recompiling my entire system with it. There's a terrific package called acovea - http://www.coyotegulch.com/acovea/ for info on the programme, http://home.jesus.ox.ac.uk/~rmoss/acovea/ for an ebuild (very much work in progress - nowhere near FHS compliant, need to sort out those makefiles!) - which has told me that with GCC 3.3 my CFLAGS should look something like this:

Code: Select all

-O3 -march=athlon-xp -msse -mmmx -m3dnow -momit-leaf-frame-pointer -fomit-frame-pointer -funroll-loops -ftracer -ffast-math -fprefetch-loop-arrays -freduce-all-givs -finline-limit=600 -mfpmath=387 -pipe

But that's just for GCC 3.3. GCC 3.4 has a few new ones that look like they could be very nice indeed! I'll just start with the above ones, however. I tried -fnew-ra but with GCC 3.3 this is still very much broken.

So, anyway, here's a place to post your success/failure stories, workarounds, HOWTOs, fixes, questions etc. If you know something about GCC 3.4 that the rest of us might not, please let us know about it!

robmoss · Post by **robmoss** » Sun Nov 23, 2003 5:21 pm

EDIT: It appears that the GCC 3.4 ebuild on Breakmygentoo is actually a 3.3 + cvs snapshot update, so I might have to have a go at writing a new ebuild to use the sources available from here:

ftp://ftp.mirror.ac.uk/sites/sources.re ... index.html

Lovechild · Post by **Lovechild** » Sun Nov 23, 2003 5:47 pm

I had gcc 3.4 running - it's still fairly unstable and not worth the risk.

I wrote my own snapshot ebuild for the 3.4 branch, it's not hard to modify the in portage one to fit the bill.

the real action is in the tree-ssa branch which is to become 3.5.... yummy.

robmoss · Post by **robmoss** » Sun Nov 23, 2003 6:05 pm

GCC 3.4 has now started building most things, and apparently does what GCC 3.3 was supposed to do when they did that - generates nicer code, faster, but nothing too ambitious. GCC 3.5 is the same, but WAY more ambitious - and looks like it should be very, very nice indeed... unfortunately I don't think it even builds against itself at the moment.

But anyway, GCC 3.4 is much better for generating optimized code than 3.3 is, so I figured that some at least mildly insane people, like me, might want to give it a go. Of course, it can be slotted so that you can use it alongside 3.3 or even 3.2.

Also, it would be nice if we could avoid the debacle again of having a stable compiler being masked (remember 3.3?) due to the fact that there are so many obviously broken packages in the portage tree - this should at least allow some testing.

robmoss · Post by **robmoss** » Sun Nov 23, 2003 7:13 pm

Okay, I now have a working GCC 3.4 ebuild based on the ebuilds at Breakmygentoo.net. It's available from here:

http://home.jesus.ox.ac.uk/~rmoss/sys-devel/gcc/

Let me know how you get on, if you're feeling brave! Compile time actually seems marginally slower with GCC 3.4 at the moment, but that's probably just me being overly and overtly pessimistic about things without really checking and wanting to give myself something to fix

robmoss · Post by **robmoss** » Mon Nov 24, 2003 1:18 am

It appears that it's currently at best a struggle (I've not managed it yet) to build glibc-2.3.2 with gcc-3.4.

Has anyone managed to do this yet? I get all sorts of errors when iconv is being built. If I can't get rid of them I'll post them here soon for you all to have a look at.

robmoss · Post by **robmoss** » Mon Nov 24, 2003 1:41 am

Okay, it appears that it's possible to get considerably further along - possibly all the way - in the glibc-2.3.2-r9 build if you use:

Code: Select all

CFLAGS="-O"

Obviously this isn't ideal, but if and when it either builds or doesn't build, I'll report on my level of success, and then see how far back up I can get with the CFLAGS, possibly even if I can find out which particular flag it is that breaks things so that I can submit a bug which won't break linuxthreads for those who don't use NPTL (linuxthreads actually needs -O2).

robmoss · Post by **robmoss** » Mon Nov 24, 2003 5:52 am

Right, we're getting segfaults now. This is annoying.

http://gcc.gnu.org/ml/gcc/2003-01/msg00069.html

This appears to be that exact same bug - the one that's been know about since January. I've e-mailed Andreas Jaeger, the guy who appears to have a patch for glibc, so I'll see if I can get that into an ebuild.

These ebuilds should hopefully soon appear on Breakmygentoo soon, as GCC 3.4 is heading in the vague direction of usability. For now, if you'd like to help (please!!!!!!), keep looking on http://home.jesus.ox.ac.uk/~rmoss/portage/ (which now mirrors my local portage overlay, as of 0600 UTC) for my latest efforts. GCC 3.4 has already hit -r1...

robmoss · Post by **robmoss** » Mon Nov 24, 2003 8:16 am

Come on! Where's the nutters from this thread gone...

http://forums.gentoo.org/viewtopic.php?t=50679

We're further on with this one than we were with that one when that thread started, and it appears that there's much less broken with that one than there is with this one...

Lovechild · Post by **Lovechild** » Tue Nov 25, 2003 3:29 am

you calling me a nutter ?

robmoss · Post by **robmoss** » Tue Nov 25, 2003 10:30 am

Lovechild wrote:you calling me a nutter ?

Possibly...

I've just found out that it's possible that my glibc compiling problems may be down to the lack of a "-fno-unit-at-a-time" flag, so I'm recompiling with that. I'm getting there... I think...

robmoss · Post by **robmoss** » Tue Nov 25, 2003 11:51 am

Okay, despite that, we're still getting segfaults when the linker is used for the first time. I shall endeavour to find out what in the hell is going on!

robmoss · Post by **robmoss** » Tue Nov 25, 2003 2:53 pm

Baaah. Impending insanity. ALL I need to do is get glibc compiled with GCC 3.4, and then I can get into the meaty business of recompiling everything with GCC 3.4 and using some seriously insane optimizations. It's worth remembering that this is what GCC 3.3 was supposed to be - 3.2 is a rehashed 3.1 and 3.3 is what 3.2 was supposed to be, thanks to a rather major glitch in what is now 3.3 that caused an 11 month delayed. This compiler is worth having...

cyfred · Post by **cyfred** » Wed Nov 26, 2003 11:17 pm

Nutter or no, I have been following the gcc ml thread and this... But I also did find this today, which maybe somewhat interesting for you to read...
http://lists.parisc-linux.org/pipermail ... 12331.html

Basically as a quick wrap up it implies that the segfault is actually a glibc / kernel problem.
EDIT: Yes I know its for hppa but that doesnt make it arch exclusive either.

robmoss · Post by **robmoss** » Thu Nov 27, 2003 2:08 am

I'm afraid that it's just one of many problems which are all identical in appearance. The segfault occurs because something breaks *somewhere* in the build - although quite where I don't know. This is simply the first time that the linker - part of glibc - is used, and if there's a bug in glibc (which there almost certainly is) which causes ld.so to be built incorrectly, this error occurs.

So, unfortunately, that's just one (now fixed) example - cheers for trying though, it's much appreciated!

Lovechild · Post by **Lovechild** » Thu Nov 27, 2003 7:21 am

cyfred wrote:Nutter or no, I have been following the gcc ml thread and this... But I also did find this today, which maybe somewhat interesting for you to read...
http://lists.parisc-linux.org/pipermail ... 12331.html

Basically as a quick wrap up it implies that the segfault is actually a glibc / kernel problem.
EDIT: Yes I know its for hppa but that doesnt make it arch exclusive either.

Fri, 20 Apr 2001

I doubt that's relevant for gcc 3.4

robmoss · Post by **robmoss** » Thu Nov 27, 2003 3:25 pm

Lovechild wrote:
cyfred wrote:Nutter or no, I have been following the gcc ml thread and this... But I also did find this today, which maybe somewhat interesting for you to read...
http://lists.parisc-linux.org/pipermail ... 12331.html

Basically as a quick wrap up it implies that the segfault is actually a glibc / kernel problem.
EDIT: Yes I know its for hppa but that doesnt make it arch exclusive either.
Fri, 20 Apr 2001

I doubt that's relevant for gcc 3.4

Correct, it isn't - as I said in the above post, it isn't relevant, but the error message is the same.

Annoying, isn't it?

robmoss · Post by **robmoss** » Fri Dec 05, 2003 2:54 pm

Okay, the bug is not in glibc, it's in GCC. The problem is that it appears GCC 3.4 ignores the visibility attribute, so already in the first 20 assembler instructions that are executed, things break all over the place.

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

Jesse · Post by **Jesse** » Sat Dec 06, 2003 3:13 am

Hmmm, is it good enough for KDE/QT yet or other biggish C++ programs?

If it is, can you try the precompiled header support? (Please

Not just if it works, but research the compile time reduction?

robmoss · Post by **robmoss** » Sat Dec 06, 2003 9:00 am

Jesse wrote:Hmmm, is it good enough for KDE/QT yet or other biggish C++ programs?

If it is, can you try the precompiled header support? (Please Not just if it works, but research the compile time reduction?

I'd like to be able to try, but unfortunately at the moment the above bug kills off any hope of anything involving assembly working.

Once it's fixed, I'll have a go at compiling KDE/QT with 3.3.3 (which will be out by then) and 3.4.

I've heard that 3.4 will be (literally!) 10 times faster for compiling such programmes than 3.3.3 - and that was from a GCC developer, so I assume he's tested it.

The other thing you can do is be much more aggressive with your CFLAGS, so I'm hoping to write a wrapper script for GCC that will give you the best possible optimizations (using acovea) for any particular programme. Obviously you'd have to be absolutely mad to do this with a huge programme like Mozilla or Openoffice, where the speed-up wouldn't be worth the week or two spent compiling, but something like chessbrain, for example, would benefit greatly. Actually, I could have a go at compiling an entire system using that - now there's a project and a half...

Jesse · Post by **Jesse** » Sat Dec 06, 2003 5:29 pm

Actually, I could have a go at compiling an entire system using that - now there's a project and a half...

whoa .... that would take forever and a year ...

I'd much rather have them (gcc) fix the behavior of -O1-3 so they work as expected

... using acovea I don't really see why they would leave the settings as is. But at the same time, I really don't want to read through the recent gcc thread either

: Should -fcross-jumping be part of -O1?

I'm also interested in any improvements they made with -fprefetch-loop-arrays. My current CFLAGS of -march=pentium4 -O2 -fomit-frame-pointer -fprefetch-loop-arrays -fPIC are probably not the best right now. (Yes everything is stable though)[/quote]

robmoss · Post by **robmoss** » Sun Dec 07, 2003 12:02 pm

Jesse wrote:I'm also interested in any improvements they made with -fprefetch-loop-arrays. My current CFLAGS of -march=pentium4 -O2 -fomit-frame-pointer -fprefetch-loop-arrays -fPIC are probably not the best right now. (Yes everything is stable though)

Actually, by far and away the best flag with regards speed improvements, I've found, is -ftracer (at least for my computer). This provides some quite serious speed-ups! You might want to give it a go - looking at the gcc info pages doesn't lead me to believe that it should cause any instabilities.

robmoss · Post by **robmoss** » Wed Dec 10, 2003 7:53 am

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

Woo!

Looks like it's been fixed. I'm currently in the midst of setting up an openMosix cluster right now, but rest assured I will be testing this as soon as I've finished

Better still, I'm working on an ebuild which basically creates a wrapper script for gcc, which allows the use of gcc-acovea to determine the optimal CFLAGS for each file in the package and then compile that file with those CFLAGS (or CXXFLAGS, obviously) - which means some seriously ludicrous optimization...

Jesse · Post by **Jesse** » Wed Dec 10, 2003 8:03 am

cool. By the way, I haven't read to much into acovea but how does it determine the best optimizations if the executable really isn't executable

... like what's the best settings for Konqueror or khtml for that matter? This is what I don't get about gcc's profile feedback either ... :-/

robmoss · Post by **robmoss** » Wed Dec 10, 2003 10:07 am

Jesse wrote:cool. By the way, I haven't read to much into acovea but how does it determine the best optimizations if the executable really isn't executable ... like what's the best settings for Konqueror or khtml for that matter? This is what I don't get about gcc's profile feedback either ... :-/

This is what I'm working on - otherwise it would be easy! The current idea is that it trawls through file by file. However, if executing the 'executable' gives you nothing useful, I'm unsure what to do. Perhaps in this case I should make GCC fall back to the default optimizations in /etc/make.conf, perhaps?