Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
27232 Discussions

ifort: do concurrent locality specifiers appear to be ignored


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

      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 #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.



0 Kudos
1 Reply
Honored Contributor II

@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:


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