Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
CFLAGS Central (Part 2)
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3 ... 15, 16, 17  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Maedhros
Bodhisattva
Bodhisattva


Joined: 14 Apr 2004
Posts: 5511
Location: Durham, UK

PostPosted: Wed May 04, 2005 8:53 pm    Post subject: CFLAGS Central (Part 2) Reply with quote

Continued from CFLAGS Central (Part 1)
_________________
No-one's more important than the earthworm.
Back to top
View user's profile Send private message
elvisthedj
Guru
Guru


Joined: 21 Jun 2004
Posts: 483
Location: Nampa, ID

PostPosted: Wed May 04, 2005 10:41 pm    Post subject: Reply with quote

Code:

CFLAGS="-O2 -march=athlon-xp -pipe -mcpu=i686 -fomit-frame-pointer -msse -mmmx -m3dnow -ffast-math -fprefetch-loop-arrays -finline-limit=600 -ftracer


I just realized that I'm some point I've added some P4 specific flags to my athlon xp make.conf .. yet, I haven't broken anything. Do these flags (-msse -mmmx -m3dnow) jus get ignored? Does gcc just think i'm a retard? do you guys?? :P

edit: I remember why I did this. mplayer :D If I ran it, it was saying ".... supported, but not enabled" or some such thing.

So I added those flags and recompiled and I guess I just never took them out.

Code:

MPlayer 1.0pre6-3.3.5-20050130 (C) 2000-2004 MPlayer Team
CPU: Advanced Micro Devices Athlon 4 /Athlon MP/XP Palomino (Family: 6, Stepping: 2)
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE


Warning unknown option cache_min at line 144
Warning unknown option cache_prefill at line 14


So, are these not "pentium specific" .. hmmm.. perhaps I should read the other 35 pages of the thread :D
_________________
Kris Edwards
kris edwards at g mail dot c0m
PGP
WWW
Back to top
View user's profile Send private message
moocha
Watchman
Watchman


Joined: 21 Oct 2003
Posts: 5722

PostPosted: Thu May 05, 2005 3:06 am    Post subject: Reply with quote

  • -mmmx: Not P4-specific. Supported since Pentium-MMX and AMD K6 (the later revisions).
  • -msse: Not P4-specific. Supported since Pentium 3 and AMD Athlon / Duron.
  • -m3dnow: Not P4-specific, in fact AMD-specific. Supported since AMD K6-2.

_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin
Back to top
View user's profile Send private message
Gherald
Veteran
Veteran


Joined: 23 Aug 2004
Posts: 1399
Location: CLUAConsole

PostPosted: Thu May 05, 2005 3:18 am    Post subject: Reply with quote

yay, giant thread gone, I can get some personal attention ;)

How's this:
Code:
CFLAGS="-march=pentium-m -pipe -mmmx -msse -msse2 -mfpmath=sse \
-fomit-frame-pointer -momit-leaf-frame-pointer -funit-at-a-time -frename-registers \
-O2 -Os -fno-align-functions -fno-align-jumps -fno-align-loops \
-fno-align-labels -fno-reorder-blocks -fno-prefetch-loop-arrays"

I'm assuming the rightmost flag has priority in resolving conflicts... but perhaps I've got that backwards?
Back to top
View user's profile Send private message
elvisthedj
Guru
Guru


Joined: 21 Jun 2004
Posts: 483
Location: Nampa, ID

PostPosted: Thu May 05, 2005 3:50 am    Post subject: Reply with quote

Quote:

* -mmmx: Not P4-specific. Supported since Pentium-MMX and AMD K6 (the later revisions).
* -msse: Not P4-specific. Supported since Pentium 3 and AMD Athlon / Duron.
* -m3dnow: Not P4-specific, in fact AMD-specific. Supported since AMD K6-2.


ty. I notice that these are on the "safe list" for p4 and not for amd.
http://gentoo-wiki.com/Safe_Cflags

Anyone have a good reason any or all might be "unsafe"? (for desktop environment)
_________________
Kris Edwards
kris edwards at g mail dot c0m
PGP
WWW
Back to top
View user's profile Send private message
codergeek42
Bodhisattva
Bodhisattva


Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)

PostPosted: Thu May 05, 2005 4:37 am    Post subject: Reply with quote

