Linux Fortran OpenMP - accessing global variables from a subroutine called from an OpenMP task

Question

Is it legal/valid to access program global variables from an internal subroutine called from an OpenMP task?

ifort 2021.7.0 20220726 doesn't report an error, but appears to produce random results depending on compiler options. 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:

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

Obtained result:

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

Note: the order of output lines doesn't matter --- just the number 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.

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.

Thanks, Peter McGavin.

Wavawave

It looks like a bug at first glance. It works with gfortran. – Elyn

Using global variables in contains routines is usually a bad idea. Can you put those variables in a module? – Septempartite

Global variables are usually a bad idea full stop, especially when parallelism is involved. I'm not sure modules are massively better than via host association. – Supervisor

Second the compiler bug theory - this works for me with gfortrans 9.4.0 and 10.3.0, ifort 2021.6.0 20220226 and ifx 2022.1.0 20220316 . What version of ifort are you using? Does it work if you download the latest and possibly greatest? – Supervisor

Ian, I tested with ifort versions 2021.2.0 20210228 and 2021.7.0 20220726, the latter included in Intel's latest oneAPI HPC Toolkit downloaded yesterday. The example I posted works OK with just "-qopenmp" but fails when "-check all" or "-O0" are added. More complex examples I tried fail with just "-qopenmp". – Wavawave

OK - I can repeat that, without -O0 or -check all it works, with them it gives the wrong answer. I still think it is a compiler bug - I would report to Intel – Supervisor

Interestingly ifort -qopenmp -check all,nostack ompgl.f90 works which to me strongly suggests that it is a compiler bug associated -check stack - hopefully this also gives a partial workaround – Supervisor

Thanks Ian. Actually I tried posting to the the Intel Fortran Forum before posting here, but my message was immediately marked as spam and the moderator did not respond to my message. I don't know how else to report a compiler bug to Intel. – Wavawave

That's ... disappointing. Maybe Steve Lionel who is sometimes seen here can point you in the right direction. – Supervisor

Answer 1

Please try the oneAPI compiler package 2022.2 or 2022.3.

/iusers/xtian/temp$ ifx -qopenmp  jimtest.f90
/iusers/xtian/temp$ ./a.out
           2           2          42
           1           1          42
           3           4          42
           5          16          42
           4           8          42
           6          32          42

Tartarus

2022.3 Release is externally available intel.com/content/www/us/en/developer/tools/oneapi/… – Tartarus

Note that the question uses ifort, not ifx. Does the problem exist in older versions of ifx? Does it exist in the new version of ifort? – Chook

ifx version 2022.2.0 20220730 fails with the "-check all", "-check stack" or "-O0" option. I'm about to try 2022.3. – Wavawave

@Tartarus One of the points of the question is it works with earlier versions ifort or ifx if compiled as you suggest, but fails if you add the flags listed above by Peter. Please see my comments below the question – Supervisor

The ifort and ifx compilers in the 2022.3 HPC pack also fail for me with any of the "-check all", "-check stack" or "-O0" options. They are ifort 2021.7.0 20220726 and ifx 2022.2.0 20220730 – Wavawave

For -check all, -cheack stack support, please try 2022.3. Thanks. – Tartarus

If you still see fails, file a JIRA report by contacting our compiler support team. We will look into that. Thanks. – Tartarus

xtian, I am using the 2022.3 HPC pack. The Fortran compilers in the 2022.3 HPC pack are ifort 2021.7.0 20220726 and ifx 2022.2.0 20220730. I don't know how to get any higher numbered compilers. – Wavawave

Filing a JIRA report by contacting the Intel compiler support team appears to require a paid subscription. In any case, my post to the Intel Fortran Forum has been accepted now. – Wavawave

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Indebted

Added the link to the Intel support. intel.com/content/www/us/en/developer/tools/oneapi/… – Tartarus

community.intel.com/t5/Intel-Fortran-Compiler/bd-p/… This link has more Fortran related information. Thanks. – Tartarus