On Mon, Jan 08, 2018 at 06:51:06PM -0800, Jerry DeLisle wrote: > On 01/08/2018 04:58 PM, Steve Kargl wrote: > > On Sun, Jan 07, 2018 at 06:52:22PM -0800, Steve Kargl wrote: > >> > >> I have zero knowledge about co-arrays and especially zero > >> knowledge about gfortran internals for co-arrays. I'm > >> disinclined to waste another 12 hours trying to get gfortran > >> to emit essentially a call to this_image(). See iresolve.c > >> for details. > >> > > > > An epiphany came to me last night, which has led to the attach > > patch. This patch should be a complete implementation of > > RANDOM_INIT. > > > > RANDOM_INIT takes two LOGICAL, INTENT(IN) arguments. To > > avoid library bloat, these arguments are converted/casted to > > LOGICAL(4) in trans-intrinsic.c (conv_intrinsic_random_init). > > It is also in this function, that I set up the hidden argument > > that is needed to hopefully give standard conforming behavior > > when co-arrays are involved. I, however, cannot test -fcoarray=lib > > situation. I would appreciate feedback from a co-array user. > > > > Boostrapped and regression tested on x86_64-*-freebsd. > > OK to commit? > > > > Yes, Looks good Steve. So all we need is a run test with actual =lib case. >
Yes. If someone adds this to a program that creates two images, and each image executes foo subroutine foo character(len=10) name real x(2) integer fd write(name,'(A,I0)') 'dat', this_image() call random_init(repeatable=.true., image_distinct=.true.) call random_number(x) open(newunit=fd,file=name) write(fd,*) x close(fd) end program then dat0 and dat1 will contain distinct numbers, and everytime the program executes the new dat0 and new dat1 should match the old dat0 and dat1. If repeatable=.false., then dat0 and dat1 will still be distinct sequences. Repeated execution of the program will cause the new dat0 and new dat1 to not match the old dat0 and old dat1. -- Steve
