> The source of this bug is LLVM [2] which Rust relies on for optimisations and
machine code generation.
So basically rustc_codegen_gcc and cranelift can compile code that don't with LLVM and then introduce (or solve) new bugs?
So basically rustc_codegen_gcc and cranelift can compile code that don't with LLVM and then introduce (or solve) new bugs?
But in general, yes, if this was unintended behavior of LLVM, then we would expect alternative backends to exhibit differing behavior.
>Infinite loops and recursions are Undefined Behaviour in C and C++, therefore the compiler can assume that a loop always terminates.
... which is wrong - only C++ requires loops to terminate. C allows non-terminating loops (with some specific requirements), and LLVM was already known to miscompile C in this same way until it was fixed in LLVM 12 with the `mustprogress` attribute.
https://bugs.llvm.org/show_bug.cgi?id=965
https://stackoverflow.com/questions/59925618/how-do-i-make-a...
Then this:
>While LLVM does not require loops to terminate and should compile Rust loops correctly, its code contained assumptions that only hold for C/C++, thus miscompiling Rust code.
... is implied to be a different LLVM bug after the first one was already fixed, ie despite using `mustprogress` LLVM had additional miscompilations for Rust code because of "assumptions that only hold for C/C++". I can't tell which one in table 4.2 it is, though; none of them see to match.