[Flang][OpenMP] Execution error when derived type is specified in lastprivate clause of sections construct

[ohno-fj]

Version of flang-new : 20.0.0(5621929f7f4878c318deecb592cd03f5ecbb83ba)/AArch64

When derived type is specified in lastprivate clause of sections construct, segmentation fault (core dumped) occurs.

The following are the test program, Flang-new, Gfortran and ifx compilation/execution result.

FT_OMP_LastPrivate_009_2232.f90:

program main
  type x
     integer::x2
     character(len=5)::c1
     integer,allocatable::x1(:,:)
  end type x
  type(x) :: v(2)
  allocate(v(1)%x1(2,2))
  v(1)%x1 = 11
!$omp parallel
!$omp sections lastprivate(v)
  if (any(v(1)%x1/=11)) print *,1201,v(1)%x1
  deallocate(v(1)%x1)
  allocate(v(1)%x1(4,6))
  v(1)%x1 = 21
!$omp end sections
!$omp end parallel
  print *,'PASS'
end program main

$ export OMP_NUM_THREADS=2; flang-new -fopenmp FT_OMP_LastPrivate_009_2232.f90; ./a.out
flang-20: warning: OpenMP support in flang is still experimental [-Wexperimental-option]
Segmentation fault (core dumped)
$

$ export OMP_NUM_THREADS=2; gfortran -fopenmp FT_OMP_LastPrivate_009_2232.f90; ./a.out
        1201           0           0           0           0
 PASS
$

$ export OMP_NUM_THREADS=2; ifx -qopenmp FT_OMP_LastPrivate_009_2232.f90; ./a.out
        1201           0           0           0           0
 PASS
$

[luporl]

In my environment, with latest flang, the test program sometimes passes and sometimes hangs (although line 1201 0 0 0 0 is never printed).

[luporl]

The problem happens in this line:

if (any(v(1)%x1/=11)) print *,1201,v(1)%x1

If it is commented, the issue doesn't happen. It seems to me that this test program is not conforming.
This is because lastprivate(v) creates an uninitialized private version of v, where x1 is not allocated, and the line above tries to access x1 elements.

[luporl]

According to OpenMP 5.2, https://www.openmp.org/spec-html/5.2/openmpse25.html#x68-700005.3:

For a list item or the subobject of a list item with the ALLOCATABLE attribute:

• If the allocation status is unallocated, the new list item or the subobject of the new list item will have an initial allocation status of unallocated;
• If the allocation status is allocated, the new list item or the subobject of the new list item will have an initial allocation status of allocated; and
• If the new list item or the subobject of the new list item is an array, its bounds will be the same as those of the original list item or the subobject of the original list item.

So the test program is actually conforming.

[kiranchandramohan]

@luporl are you working on this? Will the fix address similar issues (#114888) where there are allocatable components in derived types?

[luporl]

@luporl are you working on this? Will the fix address similar issues (#114888) where there are allocatable components in derived types?

@kiranchandramohan yes, I'm finishing a patch to fix this issue. I plan to post it in the next days. It consists of a new runtime function, that is called when the privatized item is a derived type with allocatable components, to initialize these from the original item.

It should fix #114888 too. Its test program works with my branch.