[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.046 / U:14.588 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site