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
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
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
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
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
