From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by sourceware.org (Postfix) with ESMTPS id 2E922385DC2E for ; Sun, 4 Apr 2021 05:34:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2E922385DC2E Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1345XWDC018141 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 3 Apr 2021 22:33:44 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1345XVOA018140; Sat, 3 Apr 2021 22:33:31 -0700 (PDT) (envelope-from sgk) Date: Sat, 3 Apr 2021 22:33:31 -0700 From: Steve Kargl To: Damian Rouson Cc: gfortran , Andre Vehreschild Subject: Re: RANDOM_INIT() and coarray Fortran Message-ID: <20210404053331.GA18048@troutmask.apl.washington.edu> References: <20210403172846.GA14134@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2021 05:34:10 -0000 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