Re: [PATCH -mm] sys_semctl gcc 4.1 warning fix
From: Al Viro
Date: Wed May 10 2006 - 21:28:02 EST
On Wed, May 10, 2006 at 04:45:54PM -0700, Andrew Morton wrote:
> Al Viro <viro@xxxxxxxxxxxxxxxx> wrote:
> > Sorry, no - it shuts up too much. Look, there are two kinds of warnings
> > here. "May be used" and "is used". This stuff shuts both. And unlike
> > "may be used", "is used" has fairly high S/N ratio.
> >
> > Moreover, once you do that, you lose all future "is used" warnings on
> > that variable. So your ability to catch future bugs is decreased, not
> > increased.
>
> Only for certain gcc versions. Other people use other versions, so it'll
> be noticed. If/when gcc gets fixed, more and more people will see the real
> warnings.
>
> Look, of course it has problems. But the current build has problems too.
> It's a question of which problem is worse..
FWIW, I've got mostly finished pile of scripts (still needs to be
consolidated, with merge into git for some parts) that does that following:
take two trees and build log for the first one; generate remapped log
with all lines of form <filename>:<line number>:<text> modified. If line
in question survives in the new tree, turn it into
N:<new filename>:<new line number>:<text>
with new filename and line giving its new location, otherwise turn it into
O:<filename>:<line number>:<text>
That reduces the size of diff between build logs a _lot_ - basically,
all noise from changed line numbers is gone and we are left with real
changes. It works better with git (we catch renames that way), but
even starting with diff between the trees works fairly well.
IME, it makes watching for regressions quite simple, even when dealing with
something like 2.6.16-rc2 and current, with shitloads of changes in between.
And yes, I _do_ watch ia64 tree, with all its noise. Moreover, I watch
CHECK_ENDIAN sparse builds, aka thousands of warnings all over the tree...
I'll get that stuff into sane form and post it; IMO it solves the noise
problem just fine.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/