3 ms·

UB is a property of standard. GCC implements plenty of deviations from standard. Nothing wrong with that, as long as it's explicitly documented. I'd even argue

• deleted 3y ago
  [deleted]
• saagarjha 3y ago
  Optimizing out an empty loop in C is illegal.
  • Karellen 3y ago
    That doesn't fit with my understanding of the C abstract machine. Can you give any links that explain this further? (Or to the relevant part of the standard itself?)
    • dzaima 3y ago
      N1570, 6.8.5, point 6 under "Semantics": An iteration statement whose controlling expression is not a constant expression,156) that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression-3, may be assumed by the implementation to terminate. Namely, the "not a constant expression" restriction is important here. So an empty loop with a non-constant end test can be assumed to terminate, but a constant one (e.g. while(1){} or for(;;); ) cannot. Note that the rules in C++ on this are different, and do allow even a constant-end-condition empty loop to be assumed to terminate.
      • tialaramex 3y ago
        Further bonus notes, the C++ behaviour is sufficiently controversial and disliked that there is a C++ 26 proposal to "fix" it: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2809r1.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p28... And, Rust's only actual loop is an infinite loop. Rust's "loop" syntax is an infinite loop, and both "for" and "while" in Rust are just syntax sugar which the documentation explains how to transform your "for" or "while" into the exact same "loop" that it's going to emit when you do that - they're not merely "equivalent" that's how it really works via a process called "de-sugaring". Interestingly "loop" is categorically more powerful than "for" or "while" because it has a type, the type of a "for" or "while" is always the unit type, but the type of a "loop" can be anything, for example maybe the loop finds a Goose, and the value of your loop is a Goose, this means to exit the loop we need a Goose and we can't leave the loop without one. Because of the C++ misfeature, Rust has sometimes run into problems where LLVM is like "Oh, that's an infinite loop, I'll just ignore it" but LLVM is not a C++ compiler. Clang is a C++ compiler so Clang is allowed to obey C++ rules, but LLVM is not, it's supposed to provide an actual infinite loop, for both C and Rust to use.
        • gpderetta 3y ago
          I understand thal LLVM implements the C++11 memory model, which specifies the termination requirements for non-side effects loops.
          • tialaramex 3y ago
            It's true that C++ specifies this as part of its forward progress guarantees and that's likely how it infected LLVM, but I'd deny that LLVM's rather sparse documentation of their IR lowering says basically "Ooops, we actually are only suitable as the core of a C++ compiler" was part of their intent, especially since LLVM substantially pre-dates Clang... Lattner started work on Clang in 2006, but LLVM is from 2000.. And sure enough when the Rust project finds bugs in LLVM related to this, there is no "Oh you can't have the semantics we documented, we actually provide exactly whatever C++ says instead for some reason". Sometimes it's a doc bug but most often the problem is that as usual the optimisation passes assumed something that's just not true outside of C++.
  • vbezhenar 3y ago
    https://godbolt.org/z/Ke7MvoEb9 https://godbolt.org/z/Ke7MvoEb9 clang does that
    • dzaima 3y ago
      That's C++, which is not C. Granted, the C++ behavior is weird and annoying. (the C behavior, while better for truly-infinite loops, is still "broken" for potentially-not-but-still-possibly-infinite loops, though such should be less common)
      • vbezhenar 3y ago
        Huh, didn't think about it, thanks.