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

[Daniel Murphy via Digitalmars-d]

"Lumi Pakkanen"  wrote in message 
news:choqmgtkydoxleapeyhw at forum.dlang.org...

> I'm creating a somewhat large hobby project with D. I'm enjoying the ride 
> so far. Unit tests and contract programming have saved me from long bug 
> hunts, but today I ran into a bug that seems to be caused by the -O 
> and -inline flags with dmd.
>
> Without the flags the program runs correctly, but -O produces wrong 
> results consistently and -inline seems to cause memory corruption.
>
> Now my problem here is that the program has over 5000 lines of code with 
> interdependencies running everywhere so I'm not sure if it's possible to 
> come up with a neat small program that demonstrates the problem for a bug 
> report.
>
> What should I do? Am I stuck with not using -O and -inline for now, hoping 
> that things will improve in the future?

There are a few techniques to try and track this sort of thing down.

0. Build dmd from the lastest master and see if it works (if you haven't 
done this already).  The bug may have been fixed.

1. As others have suggested, run dustime on your code.  It's magical.

2. Do a binary search, compiling with some modules not using -inline (or 
instead with -O).  Then, do the same with functions within the module, 
moving them to another module (or using d/di split) to prevent inlining. 
When the caller function is found, disable inlining of the potential 
problematic callees by adding asm { nop; } or similar to their body.

3. Spend some quality time with a debugger and a disassembler, tracing back 
from the fault to find out where it all went wrong.  This becomes more 
difficult, but still possible if the call stack is corrupted.  This could be 
the fastest or the slowest method depending on your luck.  Usual debugging 
tools like valgrind may be a huge help.

4. Switching word size (-m32/-m64) may make the problem go away, if that's 
an option for your project.