Re: volatile variable

From: Jakub Jelinek
Date: Mon Aug 11 2003 - 09:42:23 EST


On Mon, Aug 11, 2003 at 10:06:36AM -0400, Richard B. Johnson wrote:
> > If 'a' is a local variable that's true. If 'a' is a global as the
> > original poster explicitly declared, then the compiler must assume that
> > function calls (such as the one to schedule()) may modify it, and hence
> > may not optimise away the second and subsequent reads. Therefore, the
> > 'volatile' is not required.
> >
>
> Again, this is incorrect. If you look at the declaration of schedule(),
> you will note "asmlinkage void schedule(void);". Now look up
> "asmlinkage"
> #define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
>
> The regparm(0) atttibute tells gcc that schedule() will get any/all
> of its parameters in registers. Since schedule() receives no parameters,
> that means that, as far as gcc is concerned, it cannot modify
> anything. That said, this may be a bug or it may have been added
> to work around some gcc bug. But, nevertheless, as the declaration
> stands, schedule() will never modify anything because somebody told
> gcc it won't.

You're wrong. regparm(0) attribute tells GCC to pass all arguments
on the stack. Also function argument passing (the only thing this
attribute controls) is completely orthogonal to whether a function may
modify global variables or not.
__attribute__((const)) functions are not allowed to write nor read
global memory, __attribute__((pure)) functions are not allowed to
write global memory and all other functions are allowed to both
read and write global memory.
As schedule is neither const nor pure, the compiler must assume
a global variable can be changed by schedule().

Jakub
-
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/