lkml.org 
[lkml]   [2008]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] get rid of some "may be used uninitialized" compiler warnings

* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Sat, 29 Nov 2008 10:26:01 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> > 196 files changed, 545 insertions(+), 436 deletions(-)
>
> Is any of this going anywhere?

We are using it to allow -tip to build without a single warning in
allyes/allno/allmod and randconfig kernels with -Werror, on 32-bit and
64-bit x86. Hence we use it to filter out our own bogosities that come in
via -tip maintained subsystems. (The fact that we need to look at _all_
warnings all across the kernel is a side effect.)

> There's a lot of resistance to fixing these things with
> uninitialized_var() (usually bogus resistance, IMO, but one gets tired
> of repeating oneself).

The networking tree picked up a whole bunch of them a few days ago. Most
of the maintainers of actively maintained subsystems are reasonable about
these things.

The only really contentious ones are the ones i kept separated out in
tip/warnings/bug: they are the warnings that are triggered by
!CONFIG_BUG.

> Many of these warnings can be fixed by restructuring the code, and
> often the end result is better overall.

i can give you the identity of more than 1 million separate lines of code
in the kernel where we have tool output that somehow tells us: "this code
sucks and could be improved by restructuring it".

So the cleanup effect is there, but by far not as important as the other,
reverse effect: a baseline of ~200 warnings obscures _nasty_ bugs that
the compiler does point out. So we need to reach a zero baseline - and
all the _new_ warnings tend to be very interesting.

We saw that in the x86 tree which reached a zero baseline -Werror a few
months ago: out of 10 warnings fixed after we reached the baseline 9 were
real fixes, only one is a GCC annotation.

I.e. we have amassed 100+ sites in the kernel that needs annotations -
then we could move to the next phase and reliably enforce a -Werror build
by subsystems who care about that. I know you care about it in -mm.

> But it's a lot more work. It would be much more scalable to, umm,
> motivate the various code-owners to fix their stuff independently. I
> don't know how, really - people just don't seem to appreciate how
> irritating and damaging that great warning spew is.
>
> Is there any prospect that some of these things will be fixed by newer
> gcc versions? If so, we could just ignore those warnings and
> concentrate on the ones which newer gcc emits.

Some go away with new GCC versions - that is why i'm always testing with
the very latest GCC version.

Would you be interested in picking up the ones in tip/warnings/complex
and tip/warnings/simple [but not tip/warnings/bug] into -mm? You could
pick up auto-warning-next tree into -mm straight away - it's well-tested
on x86, it is -git based and kept uptodate. Then you could do
!CONFIG_ALLOW_WARNINGS builds yourself.

Ingo


\
 
 \ /
  Last update: 2008-11-29 11:17    [from the cache]
©2003-2011 Jasper Spaans