FIRSTPRIVATE clause fails to duplicate nested derived types

[SebastienB]

Dear Ifort community,

I am facing a bug with ifort 14.0.2 and 18.0.3. I do not have access to a newer ifort version.

$ cat structures.f90 
program test
  implicit none

  type :: sub_t
    integer(kind=8) :: a
    integer(kind=8) :: b
    integer(kind=8) :: c
    integer(kind=8) :: d
    integer(kind=8) :: e
  end type sub_t

  type :: main_t
    integer(kind=8)  :: tasknum
    type(sub_t) :: s
  end type main_t

  integer, parameter :: mtask=3
  integer :: itask
  type(main_t) :: m

  ! Initialization of the subtype
  m%tasknum = 0
  m%s%a = 10
  m%s%b = 11
  m%s%c = 12
  m%s%d = 13
  m%s%e = 14

  call print_it(m,'0')
  !$OMP PARALLEL DEFAULT(none) SHARED(itask,m)
  !$OMP SINGLE
  do itask=1,mtask
    m%tasknum = itask
    call print_it(m,'1')
    !$OMP TASK FIRSTPRIVATE(m)
    call print_it(m,'2')
    !$OMP END TASK
  enddo
  !$OMP END SINGLE
  !$OMP END PARALLEL

contains
  !
  subroutine print_it(what,where)
    type(main_t),     intent(in) :: what
    character(len=*), intent(in) :: where
    write (*,'(2A,6(1X,A,I3))')  &
      where,': ',  &
      'TASKNUM=',what%tasknum,  &
      'A=',what%s%a,  &
      'B=',what%s%b,  &
      'C=',what%s%c,  &
      'D=',what%s%d,  &
      'E=',what%s%e
  end subroutine print_it
end program test

$ ifort -qopenmp structures.f90 -o structures && ./structures 
0:  TASKNUM=  0 A= 10 B= 11 C= 12 D= 13 E= 14
1:  TASKNUM=  1 A= 10 B= 11 C= 12 D= 13 E= 14
1:  TASKNUM=  2 A= 10 B= 11 C= 12 D= 13 E= 14
2:  TASKNUM=  1 A= 10 B= 11 C= 12 D= 10 E= 11
1:  TASKNUM=  3 A= 10 B= 11 C= 12 D= 13 E= 14
2:  TASKNUM=  3 A= 10 B= 11 C= 12 D= 10 E= 11
2:  TASKNUM=  2 A= 10 B= 11 C= 12 D= 10 E= 11
$

 In order to give a bit of context: there is master (SINGLE) thread which creates a task pool (3 tasks in this example). Each task is given its own copy of the "m" structure (in my real code, this describes the piece of work to be processed by the task).

When executing the program, the lines "1:" show what the master thread has given to each task. The lines "2:" show what the tasks actually got. You can see that the D and E components are incorrect, they have been changed from the original values. My tests tend to conclude this bug appears because the A/B/C/D/E components are in a sub-structure (no problem if they are at the top-level).

Can you confirm this bug still exists or if it has been fixed in a recent ifort version?

[jimdempseyatthecove]

This looks like a previously reported bug where firstprivate copy used SIMD instructions  to copy and the residual data was not copied.

Your main_t has 6 integer(8)'s, 4 fit in a SIMD register, 2 do not. The newer versions may have this fixed.

As a test of this theory, add two more integer(8)'s to the sub_t. 

Note, this isn't a fix for the bug, rather it is confirmation of a supposition, it can also be used as a workaround should you not be able to upgrade.

The newer version is free for download.

Jim Dempsey

[SebastienB]

Unfortunately adding 2 more integer(8) does not help.

[Barbara_P_Intel · Accepted solution]

I just tried this with the currently released compiler, 2021.9.0. It's part of oneAPI HPC Toolkit 2023.1.

Is this the output you expect?

+ ifort -qopenmp structures.f90
+ a.out
0:  TASKNUM=  0 A= 10 B= 11 C= 12 D= 13 E= 14
1:  TASKNUM=  1 A= 10 B= 11 C= 12 D= 13 E= 14
1:  TASKNUM=  2 A= 10 B= 11 C= 12 D= 13 E= 14
1:  TASKNUM=  3 A= 10 B= 11 C= 12 D= 13 E= 14
2:  TASKNUM=  3 A= 10 B= 11 C= 12 D= 13 E= 14
2:  TASKNUM=  2 A= 10 B= 11 C= 12 D= 13 E= 14
2:  TASKNUM=  1 A= 10 B= 11 C= 12 D= 13 E= 14

[SebastienB]

Dear Barbara,

I confirm this is the expected solution. As a workaround, for now I have moved all the components in the sub-structure into the main structure. But for other reasons this is not satisfying, so I am considering going to the latest ifort version.

I mark this problem solved. Thank you for your support.