7 ms·

> Loops that Neither Perform I/O nor Terminate > Summary: This UB is probably not a problem in practice (even if it is moderately displeasing to some of us).

> Loops that Neither Perform I/O nor Terminate > Summary: This UB is probably not a problem in practice (even if it is moderately displeasing to some of us). Since LLVM is mostly based around C/C++ semantics this actually turned out to be a problem for rust, because rust can encode diverging functions in its type system and assume certain code sections to be unreachable. If the compiler then optimizes out code and the unreachable (thus not-compiled) section is reached things explode. https://github.com/rust-lang/rust/issues/28728 https://github.com/rust-lang/rust/issues/28728

userbinator 9y ago
I think that's a great example of how optimisers have gone off the deep end: no reasonable human programmer would think "I can't figure out if this loop terminates, so let's just leave it out", but that appears to be the default behaviour in this case --- when what should happen when the optimiser "gives up" is that it should just translate the code verbatim.
- deleted 9y ago
  [deleted]
- adrianN 9y ago
  But the optimizer doesn't give up in this case. It successfully figures out that the loop has no side effect except heating up your processor and eliminates it.
  - iainmerrick 9y ago
    What's the advantage of eliminating the loop? If the compiler is able to do that analysis, why not flag the endless spin loop as a compilation error?
    - kazagistar 9y ago
      Loop is inside a function, that can have no side effect conditionally. Function is used in multiple places and inlined. With inlined context, compiler can eliminate loop sometimes.
      - deleted 9y ago
        [deleted]
    - flamedoge 9y ago
      effectively a no-op... isn't code after inf-loop also removed as it is considered unreachable?
- caf 9y ago
  N1528: Why undefined behavior for infinite loops? (Boehm) http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm
mnarayan01 9y ago
At least according to https://github.com/rust-lang/rust/issues/28728#issuecomment-263742266 https://github.com/rust-lang/rust/issues/28728#issuecomment-... this is a more general issue with clang/llvm -- even e.g. `while(1);` in C is being optimized out.

userbinator 9y ago

I think that's a great example of how optimisers have gone off the deep end: no reasonable human programmer would think "I can't figure out if this loop terminates, so let's just leave it out", but that appears to be the default behaviour in this case --- when what should happen when the optimiser "gives up" is that it should just translate the code verbatim.

deleted 9y ago
[deleted]
adrianN 9y ago
But the optimizer doesn't give up in this case. It successfully figures out that the loop has no side effect except heating up your processor and eliminates it.
- iainmerrick 9y ago
  What's the advantage of eliminating the loop? If the compiler is able to do that analysis, why not flag the endless spin loop as a compilation error?
  - kazagistar 9y ago
    Loop is inside a function, that can have no side effect conditionally. Function is used in multiple places and inlined. With inlined context, compiler can eliminate loop sometimes.
    - deleted 9y ago
      [deleted]
  - flamedoge 9y ago
    effectively a no-op... isn't code after inf-loop also removed as it is considered unreachable?
caf 9y ago
N1528: Why undefined behavior for infinite loops? (Boehm) http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm

mnarayan01 9y ago

At least according to https://github.com/rust-lang/rust/issues/28728#issuecomment-263742266 https://github.com/rust-lang/rust/issues/28728#issuecomment-... this is a more general issue with clang/llvm -- even e.g. `while(1);` in C is being optimized out.