Consistent bugs with dmd -O -inline in a large project

[Chris via Digitalmars-d]

On Thursday, 16 October 2014 at 13:35:57 UTC, Chris wrote:
> On Thursday, 16 October 2014 at 11:54:09 UTC, Chris wrote:
>>
>> Ok, I've found the flaw in my program. It's code that was left 
>> over after refactoring some modules. It looks like this 
>> (simplified):
>>
>> I import a module and access an enum in that module. However, 
>> I never use the accessed element
>>
>> module politician.answer;
>>
>> enum { Statement = "Blah" }
>>
>> mixin template PressConference {
>>  int STATEMENT_LEN;
>>  // ...
>> }
>>
>> -------------
>>
>> module press.article;
>>
>> mixin PressConference;
>> this() {
>>  STATEMENT_LEN = Statement.length;  // Not good! Left over 
>> code from refactoring.
>> }
>>
>> Even worse, I never use STATEMENT_LEN in this class. The whole 
>> logic is non-sense and is due to my not cleaning up the 
>> constructor.
>>
>> So the optimizer optimized this away, seeing that it is never 
>> used, but it is still accessed in the class constructor.
>>
>> My question now is, shouldn't the optimizer have noticed that 
>> it is still being accessed? Or what did the optimizer actually 
>> do.
>>
>> This helped me to find "dead code" at least.
>
> Update on the above. I actually do use the variable 
> STATEMENT_LEN later in the mixed in code. This escapes the 
> optimizer.
>
> mixin template PressConference {
>   int STATEMENT_LEN;
>   // ...
>   void someFunction() {
>     // uses STATEMENT_LEN
>   }
> }
>
> Hm.

If I compile with

-release -noboundscheck -inline

(but without -O), I get this error:

Internal error: backend\cod4.c 358

If I compile with

-O -release -noboundscheck -inline

It compiles, but crashes.

The only thing that works is:

-release -noboundscheck

What is the optimizer optimizing away?