Understand Intel Inspector output

[unrue]

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?

Thanks.

[Peter_W_Intel]

Can you repeat this problem if you disable optimization option?

[unrue]

Optimization are already disabled, and I compiled the code by using -O0 -g -shared-intel -check:none, according with Intel Inspector tutorial.

[Mark_D_Intel]

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?

[unrue]

The parameters are: two real 1D arrays as input, one real 1D array as INOUT, another 2D real matrix as INOUT, The routine is called from OpenMP region.

[Mark_D_Intel]

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

subroutine search_ranking(array1)

   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.

[unrue]

Hello mark,

thanks for your detailed reply. From what I understand, I can ignore this type of data race error reported from Intel Inspector?

[unrue]

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.