Pure functions not deterministic in serial and parallel loops

@plevold great example. Let’s analyze it.

I think the issue of main being “pure” is not relevant. In your second example, main is both side-effect-free and deterministic (well, it’s not deterministic in practice because of the “bug” that we are trying to identify and exclude using some rules; but it does not read from any global variables).

I think it’s the function h that must be both side-effect-free and deterministic. It is side-effect-free, but not deterministic: it depends on “A”, which would not be a problem if we never wrote to “A”. But the whole point of parallel loops is to write to some arrays (“A” in this case), so we have to modify some arrays. The whole point of a parallel loop is to produce a side effect.

But all that we are doing is just A(i) = h(A(i)). That should be allowed, but h must be both side-effect-free and deterministic.

So it seems to me one way to fix all of the above issues is to require in do concurrent (and in openmp loops) for all functions to be both side-effect-free as well as deterministic, which is the upcoming simple attribute in Fortran. So the compiler would say that A(i) = h(A(i)) is not allowed in do concurrent, because h is not “simple” (only “pure”, which is not enough).

I think also elemental should require the function to be simple, which would forbid the case above and both ifort and gfortran should then return exactly the same numbers.

1 Like