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.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
