Is writing to memory an observable behaviour?

I've looked at the standard but couldn't find any indication that simply writing to memory would be considered observable behaviour. If not, that would mean the compiled code need not actually write to that memory. If a compiler choose to optimize away such access anything involving mapper memory, or shared memory, may not work.

1.9-8 seems to defined a very limited observable behaviour but indicates an implementation may define more. Can one assume than any quality compiler would treat modifying memory as an observable behaviour? That is, it may not guarantee atomicity or ordering, but does guarantee that data will eventually be written.

So, have I overlooked something in the standard, or is the writing to memory merely something the compiler decides to do?

Statements from the current or C++0x st开发者_StackOverflowandard are good. Please note I'm not talking about accessing memory through a function, I mean direct access, such as writing data to a pointer (perhaps retrieved via mmap or another library function).

This kind of thing is what volatile exists for. Else, writing to memory and never apparently reading from it is not observable behaviour. However, in the general case, it would be quite impossible for the optimizer to prove that you never read it back except in relatively trivial examples, so it's not usually an issue.

Can one assume than any quality compiler would treat modifying memory as an observable behaviour?

No. Volatile is meant for marking that. However, you cannot fully trust the compiler even after adding the volatile qualifier, at least as told by a 2008 paper: http://www.cs.utah.edu/~regehr/papers/emsoft08-preprint.pdf

EDIT:

From C standard (not C++) http://c0x.coding-guidelines.com/5.1.2.3.html

An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).

My reading of C99 is that unless you specify volatile, how and when the variable is actually accessed is implementation defined. If you specify volatile qualifier then code must work according to the rules of an abstract machine.

Relevant parts in the standard are: 6.7.3 Type qualifiers (volatile description) and 5.1.2.3 Program execution (the abstract machine definition).

For some time now I know that many compilers actually have heuristics to detect cases when a variable should be reread again and when it is okay to use a cached copy. Volatile makes it clear to the compiler that every access to the variable should be actually an access to the memory. Without volatile it seems compiler is free to never reread the variable.

And BTW wrapping the access in a function doesn't change that since a function even without inline might be still inlined by the compiler within the current compilation unit.

From your question below:

Assume I use an array on the heap (unspecified where it is allocated), and I use that array to perform a calculation (temp space). The optimizer sees that it doesn't actually need any of that space as it can use strictly registers. Does the compiler nonetheless write the temp values to the memory?

Per MSalters below:

It's not guaranteed, and unlikely. Consider a a Static Single Assignment optimizer. This figures out each possible write/read dependency, and then assigns registers to optimize these dependencies. As a side effect, any write that's not followed by a (possible) read creates no dependencies at all, and is eliminated. In your example ("use strictly registers") the optimizer has satisfied all write/read dependencies with registers, so it won't write to memory at all. All reads produce the correct values, so it's a correct optimization.