It happens that, as many great GCC features are coming up, a few packages fail to compile for with them. Current such features are lto and graphite which are reasonably stable for use as of now, but some packages fail to build with them. So if a package fails to build it's obvious that either lto or graphite is the culprit; so an alternative set of CFLAGs must be tried to see if the packages build without them. So instead of manually changing make.conf to disable certain GCC flags, and trying to compile the failed ebuild, why not automate the process? I propose shell arrays (do they work with sourced files?) -- CFLAGS[0]="..." CFLAGS[2]="..." CFLAGS[3]="..." So once an ebuild fails to build, emerge will immediately (not after everything has been compiled, since the build can fail for dependency reasons also) switch to the next alternate CFLAGS and try and compile; this'll happen till the last CFLAGS is tried. As the CFLAGS change they're also interpolated in the correct places in make.conf ($CFLAGS).
Why not just use package.env to change CFLAGS for broken ebuilds?
The problem may have been solved after an upgrade of either GCC or the package; so we've to track the package specific CFLAGS manually and remove them after change in version of either both. Worst, you can just forget about env and it'll remain there without your knowledge.
I would also suggest post and pre trigger scripts for each switch of CFLAGS. Useful for things like changing the default linker.
This is really an awful hack, and a very bad idea. If something doesn't build with your configuration, fix the configuration. Attempting to rebuild in the dark is just a waste of everyone's time. Furthermore, CFLAGS are in no way special, and next thing I know we build a huge cartesian product of all configuration variables in case one combination might work.
