Re: In fs/proc/array.c error in function proc_pid_stat
From: William Lee Irwin III (wli_at_holomorphy.com)
Date: 12/14/03
- Previous message: Nick Piggin: "Re: [CFT][RFC] HT scheduler"
- In reply to: Marco Roeland: "Re: In fs/proc/array.c error in function proc_pid_stat"
- Next in thread: Marco Roeland: "Re: In fs/proc/array.c error in function proc_pid_stat"
- Reply: Marco Roeland: "Re: In fs/proc/array.c error in function proc_pid_stat"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 14 Dec 2003 01:59:53 -0800 To: Marco Roeland <marco.roeland@xs4all.nl>
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Nick Piggin: "Re: [CFT][RFC] HT scheduler"
- In reply to: Marco Roeland: "Re: In fs/proc/array.c error in function proc_pid_stat"
- Next in thread: Marco Roeland: "Re: In fs/proc/array.c error in function proc_pid_stat"
- Reply: Marco Roeland: "Re: In fs/proc/array.c error in function proc_pid_stat"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
