Extreme CFLAGS problems...

[racoontje]

Japanese Honda rice munchers?

[valkyrite]

Do LDFLAGS help and how??
Should I use LDFLAGS="-s" in my make.conf. Does it give any significant performance gain.

I am using the following CFLAGS and my system rocks
CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer"
I guess all other CFLAGS bloat the system rather than make it actually fast.

TIA

[ciaranm]

Do LDFLAGS help and how??
Should I use LDFLAGS="-s" in my make.conf. Does it give any significant performance gain.

Don't set LDFLAGS in make.conf at all if you want your system to be supported. This may change at a later date -- vapier is preparing a proposed list of permitted LDFLAGS. For now, however, don't touch them.

[Xaignar]

Why not have a list of officially supported C(XX)FLAGS, and then just make portage post a big honking "WTF are you doing?" warning if a non-supported flag are used when emerge/etc is evoked?

[ciaranm]

Why not have a list of officially supported C(XX)FLAGS, and then just make portage post a big honking "WTF are you doing?" warning if a non-supported flag are used when emerge/etc is evoked?

Surely you mean a small list? And portage doesn't tend to warn you if you're doing something really stupid...

[Xaignar]

Why not have a list of officially supported C(XX)FLAGS, and then just make portage post a big honking "WTF are you doing?" warning if a non-supported flag are used when emerge/etc is evoked?

Surely you mean a small list? And portage doesn't tend to warn you if you're doing something really stupid...

I know that portage will let you do stupid things (there is no such thing as 100% functional protection against stupidity), but as other has suggested, some sort of validation would be useful and could help cut down on the "if gcc runs, then it's OK"-crowd.

[ciaranm]

I know that portage will let you do stupid things (there is no such thing as 100% functional protection against stupidity), but as other has suggested, some sort of validation would be useful and could help cut down on the "if gcc runs, then it's OK"-crowd.

Well, I'm trying to get this through as policy... *shrug*

[Xaignar]

Well, I'm trying to get this through as policy... *shrug*

Seems sensible, though there are many other flags that don't effect the resulting binary, such as -w, etc.

[BrightSide]

How about including "filter-cflags" in Portage's feature list instead of forcing filtering on users and leaving it turned on by default? That way, everyone would still be able to enjoy a stable system but it's possible to turn it off for those who want to play with flags other than the "known to work" ones.

Gentoo has always been about choice and most of that choice in my view comes from not only what is being built (through the use flags) but also how it is being build (through the cflags) so if you want to turn of the safe compile-flags feature and break your system. Well, that should be your choice.

[ciaranm]

Gentoo has always been about choice

By saying that you just lost any chance you had of anyone ever considering your idea further.

[TrueDFX]

Do you disagree that Gentoo is about choice, or do you feel that it's simply not relevant?

[thechris]

i had a similar idea. except i delegated it to what i called the "gentoo extreme project". basically people are rightfully afraid to use certain cflags. My idea involved a "package.cflags" feature in portage, something which people either agree with or think is not needed. please note that such a featuer may be very useful for amd64, where 32 bit binaries are STRONGLY reccomended to be compiled manually with the -m32 option.

from here you just have to have a organization of gentooers that want to test programs with cflags to see if: 1. they compile; 2. pass maketest; 3. work when used. a package.cflags might be made from a database made by these users -- basically a community effort.

I have other non-performance reasons for a package.cflags. a major issue with it however is that portage doesn't control gcc, thus when gcc deprecates -mcpu, the package.cflags will need to be changed.

[ciaranm]

Do you disagree that Gentoo is about choice, or do you feel that it's simply not relevant?

One of Gentoo's goals is to provide reasonable choices where such choices are possible. This does not mean that we will always provide you with a choice for absolutely everything, especially if it makes no sense to do so. It also does not mean that the phrase "Gentoo is about choice" is adequate justification for any proposal.

For example, we will provide you the choice of KDE, Gnome or a lightweight window manager. We will provide you with a choice of how packages with optional depencies are built. We will provide you with a choice of how often you want to update your system. What we won't do is go around adding silly or pointless features under the justification that they provide more choice.

[TrueDFX]

No argument there, then, but BrightSide's suggestion makes sense for other reasons too. One possible example might be to continue using a system built with -mregparm (I won't get into a discussion of whether it's a good idea to do that).

[mcspiff]

View ciaranm packages (that he maintains). This are some of the most rock solid packages on gentoo, and the most used. Thus his feelings on "Experimental" and the benefits of having gentoo be bleeding edge (with support) is somewhat different than the rest of us. Which is fine. I honestly doubt you'll change his mind

[Xithix]

Why does gcc even include flags like -malign-double if they are so obviously dangerous to the point that no one in their right mind would ever use them?

Experimental flags I can understand. Leaving something that never should be used under any circumstance in gcc is spreading the problem.

I understand that Gentoo devs are not gcc devs ... but still, it seems like the gcc devs, by including the flags (as warnings are ignored) are as much to blame as the "ricers" abusing them.

[ciaranm]

Why does gcc even include flags like -malign-double if they are so obviously dangerous to the point that no one in their right mind would ever use them?

Because under certain situations, such as when you're making PROM-level code which will run without an operating system and when no ABI rules are in effect, they make sense.

[rhill]

If a package breaks with other CFLAGS, it is perfectly ok to close the bug with a WONTFIX suggesting that the user picks more sensible global CFLAGS.

to me this conjures up an image of hurried developers just searching for non-whitelisted CFLAGS in an effort to close as many bugs as they can, ignoring the issue altogther (valid or not). of course, the user shouldn't be submitting bugs before trying out sane flags in the first place, but let's stay in reality for the moment . and i don't actually believe the devs do that, i'm just saying what first comes to mind.

