You probably could implement some workarounds in the compiler, though the linked Oodle blog-post does a good job of explaining why that isn’t feasible in this particular case:
The bug is not a flaw in the CPU logic as such, but rather the result of the CPU physically degrading due to design flaws. And for whatever reason, that degradation most frequently manifested as the mov instruction occasionally doing the wrong thing. Though the blog-post also makes it clear that this is not the only issue resulting from this degradation.
Moreover, the mov instruction is a very common instruction, so a general workaround for this problem would affect large parts of the resulting programs. For example, the 1-line function that Godbolt uses as its example code results in 3 mov instructions when compiled without optimizations:
intsquare(int num) {
return num * num;
}
becomes
"square(int)":
push rbp
mov rbp, rsp
mov DWORD PTR [rbp-4], edi
mov eax, DWORD PTR [rbp-4]
imul eax, eax
pop rbp
ret
You probably could implement some workarounds in the compiler, though the linked Oodle blog-post does a good job of explaining why that isn’t feasible in this particular case:
The bug is not a flaw in the CPU logic as such, but rather the result of the CPU physically degrading due to design flaws. And for whatever reason, that degradation most frequently manifested as the
movinstruction occasionally doing the wrong thing. Though the blog-post also makes it clear that this is not the only issue resulting from this degradation.Moreover, the
movinstruction is a very common instruction, so a general workaround for this problem would affect large parts of the resulting programs. For example, the 1-line function that Godbolt uses as its example code results in 3 mov instructions when compiled without optimizations:int square(int num) { return num * num; }becomes
"square(int)": push rbp mov rbp, rsp mov DWORD PTR [rbp-4], edi mov eax, DWORD PTR [rbp-4] imul eax, eax pop rbp ret