[Omp] fortran: copyin of derived types with allocatable components

Tobias Burnus burnus at net-b.de
Sat Jun 23 15:32:35 PDT 2007


Daniel Franke wrote:
> Section 2.8.4.1 COPYIN clause, Restrictions:
> 	* Allocatable arrays may not appear in a copyin clause.
>
> Does the same apply for derived types with allocatable components?

I have a more general question to this restriction; what do you expect
for a decent compiler to react for

a) allocatable arrays:
  real, allocatable :: b(:)
  [...]
  !$omp parallel copyin(b)

b) the above mentioned allocatable components in derived types, i.e

      type :: foo
          integer, allocatable :: a(:)
      end type
      type(foo), save :: t
      [...]
!$omp parallel copyin(t)


Should a decent compiler do:

i) Reject the code with an error
ii) Give by default a warning, but accept it
iii) Give a warning when -Wsomething is specified
iv) Accept the code - the user does know what (s)he is doing

I think one can find compilers which do (iv) and which do (i), but what
do you prefer? Additional, does anyone knows the rational behind this
restriction. Is is just to make live of the compiler developer easier or
is there a further catch?

(sunf95 and gfortran gives an error for (a) and allow (b); ifort and
portland 6.2 allow (a) and (b); pathscale 2.4 gives an error for (a) and
does not support allocatable components at all.)

I'm personally in favour of (ii) given that several compiler do (iv).

For whether (b) is allowed, I'm inclined to interpret the standard such
that it is not allowed (following also the argument in the initial
bugreport, cf. below), but I'm far from being sure.

 *  *  *

I have a different question (which is in so far related as both
questions came up with a bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32467)

Assuming:

use omp_lib
integer :: a(4)
call omp_set_dynamic(.true.)
call omp_set_num_threads(4)
a = 0
!$omp parallel
 a(omp_get_thread_num()+1) = 1
!$omp end parallel
print *, a
end

does this always need to print out "1 1 1 1" or may there be fewer
threads such that "1 1 1 0", "1 1 0 0" or "1 0 0 0" are valid outputs as
well? The problem is that some compiler (e.g. gfortran, sunf95) seem to use
   MIN(no. of cpu cores online, 4 (via omp_set_num_threads)
threads which might be, e.g., one instead of four.

I would assume that using less than four thread is also correct since
with omp_set_dynamic(.true.) there is nothing which guarantees the
number of threads. Is this correct or have I overlooked something?

Tobias


More information about the Omp mailing list