- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm using Visual Studio 2005 with Composer XE 12.1.3.300 (IA32) under WinXP32. When I run a debug session on a debug build, I notice that array values shown in datatips and the watch and memory windows are wrong. In previous versions of Composer, I did not see this error, so I am wondering if this is a known bug, or whether I have set up something wrong.
For a 1-D array, the array values are correct, and the variable name in the memory window shows the address of the array. But for a 2-D array, the datatip or watch window values are wrong (they are another variable's values), and the variable name in the memory window shows the same incorrect values (not the address, or the array descriptor).
The 2-D array is declared as REAL(8), DIMENSION(0:10001,28).
For a 1-D array, the array values are correct, and the variable name in the memory window shows the address of the array. But for a 2-D array, the datatip or watch window values are wrong (they are another variable's values), and the variable name in the memory window shows the same incorrect values (not the address, or the array descriptor).
The 2-D array is declared as REAL(8), DIMENSION(0:10001,28).
Link Copied
9 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have not seen this reported before - can you provide a small test case?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Working on it. The app is huge, so it will take a while.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, I have a test case. I think there is an interaction between the OMP preprocessor and XE.
Build the attached subroutine and call it, setting breakpoints and examining the arrays CpShared (1-D, OK) and CmTentative (2-D, wrong).
BTW, the purpose of this chicanery is to avoid allocating the private variables in the parallel loop, which dominates the parallel run time, due to the inefficiency of chkstk (but that's another discussion).
Build the attached subroutine and call it, setting breakpoints and examining the arrays CpShared (1-D, OK) and CmTentative (2-D, wrong).
BTW, the purpose of this chicanery is to avoid allocating the private variables in the parallel loop, which dominates the parallel run time, due to the inefficiency of chkstk (but that's another discussion).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is the build line I used:
Compiling with Intel Visual Fortran Compiler XE 12.1.3.300 [IA-32]...
ifort /nologo /debug:full /Od /Ot /Qparallel /fpp /IC:\Non-linear eqn solvers\nleqslv\Win32\Debug /DFortranBuild /DDebugLines /free /noaltparam /Qopenmp /fpscomp:nolibs /stand:f03 /warn:all /debug-parameters:all /Qauto /Qtrapuv /fpe:0 /fpconstant /Qfp-stack-check /iface:mixed_str_len_arg /module:Debug/ /object:Debug/ /FAcs /FaDebug/ /traceback /check:pointer /check:bounds /check:uninit /check:format /check:output_conversion /libs:static /threads /dbglibs /winapp /c /Qopenmp-link:static /Qvc8 /Qlocation,link,C:\Program Files\Microsoft Visual Studio 8\VC\\bin C:\ClavSim array bug.f90
ifort: command line remark #10010: option '/Qopenmp-link:static' is deprecated and will be removed in a future release. See '/help deprecated'
Compiling with Intel Visual Fortran Compiler XE 12.1.3.300 [IA-32]...
ifort /nologo /debug:full /Od /Ot /Qparallel /fpp /IC:\Non-linear eqn solvers\nleqslv\Win32\Debug /DFortranBuild /DDebugLines /free /noaltparam /Qopenmp /fpscomp:nolibs /stand:f03 /warn:all /debug-parameters:all /Qauto /Qtrapuv /fpe:0 /fpconstant /Qfp-stack-check /iface:mixed_str_len_arg /module:Debug/ /object:Debug/ /FAcs /FaDebug/ /traceback /check:pointer /check:bounds /check:uninit /check:format /check:output_conversion /libs:static /threads /dbglibs /winapp /c /Qopenmp-link:static /Qvc8 /Qlocation,link,C:\Program Files\Microsoft Visual Studio 8\VC\\bin C:\ClavSim array bug.f90
ifort: command line remark #10010: option '/Qopenmp-link:static' is deprecated and will be removed in a future release. See '/help deprecated'
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve -
Not only does the VS2005 debugger report the wrong value for the 2D array, it reports incorrect values for some of the other shared arrays and scalars as well.
It is as if the table of variable addresses has been corrupted.
This makes it almost impossible to use the debugger when OpenMP is being used.
Not only does the VS2005 debugger report the wrong value for the 2D array, it reports incorrect values for some of the other shared arrays and scalars as well.
It is as if the table of variable addresses has been corrupted.
This makes it almost impossible to use the debugger when OpenMP is being used.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, will take a look. I am not sure how much we can do here, as a lot of the debugger variable access is dependent on Visual Studio's implementation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have the Parallel Studio 2013 beta and VS2012 RC, and I could switch to that, except that Composer 20132 beta has a bug that doesn't allow the debugger to be used with Fortran.
I could conceivably use VS2010, although it is pretty slow (not your fault, of course).
Maybe there is some workaround using VS2005, something such as the order in which variables are declared, or where the OpenMP parallel constructs are located?
I could conceivably use VS2010, although it is pretty slow (not your fault, of course).
Maybe there is some workaround using VS2005, something such as the order in which variables are declared, or where the OpenMP parallel constructs are located?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can reproduce this in VS2005, 2008 and 2010. I'm not sure how much support VS has for this sort of thing, but I will show it to the developers and let them advise me.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After some more experimentation, I believe that it is not just that the debugger is showing wrong values; the code uses the wrong values. If this is so, it isn't just a VS issue.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page