Re: In fs/proc/array.c error in function proc_pid_stat

[William Lee Irwin III]

On Saturday December 13th 2003 William Lee Irwin III wrote:
>> A quick reading of the patch (BTW, your MUA is mangling whitespace)
>> reveals it's merely creating a local variable, which should have no
>> bearing on code generation.

On Sun, Dec 14, 2003 at 10:28:02AM +0100, Marco Roeland wrote:
> It shouldn't indeed, but it does anyway. The main fault here is some
> bug that RedHat's gcc 2.96 has with dealing with 'unsigned long long'
> variables. It seems to be partly triggered by the relative complexity
> of the very long printf statement it's part of in this file. An earlier
> patch that *only* broke up the printf (so without the local variable)
> also fixed compilation for some people, though not for all. Changing
> some random local variable to 'volatile' also fixed compilation.

s/fixed compilation/appeared to work around a compiler bug/


On Saturday December 13th 2003 William Lee Irwin III wrote:
>> i.e. the compiler is broken.

On Sun, Dec 14, 2003 at 10:28:02AM +0100, Marco Roeland wrote:
> It's a known *bug*, and seems to be triggered in the current 2.6.0-test
> series for gcc 2.96 only in this particular function. Perhaps 'broken'
> is a bit too harsh!

It breaks elsewhere in various ways (or has broken; maybe they update
things they still call 2.96).


On Saturday December 13th 2003 William Lee Irwin III wrote:
>> Bad code generation can cause runtime problems too; upgrading to a
>> bugfixed compiler is the only sound course of action.

On Sun, Dec 14, 2003 at 10:28:02AM +0100, Marco Roeland wrote:
> Perhaps. But older (server) platforms with this compiler are still in
> wide use, if a simple patch can make use of an otherwise reasonable
> compiler again, what's the big deal. And on these platforms dual
> installing two versions of gcc (and especially g++ for userspace) can
> lead to other mistakes and very hard to debug artifacts from mixed
> object code.

(1) I don't trust it for runtime code either; there have been problems.
(2) These idiotic rearrangements of code to work around compiler bugs
	are worthless since you'll eventually end up eventually needing
	contradictory changes to work around different compilers' bugs.
	They're also total crap changes, worthless code churn, and even
	uglify the code.
(3) 2.96? You must be kidding. Current is bordering on 3.4 if it's not
	there already. Do you think anyone's still taking patches for
	2.2.8 Linux kernels? Now apply the same reasoning to gcc. Some
	backport TLC from a distro is not going to be able to bring it
	up to modern standards.
(4) 2 versions of gcc is nothing and has zero bearing on the C++ ABI
	braindamage that went around a couple of years ago as it's not
	a C++ compiler.


-- wli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/