https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
Damian Rouson <damian at sourceryinstitute dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #8 from Damian Rouson <damian at sourceryinstitute dot org> --- Steve, one more question. How do you interpret the second sentence in the text that I originally quoted: "In each execution of the program with the same execution environment, if the invoking image index value in the initial team is the same, the value for PUT shall be the same." This is in 16.9.155 Case (i) describing the relationship between random_init and random_seed. I originally interpreted this quote to mean that each image would use the same seed each time the program runs, which would be a constraint on the PRNG. I'm now thinking that the reference to PUT implies that the user is setting the seed and this is saying that the program must set the same seed each a given image executes, but that seems like an odd constraint so I'm probably still horribly confused. Feel free to mark this issue as invalid if this is starting to seem like a waste of time. I'm just trying to understand. Either way, an image number is defined for all programs whether or not there are coarrays anywhere in the program and whether or not the program is ever executed in multiple images -- for example, this_image() is just an intrinsic function rather than a (hypothetical) "coarray" intrinsic function. This point is most meaningful with a compiler like the Cray compiler, which requires no special flags to compile a program that invokes this_image(). In some sense, all Fortran programs are now parallel programs whether the user takes advantage of that fact in any explicit way or not. I suspect that's the reason that IMAGE_DISTINCT is not optional. Possibly the committee deemed it better to require users to specify the desired behavior in multi-image execution. Even libraries that were never designed in any way to exploit parallelism can be linked into parallel programs so it seems better to have developers of such a library specify the desired behavior if their code is ultimately linked into a parallel program -- analogous to requiring that code be thread-safe even if the code makes no explicit use of multi-threading.