[flang][OpenMP] Memory leak in first private declaration of a derived type.

[scamp-nvidia]

Consider the following code:

PROGRAM DRIVER
    use omp_lib
    IMPLICIT NONE
    INTEGER, PARAMETER :: NVAL = 2000
    TYPE TCONTAINER
        REAL(KIND=8), ALLOCATABLE :: ARR(:)
    END TYPE TCONTAINER
    TYPE(TCONTAINER) :: obj
    INTEGER :: idx
    ALLOCATE (obj%ARR(NVAL))
        do idx=1,4
        !$OMP PARALLEL FIRSTPRIVATE (obj)
        write(*,*), 'thread', omp_get_thread_num()
        !$OMP END PARALLEL
        enddo
    DEALLOCATE (obj%ARR)
END PROGRAM DRIVER

Compiling with a recent version of upstream Flang and running this code with valgrind on an icelake machine (x86):

[scamp]$ flang test.F90 -o test -fopenmp -g
[scamp]$ export OMP_NUM_THREADS=2
[scamp]$ valgrind --leak-check=full ./test
==3579486== Memcheck, a memory error detector
==3579486== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==3579486== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info
==3579486== Command: ./test
==3579486==
 thread 0
 thread 1
 thread 0
 thread 1
 thread 0
 thread 1
 thread 0
 thread 1
==3579486==
==3579486== HEAP SUMMARY:
==3579486==     in use at exit: 210,753 bytes in 24 blocks
==3579486==   total heap usage: 796 allocs, 772 frees, 1,756,205 bytes allocated
==3579486==
==3579486== 64,000 bytes in 4 blocks are definitely lost in loss record 11 of 13
==3579486==    at 0x4C3E2E1: malloc (vg_replace_malloc.c:446)
==3579486==    by 0x501C0E6: Fortran::runtime::Descriptor::Allocate(long*) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486==    by 0x4FD3B47: Fortran::runtime::AssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486==    by 0x4FD1ABC: Fortran::runtime::DerivedAssignTicket<true>::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486==    by 0x4FD3E6F: Fortran::runtime::AssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486==    by 0x4FD65BC: _FortranAAssign (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486==    by 0x40014E4: _QQmain..omp_par (test.F90:8)
==3579486==    by 0x4132178: __kmp_invoke_microtask (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486==    by 0x40AE59E: __kmp_invoke_task_func (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486==    by 0x40A8BC4: __kmp_fork_call (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486==    by 0x40986FC: __kmpc_fork_call (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486==    by 0x40012DF: _QQmain (test.F90:8)
==3579486==
==3579486== 64,000 bytes in 4 blocks are definitely lost in loss record 12 of 13
==3579486==    at 0x4C3E2E1: malloc (vg_replace_malloc.c:446)
==3579486==    by 0x501C0E6: Fortran::runtime::Descriptor::Allocate(long*) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486==    by 0x4FD3B47: Fortran::runtime::AssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486==    by 0x4FD1ABC: Fortran::runtime::DerivedAssignTicket<true>::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486==    by 0x4FD3E6F: Fortran::runtime::AssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486==    by 0x4FD65BC: _FortranAAssign (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486==    by 0x40014E4: _QQmain..omp_par (test.F90:8)
==3579486==    by 0x4132178: __kmp_invoke_microtask (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486==    by 0x40AE59E: __kmp_invoke_task_func (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486==    by 0x40AD1FD: __kmp_launch_thread (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486==    by 0x4111BF7: __kmp_launch_worker(void*) (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486==    by 0x65521C9: start_thread (in /usr/lib64/libpthread-2.28.so)
==3579486==
==3579486== LEAK SUMMARY:
==3579486==    definitely lost: 128,000 bytes in 8 blocks
==3579486==    indirectly lost: 0 bytes in 0 blocks
==3579486==      possibly lost: 0 bytes in 0 blocks
==3579486==    still reachable: 82,753 bytes in 16 blocks
==3579486==         suppressed: 0 bytes in 0 blocks
==3579486== Reachable blocks (those to which a pointer was found) are not shown.
==3579486== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==3579486==
==3579486== For lists of detected and suppressed errors, rerun with: -s
==3579486== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
[scamp]$

There's definitely a memory leak associated with the first private declaration of 'obj' at the parallel region. Analyzing the assembly with "-S" and comparing against the valgrind output, I believe for the parallel region, there's a '_FortranAAssign' that allocates at the beginning of the parallel region, but there's not corresponding free for that allocation, leading to the leak.