Safety of associate construct in an open MP parallel region

[Andrew_Smith]

In code such as the following I have found the associations are not thread safe, but cannot be put in a PRIVATE clause because they dont exist until we enter the contruct:

type G

   real x, y

end type

integer n

n = 10

type(G) array(n)

array%x = 1.0

!$OMP PARALLEL DO

do i = 1, n

   associate(x => array(i)%x, y => array(i)%y)

      y = 2*x

   end associate

end do

[jimdempseyatthecove]

In your above post, the assocate's asso-entity's associate-name is undeclared at the point of compilation of the !$OMP PARALLEL DO. Being a forward reference, and more importantly out of the scope of the !$OMP PARALLEL DO, the compiler has no way of knowing what you mean or to do. Take the C example:

if(pointer) doFoo();
for(int i = 0; i < n; ++i) {
char* pointer = something;
...
}

In the C/C++ program the variable "pointer" would not refer to the scope within the for statement. (it would either be undefined or reference a different variable named pointer).

To fix this:

[fortran]

type G
   real x, y
end type

integer n
n = 10
type(G), target :: array(n)
type(G), pointer :: x, y

array%x = 1.0

!$OMP PARALLEL DO PRIVATE(x,y)

do i = 1, n

   x => array(i)%x
   y => array(i)%y

   y = 2*x

end do
[/fortran]

Jim Dempsey

[Andrew_Smith]

Thanks Jim, yes that basically how I fixed my code. But it means less oportunity for compiler code optimization and more code.

I think that because the asso-entity's associate-name is local to the associate contruct it should be treated like a local function variable and should be compiled as a new instance on each entry to the construct. Especially when one has flagged use of OpenMP to the compiler.  

[jimdempseyatthecove]

Andrew,

I think the following program should work. However, Using w_fcompxe_2011.10.325, and uncommenting the !!$OMP's I get an internal compiler error.

1>Compiling with Intel(R) Visual Fortran Compiler XE 12.1.4.325 [IA-32]...

1>ASSOCIATE.f90
1>fortcom: Fatal: There has been an internal compiler error (C0000005).
1>compilation aborted for C:\Test\ASSOCIATE\ASSOCIATE.f90 (code 1)

Commented !!$OMP it compiles and runs OK.

[fortran]

program associateTest
type G
   real x, y
end type
integer, parameter :: n = 10
type(G) :: array(n)

array%x = 1.0

associate(x => array(:)%x, y => array(:)%y)
!!$OMP PARALLEL DO PRIVATE(x,y)
do i = 1, n
      y(i) = 2*x(i)
end do
!!$OMP END PARALLEL DO
end associate
write(*,*) array
end program associateTest
[/fortran]

[bash]
   1.000000       2.000000       1.000000       2.000000       1.000000
   2.000000       1.000000       2.000000       1.000000       2.000000
   1.000000       2.000000       1.000000       2.000000       1.000000
   2.000000       1.000000       2.000000       1.000000       2.000000
[/bash]

Jim Dempsey

[IanH]

Have you read the OpenMP 4.0 draft?  It now defines behaviour for ASSOCIATE constructs, but to be honest I'm not sure how to interpret what it says.  You are roaming somewhat ahead of the pack here, but I find it a bit of a shame that OpenMP has lagged behind the Fortran language to the extent that it has.  References to associate construct stuff that I found, not all relevant:

1. Bottom of page 123, in the context of variables referenced in a construct - "An associate name preserves the association with the selector established at the ASSOCIATE statement."  This also means that an associate name referenced in a construct has a "predetermined data sharing attribute", and there's the general prohibition that "variables with predetermined data sharing attributes may not be listed in data sharing attribute clauses, except for [cases not relevant]."

2. On page 135, in the context of the private clause - "the value and/or allocation status of the original list item will change only:... if accessed and modified via construct association."  (From context I think this refers to construct association in the Fortran sense - i.e. associate and select type constructs, but OpenMP 4.0 explicitly does not support select type.)

3. On page 136, in the context of the private clause and storage associated variables (which is a bit odd from a Fortran language point of view) - "An item that appears in a private clause may be a selector of an associate construct.  If the construct association is established prior to a parallel region, the association between the associate name and the original list item will be retained in the region" (which relates back to point 2).

I think point 1 means that Andrew's original code should work as intended (the associate name in each task should preserve the association with the element of the array that it is associated with).  I think point 1 also means that Jim's last work around is "non-conforming" because of the appearance of the associate names in the PRIVATE clause. 

[Steven_L_Intel1]

I've escalated the internal compiler error as issue DPD200245965.

[Andrew_Smith]

I notice some aspects of OpenMP 4 are in XE2013 SP1. Will the asoociate construct be fixed according to this standard:

A list item that appears in a private clause may be a selector of an ASSOCIATE construct. If the construct association is established prior to a parallel region, the association between the associate name and the original list item will be retained in the region.