https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98253
--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Sat, Dec 12, 2020 at 11:55:41PM +0000, damian at sourceryinstitute dot org wrote: > 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. > It's been awhile since I implemented random_init(), and thought about the combinations for the two arguments. Presonally, I think the standard is flawed. If someone wants to review the wording of the standard and the implementation details of random_init(), I am certainly not going to object.
