On Thu, Oct 05, 2006 at 10:37:54AM +0200, Ingo Molnar wrote:
>
> * Andrew Morton <[email protected]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
