3 ms·

Accidents happen, and LLVM is a really large complex project with tons of downstream users (like Zig and Rust) discovering issues not caught by LLVM's test suit

Accidents happen, and LLVM is a really large complex project with tons of downstream users (like Zig and Rust) discovering issues not caught by LLVM's test suite / clang. It's definitely a real problem[0][1][2][3], I would argue LLVM needs a longer release-candidate cycle before a release is cut - to give downstream users more to pick up and report regressions, as well as LLVM contributors to fix them. A higher quality bar would be great. [0] https://twitter.com/andy_kelley/status/1365186310088974336 https://twitter.com/andy_kelley/status/1365186310088974336 [1] https://twitter.com/andy_kelley/status/1303046926430908416 https://twitter.com/andy_kelley/status/1303046926430908416 [2] https://www.reddit.com/r/rust/comments/gh3thc/llvm_10_has_performance_regressions_with_rust/ https://www.reddit.com/r/rust/comments/gh3thc/llvm_10_has_pe... [3] https://www.reddit.com/r/rust/comments/n5ne5i/regression_miscompilation_due_to_bug_in_mutable/ https://www.reddit.com/r/rust/comments/n5ne5i/regression_mis...

tialaramex 5y ago
It's definitely a problem that LLVM has features which are in practice not really exercised by C++ (because the ISO C++ standard says something is Undefined Behaviour) and so clang doesn't need to use those features yet LLVM developers too often act as though only C++ matters. Rust spent a while with trivial crashes if you have an infinite loop. Here's how that happened as I understand it: From Rust's point of view infinite loops are well formed. Sure, your program never exits but that's what you told it to do, so it's your problem not Rust's. However in C++ that isn't a thing. In C++ an infinite loop is Undefined Behaviour. And so LLVM just didn't have working infinite loop code. If your C++ program has an infinite loop, too bad the ISO Standard says your program is wrong, clang is behaving as intended. Sure that's crazy but C++ programmers have a sort of Stockholm Syndrome. So LLVM had a bug, but because the most important customer of LLVM is clang, and clang didn't care about this hideous bug while its users had just become numbed to the consequences, the bug lived on for ages.
- duped 5y ago
  If we're throwing stones at LLVM features that don't work let's toss one at noalias
- pjmlp 5y ago
  Add Swift, C and Objective-C to the "customers" list that really matter.

tialaramex 5y ago

It's definitely a problem that LLVM has features which are in practice not really exercised by C++ (because the ISO C++ standard says something is Undefined Behaviour) and so clang doesn't need to use those features yet LLVM developers too often act as though only C++ matters. Rust spent a while with trivial crashes if you have an infinite loop. Here's how that happened as I understand it: From Rust's point of view infinite loops are well formed. Sure, your program never exits but that's what you told it to do, so it's your problem not Rust's. However in C++ that isn't a thing. In C++ an infinite loop is Undefined Behaviour. And so LLVM just didn't have working infinite loop code. If your C++ program has an infinite loop, too bad the ISO Standard says your program is wrong, clang is behaving as intended. Sure that's crazy but C++ programmers have a sort of Stockholm Syndrome. So LLVM had a bug, but because the most important customer of LLVM is clang, and clang didn't care about this hideous bug while its users had just become numbed to the consequences, the bug lived on for ages.

duped 5y ago
If we're throwing stones at LLVM features that don't work let's toss one at noalias
pjmlp 5y ago
Add Swift, C and Objective-C to the "customers" list that really matter.