From: Al Viro <viro@ftp.linux.org.uk>
To: Andrew Morton <akpm@osdl.org>
Cc: davem@davemloft.net, dwalker@mvista.com,
alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm] sys_semctl gcc 4.1 warning fix
Date: Thu, 11 May 2006 02:28:18 +0100 [thread overview]
Message-ID: <20060511012818.GL27946@ftp.linux.org.uk> (raw)
In-Reply-To: <20060510164554.27a13ca9.akpm@osdl.org>
On Wed, May 10, 2006 at 04:45:54PM -0700, Andrew Morton wrote:
> Al Viro <viro@ftp.linux.org.uk> 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.
next prev parent reply other threads:[~2006-05-11 1:28 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-10 2:56 [PATCH -mm] sys_semctl gcc 4.1 warning fix Daniel Walker
2006-05-10 10:34 ` Alan Cox
2006-05-10 14:31 ` Daniel Walker
2006-05-10 15:09 ` Alan Cox
2006-05-10 15:06 ` Daniel Walker
2006-05-10 15:24 ` Steven Rostedt
2006-05-10 16:24 ` Adrian Bunk
2006-05-10 17:18 ` Steven Rostedt
2006-05-10 17:45 ` Steven Rostedt
2006-05-10 18:27 ` Stephen Hemminger
2006-05-10 19:07 ` Serge Belyshev
2006-05-10 20:24 ` Adrian Bunk
2006-05-10 20:35 ` Steven Rostedt
2006-05-10 20:36 ` Adrian Bunk
2006-05-10 20:53 ` Steven Rostedt
2006-05-10 19:20 ` Steven Rostedt
2006-05-10 19:49 ` Daniel Walker
2006-05-10 20:44 ` Steven Rostedt
2006-05-10 21:11 ` Daniel Walker
2006-05-10 21:20 ` Al Viro
2006-05-10 21:33 ` Daniel Walker
2006-05-10 21:39 ` Al Viro
2006-05-10 21:45 ` Daniel Walker
2006-05-10 21:48 ` Al Viro
2006-05-11 6:36 ` Steven Rostedt
2006-05-10 15:39 ` Alan Cox
2006-05-10 15:38 ` Daniel Walker
2006-05-10 16:21 ` Al Viro
2006-05-10 16:37 ` Daniel Walker
2006-05-10 16:42 ` Al Viro
2006-05-10 17:25 ` Daniel Walker
2006-05-10 19:55 ` Alistair John Strachan
2006-05-10 22:03 ` Andrew Morton
2006-05-10 22:10 ` Al Viro
2006-05-10 22:31 ` David S. Miller
2006-05-10 22:45 ` Al Viro
2006-05-10 23:05 ` Andrew Morton
2006-05-10 23:20 ` Al Viro
2006-05-10 23:45 ` Andrew Morton
2006-05-11 1:28 ` Al Viro [this message]
2006-05-11 8:11 ` Steven Rostedt
2006-05-11 10:07 ` [PATCH -mm] introduce a false positive macro Steven Rostedt
2006-05-11 20:40 ` [PATCH -mm] sys_semctl gcc 4.1 warning fix Adrian Bunk
2006-05-11 21:14 ` Al Viro
2006-05-10 23:06 ` Roland Dreier
2006-05-10 22:30 ` David S. Miller
2006-05-11 2:58 ` Mike Galbraith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060511012818.GL27946@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@davemloft.net \
--cc=dwalker@mvista.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox