https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014
--- Comment #8 from Harald Anlauf <anlauf at gmx dot de> --- (In reply to Keith Lindsay from comment #6) > Harald, > > The problem does go away if I add a PRIVATE(i) clause to the OMP directive. > > However, my understanding of OpenMP in fortran is that all loop iteration > variables, even inner nested loops, in an OpenMP PARALLEL DO construct (and > some others) are private by default. I.e., they do not need to be declared > private in the OMP directive. (I think this specification is different than > the specification for inner loops in C.) The OpenMP 4.5 standard says (2.15.1.1, for Fortran): - The loop iteration variable(s) in the associated do-loop(s) of a do, parallel do, taskloop, or distribute construct is (are) private. [...] - A loop iteration variable for a sequential loop in a parallel or task generating construct is private in the innermost such construct that encloses the loop. [...] Now the question is: what are the "associated do-loop(s)"? And what exactly does the second item above mean? I'm not too versed in reading the standard, and I tend to be on the conservative side here and interpret the ASSOCIATE construct to generate something like a BLOCK that makes things interesting, so that the i loop is to be dealt with separately. (I usually declare all loop variables explicitly.) What do you get when replacing ASSOCIATE by BLOCK/END BLOCK? I'd expect you experience the same problem. > Indeed, if I comment out the associate construct, the problem goes away. So > I'm inferring that the associate construct is interfering with the inner > loop index being assigned the private attribute. > > Keith I would recommend to always validate OpenMP parallelized code under some suitable tool, like valgrind/helgrind, gcc/thread-sanitizer, or Intel Inspector. Don't rely on just running your code. (I get a possible data race when running your original code under valgrind with gfortran and ifort, and a cross-thread stack access with ifort/Intel Inspector for the line doing the accumulation. However, I also get this for the fixed code.) If you need more insight on what gfortran is doing, add the option "-fdump-tree-original" and compare the resulting intermediate files *.003t.original.
