Suspected ifort compiler bug - Accessing global variables from a subroutine called from OpenMP task

[mcgavinp]

Depending on compiler options, ifort version 2021.7.0 20220726 appears to give incorrect, random results when accessing program global variables from a subroutine called from an OpenMP task.  Example:

program test1
  implicit none
  integer :: i, j, g
  g = 42
  !$OMP PARALLEL DEFAULT(SHARED)
     !$OMP SINGLE
        i = 0
        j = 1
        do while (j < 60)
           i = i + 1
           !$OMP TASK DEFAULT(SHARED) FIRSTPRIVATE(i,j)
              call sub(i,j)
           !$OMP END TASK
           j = j + j
        end do
     !$OMP END SINGLE
  !$OMP END PARALLEL
  stop

contains

  subroutine sub(i,j)
    implicit none
    integer i,j
    !$OMP CRITICAL(unit6)
       write(6,*) i,j,g
    !$OMP END CRITICAL(unit6)
  end subroutine sub

end program test1

 Compiled with: ifort -o test1 test1.f90 -qopenmp -warn all -check all

Expected result:

           2           2          42
           3           4          42
           1           1          42
           4           8          42
           5          16          42
           6          32          42

 Obtained result with "-check all":

           3           4  -858993460
           1           1  -858993460
           2           2  -858993460
           4           8  -858993460
           6          32  -858993460
           5          16  -858993460

 Note: the order of output lines doesn't matter --- just the numbers in the third column should be 42.

Different unexpected results are obtained by changing compiler options. For example, with "ifort -o test1 test1.f90 -qopenmp -warn all -O0", the third column is 256 and with "ifort -o test1 test1.f90 -qopenmp -O0" it is -740818552.  With only "ifort -o test1 test1.f90 -qopenmp", the correct result is obtained, at least, in this example, but not in some more complex examples.

Of course g could be passed to sub() as an argument, but the program I'm assisting with working on has dozens of shared global variables (that don't change in the parallel part) and subroutine calls go several layers deep.  Or the shared globals could be defined in a separate module.  But that's all beside the main point of this post.

Thanks, Peter McGavin.

[Barbara_P_Intel]

It is -O0 causing the wrong answers with and without -check all.

According to the Developer Guide, -check all disables optimization and overrides any optimization level set by option O.

I get the right answers with -O1, -O2 and -O3 without -check all.

I filed a bug report on the -O0 problem, CMPLRLLVM-40730.

[Barbara_P_Intel]

This issue of getting wrong answers with ifx at -O0 is fixed in the latest compiler release, 2023.0.0. Please give it a try!

[mcgavinp]

Thank-you very much Barbara_P_Intel,

Yes, with the oneAPI HPC Toolkit 2023.0.0, "ifx -O0 -qopenmp" now gives me the right answer.  That's great.

I note that the bug appears to still exist in the oneAPI HPC Toolkit 2023.0.0 classic Fortran compiler, "ifort -O0 -qopenmp"

Kind regards, Peter McGavin.

[Barbara_P_Intel]

I noticed that it still fails with ifort, too. We are concentrating our efforts on ifx to make it the best in the industry.

Please continue to report any issues you find. Remember that ifx and ifort share the same front-end. Fixes that relate to the front-end benefit both compilers.

This particular issue is in the code generator.

Thank you for your efforts to help us improve our products.