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?
Second question:
Can you reproduce the error?
Third question:
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.
Thanks for testing OpenMP array reductions. It’s a new feature so we appreciate you exercising it. It looks like there’s a few issues.
First, it looks like the array reductions are having issues when used within a contained subroutine. If you move this to a module, it should fine. I’ve added a problem report, TPR #31162, and sent to engineering for furthiner investigation.
Second, in the small example you include “tmp_arr” in both a “shared” and “reduction” clause. This is invalid but we accept it since “shared” can safely be ignored. However, gfortran flags it as an error. In order to help with portability between compilers, I’ve added a request that we flag this as an error as well. Filed as TPR #31163.
Finally in the full test_reduce.F90 code, you are also testing using array reductions on pointers and associate. We couldn’t find anything in the OpenMP standard that stated this shouldn’t be ok, but it’s just not something we support as of yet. Hence I added an RFE, TPR #31164, to see if it’s somethin we can add. Or if not, at least in the near future, catch this at compile time (like gfortran does). Note though we believe adding the array bounds to the array reduction when using pointers will be needed.
Many thanks for the reply!
As you can probably tell, this started out as “what’s the best way to do a reduction on an array in a derived type”, and various compilers seemed to like/dislike various ideas that I had.
In the end, it seemed interesting enough for me to make this test case of various recipes.
Thanks for passing on the various behaviour to the rest of the team.