ifort: do concurrent locality specifiers appear to be ignored

[hsnyder]

Hi everyone.

I noticed that ifort doesn't seem to respect locality specifiers in `do concurrent` statements. For example, I believe the following should not compile, since default(none) is present, but I'm not explicitly indicating that the variables inside the loop are local(), local_init(), or shared()

module m_demo
      implicit none
contains

      function demo_f(a,b)
          real, contiguous, intent(in) :: a(:), b(:)
          real :: demo_f(size(a)), c(size(a))

          c = 1
          !dir$ loop count min(512)
          do concurrent (integer :: i = 1:size(a)) default(none)
            demo_f(i) = sin(a(i)) + exp(b(i))
            c(i) = c(i) + sin(a(i)) + 14.2*sqrt(b(i))
          end do
          demo_f = demo_f + c
      end function

end module

 Furthermore, when this is compiled with `ifort -O3 -c -parallel -qopt-report=3`, the resulting optimization report says:

remark #17109: LOOP WAS AUTO-PARALLELIZED
remark #17101: parallel loop shared={ } private={ } firstprivate={ ? c i } lastprivate={ } firstlastprivate={ } reduction={ }

To me, this suggests that OpenMP is being used under the hood to parallelize the loop, and the variables `c` and `i` are being given firstprivate status. Adding `shared(c)` to the end of the do concurent statement doesn't change this.

I think this is a bug, but I'd love to know if it's just a misunderstanding on my part. I'm on Linux (Ubuntu 20.04 LTS), using ifort 2021.3.0 20210609.

Thanks,
Harris

[FortranFan]

@hsnyder ,

Intel Fortran compiler appears not to conform to the standard here, the latter being clear with a constraint - C1130 - in its document about requiring the locality-spec of variable(s) in the DO construct to be specified by locality statement(s) when DEFAULT(NONE) is in effect.  Thus a bug in the compiler.

If you have support subscription procured with Intel, you can submit a support request toward a bug resolution at Intel OSC:

https://supporttickets.intel.com/servicecenter?lang=en-US

Or, someone from the Intel staff is likely to pick up the issue from this thread.