The Microsoft compiler can do some level of automated mitigation. But fundamentally it is a static analysis that cannot cover all cases. You do need help from t

The Microsoft compiler can do some level of automated mitigation. But fundamentally it is a static analysis that cannot cover all cases. You do need help from the compiler to de-speculate loads appropriately (GCC and Clang will feature these intrinsics). But only the programmer knows the true security model the program exists under. Spectre V1, quite fundamentally, means that branch conditions are not necessarily a legitimate security boundary anymore. That's really all there is to it. Either you have to accept this and fix your code, or not fix it and say the threat exists outside your model. Even leveraging newer hardware features (e.g. perhaps segregating cache regions like Intel CAT) will likely require software integration if they wish to retain speculative capabilities, and this seems likely. We also cannot test for all possible side channel attacks in highly error-prone and detailed cryptographic algorithms, and new ones are found. But we manage through many mechanisms to try and mitigate the things we know about (through various static and dynamic methods, and enhancing our security and programming models). These all require coordination on the programmers behalf, still. It's not necessarily our fault this is all happening. It's unfortunately our responsibility to fix and mitigate it. And, unfortunately -- it's also another thing on top of the 200 other things a C/C++ programmer/systems programmer writing security-relevant code will have to understand.