You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting.
_________________
~~ Peter: Programmer, Mathematician, STEM & Free Software Advocate, Enlightened Agent, Transhumanist, Fedora contributor
Who am I? :: EFF & FSF
Back to top
View user's profile Send private message
Gherald
Veteran
Veteran


Joined: 23 Aug 2004
Posts: 1399
Location: CLUAConsole

PostPosted: Thu May 05, 2005 4:46 am    Post subject: Reply with quote

codergeek42 wrote:
You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting.
I do not understand why some people think there is a reason to not use flags which are already implied by a previous flag. Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact.

Notice that I use both -O2 and -Os.
Back to top
View user's profile Send private message
elvisthedj
Guru
Guru


Joined: 21 Jun 2004
Posts: 483
Location: Nampa, ID

PostPosted: Thu May 05, 2005 5:10 am    Post subject: Reply with quote

Quote:

You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting


Makes sense to me.. Seems like I distinctly remember having to add these for mplayer though. If I didn't use mplayer so often, I'd re-emerge it w/o them so I could see the original messages. But, instead I'll go check to see I overlooked some mplayer use flags :)
_________________
Kris Edwards
kris edwards at g mail dot c0m
PGP
WWW
Back to top
View user's profile Send private message
Gherald
Veteran
Veteran


Joined: 23 Aug 2004
Posts: 1399
Location: CLUAConsole

PostPosted: Thu May 05, 2005 5:19 am    Post subject: Reply with quote

I thought mplayer ignored most CFLAGS...
Back to top
View user's profile Send private message
codergeek42
Bodhisattva
Bodhisattva


Joined: 05 Apr 2004
Posts: 5142
Location: Anaheim, CA (USA)

PostPosted: Thu May 05, 2005 5:23 am    Post subject: Reply with quote

Yup. That's why it has mmx, mmxext, sse, sse2, 3dnow, and 3dnowext USE flags. :)
_________________
~~ Peter: Programmer, Mathematician, STEM & Free Software Advocate, Enlightened Agent, Transhumanist, Fedora contributor
Who am I? :: EFF & FSF
Back to top
View user's profile Send private message
elvisthedj
Guru
Guru


Joined: 21 Jun 2004
Posts: 483
Location: Nampa, ID

PostPosted: Thu May 05, 2005 5:42 am    Post subject: Reply with quote

codergeek42 says:
Quote:

Yup. That's why it has mmx, mmxext, sse, sse2, 3dnow, and 3dnowext USE flags


mplayer's ebuild says:
Quote:

# let's play the filtration game! MPlayer hates on all!
strip-flags


sometimes I do weird things and spend too much time trying to figure out why. I'm just going to quietly step away from the thread.
_________________
Kris Edwards
kris edwards at g mail dot c0m
PGP
WWW
Back to top
View user's profile Send private message
moocha
Watchman
Watchman


Joined: 21 Oct 2003
Posts: 5722

PostPosted: Thu May 05, 2005 9:31 am    Post subject: Reply with quote

Gherald wrote:
yay, giant thread gone, I can get some personal attention ;)

How's this:
Code:
CFLAGS="-march=pentium-m -pipe -mmmx -msse -msse2 -mfpmath=sse \
-fomit-frame-pointer -momit-leaf-frame-pointer -funit-at-a-time -frename-registers \
-O2 -Os -fno-align-functions -fno-align-jumps -fno-align-loops \
-fno-align-labels -fno-reorder-blocks -fno-prefetch-loop-arrays"

No, no, no, No, NO. Read this thread and learn one or two things about the concept of optimization before doing that to your system.
Gherald wrote:
I do not understand why some people think there is a reason to not use flags which are already implied by a previous flag.
Because some people actually know better, out of dire experience...
Gherald wrote:
Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact.
And might break horribly.
Gherald wrote:
Notice that I use both -O2 and -Os.
Which you shouldn't, unless you don't like glibc. There was a bug last year that would kill your glibc if you built it with two -O flags in your CFLAGS. Who's to know if and when that might happen again?
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin
Back to top
View user's profile Send private message
Gherald
Veteran
Veteran


Joined: 23 Aug 2004
Posts: 1399
Location: CLUAConsole

