From: Adrian Bunk <bunk@stusta.de>
To: Ingo Molnar <mingo@elte.hu>
Cc: Jeff Garzik <jeff@garzik.org>,
linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: make-bogus-warnings-go-away tree [was: 2.6.18-mm3]
Date: Thu, 5 Oct 2006 18:37:21 +0200 [thread overview]
Message-ID: <20061005163721.GJ16812@stusta.de> (raw)
In-Reply-To: <20061005083754.GA1060@elte.hu>
On Thu, Oct 05, 2006 at 10:37:54AM +0200, Ingo Molnar wrote:
>
> * Andrew Morton <akpm@osdl.org> wrote:
>
> > - Added Jeff's make-bogus-warnings-go-away tree to the -mm lineup, as
> > git-gccbug.patch
>
> Jeff: very nice! (I did this myself on a much smaller scale for the -rt
> patch, because it's just so lethal if some serious warning gets lost in
> the myriads of 'possible use of uninitialized' messages.)
>
> A small suggestion: to give GCC folks a chance to actually fix this,
> could we actively annotate these places instead of working them around?
>
> I.e., instead of:
>
> long cursor = 0;
> int error = 0;
> - void *new_mc;
> + void *new_mc = NULL;
> int cpu;
> cpumask_t old;
>
> couldnt we do:
>
> void *new_mc __GCC_WARN_BUG;
>
> and then do something like this in gcc.h:
>
> #ifdef CONFIG_ELIMINATE_BOGUS_GCC_WARNINGS
> # define __GCC_WARN_BUG = 0
> #else
> # define __GCC_WARN_BUG
> #endif
>
> this both gives an in-source incentive for GCC folks to get rid of these
> bogus warnings (or remain shamed for eternity),
Not all of the false positives are gcc bugs.
There are cases where it's technically impossible for gcc to figure out
that a variable is always initialized.
> and gives us the ability
> to control the presence of these workarounds (and the eventual ability
> to eliminate them in the future).
>
> this would also mean we could merge your tree upstream without worrying
> about hiding gcc bugs.
What we'd need would be some -Wno-may-be-used-uninitialized gcc option
that turns off the "may be may be used uninitialized" warnings but not
the "is used uninitialized" warnings.
This would:
- give us a way to silence these warnings
- allow people to see the warnings if they want to
- not increase the maintenance overhead
> Ingo
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
next prev parent reply other threads:[~2006-10-05 16:37 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-03 7:11 2.6.18-mm3 Andrew Morton
2006-10-03 14:33 ` 2.6.18-mm3 Michal Piotrowski
2006-10-03 17:37 ` 2.6.18-mm3 Badari Pulavarty
2006-10-03 18:01 ` 2.6.18-mm3 Andrew Morton
2006-10-03 18:16 ` 2.6.18-mm3 Badari Pulavarty
2006-10-03 18:05 ` 2.6.18-mm3 Badari Pulavarty
2006-10-04 13:44 ` [-mm PATCH] fixed PCMCIA au1000_generic.c Yoichi Yuasa
2006-10-06 6:18 ` Om Narasimhan
2006-10-06 7:31 ` Yoichi Yuasa
2006-10-07 22:31 ` Om Narasimhan
2006-10-04 15:14 ` 2.6.18-mm3 oops in xfrm_register_mode Steve Fox
2006-10-04 16:57 ` Andrew Morton
2006-10-04 21:02 ` Steve Fox
2006-10-05 15:06 ` Badari Pulavarty
2006-10-05 8:37 ` make-bogus-warnings-go-away tree [was: 2.6.18-mm3] Ingo Molnar
2006-10-05 10:05 ` Jeff Garzik
2006-10-05 16:21 ` make-bogus-warnings-go-away tree Roland Dreier
2006-10-05 20:52 ` make-bogus-warnings-go-away tree [was: 2.6.18-mm3] Kyle Moffett
2006-10-05 16:37 ` Adrian Bunk [this message]
2006-10-05 16:44 ` Jeff Garzik
2006-10-05 16:51 ` Adrian Bunk
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=20061005163721.GJ16812@stusta.de \
--to=bunk@stusta.de \
--cc=akpm@osdl.org \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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