Dear Intel Inspector users,
I'm using for the first time this tool to analyze some possible data race in my mixed Fortran/C and OpenMP code. My tools is from intel cs 2013 package. By using the interface on a little run, Inspector detect some data race problem. Analyzing the report, are reported in each data race the source line where should be. The strange thing is that Inspector report a data race in the line where I define the subroutine, not in the body of the function. For example:
Write Thread main file.f90 subroutine search_ranking (...) <<< this line is highlighted end subroutine search_ranking Write - Thread OMP wroker thread #1 subroutine search_ranking (...) <<< this line is highlighted end subroutine search_ranking
What does it means? There is a problem on a subroutine call or inside the subroutine? If I'm in the second case, how can I see the line involved?
- Development Tools
- Intel® Inspector
- Parallel Computing
What are the parameters (and their types) to the subroutine? Depending on the types, the compiler may generate setup code that occurs before the first executable statement in the subroutine.
Is this subroutine called from the OpenMP region, or is the OpenMP region defined inside this subroutine?
I was able to reproduce a data race that points to the 'subroutine' line in the source. It results from subtleties in lower bound handling.
If the array is an assumed-shape array, like this
real :: array1(:)
The lower bound is specified by this declaration (in this case, 1, the default). It is independent of the bounds given in the caller.
The compiler implements this by saving the lower bound from the array descriptor, setting it to one (or whatever is in the type declaration in the subroutine), and then restoring the lower bound at the end of the subroutine.
If the array is a deferred-shape array (declared with 'pointer' or 'allocatable' in the subroutine), the lower bound specified at allocation time is used in the subroutine, and it is not manipulated by the compiler.
To make the data race error go away, change the type declaration to 'real, allocatable :: array1(:)'. Alternately, it could be ignored as benign, since the array bounds will be set and reset to the same value in each thread.
What about write data race on lines like this:
write(*,*) " number:", num
It means "num" is uninitialized or the data race is about shared standard output? Because I checked that value and it's ok for each thread.