I don't get it, the compiler operates within the memory model specified by the language. If it "optimizes" a memset it does not change the behavior of the program (or it is a bug in the compiler which is a different topic).
Common misconception with C. A pointer does not mean a pointer to a sequence of capacitors in your RAM-memory. It really means a pointer to an abstract and temporary variable. How this abstract variable is executed on your hardware is implementation specific. Everything except input, output and explicitly defined side effects (volatile) is of no interest.
Really, you can print a c program on piece of paper and ask some slave to "execute" the program in his head given some input x, how he "implements" memset will surely be different than what a computer would, and if you only ask for the output y he will surely see that this memset doesn't affect y at all and skip doing it.
You're correct - the compiler operates within the memory model of the language. But C / C++'s memory model is broken w.r.t. security.
There is no way to ensure that something is actually overwritten, because under the memory models of C and C++ you cannot ever read that memory again, even though in actuality you can.
I'm not sure what you mean here, if you have a volatile pointer that points to a memory buffer returned by malloc, how can the compiler prevents a write through the pointer from happening?
Edit: unless your point is a temporary copy can be spilled in memory and this copy will stay in memory and won't be overwritten?
Because the compiler will optimize it out. Even if you return the random data / constant the compiler will optimize out the store to the variable and just pass it through directly.
The problem is that the memory model specified by the language is a subset of the memory model specified by the hardware. This leads to exploitable systems when you lift those blinders.