Hi Jerry, I am back on track.
I tried to replay your fault with my latest patch for pr88076 and the latest patch on the OpenCoarray's branch, namely this one: https://github.com/sourceryinstitute/OpenCoarrays/commit/47a7a470a0a88f8a9e8c72dfaa8ab685f6b58ecd I can not replay the error you got. For me the result for OpenCoarray evaluation is: $ time cafrun -np 8 ./tsunami ... step, min(h), max(h), mean(h): 998 -0.072279 0.188818 0.003907 step, min(h), max(h), mean(h): 999 -0.071815 0.190565 0.003907 step, min(h), max(h), mean(h): 1000 -0.071207 0.192070 0.003907 real 4m43,074s user 30m2,998s sys 0m50,211s and for shmem: $ gfortran -fcoarray=lib -O3 tsunami.f90 mod_*.o -lcaf_shmem -o tsunami_shmem $ GFORTAN_NUM_IMAGES=8 GFORTRAN_SHARED_MEMORY_SIZE=1G time ./tsunami_shmem ... step, min(h), max(h), mean(h): 998 -0.072279 0.188818 0.003907 step, min(h), max(h), mean(h): 999 -0.071815 0.190565 0.003907 step, min(h), max(h), mean(h): 1000 -0.071207 0.192070 0.003907 real 0m3,566s user 0m2,539s sys 0m2,702s Both result in the same values for h. Just a bit quicker. You are using freebsd on aarch64? Am I right? I will test on that, but it will take me ages, because I have to fully emulate the hardware. Regards, Andre On Tue, 8 Jul 2025 11:34:55 -0700 Jerry D <jvdelis...@gmail.com> wrote: > On the tsunami example from Curcic book Modern Fortran I am getting the > following: > > $ cafrun -np 4 ./tsunami > At line 201 of file mod_field.f90 > Fortran runtime error: Attempting to allocate already allocated variable > 'edge' At line 201 of file mod_field.f90 > Fortran runtime error: Attempting to allocate already allocated variable > 'edge' At line 201 of file mod_field.f90 > Fortran runtime error: Attempting to allocate already allocated variable > 'edge' At line 201 of file mod_field.f90 > Fortran runtime error: Attempting to allocate already allocated variable > 'edge' Error: Command: > `/usr/lib64/mpich/bin/mpiexec -n 4 ./tsunami` > failed to run. > > It compiles fine. This is with OpenCoarrays using mpich. > > With -lcaf_shmem it segfaults. > > Does this look like one of the other bugs already identified? > > The source code is here: > > https://github.com/modern-fortran/tsunami > > Jerry > On 7/7/25 2:00 PM, Jerry D wrote: > > Hello all, > > > > I have done the following to test the collection of Andre's patches which > > implement the subject -lcaf_shmem: > > > > 1) Successfully compiled and executed Toon's random_weather.f90 program. > > The only question I have on this one is when I select an np value such that > > the slab size does not come out even, the program exits as expected with a > > STOP code. However, I think this is performed by the first image to hit the > > stop. It looks like execution of the other images may just be frozen. I > > wonder if there are constraints in the standard regarding using a STOP > > within multiple images where each image may be trying to execute it? Is > > this a race condition or invalid Fortran. Ctrl-C does exit the program. > > > > 2) I can build and run OpenCoarrays with this test version of gfortran. > > However, when I do the usual 'make test', the test program > > register_alloc_vector hangs in a bad way with execution burning CPU cycles. > > Outside the OpenCoarrays test environment it appears to run correctly. > > While testing this with valgrind also hangs. It appears that valgrind is > > inside some memory check routine. I do not know if it is valid to even try > > to use valgrind with multiple images. So this test may be invalid. > > > > 3) I want to get broader testing of this so I set up a testing branch at > > the following location where others can clone this and test. > > > > https://forge.sourceware.org/JerryD/gfortran-TEST > > > > This is a test only repository and I intend to delete it after a few weeks > > until I can set up a better gfortran testing repo that is maintained > > current to trunk. One may have to register with sourceware to access this, > > I have not checked. I would appreciate anyone willing to build and test > > this branch to help flush out any issues. > > > > Feedback and/or test results welcome. > > > > Regards, > > > > Jerry > -- Andre Vehreschild * Email: vehre ad gmx dot de
