- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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'.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
![](/skins/images/C4F7392A5C68ACA60290C9576F107044/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page