Re: user-mode port 0.44-2.4.7

[Andrea Arcangeli <andrea@suse.de>]

On Mon, Jul 23, 2001 at 04:44:06PM -0400, Chris Friesen wrote:
> Linus Torvalds wrote:
> > 
> > On Mon, 23 Jul 2001, Andrea Arcangeli wrote:
> > >
> > > gcc can assume 'state' stays constant in memory not just during the
> > > 'case'.
> > 
> > The point is that if the kernel has _any_ algorithm where it cares, it's a
> > kernel bug. With volatile or without.
> > 
> > SHOW ME THE CASE WHERE IT CARES. Let's fix it. Let's not just hide it with
> > "volatile".
> 
> If I understand correctly, xtime is updated asynchronously.  If it isn't, then
> ignore this message totally.  However, if it is, then *not* specifying it as
> volatile could easily cause problems in technically correct but poorly written
> code.
> 
> Suppose I loop against xtime reaching a particular value.  While this is
> definately not good practice, if xtime is not specified as volatile then since I
> never modify it within the loop the compiler is free to move the initial load
> out of the loop when optimizing.  In this example the case where it is marked as
> volatile will run (though inefficiently), but the non-volatile case can hang
> totally.
> 
> Do we want to get ourselves into something like this?

This is actually another issue, not really the problem I was talking
about. The problem I was talking about was just about the C language and
about writing correct C code (whith correct C code I mean something that
cannot break by using a future release of gcc). Without my patch you
never know. About the loop problem you mentioned you can know it won't
break instead if you write it carefully. Of course I understand in most
cases if the code breaks in the actual usages of xtime it is likely that
gcc is doing something stupid in terms of performance. but GCC if it
wants to is allowed to compile this code:

	printf("%lx\n", xtime.tv_sec);

as:

	unsigned long sec = xtime.tv_sec;
	if (sec != xtime.tv_sec)
		BUG();
	printf("%lx\n", sec);

Andrea