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
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.