assume, assert, enforce, @safe

[via Digitalmars-d]

On Thursday, 31 July 2014 at 22:21:46 UTC, Daniel Gibson wrote:
> Am 31.07.2014 23:59, schrieb Walter Bright:
>> On 7/31/2014 10:40 AM, Daniel Gibson wrote:
>>> It's a major PITA to debug problems that only happen in 
>>> release builds.
>>
>> Debugging optimized code was a well known problem even back in 
>> the 70's.
>> Nobody has solved it, and nobody wants unoptimized code.
>>
>
> Yeah, and because of this I'd like optimizations not to cause 
> different behavior if at all possible to keep these kind of 
> bugs as low as possible.
>
> And I agree with your stance on those fine-grained optimization 
> switches from your other post. GCC currently has 191 flags the 
> influence optimization[1] (+ a version that negates them for 
> most), and I don't understand what most of them do, so it would 
> be hard for me to decide which optimizations I want and which I 
> don't want.
>
> However, what about an extra flag for "unsafe" optimizations?
> I'd like the compiler to do inlining, replacing int 
> multiplications with powers of two with shifts and other "safe" 
> optimizations that don't change the semantics of my program 
> (see the examples in the post you quoted), but I *don't* want 
> it to e.g. remove writes to memory that isn't read afterwards 
> or make assumptions based on assertions (that are disabled in 
> the current compile mode).
>
> And maybe a warning mode that tells me about 
> "dead"/"superfluous" code that would be eliminated in an 
> optimized build so I can check if that would break anything for 
> me in that respect without trying to understand the asm output 
> would be helpful.
>

A compiler is a program that turns code in one programming 
language to equivalent machine code, according to a language 
specification. There are obviously many different equivalent 
machine code programs corresponding to any sufficiently complex 
higher-level program. Classifying them into optimized and 
unoptimized ones is rather arbitrary. The same goes for safe vs. 
unsafe optimizations.

To achieve what you want, the compiler would have to ignore the 
actual language specification and use a different one that is 
tweaked according to your criteria. I don't think this is 
desirable. If the official language specification has parts that 
can lead to the errors you want to avoid, then it's not the 
compiler's fault, and therefore the compiler should not be 
changed to workaround it. Instead, deficiencies in the 
specification should be fixed there.