Debug vs. Release in CVF 6.6

Debug vs. Release in CVF 6.6

After compling a program using debug configuration to create a debug executable, I run a set of test problems and everthing in the set tests out perfectly compared to benchmarked solutions. I then compile using release configuration to create a release executable. Running the test set with the release version causes several of the tests to fail (numerical differences with respect to the benchmarks, some of the problems don't converge, etc.) If I add debug:full to the release configuration flags, everthing checks out fine again.

Any ideas (or suggestions to try) on why a program would run OK for debug:full but not otherwise?

publicaciones de 3 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

You can find this topic in several questions and answers in the old forum. See this one for example.

Sabalan.

This is a recurring problem in Visual Fortran, much more so than any other FORTRAN compiler I have ever used, and I've used just about all of them. Unfortunately, the developers of Visual Fortran do not appear to want to address this problem, so you are probably stuck with putting in print statements in your code in order to identify where the results first start to deviate. In other words, you have to resort to 30 year old techniques that I first used in assembly language on a PDP 11 machine for debugging your program. When this problem occurs for me, it is generally because a variable appears on the right hand side of an assignment statement before being initialized. In the debug configuration, the variable tends to take on a value of zero for reals and integers, but the value can be anything in release configuration. To make things even more frustrating, the release version may run fine on one machine and not on another. An option to initialize all variables to a default value would completely eliminate this problem, but this has been deemed "bad practice" by the developers, so you are stuck with using 30 year old debugging techniques in order to find out the source of the problem. As others have pointed out in previous posts, there are other causes of this problem, but I would check the uninitialized variable(s) first.

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya