- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
![](/skins/images/7B0AB6865064EAE32B30EC9A4E94B48A/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page