Hi Iain,
thank you for testing. I know already about the missing <signal.h> include. It
is also needed on FreeBSD. What's new is the <sys/types.h>. Is that really
needed or is it transitively included by <signal.h>? Could you check by, for
example, just grepping signal.h for it?
grep 'sys/types.h' /usr/include/signal.h
As "hello world" so to say test every test under
gcc/testsuite/gfortran.dg/coarray can be used, for example get_array.f90. Most
tests do not output anything, well, because they are tests, but they run within
milliseconds usually.
What did you do in the hello.f90 program? I have never seen a hang in the init
phase. I also have no system available that runs Mac OS. This will get
interesting to debug. Any one also running Mac OS who can confirm?
Thanks again for testing,
Andre
On Tue, 22 Jul 2025 16:22:07 +0100
Iain Sandoe <i...@sandoe.co.uk> wrote:
> Hi Andre
>
> It would be very helpful if there were such a thing as a “hello-coarrays.fxx”
> code for those of us who do not have existing installations of mpi &c. aand
> limited time to so tests…
>
> … experiments so far - below
>
> thanks
> Iain
>
> > >> > > We like everyone to test the new caf_shmem library and report back
> > >> > > any problems, like "does not compile", "does not run" or "hangs
> > >> > > during execution”.
>
> On x86_64 Darwin, (macOS)
>
> 1. we need a small patch to build:
>
> diff --git a/libgfortran/caf/shmem/supervisor.c
> b/libgfortran/caf/shmem/supervisor.c index 9e5b794a23f..0e27d15ea52 100644
> --- a/libgfortran/caf/shmem/supervisor.c
> +++ b/libgfortran/caf/shmem/supervisor.c
> @@ -37,6 +37,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
> If not, see #elif HAVE_SYS_WAIT_H
> #include <sys/wait.h>
> #endif
> +#include <sys/types.h> /* for kill() */
> +#include <signal.h> /* for kill() */
>
> #define GFORTRAN_ENV_NUM_IMAGES "GFORTRAN_NUM_IMAGES"
> #define GFORTRAN_ENV_SHARED_MEMORY_SIZE “GFORTRAN_SHARED_MEMORY_SIZE”
>
> 2. If I try linking a trivial Fortran code thus:
>
> gfortran /src-local/test/fortran/hello.f90 -o h -lcaf_shmem -fcoarray=lib
>
> the exe then hangs - it looks like it might be deadlocked in startup code:
>
> Call graph:
> 2166 Thread_408707810 DispatchQueue_1: com.apple.main-thread (serial)
> + 990 _pthread_cond_wait (in libsystem_pthread.dylib) + 152
> [0x7ff818e29626]
> + ! 749 ??? (in <unknown binary>) [0x7ff8a93092f0]
> + ! 127 _pthread_cond_wait (in libsystem_pthread.dylib) + 147
> [0x7ff818e29621]
> + ! 114 pthread_testcancel (in libsystem_pthread.dylib) + 1
> [0x7ff818e2697f]
> + 630 _pthread_cond_wait (in libsystem_pthread.dylib) + 97,139,...
> [0x7ff818e295ef,0x7ff818e29619,...]
> + 537 counter_barrier_wait (in h) + 67 [0x1044a8a93]
> counter_barrier.c:71
> + ! 271 DYLD-STUB$$pthread_cond_wait (in h) + 0 [0x1044aa8e6]
> + ! 154 counter_barrier_wait (in h) + 62 [0x1044a8a8e]
> counter_barrier.c:71
> + ! 112 _pthread_cond_wait (in libsystem_pthread.dylib) + 1418,0
> [0x7ff818e29b18,0x7ff818e2958e]
> + 9 _gfortran_caf_init (in h) + 47 [0x1044a52ff] shmem.c:91
> + 9 counter_barrier_wait (in h) + 48 [0x1044a8a80]
> counter_barrier.c:70 2166 Thread_408707823: com.apple.rosetta.exceptionserver
> 2166 ??? (in runtime) load address 0x7ff7fff8b000 + 0x13e58
> [0x7ff7fff9ee58] 2166 ??? (in runtime) load address 0x7ff7fff8b000 +
> 0x123e0 [0x7ff7fff9d3e0] 2166 ??? (in runtime) load address 0x7ff7fff8b000
> + 0x4944 [0x7ff7fff8f944]
--
Andre Vehreschild * Email: vehre ad gmx dot de
