I agree, the idea of fiddling with hopeful compiler command line switches or throwing oddball intrinsics like pixie dust all over your code is a fools errand.

I agree, the idea of fiddling with hopeful compiler command line switches or throwing oddball intrinsics like pixie dust all over your code is a fools errand. The last word in this article is an architectural recommendation/option that seems the right one to me: > Removing sensitive information from memory > Another technique that can be used to mitigate speculative execution side channel vulnerabilities is to remove sensitive information from memory. Software developers can look for opportunities to refactor their application such that sensitive information is not accessible during speculative execution. This can be accomplished by refactoring the design of an application to isolate sensitive information into separate processes. For example, a web browser application can attempt to isolate the data associated with each web origin into separate processes, thus preventing one process from being able to access cross-origin data through speculative execution. So, one should sandbox her sensitive data into a separate processes and allow the Operating System to do its job of isolating the processes. As new hardware attacks become known and understood, the OS vendors will eventually patch their systems to enforce and strengthen the boundary contract that is supposed to exist between processes. I understand that the low-level recommendations in this article are probably salient to systems-level developers (who comprise a large percentage of C++ devs), so maybe I shouldn't be so irked to see the geek stuff listed front and center.