Re: Linux 2.6.27.27

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 29 Jul 2009, Pavel Machek wrote:
> 
> So... we are going to just work around the gcc bug in the kernel?

Well, the gcc people hopefully will fix it in the 4.2.4 tree too.

Also, it's not exactly the first time we work around compiler bugs. We've 
done it before, I'm sure we'll do it again.

In this case, the work-around is trivial, and in many ways makes the code 
more "normal" (it's just a loop counter, might as well use an "int" for 
it), so there are no downsides to it. 

We could disallow gcc-4.2.4 entirely, of course, and have a big "this 
compiler is known to generate broken code" message and refuse to compile 
the kernel with it, but while that would be a "safer" approach, it would 
be rather user-unfriendly.

Compiler bugs happen. They're really really annoying, and nasty to track 
down. But they aren't the end of the world, and the pattern of this 
particular bug doesn't seem like it would likely trigger anywhere else.

For example, I suspect it really does need that loop induction variable to 
be 'unsigned char', and it really needs that limit to be exactly 128. It 
looks like a combination of loop optimization and broken range logic. I 
doubt it would hit in some random code that just happens to compare an 
unsigned char against 128 in general.

And using 'unsigned char' as a lop induction variable is _very_ rare. 
Which is probably why the gcc bug happened in the first place - no 
testing.

			Linus