Re: [announce] new tree: "fix all build warnings, on all configs"

Roland Dreier
2008-10-17T18:47:56Z

> OTOH, there should be a well-defined work flow to keep this all
> manageable: once we know why a warning triggers and it has been
> categorized by a human, we should get rid of the warning in some way.
>
> Applying this patch as-is would be one option. Annotating it with a
> specific gcc version would be overkill i think. Ignoring it would be
> bad, because there's real value in standardizing on a "no warnings"
> build output. Many new warnings get introduced because people do not
> notice new warnings amongst the very high baseline noise of the kernel
> build.

The specific change I noticed:

> - (1 << MGM_BLCK_LB_BIT));
> + (1U << MGM_BLCK_LB_BIT));

is not a problem to me -- the code is fine either way, and if we're
making an effort to kill all warnings, then I'm OK with merging it.
It's a little unfortunate to add churn due to a gcc bug that is only in
certain 4.3 releases, but this particular case doesn't seem to trigger
in many places, so the cost is low.

However I worry about warnings produced by gcc bugs forcing us to tinker
with correct code. Maybe it just makes sense to wait and see if we ever
hit a case where a gcc bug forces us to make too many stupid changes,
and figure out what to do if and when that happens.

- R.