New ATOMIC constraint in OpenMP 4.0

[Greynolds__Alan]

I ran into an interesting change from OpenMP 3.1 to 4.0: ATOMIC variables can no longer be ALLOCATABLE (I've asked on an OpenMP forum why this change was made).  This broke my code when I compiled it under gfortran 4.9.1, but it still works with 14.0.3, so assume Intel Fortran does not (luckily for me) implement the full OpenMP 4.0 standard yet.  I wish they had kept the old behavior with a bare ATOMIC directive and implemented the new behavior with the ATOMIC UPDATE form.  Probably to late to complain now.

[Greynolds__Alan]

Just to be sure, this is a code example that gfortran 4.9.1 now says violates the new OpenMP 4.0 constraint on ATOMIC:

module storage
  integer,allocatable :: nerrs(:,:)
end module

program atomic
  use storage
    allocate(nerrs(10,10))
!$omp parallel do
    do k=1,10
      call uperrs(k,1)
    enddo
!$omp end parallel do
  stop
contains
  subroutine uperrs(i,io)
  integer,intent(in) :: i,io
!$omp atomic
    nerrs(i,io)=nerrs(i,io)+1
  end subroutine
end

Are they correctly interpreting the spec?

[jimdempseyatthecove]

As used above, I cannot see why that would be in error.

I could (potentially) see a concern in the situation where the left hand side gets auto-reallocated due to the result of the expression on the right hand side. And in that situation I can anticipate there was disagreement amongst the members of the committee as to what to do. To blatantly prohibit it as used above I see no reason. I would guess then that this is a compiler error. 

Jim Dempsey

[Nick_M_3 · Accepted solution]

I am pretty sure gfortran is wrong.  nerrs(i,io) is not an allocatable variable.  nerrs is, but that does not make subobjects allocatable in their own right.

On the other hand, the OpenMP specification is such a mess, and 4.0 has made so many radical changes to this area, that it's difficult to know what it means.  I haven't checked 4.0, but all previous versions have had serious inconsistencies (both internally and between it and the languages it refers to), as well as unimplementabilities and just plain insanities.  But this doesn't look like one of those.  It looks like a simple gfortran bug.

[Nick_M_3]

I forgot to say why it was made - I wasn't involved, but it's fairly clear.

OpenMP 3.1 was based on Fortran 95; OpenMP is on Fortran 2003.  In the latter, allocatable variables are automatically reallocated to the size of their RHS on assignment.  That's tricky to implement atomically, as it needs memory deallocation and reallocation - and the former might cause a finaliser to be called!

[jimdempseyatthecove]

Thanks Nick for mentioning the potential for a finaliser, I overlooked that.

Auto-reallocation can be good when you want it, and it can equally be bad when you don't want it (hides a programming error). Also, I do not like the fix for this to be a global compiler option. I'd rather that they used either a new attribute on arrays REALLOCATABLE, or introduced a new token

  ThisArrayIsReallocated := SomeArrayExpressionHere

Either would be ok, but I would prefer the new token as it expressly states what you intend to do and where you intend it to occur.

Jim Dempsey