On Sat, Sep 7, 2013 at 4:42 PM, Daniel Micay <[email protected]> wrote:
> On Sat, Sep 7, 2013 at 4:37 PM, Geoffrey Irving <[email protected]> wrote: > >> >> On Sep 7, 2013, at 1:32 PM, Daniel Micay <[email protected]> wrote: >> >> > On Sat, Sep 7, 2013 at 4:27 PM, Geoffrey Irving <[email protected]> wrote: >> > To clarify why undefined behavior is really bad in practice: if LLVM >> ever detects that your code performs undefined behavior according to the >> standard, it is *designed* to take full advantage of that fact when making >> optimizations. In other words, all hell will break lose, in potentially >> very complicated and subtle ways. >> > >> > Geoffrey >> > >> > Note that there's no detection of undefined behaviour or optimizations >> based upon it being detected. LLVM simply operates on valid LLVM bytecode, >> and if it performs undefined behaviour it is not valid LLVM bytecode. The >> optimization passes and code generation will base all of their assumptions >> on the invariants provided by the specification, including that null >> pointers are never dereferenced. >> >> That may be true; I got the opposite impression from this article: >> >> >> http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html >> >> Geoffrey >> > > You're getting a very wrong impression if you think it optimizes based on > those assumptions only when it can detect undefined behaviour. It > completely ignores the possibility of undefined behaviour in the > optimization passes by assuming all of the invariants required for the > bytecode to be valid hold true. > > The `-fcatch-undefined-behaviour` switch inserts runtime checks. > Note that `clang` generating traps on certain operations left undefined by C to aid in debugging is unrelated to Rust, because we don't compile to C and then compile with `clang`. There are no exceptions to the undefined behaviour rules for us.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