PostPosted: Thu May 05, 2005 9:46 am    Post subject: Reply with quote

moocha wrote:
Gherald wrote:
Code:
CFLAGS="-march=pentium-m -pipe -mmmx -msse -msse2 -mfpmath=sse \
-fomit-frame-pointer -momit-leaf-frame-pointer -funit-at-a-time -frename-registers \
-O2 -Os -fno-align-functions -fno-align-jumps -fno-align-loops \
-fno-align-labels -fno-reorder-blocks -fno-prefetch-loop-arrays"

No, no, no, No, NO. Read this thread and learn one or two things about the concept of optimization before doing that to your system.

So you object to -mmmx -msse -msse2 and -mfpmath=sse. I've looked into each of them and they seem safe and appropriate.

Quote:
Gherald wrote:
Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact.
And might break horribly.

Eh? -mmmx is a perfectly sensible CFLAG that has been around for *very* long time and if an ebuild were to fail because of it, I'd simply uncomment one of the other two settings I keep in make.conf for poor quality ebuilds...

Code:
#CFLAGS="-march=i686 -pipe -fomit-frame-pointer"
#CFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer"

I haven't had to use either of those ever since kdemultimedia got its act together.

Quote:
Gherald wrote:
Notice that I use both -O2 and -Os.
Which you shouldn't, unless you don't like glibc.
There was a bug last year that would kill your glibc if you built it with two -O flags in your CFLAGS. Whjo's to know when that will happen again? You're a brave man.
Hmm, that's a serious bug. Basically I want -Os, but I know there are many ebuilds that do not recognize it is actually _more conservative_ than -O2 and thus filter it out. Hence all the previous -O2 and all the -fno options that follow...

man gcc wrote:
-Os Optimize for size. -Os enables all -O2 optimizations that do not
typically increase code size. It also performs further optimiza-
tions designed to reduce code size.

-Os disables the following optimization flags: -falign-functions
-falign-jumps -falign-loops -falign-labels -freorder-blocks
-fprefetch-loop-arrays

If you use multiple -O options, with or without level numbers, the
last such option is the one that is effective.


Last edited by Gherald on Thu May 05, 2005 9:56 am; edited 1 time in total
Back to top
View user's profile Send private message
kimchi_sg
Advocate
Advocate


Joined: 26 Nov 2004
Posts: 2955

PostPosted: Thu May 05, 2005 9:51 am    Post subject: Reply with quote

Gherald wrote:
Basically I want -Os, ... it is actually _more conservative_ than -O2

Strictly speaking, this is not true.
man gcc wrote:
-Os
Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size.
Back to top
View user's profile Send private message
Gherald
Veteran
Veteran


Joined: 23 Aug 2004
Posts: 1399
Location: CLUAConsole

PostPosted: Thu May 05, 2005 9:59 am    Post subject: Reply with quote

kimchi_sg wrote:
Gherald wrote:
Basically I want -Os, ... it is actually _more conservative_ than -O2

Strictly speaking, this is not true.
man gcc wrote:
-Os
Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size.

Based on other explanations I've read about what -Os does, I feel confident in saying it is _more conservative_ than -O2 even though it is not strictly a subset of -O2.
Back to top
View user's profile Send private message
superstoned
Guru
Guru


Joined: 17 Dec 2004
Posts: 432

PostPosted: Thu May 05, 2005 12:45 pm    Post subject: Reply with quote

Gherald wrote:
codergeek42 wrote:
You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting.
I do not understand why some people think there is a reason to not use flags which are already implied by a previous flag. Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact.

Notice that I use both -O2 and -Os.

if an ebuild filters something out, there might be a reason for that... why do you want to break your system?
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


Joined: 23 Jun 2004
Posts: 1556
Location: .se

PostPosted: Thu May 05, 2005 12:51 pm    Post subject: Reply with quote

Gherald wrote:
kimchi_sg wrote:
Gherald wrote:
Basically I want -Os, ... it is actually _more conservative_ than -O2

Strictly speaking, this is not true.
man gcc wrote:
-Os
Optimize for size. -Os enables all -O2 optimizations that do not typically increase code size. It also performs further optimizations designed to reduce code size.

Based on other explanations I've read about what -Os does, I feel confident in saying it is _more conservative_ than -O2 even though it is not strictly a subset of -O2.


