OpenMP wrong-code issue with pointers in a OMP loop

Dear PGI team,

this is a repost of a bug I recently reported for flang:

It affects PGI 17.10 in the same way as flang, therefore I also report it here.

Test case:

program omp_bug
  integer, parameter :: cnt = 100
  integer, pointer :: bnd(:,:)
  integer, pointer :: chamber(:)
  integer :: i, c

  do i = 1, cnt
    bnd(1:2, i) = (/ i, i+1 /)
  end do

  allocate(chamber(1:cnt+1), source=0)

!$omp parallel do private(i)
  do i = 1,cnt
    chamber(bnd(1:2,i)) = 1
  end do
!$omp end parallel do

  do i = 1, cnt+1
    c = chamber(i)
    if (c <= 0) then
      print *, i, c
      call abort()
    end if
  end do


Compiling this with ‘flang -mp’ and executing with OMP_NUM_THREADS>1 yields errors like:

39 0
Aborted (core dumped)

The first number varies, the second is always zero, so apparently something goes wrong in the loop that sets the chamber array.

It runs through error-free with OMP_NUM_THREADS=1 or when making one of the POINTERs an ALLOCATABLE. Moreover it runs fine with gfortran and ifort (also multi-threaded).


We have replicated the behavior of your program, and we have logged this
as TPR 25053. Your submission to github was a little different, enough
to give this a unique TPR number.


Thanks for the confirmation!

Huh, really? I actually meant to repost the exact same code, just to make sure that this bug also makes it into the PGI bug database. (I have no insight on how you guys manage the development of the flang and PGI compilers, and wanted to be on the safe side here.)


I think the suggested way of programming “pointer vs allocatable” has been to use allocatable if you can, otherwise use pointer type.


I fully agree that for my simple reduced example above, using ALLOCATABLEs would be more reasonable than POINTERs. Nevertheless one can of course construct other examples where the use of POINTERs makes more sense.

In any case, PGI’s behavior here is clearly a bug that needs to be fixed.