lkml.org 
[lkml]   [1998]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.095 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site