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?
