[lkml]   [2006]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet_tick away
On Nov 29, 2006, at 20:04:28, David Schwartz wrote:
> Ask yourself this question: Can an assignment to a non-volatile
> variable be optimized out? Then ask yourself this question: Does
> casting away volatile make it not volatile any more?

Hmm, let's put this in a C file:
> int my_global = 0;

And put this in a header:
> extern int my_global;
> static int my_func(int a)
> {
> return a + my_global++;
> }

Now put this in another source file
> #include <my_header.h>
> int main()
> {
> while (my_func(3) < 5)
> printf("It hasn't happened yet!\n");
> return 0;
> }

The obvious result is that it prints "It hasn't happened yet!"
twice. On the third iteration when my_global == 2 it breaks out of
the loop. This is all fairly standard C so far.

Imagine we change the code to read from some auto-increment hardware
at a specific MMIO address instead of a global:
> static int my_func(int a)
> {
> return a + *(volatile int *)(0xABCD1234);
> }

But you're telling me that the change in the header file (where the
new function returns the exact same series of values with every call
as the old) causes the program to enter an infinite loop?

How do you rationalize this again?

> The 'readl' function should actually assign the value to a volatile
> variable. Assignments to volatiles cannot be cast away, but casts
> can and assignments to non-volatile variables can be optimized out.

Actually, no. The reason for the volatile in the pointer dereference
is to force the memory access to *always* happen. It's a guarantee
that the compiler will do that memory access every time it appears.
You have a volatile int afterwards and what you do with that nobody
cares. The point is the presence of the volatile in a single pointer-
dereference forcibly turns off any optimization of that specific
access, including loop unrolling and such.

Kyle Moffett

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-12-01 06:53    [W:0.055 / U:1.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site