18.104.22.168 (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
integer, allocatable :: a(:)
! integer, pointer :: b(:)
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
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)?