ifort/ifx: potentially two bugs about `associate` syntax

[zoziha]

Hello, Intel Fortran compiler developers,

I think `associate` is a flexible syntax, but at the same time it poses challenges and hassles for Fortran compiler developers. In the process of programming, I have found two bugs:

1. The `private` problem of `associate` structure in `OpenMP/do concurrent`, see Fortran Discourse;
2. The special pairing of `associate` with `pointers` will result in memory leaks.

Below I'll provide two minimal example of the reproducing bugs. My computer environment is `Windows 10, ifort v2021.8.0/ifx v2023.0.0, i5-8250U`.

#### Bug 1: `private` issue with `associate` constructs in `OpenMP/do concurrent`

program main

    use omp_lib
    implicit none
    integer :: ints(4) = [1, 2, 3, 4], i

    !$omp parallel do schedule(dynamic)
    do i = 1, 4
        associate (x => ints(i))
            print *, "loc = ", loc(x), ", x = ", x, ", omp_get_thread_num() = ", omp_get_thread_num()
        end associate
    end do

end program main

The code gets the expected result in the following command:

> ifort /Qopenmp main.f90; ./main
 loc =  140697311514632,  x =   3,  omp_get_thread_num() =  3
 loc =  140697311514628,  x =   2,  omp_get_thread_num() =  2
 loc =  140697311514636,  x =   4,  omp_get_thread_num() =  6
 loc =  140697311514624,  x =   1,  omp_get_thread_num() =  4

Use the following command to get unexpected results:

> ifort /Qopenmp /Z7 main.f90; ./main
 loc = 140700606185484 , x = 4 , omp_get_thread_num() = 2
 loc = 140700606185484 , x = 4 , omp_get_thread_num() = 3
 loc = 140700606185484 , x = 4 , omp_get_thread_num() = 5
 loc = 140700606185484 , x = 4 , omp_get_thread_num() = 1

> ifx /Qopenmp main.f90; ./main
loc = 140702410522632, x = 3, omp_get_thread_num() = 1
loc = 140702410522636, x = 4, omp_get_thread_num() = 0
loc = 140702410522636, x = 4, omp_get_thread_num() = 4
loc = 140702410522636, x = 4, omp_get_thread_num() = 2

For details, please refer to Fortran Discourse.

#### Bug 2: A special pairing of `associate` with `pointers` will result in a memory leak

program main

    implicit none
    real, target :: loc(2, 100001) = 1.0
    integer :: i, j
    real, pointer :: loc1(:, :)

    loc1 => loc
    do j = 1, 10
        do i = 1, size(loc, 2) - 1
            associate (ik => loc1(:, i) - loc(:, i + 1))  ! bad code, memory leak
            ! associate (ik => loc(:, i) - loc1(:, i + 1)) ! good code
            end associate
        end do
        write (*, "(i0)", advance="no") j
        read (*, *)
    end do

end program main

The above code has a line of code with a memory leak, run it, every time with `J` loop, observe the program memory usage, the memory usage will increase significantly.

However, simply switching the position of `loc1(:, i)`(`pointer`) and `loc(:, i+1)` will not cause a memory leak.

> ifort /heap-arrays:0 main.f90; ./main

[martinmath]

Associate and block within openmp has been discussed here:

Openmp+associate/block 

Openmp 5.1 added support for these cases. This is not in the realm of the fortran standard. I have not yet checked whether recent releases handle it accordingly and are conforming to 5.1.

[zoziha]

Thanks for your reply, @martinmath  I'm glad to know that the first bug is fixed in the latest OneAPI Fortran (I haven't updated the latest OneAPI to verify it yet).

The second bug, the combination of `pointers` and `associate` causes a memory leak, it has nothing to do with OpenMP, this bug would like to be confirmed, thank you in advance.

[Barbara_P_Intel]

@zoziha, do you see the same "memory leak" for bug 2 using ifx?

[zoziha]

@Barbara_P_Intel , I checked and yes, there are bug 2 in both `ifort/ifx`, using `ifx` test as shown:

> ifx /heap-arrays:0 main.f90; ./main

[Barbara_P_Intel]

@zoziha, I just reread your original post. Can you use the latest compiler release? There have been 2 releases since the one you are using. The current release of ifort is 2021.10.0 and ifx is 2023.2.0.

The compiler team addresses many issues in each release.