I was experimenting with OpenMP reductions in Fortran and I found some strange behaviour with the 21.11 release of NVHPC compilers. I did my best to reduce the scope of the program, and I built the following Fortran code.
Essentially it looks like:
if the array in the reduction in the subroutine has the same name as the array in the reduction at the top, the code crashes if -Mbounds is enabled. But lbound() and ubound() at runtime are still well behaved.
If I rename “tmp_arr” in the subroutine to “tmp_arr2”, then I don’t get the bug (unless I duplicate the subroutine call on line 35).
I think maybe the code can be further simplified. The fact that we start with a derived tape seems to be completely irrelvant.
The error (and how it’s compiled) is documented at the bottom of:
My first question:
Have I violated the OpenMP standard with my reduction?
Can you reproduce the error?
On the main branch, there are a number of other reductions in the test_reduce.F90 file. The #defines in the header for NVHPC, and the output in the README.md show which cases seem correct/false/won’t compile/run.
nvfortran seems to support fewer approaches c.f. gfortran and ifort. I don’t know if these are bugs per se or not.