-Os disables some -O2 optimization but also turns on other. Something that compiles with -O2 might break with -Os, perl for example.
Back to top
View user's profile Send private message
Gherald
Veteran
Veteran


Joined: 23 Aug 2004
Posts: 1399
Location: CLUAConsole

PostPosted: Thu May 05, 2005 12:57 pm    Post subject: Reply with quote

superstoned wrote:
Gherald wrote:
codergeek42 wrote:
You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting.
I do not understand why some people think there is a reason to not use flags which are already implied by a previous flag. Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact.

Notice that I use both -O2 and -Os.

if an ebuild filters something out, there might be a reason for that... why do you want to break your system?

You don't understand. Let's use a contrived example.

Suppose "-superflag" enables optimizations -fA, -fB, and -fC and "-lesserflag" only enables optimization -fA.

Thus, compiling a package with "-superflag -lesserflag" enables -fA,-fB,-fC. Compiling a package with only "-superflag" does the same thing.

Now suppose there is an ebuild that needs to disable -fB and -fC, but doesn't care about -fA. The correct way to deal with this would be to append -fnoB and -fnoC to the end of CFLAGS (after -superflag). For simplicity, an ebuild might simply filter out -superflag. But what about -fA? If CFLAGS still contains "-lesserflag", it will be enabled.

Now obviously there would never be a "-lesserflag" that only enables one thing (-fA) but this isn't meant to be a real example.
Back to top
View user's profile Send private message
superstoned
Guru
Guru


Joined: 17 Dec 2004
Posts: 432

PostPosted: Thu May 05, 2005 1:29 pm    Post subject: Reply with quote

Gherald wrote:
superstoned wrote:
Gherald wrote:
codergeek42 wrote:
You don't need to add those though. The proper MMX/SSE/3DNow! options are implied by your "-march=" setting.
I do not understand why some people think there is a reason to not use flags which are already implied by a previous flag. Ebuilds, particularly poorly written ones, might filter out a general flag like -march but leave something like -mmmx intact.

Notice that I use both -O2 and -Os.

if an ebuild filters something out, there might be a reason for that... why do you want to break your system?

You don't understand. Let's use a contrived example.

Suppose "-superflag" enables optimizations -fA, -fB, and -fC and "-lesserflag" only enables optimization -fA.

Thus, compiling a package with "-superflag -lesserflag" enables -fA,-fB,-fC. Compiling a package with only "-superflag" does the same thing.

Now suppose there is an ebuild that needs to disable -fB and -fC, but doesn't care about -fA. The correct way to deal with this would be to append -fnoB and -fnoC to the end of CFLAGS (after -superflag). For simplicity, an ebuild might simply filter out -superflag. But what about -fA? If CFLAGS still contains "-lesserflag", it will be enabled.

Now obviously there would never be a "-lesserflag" that only enables one thing (-fA) but this isn't meant to be a real example.

so, you say there are ebuilds that unnecesair filter certain flags. and, altough its very likely they also don't filter certain flags they should if you try to pass around this, you take the risk. well, i hope the dev's don't mind the bugreports...
Back to top
View user's profile Send private message
kimchi_sg
Advocate
Advocate


Joined: 26 Nov 2004
Posts: 2955

PostPosted: Thu May 05, 2005 1:33 pm    Post subject: Reply with quote

Gherald wrote:
superstoned wrote:
if an ebuild filters something out, there might be a reason for that... why do you want to break your system?

You don't understand. Let's use a contrived example.

Suppose "-superflag" enables optimizations -fA, -fB, and -fC and "-lesserflag" only enables optimization -fA.

Thus, compiling a package with "-superflag -lesserflag" enables -fA,-fB,-fC. Compiling a package with only "-superflag" does the same thing.

Now suppose there is an ebuild that needs to disable -fB and -fC, but doesn't care about -fA. The correct way to deal with this would be...

... to understand exactly why the ebuild does this, before even considering dangerous things like flag redundancy.

Don't you think that he already understands the mechanics what you're trying to do? :)

Apparently, it's you who doesn't understand why we are trying to wean you off flag redundancy. Please do not assume those who wrote the ebuilds are villains who wish to block the way to the Great Treasure Trove of Speed. They do think for the health of your system.


