On Thursday, 16 October 2014 at 10:25:12 UTC, Peter Alexander
wrote:
On Thursday, 16 October 2014 at 08:45:18 UTC, Chris wrote:
I think there is no easy way of finding out where the
optimization goes wrong. But should this happen at all, i.e.
does it point to a flaw in my program or is it a compiler bug?
I like to think it's the latter, after all the program works
perfectly without -O. On the other hand, it's scary because I
have no clue where to look for the offender.
It could be either.
Sometimes, if you program relies on undefined behaviour,
enabling optimizations might be what uncovers the bug, and
manifest as a crash.
On the other hand, it could be just a compiler bug. It has
happened several times to me with DMD, so it's not entirely
unlikely. These things happen.
Run Dustmite, reduce, and if you still think you're program is
right, file a bug against DMD.
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.
