public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Andrew Morton <akpm@osdl.org>
Cc: Al Viro <viro@ftp.linux.org.uk>,
	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:40:33 +0200	[thread overview]
Message-ID: <20060511204033.GB3570@stusta.de> (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:
> >
> > On Wed, May 10, 2006 at 04:05:48PM -0700, Andrew Morton wrote:
> > > Sure - it's sad and we need some workaround.
> > > 
> > > The init_self() thingy seemed reasonable to me - it shuts up the warning
> > > and has no runtime cost.  What we could perhaps do is to make
> > > 
> > > #define init_self(x) (x = x)
> > > 
> > > only if the problematic gcc versions are detected.  Later, if/when gcc gets
> > > fixed up, we use
> > 
> > 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..

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?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  parent reply	other threads:[~2006-05-11 20:40 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                             ` Adrian Bunk [this message]
2006-05-11 21:14                               ` [PATCH -mm] sys_semctl gcc 4.1 warning fix 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=20060511204033.GB3570@stusta.de \
    --to=bunk@stusta.de \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=davem@davemloft.net \
    --cc=dwalker@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@ftp.linux.org.uk \
    /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