VS reporting incorrect values while debugging

[Rob1]

I recently upgraded from composer 2011 to 2013.

If i set a break point (in VS 2008), the value of variables are incorrect in the watch window or when i hover over them with the mouse.

For example:

<!--break-->

...

variable_real8 = 0.D0

write(*,*) variable_real8

...

<!--break-->

If my break point is immediately after the write statement, the value of "variable_real8" according to VS is 1.230248560226257D+237, whereas the correct value (0.000000000000000E+000) is written to the command window.

The debugger was working properly as far as i know in 2011.  Is there a setting somewhere that would affect this?  I currently have optimization disabled (/0d), debug is full, etc.

thanks,

rob

[Steven_L_Intel1]

I've seen a previous report of this, but no test case was provided. Can you offer a short (if possible) test program that reproduces the problem?

[ZlamalJakub]

I have created an example where error occurs for me. It is taken from my application. Error occurs on line 168 of code (put breakpoint there) after execution of chisqlin=ochisq chisqlin is unchanged in Locals window.

[Rob1]

i have tried uploading my project 3 times. the first 2 times i got a blue screen mid upload, the third time your website said something like "upload failed, likely the file is larger than 250MB" even though it is less than 250MB.

[Steven_L_Intel1]

Please do a Build > Clean, re-ZIP it and try again. If you got a blue-screen error, then you have something wrong with your PC.

[andi_zuend]

Hi Rob and Steve, I have experienced similar issues (for certain projects only) with the latest composer (Intel(R) Visual Fortran Compiler XE 13.0.0.089) and MS Visual Studio 2010 on Windows 7. Using Intel(R) Visual Fortran Compiler XE 12.1.5.344 in the same setup (VS 2010), variable values on mouse-over and watch window at breakpoints are shown correctly in debug mode, while using the Fortran Compiler XE 13.0.0.089 (after clean re-build of code with the same compiler options) leads to some kind of shift in reported values on mouse-over at breakpoints, sometimes showing 'random' unitialized values and sometimes values that supposedly belong to another variable in the code. One observation I made is that the issue occurs only for project where I use OpenMP threaded code execution and recursive routines. Particularly, I have the suspicion that the command line switches "/recursive" and "/Qopenmp" to enable recursive routines and OpenMP compilation seem to be part of these debugger issues (at least this is the case for a rather large Fortran project, where disabling the recursive switch and disabling OpenMP compilation leads to correct debugger behavior on breakpoints). I recall there have been some changes with regard to the Intel Parallel Debugger from the compiler generation 12.1 to 13.0, so this may be related. Hope this issues get resolved soon, for now I rely on the older compiler for debugging the affected projects. Andi

[garyrwaters5428]

Good day,

I've seen this problem with Intel(R) Visual Fortran Composer XE 2011 Integration for Microsoft Visual Studio* 2010, 12.0.3471.2010, Copyright (C) 2002-2011 Intel Corporation
* Other names and brands may be claimed as the property of others.

My experience is that it happens in large subroutines with a lot of local variables.  (The subroutine I'm struggling with at the moment is about 2500 executable lines with about 200 lines of declared local variables, several of which are arrays.)  I've not noticed any problems with small subroutines.  The program with which I am working is a heritage Fortran (pre-77) program, so the compiler option to save all local variables is required.  When another subroutine (usually short) is called with a variable that displays incorrectly in the large subroutine, the variable displays correctly in the called subroutine, but not upon returning to the large subroutine.  Today it is occuring at least for real, logical, and derived types, but I think I've seen it for integer types in the past.

-gary

[Steven_L_Intel1]

If you can reproduce the problem with the 15.0 compiler, please provide a buildable and runnable test case and we'll be glad to take a look. You can use Intel Premier Support to submit the problem if you don't want to do it here.