5 ms·

> It should catch the issue and exit cleanly with an error message. IIRC LLVM's IR verification is not enabled in release build. In other words, if you're usin

> It should catch the issue and exit cleanly with an error message. IIRC LLVM's IR verification is not enabled in release build. In other words, if you're using rustc with debug version of LLVM the error message should pop up. EDIT: "...LLVM's IR verification is not enabled in release build..." this is wrong, LLVM doesn't turn off verification based on its build mode. It is up to the user of LLVM, namely rustc in this case, to enable verification. For instance, you can verify IR after each optimization Pass (which is pretty expensive) by configuring `llvm::StandardInstrumentation` properly. Or you can verify the IR before codegen by switching up one of `llvm::TargetMachine`'s options. Clang always enables the latter (verification) by default but disables the former regardless of the optimization level or its build mode.

rob74 5y ago
...and it's probably not enabled because the Rust compiler is already slow enough as it is? But yeah, I guess it's a fair trade-off having 0.0001% of builds crash if it makes the other 99.9999% a bit faster...
EE84M3i 5y ago
In either case dereferencing a null pointer would still be a bug, right? Or is it kind of "all bets are off" if you feed LLVM bad IR and don't enable verification?
- comex 5y ago
  It is.
  - eyelidlessness 5y ago
    Terse affirmative is ambiguous.
    - nlewycky 5y ago
      If you feed LLVM bad IR, all bets are off. LLVM's assertions and IR verifier are impressively comprehensive, but not a guarantee. For example, LLVM has a pointer type and a void type, but you may not make a pointer-to-void type, see https://llvm.org/docs/LangRef.html#pointer-type https://llvm.org/docs/LangRef.html#pointer-type . If you do call `Type::getVoidTy(C)->getPointerTo()` then LLVM will hit an assertion only in a build with assertions enabled. Without assertions LLVM may silently execute UB.
    - akimball 5y ago
      As are all tautologies;)
- theresistor 5y ago
  LLVM makes use of assertions to validate things like this, but many users of LLVM, including rustc, turn them off for performance reasons.
- mshockwave 5y ago
  LLVM makes trade off on enabling/disabling certain checks, including assertions and IR verification, primarily to keep compilation time acceptable in release build. The idea is that we catch as many bugs as possible in debug version of LLVM such that release version can run fast.
- tedunangst 5y ago
  If you call free((void *)-1) in C code, it will very likely crash, but it will crash in libc, not your program. Is that a bug in libc?
  - Thorrez 5y ago
    That's documented undefined behavior. Is it documented undefined behavior to feed bad IR into LLVM?
    - scatters 5y ago
      Of course. If there's an input checking mode, and you disable the checks, then you're guaranteeing that you won't supply invalid input.
  - MaxBarraclough 5y ago
    I think even deriving the argument might invoke undefined behaviour here, but I'm not certain. If I understand correctly, it's undefined behaviour to do this: int *ptr = (int*)42; As, in order to avoid undefined behaviour, ptr should only be assigned a valid address of an int, or the 'address' one past the end of an array of int, or NULL (logical zero). It's possible things are different when the type is void*, I'm not certain.
    - tedunangst 5y ago
      Make it free(free) if you want it to be a valid pointer.
  - kelnos 4y ago
    No, because the defined contract for free() is that you pass it a pointer that was previously returned from malloc(), that you don't try to free() it twice, etc.
est31 5y ago
The rust compiler has an option to enable llvm assertions, but it needs to be set at compile time (of the compiler) in config.toml: https://github.com/rust-lang/rust/blob/1f7fb6413d6d6c0c929b223e478e44c3db991b03/config.toml.example#L69 https://github.com/rust-lang/rust/blob/1f7fb6413d6d6c0c929b2... I don't know how these checks compare to what clang is doing.
- mshockwave 5y ago
  the root cause of the original problem is caused by invalid IR, which can be caught by IR verification -- which is actually different from assertion.
  - jackosdev 5y ago
    So would something like miri have caught this if it was in their CI?

rob74 5y ago

...and it's probably not enabled because the Rust compiler is already slow enough as it is? But yeah, I guess it's a fair trade-off having 0.0001% of builds crash if it makes the other 99.9999% a bit faster...

EE84M3i 5y ago

In either case dereferencing a null pointer would still be a bug, right? Or is it kind of "all bets are off" if you feed LLVM bad IR and don't enable verification?

comex 5y ago
It is.
- eyelidlessness 5y ago
  Terse affirmative is ambiguous.
  - nlewycky 5y ago
    If you feed LLVM bad IR, all bets are off. LLVM's assertions and IR verifier are impressively comprehensive, but not a guarantee. For example, LLVM has a pointer type and a void type, but you may not make a pointer-to-void type, see https://llvm.org/docs/LangRef.html#pointer-type https://llvm.org/docs/LangRef.html#pointer-type . If you do call `Type::getVoidTy(C)->getPointerTo()` then LLVM will hit an assertion only in a build with assertions enabled. Without assertions LLVM may silently execute UB.
  - akimball 5y ago
    As are all tautologies;)
theresistor 5y ago
LLVM makes use of assertions to validate things like this, but many users of LLVM, including rustc, turn them off for performance reasons.
mshockwave 5y ago
LLVM makes trade off on enabling/disabling certain checks, including assertions and IR verification, primarily to keep compilation time acceptable in release build. The idea is that we catch as many bugs as possible in debug version of LLVM such that release version can run fast.
tedunangst 5y ago
If you call free((void *)-1) in C code, it will very likely crash, but it will crash in libc, not your program. Is that a bug in libc?
- Thorrez 5y ago
  That's documented undefined behavior. Is it documented undefined behavior to feed bad IR into LLVM?
  - scatters 5y ago
    Of course. If there's an input checking mode, and you disable the checks, then you're guaranteeing that you won't supply invalid input.
- MaxBarraclough 5y ago
  I think even deriving the argument might invoke undefined behaviour here, but I'm not certain. If I understand correctly, it's undefined behaviour to do this: int *ptr = (int*)42; As, in order to avoid undefined behaviour, ptr should only be assigned a valid address of an int, or the 'address' one past the end of an array of int, or NULL (logical zero). It's possible things are different when the type is void*, I'm not certain.
  - tedunangst 5y ago
    Make it free(free) if you want it to be a valid pointer.
- kelnos 4y ago
  No, because the defined contract for free() is that you pass it a pointer that was previously returned from malloc(), that you don't try to free() it twice, etc.

est31 5y ago

The rust compiler has an option to enable llvm assertions, but it needs to be set at compile time (of the compiler) in config.toml: https://github.com/rust-lang/rust/blob/1f7fb6413d6d6c0c929b223e478e44c3db991b03/config.toml.example#L69 https://github.com/rust-lang/rust/blob/1f7fb6413d6d6c0c929b2... I don't know how these checks compare to what clang is doing.

mshockwave 5y ago
the root cause of the original problem is caused by invalid IR, which can be caught by IR verification -- which is actually different from assertion.
- jackosdev 5y ago
  So would something like miri have caught this if it was in their CI?