login
Search
Jeff Garzik suggested that more recent versions of GCC have been getting more and more verbose, "the level of warnings in a kernel build has lately increased to the point where it is hiding bugs and otherwise making life difficult." He started a new "gccbug" branch in which he's been silencing bogus warning after verifying that they are indeed bogus, "the audit has already uncovered several minor bugs, lending credence to my theory that too many warnings hides bugs." Daniel Walker pointed to an earlier posting [story] in which a macro was created to handle false positives. He summarized concerns raised in the earlier discussion, "it's not about anyone not reviewing the code properly when the warning is first silenced. It's that future changes might create new problems that are also silenced. I don't think it's a huge concern, especially since there's was a config option to turn the warning backs on."
Andrew Morton [interview] expressed interest in merging the macro, "fact is, those bogus warnings are harmful and cause real problems to not be noticed. There is value in finding some way of making real warnings apparent to all developers and testers." He added, "the downsides are that it muckies up the source a little and introduces a very small risk that real use-uninitialised bugs will be hidden. But I believe the benefit outweighs those disadvantages."
From: Jeff Garzik [email blocked] To: Linux Kernel [email blocked] Subject: Announce: gcc bogus warning repository Date: Sun, 01 Oct 2006 09:44:55 -0400 The level of warnings in a kernel build has lately increased to the point where it is hiding bugs and otherwise making life difficult. In particular, recent gcc versions throw warnings when it thinks a variable "MAY be used uninitialized", which is not terribly helpful due to the fact that most of these warnings are bogus. For those that may find this valuable, I have started a git repo that silences these bogus warnings, after careful auditing of code paths to ensure that the warning truly is bogus. The results may be found in the "gccbug" branch of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git This repository will NEVER EVER be pushed upstream. It exists solely for those who want to decrease their build noise, thereby exposing true bugs. The audit has already uncovered several minor bugs, lending credence to my theory that too many warnings hides bugs.
From: Daniel Walker [email blocked] Subject: Re: Announce: gcc bogus warning repository Date: Sun, 01 Oct 2006 08:40:13 -0700 On Sun, 2006-10-01 at 09:44 -0400, Jeff Garzik wrote: > The level of warnings in a kernel build has lately increased to the > point where it is hiding bugs and otherwise making life difficult. > > In particular, recent gcc versions throw warnings when it thinks a > variable "MAY be used uninitialized", which is not terribly helpful due > to the fact that most of these warnings are bogus. > > For those that may find this valuable, I have started a git repo that > silences these bogus warnings, after careful auditing of code paths to > ensure that the warning truly is bogus. > > The results may be found in the "gccbug" branch of > git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git > Steven Rostedt an I worked on this problem in May. Steven came up with, a nice way to handle these warnings, which doesn't increase code size. Here's the post if your interested. http://lkml.org/lkml/2006/5/11/50 Daniel
From: Andrew Morton [email blocked] Subject: Re: Announce: gcc bogus warning repository Date: Sun, 1 Oct 2006 11:12:26 -0700 On Sun, 01 Oct 2006 08:40:13 -0700 Daniel Walker [email blocked] wrote: > On Sun, 2006-10-01 at 09:44 -0400, Jeff Garzik wrote: > > The level of warnings in a kernel build has lately increased to the > > point where it is hiding bugs and otherwise making life difficult. > > > > In particular, recent gcc versions throw warnings when it thinks a > > variable "MAY be used uninitialized", which is not terribly helpful due > > to the fact that most of these warnings are bogus. > > > > For those that may find this valuable, I have started a git repo that > > silences these bogus warnings, after careful auditing of code paths to > > ensure that the warning truly is bogus. > > > > The results may be found in the "gccbug" branch of > > git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git > > Funny - I started doing the exact same thing here just eight hours ago. I'll send you anything which isn't in that git tree, thanks. > Steven Rostedt an I worked on this problem in May. Steven came up with, > a nice way to handle these warnings, which doesn't increase code size. > Here's the post if your interested. > > http://lkml.org/lkml/2006/5/11/50 I think we should merge that and use it. No overhead, self-documenting, easily greppable for. The downsides are that it muckies up the source a little and introduces a very small risk that real use-uninitialised bugs will be hidden. But I believe the benefit outweighs those disadvantages.
From: Jeff Garzik [email blocked] Subject: Re: Announce: gcc bogus warning repository Date: Sun, 01 Oct 2006 14:16:07 -0400 Andrew Morton wrote: > The downsides are that it muckies up the source a little and introduces a > very small risk that real use-uninitialised bugs will be hidden. But I > believe the benefit outweighs those disadvantages. How about just marking the ones I've already done in #gccbug? If I'm taking the time to audit the code, and separate out bogosities from real bugs, it would be nice not to see that effort wasted. #gccbug includes _only_ the bogosities. I didn't just blindly paper over everything with a 'may be used uninitialized' warning. I'm well over halfway through the 'make allmodconfig' build, and as LKML emails can attest, have found several valid warnings. Jeff
From: Daniel Walker [email blocked] Subject: Re: Announce: gcc bogus warning repository Date: Sun, 01 Oct 2006 11:26:28 -0700 On Sun, 2006-10-01 at 14:16 -0400, Jeff Garzik wrote: > Andrew Morton wrote: > > The downsides are that it muckies up the source a little and introduces a > > very small risk that real use-uninitialised bugs will be hidden. But I > > believe the benefit outweighs those disadvantages. > > How about just marking the ones I've already done in #gccbug? > > If I'm taking the time to audit the code, and separate out bogosities > from real bugs, it would be nice not to see that effort wasted. There was a long thread on this, it's not about anyone not reviewing the code properly when the warning is first silenced. It's that future changes might create new problems that are also silenced. I don't think it's a huge concern, especially since there's was a config option to turn the warning backs on. Daniel
From: Jeff Garzik [email blocked] Subject: Re: Announce: gcc bogus warning repository Date: Sun, 01 Oct 2006 14:45:28 -0400 Daniel Walker wrote: > On Sun, 2006-10-01 at 14:16 -0400, Jeff Garzik wrote: >> Andrew Morton wrote: >>> The downsides are that it muckies up the source a little and introduces a >>> very small risk that real use-uninitialised bugs will be hidden. But I >>> believe the benefit outweighs those disadvantages. >> How about just marking the ones I've already done in #gccbug? >> >> If I'm taking the time to audit the code, and separate out bogosities >> from real bugs, it would be nice not to see that effort wasted. > > There was a long thread on this, it's not about anyone not reviewing the > code properly when the warning is first silenced. It's that future > changes might create new problems that are also silenced. I don't think > it's a huge concern, especially since there's was a config option to > turn the warning backs on. That doesn't address my question at all. If there is no difference between real non-init bugs and bogus warnings, then a config option doesn't make any difference at all, does it? Real bugs are still hidden either way: if the warnings are turned on, the bugs are lost in the noise. if the warnings are turned off, the bugs are completely hidden. Jeff
From: Andrew Morton [email blocked] Subject: Re: Announce: gcc bogus warning repository Date: Sun, 1 Oct 2006 14:45:09 -0700 On Sun, 1 Oct 2006 20:33:30 +0100 Al Viro [email blocked] wrote: > On Sun, Oct 01, 2006 at 12:25:50PM -0700, Daniel Walker wrote: > > > > > I bow to your incredible power of observation. Now that you've shared > > > > > that revelation with the list, could you explain what does blanket silencing > > > > > of these warnings buy you, oh wan^H^Hise one? > > > > > > > > Did you see me silencing anything (with your crystal ball?) ? Cause I'm > > > > not. > > > > > > And what, in your opinion, does the patch in question achieve if not > > > that? > > > > You mean the patch from Steven posted in May? Well it does appear to > > silence the warning. You didn't like the approach it seems? Please tell > > me why . > > Read the list archives... There isn't much point in doing that if they're as useless as this thread. Fact is, those bogus warnings are harmful and cause real problems to not be noticed. There is value in finding some way of making real warnings apparent to all developers and testers. An external post-processor isn't very useful because few people will run it. If we can integrate such a thing into the build system and make it available to all developers and testers then OK.
From: Randy Dunlap [email blocked] Subject: Re: Announce: gcc bogus warning repository Date: Sun, 1 Oct 2006 10:07:47 -0700 On Sun, 01 Oct 2006 09:44:55 -0400 Jeff Garzik wrote: > > The level of warnings in a kernel build has lately increased to the > point where it is hiding bugs and otherwise making life difficult. > > In particular, recent gcc versions throw warnings when it thinks a > variable "MAY be used uninitialized", which is not terribly helpful due > to the fact that most of these warnings are bogus. > > For those that may find this valuable, I have started a git repo that > silences these bogus warnings, after careful auditing of code paths to > ensure that the warning truly is bogus. > > The results may be found in the "gccbug" branch of > git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git > > This repository will NEVER EVER be pushed upstream. It exists solely > for those who want to decrease their build noise, thereby exposing true > bugs. > > The audit has already uncovered several minor bugs, lending credence to > my theory that too many warnings hides bugs. I usually build with must_check etc. enabled then grep them away if I want to look for other messages. I think that the situation is not so disastrous. --- ~Randy
From: Jeff Garzik [email blocked] Subject: Re: Announce: gcc bogus warning repository Date: Sun, 01 Oct 2006 13:20:45 -0400 Randy Dunlap wrote: > On Sun, 01 Oct 2006 09:44:55 -0400 Jeff Garzik wrote: > >> The level of warnings in a kernel build has lately increased to the >> point where it is hiding bugs and otherwise making life difficult. >> >> In particular, recent gcc versions throw warnings when it thinks a >> variable "MAY be used uninitialized", which is not terribly helpful due >> to the fact that most of these warnings are bogus. >> >> For those that may find this valuable, I have started a git repo that >> silences these bogus warnings, after careful auditing of code paths to >> ensure that the warning truly is bogus. >> >> The results may be found in the "gccbug" branch of >> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git >> >> This repository will NEVER EVER be pushed upstream. It exists solely >> for those who want to decrease their build noise, thereby exposing true >> bugs. >> >> The audit has already uncovered several minor bugs, lending credence to >> my theory that too many warnings hides bugs. > > I usually build with must_check etc. enabled then grep them > away if I want to look for other messages. I think that the situation > is not so disastrous. I think it's both sad, and telling, that the high level of build noise has trained kernel hackers to tune out warnings, and/or build tools of ever-increasing sophistication just to pick out the useful messages from all the noise. If you have to grep useful stuff out of the noise, you've already lost. Jeff
From: Alistair John Strachan [email blocked] Subject: Re: Announce: gcc bogus warning repository Date: Sun, 1 Oct 2006 18:27:29 +0100 On Sunday 01 October 2006 18:20, Jeff Garzik wrote: > Randy Dunlap wrote: [snip] > >> This repository will NEVER EVER be pushed upstream. It exists solely > >> for those who want to decrease their build noise, thereby exposing true > >> bugs. > >> > >> The audit has already uncovered several minor bugs, lending credence to > >> my theory that too many warnings hides bugs. > > > > I usually build with must_check etc. enabled then grep them > > away if I want to look for other messages. I think that the situation > > is not so disastrous. > > I think it's both sad, and telling, that the high level of build noise > has trained kernel hackers to tune out warnings, and/or build tools of > ever-increasing sophistication just to pick out the useful messages from > all the noise. > > If you have to grep useful stuff out of the noise, you've already lost. The question is whether the GCC guys are actually doing anything about the problem. If they are, we should do nothing. If they aren't, maybe it's time for "x = x" hacks like Steven's. Is GCC 4.2 any better with this class of warnings? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK.
From: Adrian Bunk [email blocked] Subject: Re: Announce: gcc bogus warning repository Date: Sun, 1 Oct 2006 19:45:55 +0200 On Sun, Oct 01, 2006 at 06:27:29PM +0100, Alistair John Strachan wrote: > On Sunday 01 October 2006 18:20, Jeff Garzik wrote: > > Randy Dunlap wrote: > [snip] > > >> This repository will NEVER EVER be pushed upstream. It exists solely > > >> for those who want to decrease their build noise, thereby exposing true > > >> bugs. > > >> > > >> The audit has already uncovered several minor bugs, lending credence to > > >> my theory that too many warnings hides bugs. > > > > > > I usually build with must_check etc. enabled then grep them > > > away if I want to look for other messages. I think that the situation > > > is not so disastrous. > > > > I think it's both sad, and telling, that the high level of build noise > > has trained kernel hackers to tune out warnings, and/or build tools of > > ever-increasing sophistication just to pick out the useful messages from > > all the noise. > > > > If you have to grep useful stuff out of the noise, you've already lost. > > The question is whether the GCC guys are actually doing anything about the > problem. If they are, we should do nothing. If they aren't, maybe it's time > for "x = x" hacks like Steven's. >... Let's be fair to gcc: gcc correctly tells it "may be used uninitialized" - that's different from cases where gcc tells "is used uninitialized". Sometimes, it requires _much_ context seeing that a condition is actually not possible. And there are even cases where it's technically impossible for a compiler to figure out itself that a condition is not possible. > Cheers, > Alistair. 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
One word
-Werror
Two words
"bogus warning"
upcoming gcc options...
gcc -Wextra-pendantic -fomit-all-pointers -O99 -Wpound-me-in-the-ass-prison
-Wpedantic
I think you need -Wno-flag-spelling-check if you're going to play with -Wpound-me-in-the-ass-prison and spell pedantic that way, unless that's your thing.
That's stupid. For a long
That's stupid.
For a long time, GCC's way to silence such warnings is:
(void)variable_name;
Use pattern is:
void func(int x) { #ifdef CONFIG_PROCESS_X [code using var x] #else (void)x; /* x isn't used */ #endif }That's not the issue.
That idiom works for unused-variable warnings. The "‘x’ may be used uninitialized in this function" warnings arise in a bit more complex code sequences.
Take a look at sem.c and how setbuf is used in semctl_down. (Around line 806 if the link doesn't take you directly to the correct line.) Notice that copy_from_user initializes the struct, and the switch-case later uses the struct. This is apparently one of the functions that triggers the useless warning.
Here's an example of code which triggers the warning:
int foo(int *x, int z) { switch (z) { case 0: *x = 1; return 0; case 1: *x = 5; return 0; default: return -1; } } int bar(int y, int z) { int x; if (y != 0) if (foo(&x, z)) return -1; switch (y) { case 0: return 0; case 1: return x; default: return y; } }Well Know Deficiency
This is well know deficiency. It got better in GCC 3 & 4 - but not perfect.
I used "int x = 0;" to shut it up. Thou I'm not sure about all consequences of such practice.
In many cases refactoring code also helps. The code above - pretty normal Linux code - isn't best example of readability. I personally prefer readable code to fast code.
P.S. The code in sem.c is mess. Be am I a compiler - I would also complained about something. That micro-nano-pico-optimization - to not take lock if parameters is invalid - IMHO totally bogus. Premature optimization to put it bluntly. Move the copy_from_user into switch/case - it does set 'err' return variable too.
I agree
I agree the code seems pretty messy. Doing stuff like "don't take lock if parameters are invalid" is what I sometimes refer to as "optimizing for the error case." The error case is not the common case. You should optimize for the common case.
Granted, if you have locks that are hashed on the parameters, you could be setting yourself up for mysterious behaviors. But if the lock taken doesn't depend on the potentially-invalid arguments, then it seems like you should just go ahead and take the lock and release it in case of error. The only issue I can see there is denial-of-service if some jerk floods the kernel with bogus requests. Even then, I'm not certain you could DoS this way.
Filter output before it goes to screen?
A development technique that used to be used in times past was to filter the output of a build against a known list of expected warnings before the output is sent to output or reviewed.
Having a situation where warnings go away for no reason may be a cause for concern (were correct compiler options used? did compiler change?). So if the correct warnings listed in a filter-file aren't found, it could be considered an error in the build. Fixing a warning would also involve removing the expected warning from the build-output template file...
???useful?