Consistent bugs with dmd -O -inline in a large project
Chris via Digitalmars-d
digitalmars-d at puremagic.com
Thu Oct 16 04:54:08 PDT 2014
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.
More information about the Digitalmars-d
mailing list