Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via or IRC
Bug 48791 - Reconsider strip-flags and filter-flags usage and add USE flag to turn off some of them
Summary: Reconsider strip-flags and filter-flags usage and add USE flag to turn off so...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo Toolchain Maintainers
Depends on:
Reported: 2004-04-23 08:36 UTC by Grzegorz Kulewski
Modified: 2004-06-11 01:30 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Grzegorz Kulewski 2004-04-23 08:36:47 UTC
In the early gcc-3 era there was probably need for it.
But currently gcc-3.3/3.4 is more stable and many bugs have been fixed.
So, I think that you should check all usages of these commands and remove / make less strict some of them.
For example I can build Gentoo with ~x86 with "-O2 -march=athlon-tbird -fomit-frame-pointer -fprefetch-loop-arrays -fforce-addr -frename-registers -fno-align-functions -fno-align-labels -fno-align-jumps" flags on several systems and strip most of strip-flags commands from core and other ebuilds and have completly stable system. (-O3 seems to work too)
In gcc-3.4 some new flags are added that make executable much smaller and faster (-funit-at-a-time and others) - see LKML for some tests.
So, unless I am completly wrong, you could _at least_ add USE option to ommit most strip-flags automagically...

Reproducible: Always
Steps to Reproduce:
Comment 1 SpanKY gentoo-dev 2004-05-12 06:51:44 UTC
what works wonderfully for one user really doesnt count much for other users

or for other architectures
Comment 2 Joshua Kinard gentoo-dev 2004-06-11 01:30:46 UTC
Alot of flags like you mentioned are stripped out because invariably, Murphy's law states "What can go wrong, will go wrong", and in alot of cases, it's over-zealous CFLAGS combined with flakey hardware that triggers a number of compile failures on core system packages like glibc/gcc.

To save us from having to wade through dozens of "glibc compile failed" bugs due to such over-zealous CFLAGS usage, we strip most out except for extensively tested (by multiple users/devs across multiple archs) flags.  I would not totally rule out several additonal flags being allowed in the future, but it'll have to be discussed, and any such changes monitored closely.