Memory corruption with -O3, but not -O2 (and not with DMD)

[James Blachly]

On 8/20/19 4:18 AM, David Nadlinger wrote:
> Dear James,
> 
> As mentioned by kinke elsewhere, this is pretty much impossible to track 
> down from our end without more information.
> 
> Is the corruption deterministic across multiple runs of one particular 
> executable? Putting a memory watchpoint to the address that gets 
> corrupted might provide some extra clues as to where it comes from.
> 
> Having a look at the LLVM IR (-output-ll) might also be illuminating; I 
> personally find it easier to read than assembly. In particular, you 
> could use the LLVM `opt` tool to apply the -O3 passes one by one, 
> compiling to object code, linking and testing every step of the way, and 
> compare the IR before/after the pass that first introduces the crash. 
> (The `bugpoint` tool has some support for this, but you might be quicker 
> doing this manually.)
> 
> Best regards,
> David

Thank you David. We will open up the repo soon whether we get the bug 
nailed or not. The corruption has been nondeterministic which of course 
makes it all the more frustrating. I have not used the opt tool, nor had 
I considered examining the IR instead of the assembly -- thank you for that.