4 ms·

Rust does not use Clang. You are thinking about LLVM. But the bug is actually on rustc side because they fork LLVM on purpose and use it as they wish. If the

Rust does not use Clang. You are thinking about LLVM. But the bug is actually on rustc side because they fork LLVM on purpose and use it as they wish. If the rustc folks merge their project into LLVM, then you could claim it is an LLVM bug, otherwise please do not.

nneonneo 7y ago
Ah, nomenclature fail on my part. You're right, it's LLVM. This is an LLVM bug - it affects C code too (when it should only apply to C++). If you compile this code: static void die() { while(1) ; } int main() { die(); } as a C program with optimizations, it will die with an illegal instruction too.
- zzo38computer 7y ago
  Perhaps it should be allow to optimize it to: int main() { while(1) pause(); } But only if system call optimizations are enabled (otherwise it can't add the call to pause()), and only if you did not specifically disable the optimization for infinite loops, and only if you do not use the -Os option.
- saagarjha 7y ago
  Correct, the bug is that LLVM (being mostly built around C++?) did not have a concept of infinite loops that could not be removed for quite a while. Here's the Rust bug about this, which also contains links to relevant discussion on the LLVM side, including some forward progress: https://github.com/rust-lang/rust/issues/28728 https://github.com/rust-lang/rust/issues/28728. I believe the current status is that machinery has been added that language frontends can use to mark loops as having side effects, which will indicate to LLVM that they should not be optimized out.
- jfkebwjsbx 7y ago
  It is not a bug in the broken sense since it was intended. There is simply no way to create an infinite loop in LLVM IR. You could argue it is Clang generating bad LLVM IR for C mode, same as Rust. They could add something to the generated IR to make it formally finite.
Diggsey 7y ago
This is rubbish. The bug exists in LLVM regardless of whether Rust has its own fork, and you don't even need to use Rust to reproduce it. Furthermore, using your system (ie. unmodified) LLVM with Rust is supported, and still exhibits this bug.
- jfkebwjsbx 7y ago
  > This is rubbish. Please mind your manners. > The bug exists in LLVM regardless of whether Rust has its own fork, and you don't even need to use Rust to reproduce it. It is not a bug in the broken sense since it was intended. There is simply no way to create a formally infinite loop in LLVM IR. Clang in C mode (and rustc) are generating known broken LLVM IR for their semantics, Clang in C++ is fine. They could add something to the generated IR to make it formally finite in the IR instead of waiting years until LLVM IR adds something for that niche case. > Furthermore, using your system (ie. unmodified) LLVM with Rust is supported, and still exhibits this bug. That has nothing to do with what I said. The point is that if no frontend cares for such a feature, LLVM may not care about adding it. If rustc was inside the LLVM project, like Clang and others are, then it would be a "bug" of LLVM and they would have an incentive for fixing it. But given Clang does not care either in C mode, I don't have my hopes up.

nneonneo 7y ago

Ah, nomenclature fail on my part. You're right, it's LLVM. This is an LLVM bug - it affects C code too (when it should only apply to C++). If you compile this code: static void die() { while(1) ; } int main() { die(); } as a C program with optimizations, it will die with an illegal instruction too.

zzo38computer 7y ago
Perhaps it should be allow to optimize it to: int main() { while(1) pause(); } But only if system call optimizations are enabled (otherwise it can't add the call to pause()), and only if you did not specifically disable the optimization for infinite loops, and only if you do not use the -Os option.
saagarjha 7y ago
Correct, the bug is that LLVM (being mostly built around C++?) did not have a concept of infinite loops that could not be removed for quite a while. Here's the Rust bug about this, which also contains links to relevant discussion on the LLVM side, including some forward progress: https://github.com/rust-lang/rust/issues/28728 https://github.com/rust-lang/rust/issues/28728. I believe the current status is that machinery has been added that language frontends can use to mark loops as having side effects, which will indicate to LLVM that they should not be optimized out.
jfkebwjsbx 7y ago
It is not a bug in the broken sense since it was intended. There is simply no way to create an infinite loop in LLVM IR. You could argue it is Clang generating bad LLVM IR for C mode, same as Rust. They could add something to the generated IR to make it formally finite.

Diggsey 7y ago

This is rubbish. The bug exists in LLVM regardless of whether Rust has its own fork, and you don't even need to use Rust to reproduce it. Furthermore, using your system (ie. unmodified) LLVM with Rust is supported, and still exhibits this bug.

jfkebwjsbx 7y ago
> This is rubbish. Please mind your manners. > The bug exists in LLVM regardless of whether Rust has its own fork, and you don't even need to use Rust to reproduce it. It is not a bug in the broken sense since it was intended. There is simply no way to create a formally infinite loop in LLVM IR. Clang in C mode (and rustc) are generating known broken LLVM IR for their semantics, Clang in C++ is fine. They could add something to the generated IR to make it formally finite in the IR instead of waiting years until LLVM IR adds something for that niche case. > Furthermore, using your system (ie. unmodified) LLVM with Rust is supported, and still exhibits this bug. That has nothing to do with what I said. The point is that if no frontend cares for such a feature, LLVM may not care about adding it. If rustc was inside the LLVM project, like Clang and others are, then it would be a "bug" of LLVM and they would have an incentive for fixing it. But given Clang does not care either in C mode, I don't have my hopes up.