Different OpenMP behavior between gfortran and nvfortran

[patrick.begou]

Hi, I’m still in the porting phase of a large Fortran code from Gfortran to NVfortran and I have a different behavior that can be illustrated with the small following test code. In my mind, nvfortran 22.2 is wrong but it could be also gfortran (not a large OpenMP experience). Indeed I need to have the same behavior…

Code:

module mod1
  implicit none
  integer ::nsolver,current_solver
  !$OMP THREADPRIVATE(nsolver,current_solver)
end module mod1

program main
use mod1

implicit none
  nsolver=3
  current_solver=nsolver+1

  !$OMP PARALLEL DEFAULT(PRIVATE) &
  !$OMP COPYIN(nsolver,current_solver)
  print*, 'test ',nsolver,current_solver
  !$OMP end PARALLEL
end program main

Using gfortran and 4 threads:

> bash-4.4$ gfortran -fopenmp main.f90
> bash-4.4$ ./a.out
>  test            3           4
>  test            3           4
>  test            3           4
>  test            3           4

Using nvfortran and 4 threads:

> bash-4.4$ nvfortran  -mp=multicore main.f90
> bash-4.4$ ./a.out 
>  test             3            4
>  test             3            0
>  test             3            0
>  test             3            0

With nvfortran the second threadprivate variable is not initialized by the copyin clause, only the first one.
Any suggestion ?
Thanks
Patrick

[MatColgrove]

Hi Patrick,

I agree that something’s off in our compiler. Looks like only one threadprivate variable is getting initialized depending upon which is declared first. If I reverse the order so that “current_solver” is declared first, then the threads gets set correctly but “nsolver” does not.

I’ve added TPR #31460 and sent it to engineering for investigation.

Thanks for the report!
Mat

[MatColgrove]

Hi Patrick,

FYI, TPR #31460 has been fixed in our 22.7 release.

Thanks again for the report,
Mat

[patrick.begou]

Thanks Mat
I’ve deployed 22.7 last week before leaving for some hollidays but not tested.
It’s good news.
Patrick