Summary: | compiling gcc: -Os replaced with -O2 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Gavin <colonel_dolphin> |
Component: | New packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
appends SAFE_GCC_O_FLAG to "emerge info" results
replace-with-safe-gcc-o-flag() [ 4 lines of code ] |
Description
Gavin
2004-07-15 13:41:43 UTC
I believe all recent gcc ebuilds and several other unrelated packages make the same mistake. Because: 1) It creates a gcc that compiles faster 2) Some archs creates a _more_ buggy gcc (k6-2 comes to mind, can't remember the others) 3) Because of above, we want to keep our sanity 4) You can still edit the ebuild, and keep it in portage-local, so we do not really take away your choice. we cant even make this arch specific, since on x86 there are some weird subarchs that will blow up and others that wont... but i know for sure -Os on amd64 breaks things hardcore. elsewhere as well... do you have a more elegant solution to this problem that wont increase the number of pointless bug reports we have to close? Hmmm .. you both make very good points. I've been tweaking ebuilds for the last few months to use -Os, but it's really a headache to update them constantly. I use -Os on both Athlon-XP and Via C3 (same gcc options: -march=i586 -mmmx -m3dnow) with gcc 3.3.3, 2.6.5, and glibc from 20040420. No problems that I have found. People using Via C3 systems often use -Os everywhere (due to very tiny CPU cache). Perhaps gcc team has worked some of the bugs out of using "-Os" over the last few months? Regarding something elegant without pestering everyone with bug reports from clueless users, perhaps a function/macro/variable for use in ebuilds that replaces "dangerous" -O options with a less "dangerous", but configurable option, specified in /etc/make.globals (safely tucked away where most clueless users won't think to tweak)? For example, add 'SAFE_GCC_O_FLAG="-O2"' to /etc/make.globals, then ebuilds can use this, instead of hardcoding it. Some users may even want something more safe than "-O2" (e.g. they want an entire system without optimization, and with '-g'). such a thing might be useful to have, especially since there's been recent work on gentoo-embedded, which could probably benefit from using -Os. as for asking if you had an elegant solution, i also meant a solution with patches :) for general discussion, bugzilla probably isnt the best place. i'd really suggest subscribing to the gentoo-dev mailing list and voicing your opinions there. http://www.gentoo.org/main/en/lists.xml Created attachment 35638 [details, diff]
appends SAFE_GCC_O_FLAG to "emerge info" results
Hi Travis. How about appending the following to Gentoo's /etc/make.global? SAFE_GCC_O_FLAG="-O2" Then, in ebuilds (e.g. for gcc) DO NOT use: export CFLAGS="$(echo "${CFLAGS}" | sed -e 's|-O[0-9s]\?|-O2|g')" Instead use this: CFLAGS="${CFLAGS//-O?} $SAFE_GCC_O_FLAG" Unlike the gcc ebuild, the simple bash expression above creates no extra processes. Emerge needs a tiny patch so that "emerge info" meets your requirements for: "[not] increase the number of pointless bug reports we have to close?". Now, stepping back for moment .. perhaps we should consider a duplicate set of C*FLAGS that are supposed to be "safe", rather than just one extra variable for identifying a "safe" optimization level for the user's architecture/kernel/compiler/library combination? Oh, well, at least the SAFE_GCC_O_FLAG approach would solve my most immediate frustration with needing to tweak several ebuilds continually with this most trivial change (from -O2 to -Os). Also, for those that prefer using "inherit flag-o-matic", they can use: replace-flags -O? $SAFE_GCC_O_FLAG However, it really isn't as safe as the direct method I demonstrated above. The method I used above appends the new, desired optimization flag. Since gcc only uses the last optimization flag found on the command line, and flag-o-matic tries to directly replace an existing flag ... there is more room for "gotchya's" with replace-flags. Also, the bash method is clear, concise, simple, and familiar to all who are already familiar with bash without whatever overhead exists in "inherit flag-o-matic". > Then, in ebuilds (e.g. for gcc) DO NOT use: > export CFLAGS="$(echo "${CFLAGS}" | sed -e 's|-O[0-9s]\?|-O2|g')" > Instead use this: > CFLAGS="${CFLAGS//-O?} $SAFE_GCC_O_FLAG" > > Unlike the gcc ebuild, the simple bash expression above creates no extra > processes. Uhm, no, please do not - that breaks on '-O'. There is a bug about that somewhere ... > Uhm, no, please do not - that breaks on '-O'.
> There is a bug about that somewhere ...
What version of bash are you using?
Works peachy here (except when -O is the last option).
# foo="-O -frepo -O foobar -whatever -O2 -moreopts -O3"
# echo ${foo//-O?}
-frepo foobar -whatever -moreopts
Even if someone has CFLAGS="-O", 'export CFLAGS="${CFLAGS//-O?} $SAFE_GCC_O_FLAG"' should still work, since gcc only uses the optimization flag that is appended. For those that really care about making the result look "pretty" for the rare case when '-O' is the last option listed in CFLAGS, without the extra processes, try:
CFLAGS="${CFLAGS%-O}"
export CFLAGS="${CFLAGS//-O?} $SAFE_GCC_O_FLAG"
In the end, I really don't care how its done, just so long as I don't need to maintain a portage overlay with every ebuild I need that forces a package to be built with "-O2". Those with tight constraints on their CPU cache (even larger servers with high working loads) can sometimes benefit from avoiding -O2, depending on the application, timeslice length, etc.
You are doing it wrong: --- $ (foo="-O blah"; echo ${foo//-O?/-O2};) -O2blah --- Which will bork gcc. Sure, there are other ways do do it with bash replacement, but existing method is tested, and only run minimal, so not really an speed issue. If you really have an issue with it though, this should be the better way: --- CFLAGS="${CFLAGS//-O?/ } $SAFE_GCC_O_FLAG" --- Actually, that issue is only if you replace -O? with something else. If not like you did, it should not be an issue (or think not). It might still be the safer option to replace it with a <space> rather then nothing just in case ... Ok! Sounds good to me Martin. Lets do it. How do we add SAFE_GCC_O_FLAG to /etc/make.global, and pass the word that ebuilds should use: --- CFLAGS="${CFLAGS//-O?/ } $SAFE_GCC_O_FLAG" --- instead of something like: gcc-3.3.4-r1.ebuild: export CFLAGS="$(echo "${CFLAGS}" | sed -e 's|-O[0-9s]\?|-O2|g')" Will prob have to do something like: --- [ -z "${SAFE_GCC_O_FLAG}" ] && SAFE_GCC_O_FLAG="-O2" CFLAGS="${CFLAGS//-O?/ } ${SAFE_GCC_O_FLAG}" --- As make.global have to be updated portage side ... that is except if it is done profile side, and I am not on track with the new cascade stuff, so will rather not be the one to do it. Yup. It might be a long time before we could expect everyone using new ebuilds to have a make.global with SAFE_GCC_O_FLAG defined. I think we're on the right track, and other people will pick up on the idea and expand it (if needed) by providing different defaults for different profiles. To get the ball rolling and solve the "lack of over-loadable gcc optimization default" issue for 90+% of the Gentoo user base, I think you're last post is right on the money =) I wonder if the change would be more appealing to ebuild maintainers, if the change was encapsulated into an update to the flag-o-matic class? Maybe something simple, like a bash function called "replace-with-safe-gcc-o-flag"? /usr/portage/eclass/flag-o-matic.eclass: replace-with-safe-gcc-o-flag() { [ -z "${SAFE_GCC_O_FLAG}" ] && SAFE_GCC_O_FLAG="-O2" CFLAGS="${CFLAGS//-O?/ } ${SAFE_GCC_O_FLAG}" CFLAGS=" ${CFLAGS} " CXXFLAGS=" ${CXXFLAGS} " CFLAGS="${CFLAGS// ${1} / ${2} }" CXXFLAGS="${CXXFLAGS// ${1} / ${2} }" CFLAGS="${CFLAGS:1:${#CFLAGS}-2}" CXXFLAGS="${CXXFLAGS:1:${#CXXFLAGS}-2}" export CFLAGS CXXFLAGS return 0 } Blast .. I hit TAB and ENTER (vi habits) .. next thing I know it committed ... anyway, here is what I wanted to say: replace-with-safe-gcc-o-flag() { [ -z "${SAFE_GCC_O_FLAG}" ] && SAFE_GCC_O_FLAG="-O2" CFLAGS="${CFLAGS//-O?/ } ${SAFE_GCC_O_FLAG}" CXXFLAGS="${CXXFLAGS//-O?/ } ${SAFE_GCC_O_FLAG}" export CFLAGS CXXFLAGS return 0 } an addition to flag-o would most certainly be preferred, especially if it makes use of previously existing functions in flag-o. once again, i'll mention that nothing will ever get done here without discussion on the gentoo-dev mailing list... so hurry up and subscribe, voice your ideas, get feedback, etc. on bugzilla you have just a handfull of people on the toolchain@gentoo.org alias seeing this, and we tend to be distracted easily with other stuff :) Created attachment 40892 [details]
replace-with-safe-gcc-o-flag() [ 4 lines of code ]
The solution is sooo simple. Please apply.
toolchain.eclass does this. |