Here is the code:
program main implicit none integer :: i type Element real(8),allocatable :: eForce(:) end type Element type (Element),allocatable :: elems(:) allocate(elems(100)) !$omp parallel do private (i) schedule (guided) do i=1,100 allocate(elems(i)%eForce(1000000)) elems(i)%eForce=1. end do !$omp end parallel do write(*,*) "befor clean..." do while (.true.) write(*,fmt='(a,\)') "input 1 to continue：" read(*,*) i if(i.eq.1) exit end do deallocate(elems) write(*,*) "clean finished..." do while (.true.) write(*,fmt='(a,\)') "input 1 to continue：" read(*,*) i if(i.eq.1) exit end do end program main
If I choose "Debug Multithreaded (/libs:static /threads /dbglibs)" in project property, after clean the allocated memory, the memory usage is still near 1GB
However, If I choose "Debug Multithread DLL (/libs:dll /threads /dbglibs)", deallocate will perform right.
I notice that IVF stop support for static link of OpenMP (https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-Fortran-Static-Library-with-OpenMP-enabl...
According to the thread, Am i wrong to choose the libs:static option?
The Intel Fortran version I used is 184.108.40.206
I can reproduce the difference using the 2021.0.2 compiler and libraries. What causes it, I don't know., but I do know that there can sometimes be issues mixing DLL and static linked code. If you have paid support I suggest you report this through the Intel Online Service Center. But the most pragmatic approach would be to use DLL linking, which is the default.
Linking to DLL libraries saves space, reduces memory load, and allows for DLLs to be updated without requiring a relink. Microsoft changed its defaults many years back to default to DLL linking. In the case of OpenMP, I recall a claim that there were run-time issues caused by use of a static library for OpenMP. I don't recall the details, and note that a static OMP library is still provided on Linux, but that is a different environment.