Last edited by kimchi_sg on Thu May 05, 2005 1:36 pm; edited 1 time in total
Back to top
View user's profile Send private message
Gherald
Veteran
Veteran


Joined: 23 Aug 2004
Posts: 1399
Location: CLUAConsole

PostPosted: Thu May 05, 2005 1:34 pm    Post subject: Reply with quote

superstoned wrote:
so, you say there are ebuilds that unnecesair filter certain flags. and, altough its very likely they also don't filter certain flags they should if you try to pass around this, you take the risk.
Um, sounds like you've sorta got the idea. But the important thing to realize is that only wrong or poorly written ebuilds will be affected...
Quote:
well, i hope the dev's don't mind the bugreports...

...so they certainly should not mind.
Back to top
View user's profile Send private message
superstoned
Guru
Guru


Joined: 17 Dec 2004
Posts: 432

PostPosted: Thu May 05, 2005 3:13 pm    Post subject: Reply with quote

Gherald wrote:
superstoned wrote:
so, you say there are ebuilds that unnecesair filter certain flags. and, altough its very likely they also don't filter certain flags they should if you try to pass around this, you take the risk.
Um, sounds like you've sorta got the idea. But the important thing to realize is that only wrong or poorly written ebuilds will be affected...
Quote:
well, i hope the dev's don't mind the bugreports...

...so they certainly should not mind.

altough you might be right, i think this way you put an undesirable and unnecesairy burden on the developers. if they choose, for time constraints, to block flags "the easy way", they should be free to do so. don't force them to spend more time on it (unless you want to do it yourself) as they are willing to. they are volunteers! also, any speedgain would be extremely small - so i think they acutally should block flags the easy way, if they want to - let them spend time on more important things, be it gentoorelated or not.
Back to top
View user's profile Send private message
Thuzle
n00b
n00b


Joined: 01 Jan 2005
Posts: 3
Location: Orford, NH

PostPosted: Wed May 11, 2005 3:06 am    Post subject: Reply with quote

Hey everyone. I managed to read alot of the thread and used it in helping me with my own CFlags and various other things. I wanted to point out a pecularity on my system.

AMD64 using 2005.0 LiveCD 2.6.8 Kernal.

I was bootstraping with CFLAGS="-O2 -march=k8 -mtune=k8 -fomit-frame-pointer -fomit-leaf-frame-pointer -fforce-addr -ftracer -falign-functions=64 -fprefetch-loop-arrays -freorder-blocks -pipes -m64"

USE="nptl amd64 and the usual except for PIC"

So the bootstrap came to gettext and had an error regarding requiring -fPIC for something, not sure why, but I put it in for that compile and it worked from there on out.

Thought you might like to hear about a problem from NOT having a CFLAG rather then having too many.
Back to top
View user's profile Send private message
rhill
Retired Dev
Retired Dev


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Wed May 11, 2005 6:36 am    Post subject: Reply with quote

i think i read that error is caused by -fprefetch-loop-arrays, but i'm not sure. it's never a good idea to put PIC/PIE flags in make.conf - but i guess in this case it worked :wink: .

anyone using machine options other than -march (or -m32 / -m64 i guess) doesn't know what they're doing. not only are they redundant, they're often broken. this goes double for -mfpmath, which never worked properly until gcc4 (and still doesn't on some archs =P). yes some ebuilds filter -march. they do that rarely and specifically because the code breaks when using compiled using an arch-specific instruction set. for example, the most common filtering you'll see is changing pentium4 to pentium3. this is done because the code has been proven to break with sse2. going ahead and forcing that instruction set is kind of a retarded idea, don't you think?
_________________
by design, by neglect
for a fact or just for effect
Back to top
View user's profile Send private message
nxsty
Veteran
Veteran


Joined: 23 Jun 2004
Posts: 1556
Location: .se

PostPosted: Wed May 11, 2005 8:22 am    Post subject: Reply with quote

Thuzle:

You should neve put -m64 in your CFLAGS. 64bit is already the default on x86_64 and forcing it on like that breaks several ebuilds that needs to compile some parts 32bit. Also remove amd64 from your USE, portage will set that flag itself when necessary.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page 1, 2, 3 ... 15, 16, 17  Next
Page 1 of 17

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum