Do concurrent multicore causes wrong answers in loop over large integers

Accelerated Computing HPC Compilers nvc, nvc++ and nvfortran
1

Description of bug

See github source: GitHub - JorgeG94/nvfortran-dc-bug

When compiling a simple daxpy using do concurrent I see misbehaviours in the arrays when using do concurrent with stdpar=multicore enabled.

Program performs a daxpy of the form:

subroutine do_daxpy_of_size(n)
use, intrinsic :: iso_fortran_env, only: int64
real(dp), parameter :: tol = 1.0e-8_dp
real(dp), allocatable :: A(:), B(:)
real(dp) :: alpha
integer(int64), intent(in) :: n

print *, " my size is ", n
allocate(A(n), B(n))
do concurrent (i=1_int64:n)
A(i) = 1.0_dp
B(i) = 0.0_dp
end do
alpha = 3.0_dp
do concurrent (i=1_int64:n)
  B(i) = alpha * A(i) + B(i)
end do
call check_array(B, 3.0_dp, tol, n)
deallocate(A,B)

end subroutine do_daxpy_of_size

Expected answer is 3 in every index. The sizes to evaluate are:

integer(int64), parameter :: n1 = 1024_int64*1024_int64*1024_int64*1_int64
integer(int64), parameter :: n2 = 1024_int64*1024_int64*1024_int64*2_int64
integer(int64), parameter :: n3 = 1024_int64*1024_int64*1024_int64*3_int64
integer(int64), parameter :: n4 = 1024_int64*1024_int64*1024_int64*4_int64

Using the int64 from use, intrinsic :: iso_fortran_env, only: int64 and dp from integer, parameter :: dp = SELECTED_REAL_KIND(15, 307)

When stdpar=multicore is enabled beyond n3 the arrays are filled with zeroes, without stdpar they are correct.

How to use

Make sure you have nvfortran in your path. THen simply:

make 
make check

Currently fails like this:

Running no stdpar...
  my size is                1073741824
  my size is                2147483648
  my size is                3221225472
  my size is                4294967296
Running fail_stdpar...
  my size is                1073741824
  my size is                2147483648
  my size is                3221225472
 ERROR: array(                        1 ) =     0.000000000000000
  but expected ~    3.000000000000000
    1
make: *** [Makefile:20: check] Error 1
1 Like
2

Thanks for the report Jorge!

I recreated the issue here and filed it as TPR #37615. I’ve asked engineering to investigate.

-Mat

1 Like