in this situation - oops, i forgot i have -funit-at-a-time set.. i try again without.. i get the same error - is it proper bugzilla etiquette to reopen the bug? i always feel reopening a WONTFIX is like saying "i don't care, fix it anyways", just being beligerent and stubborn. but maybe that's just me.

Similarly, if you suspect that a bug is caused by insane CFLAGS, an INVALID resolution is suitable.

now that i can agree with. INVALID seems a much better resolution - 'your bug report is invalid without sane flags' vs. 'this is indeed a bug, but there's no way to fix it'.

*shrug*

[fca]

OK, I feel like chiming in on this and play the devil's advocate a bit:
Sometimes these "insane" flags actually do the right thing and make a task that needs speed a bit faster.

Let met focus on -ffast-math, the bane of all Gentoo developers:
What does it do?

Sets -fno-math-errno, -funsafe-math-optimizations,
-fno-trapping-math, -ffinite-math-only, -fno-rounding-math and -fno-signaling-nans.

This option causes the preprocessor macro __FAST_MATH__ to be defined.


This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions.

As for the optimizations it provides:

-fno-math-errno
Do not set ERRNO after calling math functions that are executed with a single instruction, e.g., sqrt. A program that relies on IEEE exceptions for math error handling may want to use this flag for speed while maintaining IEEE arithmetic compatibility.

This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions.


The default is -fmath-errno.

-funsafe-math-optimizations
Allow optimizations for floating-point arithmetic that (a) assume that arguments and results are valid and (b) may violate IEEE or ANSI standards. When used at link-time, it may include libraries or startup files that change the default FPU control word or other similar optimizations.

This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions.


The default is -fno-unsafe-math-optimizations.

-ffinite-math-only
Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs.

This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications.


The default is -fno-finite-math-only.

-fno-trapping-math
Compile code assuming that floating-point operations cannot generate user-visible traps. These traps include division by zero, overflow, underflow, inexact result and invalid operation. This option implies -fno-signaling-nans. Setting this option may allow faster code if one relies on “non-stop” IEEE arithmetic, for example.

This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions.


The default is -ftrapping-math.

-frounding-math
Disable transformations and optimizations that assume default floating point rounding behavior. This is round-to-zero for all floating point to integer conversions, and round-to-nearest for all other arithmetic truncations. This option should be specified for programs that change the FP rounding mode dynamically, or that may be executed with a non-default rounding mode. This option disables constant folding of floating point expressions at compile-time (which may be affected by rounding mode) and arithmetic transformations that are unsafe in the presence of sign-dependent rounding modes.

The default is -fno-rounding-math.


This option is experimental and does not currently guarantee to disable all GCC optimizations that are affected by rounding mode. Future versions of GCC may provide finer control of this setting using C99's FENV_ACCESS pragma. This command line option will be used to specify the default state for FENV_ACCESS.

-fsignaling-nans
Compile code assuming that IEEE signaling NaNs may generate user-visible traps during floating-point operations. Setting this option disables optimizations that may change the number of exceptions visible with signaling NaNs. This option implies -ftrapping-math.

This option causes the preprocessor macro __SUPPORT_SNAN__ to be defined.


The default is -fno-signaling-nans.


This option is experimental and does not currently guarantee to disable all GCC optimizations that affect signaling NaN behavior.

So, there we have all the information that is available in the Fine Manual.
Notice that the -fno-signaling-nans and -fno-rounding-math options provided by -ffast-math are the default anyway, so they don't do any extra harm.
Is this option harmful? Yes, if the program depends on a precise implementation of floating point math. What type of programs really depend on this type of things?
For the most part, arbitrary precision math libraries, which use all the tricks in the book, depend on this, and maybe system libraries, but I don't pretend to know anything about those.
It actually helps rendering, video encoding and audio encoding a lot. These programs are usually highly portable, and do not assume at all precise ISO floating point math. What they do need however, is speed. And -ffast-math delivers speed for them.
That is why I always put in -ffast-math in my own CFLAGS. When I make a bug report however, I always first check if recompiling the package without -ffast-math helps.

[Athas]

Don't set LDFLAGS in make.conf at all if you want your system to be supported. This may change at a later date -- vapier is preparing a proposed list of permitted LDFLAGS. For now, however, don't touch them.

Thanks, I wasn't aware of this. I had a very modest LDFLAGS line (-Wl,-O1), but if they can compromise system stability, I'll remove them. I have actually had Emacs crash in weird ways lately...

[Joelio]

This is my set of flags for a super 1337 system..

Code: Select all

CFLAGS="-O3 -mcpu=athlon-xp -pipe -fomit-frame-pointer -fnitrous-oxide-inject -fgo-faster-stripes"

[Lokheed]

This is my set of flags for a super 1337 system..

Code: Select all

CFLAGS="-O3 -mcpu=athlon-xp -pipe -fomit-frame-pointer -fnitrous-oxide-inject -fgo-faster-stripes"

You should probably read this entire thread then. You 1337 system is quite the contrary...

"Those who feel they need to grunt and scream, drop weights, and bump shoulders with anyone not of their physical size, aren't any more of a man than the ones who cannot lift 20 lbs. to save their lives."

[psyqil]

You should probably read this entire thread then. You 1337 system is quite the contrary...

Perhaps you should read up on his flags in the gcc manual?

[Xaignar]

Humm, he forgot "-ffuzzy-dice", that makes all the difference.

[thechris]

never forget -fsticker=type-r,azn,nos,prenelli,honda. it add 50 bogomips.