The ++x is a side effect from the abstract machine point of view. The issue is of course how the compiler maps the abstract machine to the real machine. Volatile is (purposefully) underspecified and I guess it is not completely unreasonable for a compiler to declare that a local volatile object whose address is never taken does not have a mapping at all.

There is little value on explicitly optimizing volatiles but of course that can happen as a side effect (ah!) of unrelated optimizations.

I rarely use volatile at all, but when I do, I do make sure not to apply it to local objects.

edit: I think the most reliable and portable way to make sure that the address of a variable escapes is something like this:

   volatile std::atomic<void*> sink; // global

   void escape(void*x) { 
     std::atomic_signal_fence(std::memory_oreder_release);
     sink.store(x, std::memory_order_relaxed);
   }

any signal handler executed after escape(&val) is guaranteed to be able to see the last value stored into val.