> In this case, I would say the effects are much more obvious. Just take the example in the article. The compiler cannot replace a pointer access with its value

> In this case, I would say the effects are much more obvious. Just take the example in the article. The compiler cannot replace a pointer access with its value if there has been any other pointers access in between. I have no idea what you mean. The whole point of this discussion is that the example in the article should not be optimized in the manner they're describing, because it would be wrong. That is... a good thing. Not a bad thing. And the compiler certainly could replace a pointer access with its value if there has been other pointer access in between, as long as that pointer wasn't leaked away into some opaque place via an integer. > The compiler also cannot reorder any statements with pointer accesses. They would basically behave as memory barriers (if I understand them correctly). No, I don't think you understood what I'm saying. See above. It would still be perfectly legal for the compiler to transform char p[1] = {0}; opaque(); return p[0]; to opaque(); return 0; under what I wrote above, the intervening statement notwithstanding.