Adding WRITE statement causes code to execute differently

[NotThatItMatters]

I have an application which demonstrates a bug.  I "uncommented" a specific debug line, recompiled the application and ran it.  The bug mysteriously disappears.  I have at my disposal Intel Inspector and Intel VTune Amplifier.  For what sort of bug should I be looking?  Will any tools help?

[TimP]

The usual suspects; incompletely initialized data, array over-runs, and, since you're using Inspector, data race (e.g. problems with private/shared).

comparing what comes out in opt-report-file may give a clue about changes in optimization which could be associated with the bug.

[Steven_L_Intel1]

Adding a WRITE often changes code generator choices about what data lives where (memory, registers, etc.) It can also interfere with vectorization. You may have to get creative in your analysis. Tim's suggestions are good, though I expect that you won't find the optimization reports helpful here. Is this in a Release or Debug configuration?

[NotThatItMatters]

This is in a Release configuration.  I am currently noting that, in Debug configuration, without the debug WRITE statement the code craters in a similar manner to the release configuration.  Is this "helpful"?

[Steven_L_Intel1]

Well, it means you can debug it, so that should be helpful to you toi find out what is going wrong.

[lklawrie]

FYI, there was a similar case earlier this year that was a compiler error: Issue 698745, I believe.  It was hard to reproduce but Steve finally did and it is being worked on.  In the meantime, we rewrote code to workaround the problem.

[NotThatItMatters]

Thanks everyone.  I did a lot of hammering through the code and found two errors. The first one was the use of an array in a SUBROUTINE which extended the size of the original array but did not walk beyond bounds in the extended index.  The elimination of this bug just meant that the commented WRITE statement and the uncommented WRITE statement caused the code to run the same (poorly).  The second bug involved the lack of proper initialization of a variable.  This was the real bug, but it was the first which caused the unique behavior.