RANDOM_INIT() and coarray Fortran

2021-04-03 Thread Steve Kargl via Fortran
What to do about RANDOM_INIT() and coarray Fortran? The main issue is that if one compiles with -fcoarray=lib (or the WIP -fcoarray=shared), then RANDOM_INIT() may require communication between images. Thus, RANDOM_INIT() cannot live in libgfortran for at least -fcoarray=lib. Consider the simple

gfortran, OpenMP and static linking

2021-04-03 Thread Harald Anlauf via Fortran
Dear all, is there a reason that one should not be able to statically link a Fortran binary that has been compiled with -fopenmp? A tiny example seems to fail for me with all gfortran versions: program p !$omp parallel !$omp end parallel end % gfortran -fopenmp foo.f90 -g -static % OMP_NUM_THRE

Re: gfortran, OpenMP and static linking

2021-04-03 Thread Bernhard Reutner-Fischer via Fortran
On 3 April 2021 20:55:39 CEST, Harald Anlauf via Fortran wrote: >Dear all, > >is there a reason that one should not be able to statically link a >Fortran binary that has been compiled with -fopenmp? Maybe Jakub knows more on this. Not sure if static linking with glibc is still discouraged (it w

Re: RANDOM_INIT() and coarray Fortran

2021-04-03 Thread Damian Rouson
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. 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 b

Re: RANDOM_INIT() and coarray Fortran

2021-04-03 Thread Steve Kargl via Fortran
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