[YBA] kernel compile errors with GCC >= 4.6

[YBA] kernel compile errors with GCC >= 4.6

Nadav Har'El nyh at math.technion.ac.il
Thu Apr 5 14:28:42 IDT 2012


On Thu, Apr 05, 2012, Oron Peled wrote about "Re: [YBA] kernel compile errors with GCC >= 4.6":
> On Thursday, 5 בApril 2012 11:33:51 Nadav Har'El wrote:
> > 
> > When "you" == "Linus Torvalds", I agree.
> > 
> > When "you" == "kernel user" or even "developer working on one
> > particular part of the kernel", I don't agree:
> 
> Many FOSS projects (and the kernel in particular) are very distributed,
> so there are potentially hundreds of "Linus Torvalds's" out there.

First of all, even hundreds is small compared to the many thousands
(I hope millions ;-)) who happen to compile a kernel, not develop it.

But more importantly, it's not true that there are hundreds of Linus
Torvalds out there. Let's say that I'm developing a particular driver.
Do I need to see warnings when some other driver, not directly related
to my project, didn't use a variable? Will I see this warning and jump
to send a patch? NOT LIKELY. Should the kernel build system make this
warning a fatal error to supposedly *force* me to send a patch? I don't
think so.

The few people who work on the whole kernel, including the so-called
"Kernel Janitors", Redhat's QA people, and similar people, should
probably compile with -Wall -Werror and use any other
possible-bug-catching tools they can get their hands on. But the
ordinary users, and even ordinary developers - they should not have to
constantly spend their time figuring out problems in other parts of the
code they know nothing about.

> Practically any developer working on some obscure Linux driver within
> some company is producing code which *may* eventually reach the kernel
> proper. Using global -Wall -Werror put most of the burden where it
> should be -- on the shoulder of the one writing the code, instead
> of starting to resolve these issues upon merging it upstream.

Indeed - let the writer of the code use -Wall -Werror. He'll also need
to use checkpatch.pl (to check the coding style), and maybe he'll use
various other tools to help him write quality code. But none of these
"scaffolding" needs to reach the end-user build process.

Anyway, this is my opinion - I think I've talked about it enough now,
and I better shut up after this message :-)

> In another mail on this thread, you mentioned a rare case of a compiler
> wrongly warning about uninitialized variable:
>  * Maybe this was a compiler bug -- should it be ignored? (as would
>    definitely happen without -Werror), or maybe the compiler should
>    be fixed?

I tried to avoid the details, but since you asked, here they are.
Imagine code like this:

	extern int flag;

	...

	void f(){
		int i;
		if (flag)
			i=0;	
		g();
		if (flag)
			dosomething(i);
	}

Now, the compiler (starting a certain version of GCC, with high enough
optimization setting) will warn that i may be used without being set.
Why? After all, it is only used if flag is true, and in that case, i
*was* set. Well, the problem is that the compiler can't know that flag
isn't changed in the middle of the function call, perhaps by another
thread. Perhaps in the call to g(). But *I* know that it can't - this
program is single-threaded, g() does nothing to the flag, and in fact
"flag" is never changed after initialization.

What am I supposed to do now? Add bizarre comments to tell this specific
version of the compiler to avoid warning in this case? Rewrite the code
in a way that avoids this irrelevant warning? And in any case, is this
really a reason why a user's compilation need to be aborted and the user
will not be able to use my program?

>  * More importantly, I've seen countless such warnings (in numerous
>    user-space programs). All of these were real bugs waiting to happen.

I agree, but I don't agree that programs with bugs should not be allowed
to run. I'll tell you a dirty little secret: All programs, even good
ones, have real bugs waiting to happen. Is this a reason not to allow
users to compile them?

> I think a more valid criticism is: why -Wunused-but-set-variable is
> included in '-Wall' (which unlike its name implies does not include
> all warnings). Maybe this specific warning (and other "style" ones)
> should only be included in '-Wextra'.

I actually am not sure it is included in -Wall. All I know was the
original poster had this problem, so whatever -W... parameters are used
to compile the Linux kernel (or the part of it in question) is to be
questioned.

Also note that in my example above, the problem wasn't a unused-but-set,
but the much more serious opposite, a used variable never set. This too
can be a false alarm, like I showed.

> I beg to disagree -- users do not compile code, they 'yum/aptitude install'
> packages.

Today, true - most of them install binaries. But like I said above, most
of the people who do compile their own kernel are still not
Linus-Torvald-like experts like you imagine them to be.

> Within FOSS community, each such "consumer" of your source
> code actually help the project as another test-case (maybe on a different
> platform, maybe different compiler, etc.) -- Yes, some of these test-cases
> are just noise, but you don't know this before evaluating the specific
> warning.

Test-case is fine, guinea pig is not. Let the user know about the
warning and consider it, fine. Refuse to compile the program and force
the user to deal with it? Not fine.

-- 
Nadav Har'El                        |                   Thursday, Apr 5 2012, 
nyh at math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Preserve wildlife -- pickle a squirrel
http://nadav.harel.org.il           |today!



More information about the Linux-il mailing list