CFlags This Guy Left = WTF?

[bobber205]

#CFLAGS="-O3 -march=pentium3 -msse -mmmx -funroll-loops -pipe"

While trying to fix the expat issue on our server, I was having seriously weird segfault errors.
What do you know. I looked at the cflags and saw that...

I replaced them with more sane ones and reemerged gcc 4. I am now on my way to recovery.

What I want to know is why the guy that did the server before me decided those were a good idea.

[nixnut]

Moved from Kernel & Hardware to Gentoo Chat.
Not the kind of question we can answer. Ask that person himself, or perhaps his shrink.

[jabol]

I myself did stuff like that on my personal computer. Now, I was having strange segfaults all the time (or maybe, say, from time to time), especially with big packages... Although I remember also having sth. about fast-math and sse2 or even 3dnow in CFLAGS. Then I understood that Gentoo is not about being mad, but about being lazy .

Have a emerge -e world. A good pizza, film and a coffee will do in the meantime .

[transient]

In the words of a great ex-dev, HOLY COW I'M GOING SO FAST OH F***

[enderandrew]

#CFLAGS="-O3 -march=pentium3 -msse -mmmx -funroll-loops -pipe"

I replaced them with more sane ones and reemerged gcc 4. I am now on my way to recovery.

If your cup support sse and mmx instruction sets (almost everyone does) those flags are listed as being completely stable. The official Gentoo stable flags start with -march=foo, where foo is your march, and that tag actually implies the use of msse and mmmx, so those flags are redundant, but not unsafe. The only unsafe flag there is -funroll-loops. The weird thing is that I was pretty sure the toolchain eclass (and the gcc makefile) filtered out pretty much most every flag, so the toolchain is always built with safe flags. However, the segfaults probably came from another package that was borked from -funroll-loops.

[steveL]

Thanks transient :) That was hilarious!

[aidanjt]

#CFLAGS="-O3 -march=pentium3 -msse -mmmx -funroll-loops -pipe"

I replaced them with more sane ones and reemerged gcc 4. I am now on my way to recovery.

If your cup support sse and mmx instruction sets (almost everyone does) those flags are listed as being completely stable. The official Gentoo stable flags start with -march=foo, where foo is your march, and that tag actually implies the use of msse and mmmx, so those flags are redundant, but not unsafe. The only unsafe flag there is -funroll-loops. The weird thing is that I was pretty sure the toolchain eclass (and the gcc makefile) filtered out pretty much most every flag, so the toolchain is always built with safe flags. However, the segfaults probably came from another package that was borked from -funroll-loops.

-O3 can be dodgy as well.

[transient]

Thanks transient That was hilarious!

Indeed, my favourite part was the global enabling of the truetype BCI define in his CFLAGS.

[i92guboj]

#CFLAGS="-O3 -march=pentium3 -msse -mmmx -funroll-loops -pipe"

While trying to fix the expat issue on our server, I was having seriously weird segfault errors.
What do you know. I looked at the cflags and saw that...

I replaced them with more sane ones and reemerged gcc 4. I am now on my way to recovery.

What I want to know is why the guy that did the server before me decided those were a good idea.

As someone said, mmx and sse are included in the pentium3 specification

pentium3, pentium3m
Intel Pentium3 CPU based on PentiumPro core with MMX and SSE instruction set support.

They are redundant, in any case, and not needed. But they aren't dangerous. On the opposite side, -funroll-loops (like almost anything starting with "fun" ) is risky.

-O3 is known to cause some minor trouble here and there. But usually the packages that have problems with it, filter that flag (it doesn't mean that it can't cause some trouble still). Usually, -O2 is considered to be safer (and in my opinion, smarter). So it is the default.

[i92guboj]

Thanks transient That was hilarious!

Indeed, my favourite part was the global enabling of the truetype BCI define in his CFLAGS.

That demonstrates the big big big capacity that the human brain has to absorb completely unsorted, and useless information. People see things into the forums, google or TV and they just assume that it must be true. Obviously, he did not even know what he was writing on his make.conf. He just assumed that the most "optimizations" the better, and just threw they all into his make.conf without even having a clue on what the hell we was doing.

