Discussion on the OpenMP specification run by the OpenMP ARB. OpenMP and the OpenMP logo are registered trademarks of the OpenMP Architecture Review Board in the United States and other countries. All rights reserved.
i.e. using an operator in the clause and another in the actual code.
Do you think it would be good to add something like a Restriction in the reduction clause to avoid this mixture so that compilers can check an generate an error or it is better to leave this as a bug?
There are at least three reasons that this shouldn't be a restriction:
- It can't in general be checked at compile time
- The obvious implementations are unable to enforce such a restriction
- We want to leave the door open for future extensions for user-defined reductions
The opinion of the ARB is that we made a mistake a long time ago in describing reductions as we did. A proper description of reductions requires only a private copy, an identity, and a combination operation. The compiler and runtime have no control over anything that happens to the private copy. The specification then specifies only how the private copies are initialized, how they are combined, and that the result is assigned to the original shared variable.
I thought that having explicitly declared the variable and the operator it would be "easy" for a compiler to check for that restriction (I have the AST in mind...), but I'm not a compiler writer, I was just guessing.
It is not necessarily easy for the compiler to check. What happens if the reduction code is in a subroutine compiled separately. Then to do the check, you have to require that the compiler does interprocedural analysis, which not all compilers do. Or what about the case with min or max where you are checking the values with an if statement (if x < y) then max = y). Then the compiler has to be smart enough to know what a min and max looks like. As lfm stated, there are many cases where it is just not possible to check without limiting the functionality greatly.