Article on overzealous compiler optimizations

[Timon Gehr via Digitalmars-d]

On 06/21/2014 12:20 AM, Walter Bright wrote:
> http://developers.slashdot.org/story/14/06/20/1824226/overeager-compilers-can-open-security-holes-in-your-code
>
>
> This is an opportunity for D to define the spec in such away as to
> preclude the bad optimizations while keeping the good ones. Any ideas?

A possibility is to have no undefined behaviour in standard language 
features and to add unsafe intrinsics for the cases where the optimizer 
_actually_ needs the help for generating fast enough code for a hot 
spot. (Of course, a type system that is able to preclude more of the bad 
behaviours in the first place can help too.)

E.g.

int foo(Foo* foo)@safe{
     return foo.bar; // defined behaviour in all cases
}

int bar(Foo* foo)@system{
     return __assume_non_null(foo).bar; // undefined behaviour if foo is 
null
}