Messages in this thread | | | From | "Matthias Urlichs" <> | Date | Thu, 5 Feb 1998 17:47:59 +0100 | Subject | Re: Linux 2.0.3x & gcc 2.8 |
| |
Hi,
Alan Cox: > > problem with the source code, as the optimizer is quite right in assuming > > that the variable we're modifying is a parameter on the stack and thus a > > change will not affect anything and thus it can be optimized away. > > > > I do hope that'll end up in 2.0.34, and it's already in 2.1.* anyways. > > Its not. Until someone can explain why the original cast pointer as pointer > to volatile fix I tried didnt work I have to assume that gcc 2.8 has > broken volatile handling.
I don't know. :-/
My fix added a "volatile" in front of the actual variable in the parameter list. That worked.
Volatile handling as in
int dope; foo() { *(volatile int *)&dope = 12345; *(volatile int *)&dope = 23456; }
is _not_ 'broken'. Nor is
foo(volatile int dope) { dope = 12345; dope = 23456; }
My guess as to what's happening is this. The assignment is marked 'volatile', but the actual variable isn't, and when it is going out of scope the optimizer feels free to roll up the whole thing -- it looks at the actual variable and thinks 'this thing is on the stack, it's not volatile or anything, and it's going away anyway, why should anybody bother?'.
IMHO, this is a borderline case. You can argue either way that the compiler does the Right Thing.
> I will never support a kernel built with a compiler > with any known volatile handling bug. Its _far_ too critical to the net code > that volatile and the __asm__ behaviour work as documented.
You've got _that_ right. I just am not too sure that this is a bug. A to-be-clarified borderline case, maybe.
-- Matthias Urlichs noris network GmbH
| |