- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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).
コピーされたリンク
9 返答(返信)
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
I have not seen this reported before - can you provide a small test case?
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
Working on it. The app is huge, so it will take a while.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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).
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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'
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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?
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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.
- 新着としてマーク
- ブックマーク
- 購読
- ミュート
- RSS フィードを購読する
- ハイライト
- 印刷
- 不適切なコンテンツを報告
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.
