[Bug fortran/98253] Conflicting random_seed/random_init results

[damian at sourceryinstitute dot org]

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.