From: Al Viro <viro@ftp.linux.org.uk>
To: Adrian Bunk <bunk@stusta.de>
Cc: Andrew Morton <akpm@osdl.org>,
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 22:14:02 +0100 [thread overview]
Message-ID: <20060511211401.GN27946@ftp.linux.org.uk> (raw)
In-Reply-To: <20060511204033.GB3570@stusta.de>
On Thu, May 11, 2006 at 10:40:33PM +0200, Adrian Bunk wrote:
> We could turn of this kind of warnings that generate these kind of false
> positives globally with -Wno-uninitialized until a future gcc version
> might be better at avoiding false positives.
>
> But there's one problem, this turns off two kinds of warnings:
> - 'foo' may be used uninitialized in this function
> - 'foo' is used uninitialized in this function
>
> The first kind of warnings is the one generating the false positives
> while the second kind are warnings we do not want to lose, but AFAIK
> there's no way to only turn off the first kind.
>
> Perhaps asking the gcc developers for separate options for these two
> kinds of warnings in gcc 4.2 and then turning off the first kind is
> the way to go?
Folks, let's look at it that way:
* warnings are tools to locate broken places in the tree.
* we have two signals ("is unused" and "may be unused"), say
A(location, verision) and B(location, version).
* A has fairly high S/N ratio.
* B has very large noise component, but it's only weakly dependent
on the verision.
The question is how to get useful information out of those.
* solution 1: introduce C(location, version) and filter A and B
with it, to kill noise in B.
* solution 2: ignore B, either by gcc modification or simply filtering
it with grep.
* solution 3: subtract the signals for consequent versions.
IMO it's obvious that combining outputs of (2) and (3) gives the best S/N.
The reason why (1) is bad is that it kills high-S/N channel in the areas
with high noise on low-S/N channel *and* that filtered-out areas will
remain filtered out in the next versions. IOW, it's a clear loss.
next prev parent reply other threads:[~2006-05-11 21:14 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
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 [this message]
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=20060511211401.GN27946@ftp.linux.org.uk \
--to=viro@ftp.linux.org.uk \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bunk@stusta.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.