If he knew what he was doing, in first place, he would have been ashamed to post such a thing on bugzilla.

[bobber205]

The package that was failing was apr-util btw.

[steveL]

That demonstrates the big big big capacity that the human brain has to absorb completely unsorted, and useless information. People see things into the forums, google or TV and they just assume that it must be true. Obviously, he did not even know what he was writing on his make.conf. He just assumed that the most "optimizations" the better, and just threw they all into his make.conf without even having a clue on what the hell we was doing.

True.

If he knew what he was doing, in first place, he would have been ashamed to post such a thing on bugzilla.

Yeah, but it was funny ;) IMO he'll just look back it with humour.

[StifflerStealth]

Those flags actually look stable compared to some flags I found before. I saved the config just to remember it.

CFLAGS="-Os -march=pentium4 -fweb -pipe -mmmx -msse2 -mfpmath=sse -masm=intel -fforce-addr -frename-registers -finline-functions -freorder-blocks"

I think he/she/it was trying to break the system. It worked too.

[Cyker]

Yeee... now you've all got me worried... How safe is my CFLAGS?

CFLAGS="-O2 -march=opteron -msse3 -mfpmath=sse -pipe -fomit-frame-pointer"

I want to go back to -Os, but it caused problems in the past
I wonder if it's stable yet? The allure of smaller binaries is very strong for me...

[96140]

--

[BlackEdder]

Also, -Os is definitely not safe; I heard from a few developers on this when I wrote my guide. -Os is one of the most filtered flags by ebuilds; many, many things don't like it. The binaries will only maybe be a tiny bit smaller anyway; it's more useful for applications that have to run on CPUs with miniscule cache sizes. Opterons/Athlon64s have generous cache sizes. Stick with -O2.

Hmmm I've been using Os on my laptop for some time now and never had a problem, but maybe that's just because it's mostly filtered out. Maybe I should switch back to O2.....

[Corona688]

Thanks transient That was hilarious!

Indeed, my favourite part was the global enabling of the truetype BCI define in his CFLAGS.

What, not even a chuckle over USE="GAPING_SECURITY_HOLE"?

I've never seen executables made more than a miniscule fraction smaller with -Os. I'm left to wonder if it's doing something less than obvious -- minimizing jumps, etc. to stay in the same area of code memory longer, rather than making code smaller in general.

[Phenax]

Also, -Os is definitely not safe; I heard from a few developers on this when I wrote my guide. -Os is one of the most filtered flags by ebuilds; many, many things don't like it. The binaries will only maybe be a tiny bit smaller anyway; it's more useful for applications that have to run on CPUs with miniscule cache sizes. Opterons/Athlon64s have generous cache sizes. Stick with -O2.

Hmmm I've been using Os on my laptop for some time now and never had a problem, but maybe that's just because it's mostly filtered out. Maybe I should switch back to O2.....

Generally, a lot of -O* and other non-O* CFLAGs are filtered, and not much of any specific -O option.

Code: Select all

(/usr/portage/) grep -R filter-flags . | grep "\-O3" | wc -l 
4
(/usr/portage/) grep -R filter-flags . | grep "\-Os" | wc -l 
8

[Cyker]

Don't set the floating point math instructions; let the compiler decide what's appropriate. Forcing it to a specific one is begging for trouble. Search around the forums; iirc there's a good post explaining this by dirtyepic. Leave out -mfpmath.

I don't suppose you have any recommendations of better search terms than "dirtyepic mfpmath"?

