All of lore.kernel.org
 help / color / mirror / Atom feed
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


  parent reply	other threads:[~2006-10-05 16:37 UTC|newest]

Thread overview: 24+ 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:01     ` 2.6.18-mm3 Andrew Morton
2006-10-03 18:16     ` 2.6.18-mm3 Badari Pulavarty
2006-10-03 18:16       ` 2.6.18-mm3 Badari Pulavarty
2006-10-03 18:05   ` 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 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.