Different behavior between debug and release configurations

Different behavior between debug and release configurations

Hi,

I noticed that my project behaves differently if I compile it with default debug settings compared to when using release settings.

In debug it works; in release the calculations differ slightly and lead to a failure in one of the checks of my program (it's a program for engineering calculations, more specifically process simulation).

After trying to level the differences between the two configurations on the aspect of how floating point calculations are carried out (I thought the problem could lie in optimizations or floating point speculation), I have simply solved the problem by compiling in release using the /Zi option (Debug Information Format).

The question is...why?? What's the role of debug information in the calculation of floating point operations?!

Thanks in advance.

7 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

Forgot to add, using VS 2008 Pro with IVF10.

Forgot to add: VS 2008 Pro + IVF 10

don't believe you need to 'debug information'. Simply compile w/o all optimizations OFF /Od. if that fixes the difference then you need to see where you might have tests or cacluations that fail when optimized.

It is quite likely that you have one or more bugs in your program (such as using variables before they have been assigned values). When your program gives markedly different results when compiler options are changed, that is often a symptom of bugs. Sometimes, such bugs can stay well-hidden, and appear when least expected. Another, but extremely rare, case is caused by errors in the optimizer phase of the compiler.

Zitat:

mecej4 schrieb:

It is quite likely that you have one or more bugs in your program (such as using variables before they have been assigned values). When your program gives markedly different results when compiler options are changed, that is often a symptom of bugs. Sometimes, such bugs can stay well-hidden, and appear when least expected. Another, but extremely rare, case is caused by errors in the optimizer phase of the compiler.

Very likely, as this program is tens of years old and was written by people that aren't real programmers, and...it's written in a horrible language (F77) which doesn't warn for such mistakes (and many more), making programming in big projects a pain.

If noone else comes up with a better explanation, I'll just be content with my fix and I'll live with the doubt, even though it would be cool to find the cause. I just wish there were a static analyzer like Clang's for C++...

Zitat:

Andrea B schrieb:
I just wish there were a static analyzer
Intel® Fortran Studio XE 2013 comes with a static analysis tool. There are a number of third-party tools, as well. For Fortran-77 there is Moniot's Ftnchek. Other analysis tools are PlusFort and Forcheck.

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen