Data race problem in legal(?) code

[Matthias_M_]

The following code is to illustrate a questionable(?) data race condition indicated by Intel Inspector XE 2011(build 206270) running under Ubuntu Linux 10.04 x86_64.

test.f90

[fortran]program test
  use omp_lib
  implicit none
  
  real, dimension(:), allocatable :: Da,DaLocal
  real :: di

  integer, parameter :: n=100, nset=16
  integer :: i,iset,imin,imax

  allocate(Da(n))

  ! ***
  ! Standard OpenMP Do-loop
  ! ***

  !$omp parallel do default(none) private(di) shared(i,Da)
  do i=1,size(Da)
    di    = real(i)
    Da(i) = di
  end do
  !$omp end parallel do



  ! ***
  ! Blocked OpenMP Do-loop
  ! ***

  !$omp parallel default(none) private(DaLocal,di,i,imax) shared(Da)

  allocate(DaLocal(nset))

  !$omp do schedule(static,1)
  do iset = 1, size(Da), nset
    
    ! Compute upper index of current block
    imax = min(size(Da), iset-1+nset)

    ! Loop over all 1,2,3... items in current set
    do i = 1, imax-iset+1
      ! Perform computation
      di         = real(i+iset-1)
      DaLocal(i) = di
    end do

    ! Copy local data into gobal array
    do i = 1, imax-iset+1
      Da(i+iset-1) = DaLocal(i)
    end do

  end do
  !$omp end do

  deallocate(DaLocal)

  !$omp end parallel
  
  deallocate(Da)

end program test
[/fortran]

Intel Inspector XE running Analysis "Locate Deadlocks and Data Races" with option "Detect data races on stack accesses" enabled and "Scope" set to "Extremely thorough" indicates

1. Cross-thread stack access in line 34

2. Data race in line 34

First of all, I do think that the code is correct, is it?. I understand that the standard Do-loop is preferable in this case but the code is extracted from a larger application, where each thread needs to allocate a set of private working arrays and private derived types in order to perform some more complicated computations before it can copy the local results into the global array.

If the code is correct then is the data race problem reported by Intel Inspector XE really a "problem" which can be solved by a better implementation or is it an "internal problem" of the inspector tool?

Any help will be greatly appreaciated

Matthias

[Peter_W_Intel]

I tested your code with same Inspector XE version, but hard to reproduce this problem.
Is it due to different Intel Fortran compiler, or different OS?

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)

# ifort -V
Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.1.2.273 Build 20111128
Copyright (C) 1985-2011 Intel Corporation. All rights reserved.

# ifort test.f90 -g -openmp -openmp-report -o test.ifort
test.f90(17): (col. 9) remark: OpenMP DEFINED LOOP WAS PARALLELIZED.
test.f90(34): (col. 9) remark: OpenMP DEFINED LOOP WAS PARALLELIZED.
test.f90(30): (col. 9) remark: OpenMP DEFINED REGION WAS PARALLELIZED.

# inspxe-cl -collect ti3 -- ./test.ifort
Used suppression file(s): []

0 new problem(s) found


Regadrs, Peter

[Peter_W_Intel]

I tried same Inspector XE and Intel Fortran Compiler version on Ubuntu* 10.04 - the resultwas same

[Matthias_M_]

When I repeat all your steps with ifort version12.1.1.256, then no errors/problems are reported. Unfortunately, my initial post was based on

# ifort -V

Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.1.107 Build 20101116

Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

Intel Fortran Intel 64 Compiler XE for applications running on Intel 64, Version 12.0.1.107 Build 20101116Copyright (C) 1985-2010 Intel Corporation. All rights reserved.

which yields

# ifort test.f90 -g -openmp -openmp-report -o test.ifort

test.f90(17) (col. 9): remark: OpenMP DEFINED LOOP WAS PARALLELIZED.

test.f90(34) (col. 9): remark: OpenMP DEFINED LOOP WAS PARALLELIZED.

test.f90(30) (col. 9): remark: OpenMP DEFINED REGION WAS PARALLELIZED.

and

#inspxe-cl -collect ti3 -- ./test.ifort

Warning: One or more threads in the application accessed the stack of another thread. This may indicate one or more bugs in your application. Setting the Intel Inspector XE 2011 to detect data races on stack accesses and running another analysis may help you locate these and other bugs.

0 new problem(s) found

It seems that this problem is not related to inspector but to the compiler itself.

I am sorry for all the inconvenience caused.

Regards, Matthias

[Peter_W_Intel]

You are welcome:-)

Thank you for the update. It seems that this is compiler related issue.

Regards, Peter