openmp_sample.f90

LRaim · ‎05-03-2017

For a better understanding of debugging parallel segments of an application I have generated the 'openmp_samples'
Running with: Microsoft Visual Studio Professional 2015 Version 14.0.25420.01 Update 3
and
Intel® Parallel Studio XE 2016 Update 4 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio* 2015, Version 16.0.0063.14,

Executing the application in debugging mode some variables are not visible. For example using QuickWatch fortran variables 'start' and 'end' are 'undefined variables'.

Kevin_D_Intel · ‎05-03-2017

I cannot reproduce what you are describing except for the Release configuration. I built (using the 16.0.4.246 compiler) the Debug configuration for both Win32/x64 and placing a break at the PRINT as shown, Start and End are both accessible under QuickWatch and Watch. For the Release configuration the inaccessibility relates to the compiler optimizations of those. You'd need to watch/access their values via the associated memory or registers when debugging optimized code.

LRaim · ‎05-03-2017

Kevin,
I assume that the problem has been fixed in a subsequent release.
Without creating another post, I have a couple of questions about parallel do.
1) is it possible to attach the debugger to one of the threads created at run-time ? Is any document available ?
2) are run time data available, after completion of the parallel do ? E.g. the number of threads used by parallel do and the number of iterations executed by each thread ?

Best regards

jimdempseyatthecove · ‎05-03-2017

For 1, you would have to assure the execuitable contains the debug information. You would start the VS debugger, then use the Attach to Process feature, and then Pause the application. If the symbols are found then you may be able to insert a break point within a running program. However, if the Fortran portion of the code is in a DLL that the application uses, then sometimes there is an issue in locating the symbols. For problematic situations, I end up starting the application with the debugger, making a trivial call (step into) to the DLL such that the symbols load, then l let the program Continue. If problem (hang) occurs, then Pause to figure out what happened.

For 2, you'd have to instrument your program

integer, allocatable :: ThreadIterationCounts(:)
...
allocate(ThreadIterationCounts(0:omp_get_max_threads()-1))

!$omp parallel
nthr = omp_get_thread_num()
ThreadIterationCounts(nthr) = 0
!$omp DO ...
  ThreadIterationCounts(nthr) = ThreadIterationCounts(nthr) + 1
  ...
!$omp end DO
!$omp end parallel
print *, ThreadIterationCounts

Jim Dempsey

LRaim · ‎05-16-2017

Luigi R. wrote:

Kevin,
I assume that the problem has been fixed in a subsequent release.
Without creating another post, I have a couple of questions about parallel do.
1) is it possible to attach the debugger to one of the threads created at run-time ? Is any document available ?
2) are run time data available, after completion of the parallel do ? E.g. the number of threads used by parallel do and the number of iterations executed by each thread ?

Best regards
======================================================
Sorry for the delay about this subject, since I have opened question 1 with 'premier support'.
From their answers I get that it is not possible to debug parallel threads generated by OMP in Visual Studio.
This is quite surprising and disappointing since compiler parallelization is a feature so much advertised.
Has Intel any plan about this capability ?

jimdempseyatthecove · ‎05-16-2017

Luigi,

Maybe this is a case of difference in interpretation of your request:

>>1) is it possible to attach the debugger to one of the threads created at run-time ?

The debugger inserts break points at specific locations in the process space. Any thread of the process reaching that location would trigger a break. Thus the answer to your question is no. That said, should your application be written such that only one thread will execute that section, then the answer would be yes.

Jim Dempsey