|
|
|
|
|
|
by kibwen
935 days ago
|
|
|
Note that it's entirely feasible that GCC would do the same in this specific case. This wasn't necessarily a "bug" in LLVM per se, because this is the specified behavior in C and C++, and LLVM was simply implementing those semantics. The fix here was just to allow languages to opt-out of this behavior. Since GCC is also primarily a C/C++ backend, you'd have the same problem unless they offer a similar opt-out. 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.