* Bart Van Assche: > As known the compiler may not reorder any access to any static > variable, global variable or dynamically allocated data with a call to > a function that is not declared inline.
I assume you mean "defined in another translation unit" instead of "not declared inline". Still, I don't think this is true as far as static variables are concerned (both file-scoped and function-scoped ones). There may only be a few cases where you can prove that a call to an extern function does not access a file-scoped static variable, so doing that optimization may not be worthwhile. But the optimization is not forbidden per se. > Variables that are allocated on the stack of a thread can only be > shared with another thread only by passing a pointer to that variable > to another thread first. Passing such a pointer inhibits reordering of > accesses to shared local variables with a call to a function that is > not declared inline. And this isn't really specific to threads. > Maybe it's a good idea to add a chapter to the gcc manual about > multithreaded programming, such that gcc users who did not follow this > discussion can look up this kind of information easily ? If there's a real chance that something like a C or C++ memory model will be standardized in the forseeable future (three years, perhaps), it might be unwise to set in stone a potentially conflicting set of rules for GCC.