[Flang][OpenMP]Variable used in TASK construct is not implicit firstprivate

[ohno-fj]

Version of flang-new : 17.0.0(359f170f5f712ee714193b46bad45a45656b2c59)

Variable used in TASK construct is not implicit FIRSTPRIVATE.

According to the following specification, the variable(a) in the test program is FIRSTPRIVATE.

• OpenMP Application Programming Interface Version 4.5 : subclause 2.15.1.1

The following are the test program, results of Flang-new, Gfortran and ifort compilation and execution.

omp3_task_024_2.f90:

program main
!$omp parallel
  call sub()
!$omp end parallel
  print *,"pass"
end program main

subroutine sub
  integer::a
  a=5
!$omp task
  write(6,*) "1  a = ", a
  if (a.eq.5) then
     a=a+10
  else
     print *,"NG-1:a=",a
  end if
  write(6,*) "2  a = ", a
!$omp end task
!$omp taskwait
  write(6,*) "3  a = ", a
  if (a.ne.5) then
     print *,"NG-2:a=",a
  end if
end subroutine sub

$ export OMP_NUM_THREADS=2; flang-new -fopenmp omp3_task_024_2.f90; ./a.out
 1  a =  5
 2  a =  15
 3  a =  15
 NG-2:a= 15
 1  a =  5
 2  a =  15
 3  a =  15
 NG-2:a= 15
 pass
$

$ export OMP_NUM_THREADS=2; gfortran -fopenmp omp3_task_024_2.f90; ./a.out
 1  a =            5
 2  a =           15
 3  a =            5
 1  a =            5
 2  a =           15
 3  a =            5
 pass
$

$ export OMP_NUM_THREADS=2; ifort -qopenmp omp3_task_024_2.f90; ./a.out
 1  a =            5
 2  a =           15
 3  a =            5
 1  a =            5
 2  a =           15
 3  a =            5
 pass
$

[llvmbot]

@llvm/issue-subscribers-openmp

[llvmbot]

@llvm/issue-subscribers-flang-frontend

[kiranchandramohan]

@luporl Are you working on this from the Flang semantics perspective? Or are you working on the end to end flow. If you are working on the end to end flow then please read on, otherwise it is alrite.

There are some issues in privatisation/firstprivatisation of tasks. Tasks can have delayed execution. So it is a bit different from the privatization of other constructs. Delayed execution can make things go out of scope. So for firstprivate the host variable from which the privatized variable inside the task should be initialized might have gone out of scope. I think Clang handles this by making a copy of the value and storing it along with task datastructure, and later use it to initialize the privatized variable.

The OpenMPIRBuilder for task creates only a task datastructure (%struct.kmp_task_t). Clang creates a private structure along with it.

%struct.kmp_task_t_with_privates = type { %struct.kmp_task_t, %struct..kmp_privates.t }

[luporl]

@kiranchandramohan I'm working on the end to end flow. With some changes in semantics and lowering, I was able to make some simple programs using task to firstprivatize implicit variables.

But I wasn't aware of this issue with delayed execution. I must have been lucky in my testing so far.
I'll try to post a PR with what I have soon. Do you think it would be ok to first address the implicit firstprivate issue and handle delayed execution on a later patch?

[kiranchandramohan]

But I wasn't aware of this issue with delayed execution. I must have been lucky in my testing so far.
I'll try to post a PR with what I have soon. Do you think it would be ok to first address the implicit firstprivate issue and handle delayed execution on a later patch?

Yes, this is fine.