Several 3.0 draft issues

The public comment period closed January 31, 2008. This forum is now locked (read only).

Re: Several 3.0 draft issues

Postby jakub » Tue Feb 26, 2008 7:18 am

After the changes to the handling of private (allocatable_var) I think private clauses with allocatable variables should be also mentioned in 2.9.1.1 (p74, l19), because without referencing the variable in the enclosed construct it is not possible to determine its allocation status.
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Re: Several 3.0 draft issues

Postby lfm » Tue Feb 26, 2008 7:55 am

Thanks, Jakub. We made some changes for the threadprivate stuff that answer your questions, I think. I'll also note your comment about allocatables.
lfm
 
Posts: 135
Joined: Sun Oct 21, 2007 4:58 pm
Location: OpenMP ARB

Re: Several 3.0 draft issues

Postby jakub » Thu Feb 28, 2008 8:01 am

2.9.4.1 (p98, l17-18) says: "An array with the ALLOCATABLE attribute must be in the allocated state. Each thread's copy of that array must be allocated with the same bounds."
If this means it is user's responsibility to allocate the threadprivate allocatable arrays in each thread first, then this sounds fragile. In order to use copyin with allocatable, one would need another parallel first
in which it would allocate the threadprivate allocatables, it would need to use the same num_threads and likely also omp_set_dynamic(.false.), otherwise some thread affected by copyin might not have
its threadprivate allocatable array allocated. It would make much more sense to require that either the threadprivate allocatable is allocated with the same bounds as in the master thread, or it is not currently
allocated, in which case copyin would allocate it with master thread's bounds.

Another thing, the standard doesn't seem to talk about derived types in restrictions. E.g. is allocatable component in the following testcase supposed to behave
Code: Select all
  type typef
    integer, allocatable :: a(:)
!    integer, pointer :: b(:)
  end type
  type(typef) :: foo, bar
  allocate (bar%a (3))
!  allocate (bar%b (1))
!$omp parallel private (foo) firstprivate (bar)
  allocate (foo%a (4))
!$omp end parallel
end

as allocatable arrays are supposed to (and would the testcase be invalid after removing the two comment chars because firstprivate must not use Fortran pointers)?
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Re: Several 3.0 draft issues

Postby jakub » Thu Feb 28, 2008 12:53 pm

To ammend the ALLOCATABLE comment, if the parallel is nested, the standard makes no guarantees that the threadprivate var is preserved, so there wouldn't be a way how to use copyin with allocatable arrays at all in nested parallels.
jakub
 
Posts: 74
Joined: Fri Oct 26, 2007 3:19 am

Re: Several 3.0 draft issues

Postby lfm » Wed Mar 05, 2008 10:00 am

Jakub:

Regarding allocatable arrays in threadprivate, we agree that this is awkward, and indeed we did fix it for private allocatables, but not for threadprivate. However it is too late in the game to change it for 3.0.

Allocatable components of derived types are not an F95 feature, so we didn't address them in 3.0 at all.

-- Larry
lfm
 
Posts: 135
Joined: Sun Oct 21, 2007 4:58 pm
Location: OpenMP ARB

Previous

Return to Draft 3.0 Public Comment

Who is online

Users browsing this forum: No registered users and 0 guests

cron