Re: RANDOM_INIT() and coarray Fortran

[Steve Kargl <sgk@troutmask.apl.washington.edu>]

On Sat, Apr 03, 2021 at 08:30:31PM -0700, Damian Rouson wrote:
> Hi Steve,
> 
> I hope the gfortran developers won't commit a patch that replaces
> existing behavior with a stub that simply emits an error message.

The current behavior is incorrect with respect to the Fortran standard
if one runs a compiled program multiple times.  The patch fixes a bug.

> It has been a while since I looked at the previous emails regarding
> problems with the current behavior so I'm not expressing an opinion
> about the current behavior.  I'm simply advocating against breaking
> existing codes that rely on the current behavior if nothing better is
> being provided.

It cannot be helped.  The underlying coarray implementation must
handle RANDOM_INIT().  AFAICT, there must be communication between
images if RANDOM_INIT() is used.  libgfortran is not compiled with
-fcoarray=lib (or -fcoarray=shared), so the coarray implementation(s)
must deal with RANDOM_INIT().

> Or as a compromise, would you mind changing the patch so that the
> error message is emitted only in the problematic cases? You presented
> one problematic case out of the four possible combinations of
> RANDOM_INIT() arguments.  With only four possible combinations to
> enumerate, I hope this suggestion isn't burdensome.
Consider,

   read(*,*) repeatable, image_distinct
   call random_init(repeatable, image_distinct)

for -fcoarray=none or -fcoarray=single, the image_distinct
argument is irrevelant.   This is simply translated to 

_gfortran_random_init(repeatable, image_distinct)

For -fcoarray=lib (and by extension OpenCoarray), a simple 1 line
patch on top of my patch would generate

_gfortran_caf_random_init(repeatable, image_distinct)

where is it assumed the function is coarray aware.  Similarly, if
-fcoarray=shared, then a 1 line patch would generate 

_gfortran_cas_random_init(repeatable, image_distinct)

where is it assumed the function is coarray aware.

There are 4 cases:
(1)   repeatable=.true., image_distinct=.true. 
(2)   repeatable=.true., image_distinct=.false.
(3)   repeatable=.false., image_distinct=.true.
(4)   repeatable=.false., image_distinct=.false.

IIRC, cases (1)-(3) don't require communication.  case (4) does.
That is, case (4) requires the same set of random seeds to be
used on all images.

> Regarding "someone who cares about coarray Fortran," finding people to
> work on such an effort is quite challenging.

Finding people willing to work on gfortran is as challenging if
not more so.  A year ago, I posted in c.l.f a list of 20+ PRs
with patches that I had created.  I don't do git.  It would take 
someone with git-fu little time to take my patches and apply 
them to a source tree.  Testing was done by me, but I would
encourage git-fu aware individuals to bootstrap and test the patches.
Then commit the patch.  Harald has stepped up and grabbed a few.
TO BE CLEAR, I AM NOT RANTING AT THE PEOPLE WHO HAVE CONTRIBUTED
AND MAINTAINED GFORTRAN FOR YEARS.  gfortran needs new blood, or
it is destined for the bit bucket.

> I believe Andre
> Verheschild has some limited availability so I'm cc'ing him and will
> discuss it with him if he's interested.  If you know others who might
> be interested, please let us know.

Don't know any new people who are interested in gfortran.

-- 
Steve