RANDOM_INIT() and coarray 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 code:
subroutine foo
call random_init(.true., .false.)
end subroutine foo
I have updated the patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301
to use a stub routine for -fcoarray=lib and -fcoarray=shared.
Anyone, who knows how to use git, is encouraged to commit the patch.
For -fcoarray=none (default option) and -fcoarray=single, the
patch will cause gfortran to generate
__attribute__((fn spec (". ")))
void foo ()
{
_gfortran_random_init (1, 0, 0);
}
_gfortran_random_init() live in libgfortran and it has been updated
to meet the intended requires of the Fortran standard.
With -fcoarray=lib and -fcoarray=shared, gfortran will now generate
__attribute__((fn spec (". ")))
void foo ()
{
_gfortran_random_init_foobar (1, 0);
}
where _gfortran_random_init_foobar() lives in libgfortran. It prints
an error message that RANDOM_INIT() is not yet supported for coarray
Fortran and exits. Someone, who cares about coarray Fortran, can fix
-fcoarray=lib and -fcoarray=shared by updating trans-decl.c (see the
FIXME for random_init()) to emit
__attribute__((fn spec (". ")))
void foo ()
{
_gfortran_caf_random_init (1, 0);
}
or
__attribute__((fn spec (". ")))
void foo ()
{
_gfortran_cas_random_init (1, 0);
}
--
Steve
gfortran, OpenMP and static linking
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_THREADS=1 ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. [...] Running under gdb: Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x00405198 in __gthread_mutex_destroy (__mutex=0x72ced8) at ../libgcc/gthr-default.h:739 #2 destroy_unit_mutex (u=0x72ce00) at ../../../libgfortran/io/unit.c:252 #3 close_unit_1 (u=0x72ce00, locked=locked@entry=1) at ../../../libgfortran/io/unit.c:743 #4 0x00405202 in _gfortrani_close_units () at ../../../libgfortran/io/unit.c:780 #5 0x0044c53c in __libc_csu_fini () at elf-init.c:100 #6 0x00452ef0 in __run_exit_handlers (status=0, listp=0x720630 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:83 #7 0x00452f4a in exit (status=) at exit.c:105 #8 0x0044bdc6 in __libc_start_main (main=0x4030bd , argc=1, argv=0x7fffc348, init=0x44c470 <__libc_csu_init>, fini=0x44c510 <__libc_csu_fini>, rtld_fini=0x0, stack_end=0x7fffc338) at ../csu/libc-start.c:342 #9 0x00402fba in _start () at ../sysdeps/x86_64/start.S:120 I suspect either a locking issue for unit_root in unit.c, or maybe bad initialization of it, but haven't stared long enough at the code. According to git blame almost all related references date back to 2005. Shall I open a PR against libfortran? Or is there something I am missing? Thanks, Harald
Re: gfortran, OpenMP and static linking
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 was, at least in former times) or if thread cancellation still is supposed to work in a pure static build. As said, maybe Jakub can help. thanks, > >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_THREADS=1 ./a.out > >Program received signal SIGSEGV: Segmentation fault - invalid memory >reference. >[...] > >Running under gdb: > >Program received signal SIGSEGV, Segmentation fault. >0x in ?? () >(gdb) bt >#0 0x in ?? () >#1 0x00405198 in __gthread_mutex_destroy (__mutex=0x72ced8) >at ../libgcc/gthr-default.h:739 >#2 destroy_unit_mutex (u=0x72ce00) at >../../../libgfortran/io/unit.c:252 >#3 close_unit_1 (u=0x72ce00, locked=locked@entry=1) at >../../../libgfortran/io/unit.c:743 >#4 0x00405202 in _gfortrani_close_units () at >../../../libgfortran/io/unit.c:780 >#5 0x0044c53c in __libc_csu_fini () at elf-init.c:100 >#6 0x00452ef0 in __run_exit_handlers (status=0, listp=0x720630 ><__exit_funcs>, >run_list_atexit=run_list_atexit@entry=true, >run_dtors=run_dtors@entry=true) at exit.c:83 >#7 0x00452f4a in exit (status=) at exit.c:105 >#8 0x0044bdc6 in __libc_start_main (main=0x4030bd , >argc=1, >argv=0x7fffc348, init=0x44c470 <__libc_csu_init>, fini=0x44c510 ><__libc_csu_fini>, >rtld_fini=0x0, stack_end=0x7fffc338) at ../csu/libc-start.c:342 >#9 0x00402fba in _start () at ../sysdeps/x86_64/start.S:120 > > >I suspect either a locking issue for unit_root in unit.c, or maybe bad >initialization of it, but haven't stared long enough at the code. >According to git blame almost all related references date back to 2005. > >Shall I open a PR against libfortran? Or is there something I am >missing? > >Thanks, >Harald
Re: RANDOM_INIT() and coarray Fortran
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 behavior. I'm simply advocating against breaking
existing codes that rely on the current behavior if nothing better is
being provided.
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.
Regarding "someone who cares about coarray Fortran," finding people to
work on such an effort is quite challenging. 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.
Damian
On Sat, Apr 3, 2021 at 10:28 AM Steve Kargl via Fortran
wrote:
>
> 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 code:
>
> subroutine foo
>call random_init(.true., .false.)
> end subroutine foo
>
> I have updated the patch for
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301
> to use a stub routine for -fcoarray=lib and -fcoarray=shared.
> Anyone, who knows how to use git, is encouraged to commit the patch.
>
> For -fcoarray=none (default option) and -fcoarray=single, the
> patch will cause gfortran to generate
>
> __attribute__((fn spec (". ")))
> void foo ()
> {
> _gfortran_random_init (1, 0, 0);
> }
>
> _gfortran_random_init() live in libgfortran and it has been updated
> to meet the intended requires of the Fortran standard.
>
> With -fcoarray=lib and -fcoarray=shared, gfortran will now generate
>
> __attribute__((fn spec (". ")))
> void foo ()
> {
> _gfortran_random_init_foobar (1, 0);
> }
>
> where _gfortran_random_init_foobar() lives in libgfortran. It prints
> an error message that RANDOM_INIT() is not yet supported for coarray
> Fortran and exits. Someone, who cares about coarray Fortran, can fix
> -fcoarray=lib and -fcoarray=shared by updating trans-decl.c (see the
> FIXME for random_init()) to emit
>
> __attribute__((fn spec (". ")))
> void foo ()
> {
> _gfortran_caf_random_init (1, 0);
> }
>
> or
>
> __attribute__((fn spec (". ")))
> void foo ()
> {
> _gfortran_cas_random_init (1, 0);
> }
>
> --
> Steve
Re: RANDOM_INIT() and coarray 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 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
