If a package breaks with any reasonable CFLAGS, it is best to filter the problematic flag if a bug report is received. Reasonable CFLAGS are -march=, -mcpu=, -mtune= (depending upon arch), -O2, -Os and -fomit-frame-pointer. Note that -Os should usually be replaced with -O2 rather than being stripped entirely. The -fstack-protector flag should probably be in this group too, although our hardened team claim that this flag never ever breaks anything...

The -pipe flag doesn't affect the generated code, so it's not really relevant here, but it's a sensible flag to have set globally.

If a package breaks with other (insane) CFLAGS, it is perfectly OK to close the bug with a WONTFIX suggesting that the user picks more sensible global CFLAGS. Similarly, if you suspect that a bug is caused by insane CFLAGS, an INVALID resolution is suitable.

All of the following assumes that the ebuild has an inherit flag-o-matic line in the correct place.

The filter-flags function can be used to remove a particular flag from {C,CPP,CXX,CCAS,F,FC,LD}FLAGS. Multiple arguments can be supplied; each is the name of a flag to remove.

There is a filter-ldflags function available which does the equivalent for LDFLAGS.

If a package is known to be very CFLAGS sensitive, the strip-flags function will remove most flags, leaving only a minimal conservative set of flags.

To replace a flag with a different one, use replace-flags. This is most commonly used to replace -Os with -O2 (or -O3 with -O2 if you are feeling kind).

There is also a special function named replace-cpu-flags for replacing CPU (-mtune, -mcpu, -march) designation flags. The last argument is the flag to use; previous arguments are the flags to be replaced.

Sometimes it is necessary to add in additional CFLAGS or LDFLAGS. The append-flags and append-ldflags functions can be used here.

See for a full reference.