I found a few posts saying not to use it because it was slower than x87, but those posts were 2+ years old (And I'm sure GCC must have been improved by then - Even with the context-switching overhead, SSE/3DNow! should be measurably faster than raw x87, if only because the x87 is a badly thought out piece of crap...!)

Also, since AMD64's *can't* use the x87 copper, and have to use SSE, I figured it should be okay since most of the (admittedly small) speed boost 64-bit mode gets seems to be from its FPU and extra registers...

The general consensus from the 2005-2006 postings seems to be let the compiler decide, which in my case means just let it compile it to x87 on 32-bit x86...

Hmm... Does anyone know of a good benchtest program for FPU math that I could try compiling with the different flags? I'm curious now...

[omp]

Don't set the floating point math instructions; let the compiler decide what's appropriate. Forcing it to a specific one is begging for trouble. Search around the forums; iirc there's a good post explaining this by dirtyepic. Leave out -mfpmath.

I don't suppose you have any recommendations of better search terms than "dirtyepic mfpmath"?

Hrm, I found this post by him; not sure if it's the one nightmorph is talking about, but it's possible.

[Corona688]

I found a few posts saying not to use it because it was slower than x87, but those posts were 2+ years old (And I'm sure GCC must have been improved by then - Even with the context-switching overhead, SSE/3DNow! should be measurably faster than raw x87, if only because the x87 is a badly thought out piece of crap...!)

Also, since AMD64's *can't* use the x87 copper, and have to use SSE, I figured it should be okay since most of the (admittedly small) speed boost 64-bit mode gets seems to be from its FPU and extra registers...

It can't? Better tell AMD The x87 unit is actually more accurate than SSE, it computes 80-bit floats. I'll also note that SSE is now the default choice for amd64 according to the gcc manpage, so there's little point in forcing sse. If I had to guess why, I'd say it's because floating point operations and MMX/XMM/SSE operations don't mix all that well, and gcc uses the XMM registers quite a lot in general-purpose amd64 code.

[steveL]

The allure of smaller binaries is very strong for me...

You might find this discussion interesting: C Flags Central Pt 2 as we've been talking about -falign to get smaller binaries. I don't have any figures to share though.

[Corona688]

The allure of smaller binaries is very strong for me...

You might find this discussion interesting: C Flags Central Pt 2 as we've been talking about -falign to get smaller binaries. I don't have any figures to share though.

Alignment is there to make things in memory line up nicely along and inside the width of the data bus. The x86 -- unlike most processors -- can fetch things at arbitrary misalignments for nearly all instructions, but there is a performance cost. In some cases it might even need to fetch twice.

It's weirditudes like this which make x86 relatively simple to design a generic compiler for, but difficult to design a good compiler for...

[mv]

CFLAGS="-Os -march=pentium4 -fweb -pipe -mmmx -msse2 -mfpmath=sse -masm=intel -fforce-addr -frename-registers -finline-functions -freorder-blocks"

I think he/she/it was trying to break the system. It worked too.

Except for -masm=intel and -fforce-addr (whose advantage is more than doubtful) these flags don't look that bad: There's nothing which wouldn't also set by -O3 except -pipe and -mfpmath=sse which is also not really dangerous.

[enderandrew]

CFLAGS="-Os -march=pentium4 -fweb -pipe -mmmx -msse2 -mfpmath=sse -masm=intel -fforce-addr -frename-registers -finline-functions -freorder-blocks"

can be reworked to:

CFLAGS="-Os -march=pentium4 -fweb -pipe -fforce-addr -frename-registers -finline-functions -freorder-blocks"

Pretty safe and stable. The other flags shouldn't really be explicitly declared, but rather handled by march. Generally I run with:

CFLAGS="-O2 -march=athlon64 -fweb -pipe -fomit-frame-pointer -ftracer -ftree-vectorize"

I've compiled my whole box with -Os -O2 and -O3, and can't really declare any a winner for your entire system. Some apps are better optimized for size, and some run faster with heavier optimizations. I've been flagging certain apps for -O3 like media encoders and emulators for performance, and I'm going to start trying to target certain packages for -Os while leaving most packages at -O2.

I've messed around with a bunch of other flags such as -freorder-blocks -frename-registers, hell half the flags in the GCC manual. Oddly enough, I rarely run into serious breakage. Either one program won't compile and I take the flags out. I'm not one of those who insist any flags beyond the listed stable ones are guaranteed to break your box, in fact I've found most of what people declare to be inherently unsafe really isn't that dangerous. However, at the same time, I usually don't see a whole bunch of major improvements noticably with a laundry list of flags, and if anything, it slows compile time down.

If anything, I think most major improvements in performance come from linker optimizations.