Hi Jerry,
I hope you have more luck with updating the branch. The last time I did it, I
blocked the whole gcc repository for over 1.5h and the admins had to terminate
a script on the server manually. I therefore leave my fingers well clear from
doing this again.
Regards,
Andre
On Wed, 1 Oct 2025 08:03:57 -0700
Jerry Delisle <[email protected]> wrote:
> I will work toward getting these patches on the devel branch I set up for
> this.
>
> Cheers,
>
> Jerry
>
> On Wed, Oct 1, 2025, 7:13 AM Iain Sandoe <[email protected]> wrote:
>
> > Hi Andre
> >
> > > On 1 Oct 2025, at 14:52, Andre Vehreschild <[email protected]> wrote:
> >
> > > attached series of patches adds more stable support for running shared
> > > memory multi process Fortran programs on MacOS. The only new part is the
> > last
> > > (the pr88076_v4_9.patch). Changes in the former files are only results of
> > > rebasing.
> > >
> > > On MacOS shared memory coarrays face the issue of having to have the
> > shared
> > > memory segment at the same (virtual) base address in all
> > processes/images, but
> > > the OS not always complying to our wish. The supervisor of the coarray
> > program
> > > therefore now is able to restart an image, when the OS is not complying
> > to put
> > > the shared memory segment where we need to have it. The shared memory
> > segment
> > > needs to be at the same address in all images, because else shared
> > mutexes tend
> > > malfunction. I haven't found any documentation from Apple or the
> > > MachOS kernel why this is that way, but it unfortunately is. The number
> > of
> > > restarts of images is limited. I.e. this is not going on forever, but
> > one can
> > > either set a (documented) environment variable, or got with the default
> > of
> > > 4000 at the moment. The count on restarts is total on all images and not
> > per
> > > image.
> >
> > I would expect that if one wanted a shared memory segment then it would be
> > allocated
> > in one place and the address made available to other consumers; there are
> > provisions
> > for asking for a particular address from mmap too ….
> >
> > Maybe I can help with this - but I would need to understand first what you
> > are
> > currently trying to do - and what results it gets. I think last time I
> > tried the coarrays
> > stuff there were build problems so I did not even get this far.
> >
> > Is there a development branch somewhere I can build?
> >
> > > It took me quite some time to figure what was going on and I had to fix
> > > libsanitizer on macOS for newer OS releases,
> >
> > How, exactly, did you do this?
> >
> > The sanitizers are currently disabled on newer macOS because the API to get
> > the address of the dynamic linker uses Apple Blocks which GCC does not yet
> > support. I have in mind a work-around but not had a chance to try it yet,
> >
> > > which being unfamiliar took me
> > > even longer. There might be other issues fixed unintentionally by these
> > > patches. So feel free to test.
> >
> > I will try to fit this in - if you can point me at a suitable branch - to
> > make sure I’m
> > looking at the same thing as you.
> >
> > thanks
> > Iain
> >
> > > Regtested ok on x86_64-pc-linux-gnu / F41, x86_64-w64-win32 / MSYS2 /
> > UCRT64 and
> > > x86_64-apple-darwin24.something. (Testing on MSYS2/UCRT64 gives tons of
> > fails
> > > of 'excess output' tests, which stem from gfortran emitting some escape
> > code,
> > > which doesn't even print, and expect picking it up.)
> > >
> > > Regards,
> > > Andre
> > >
> > > On Wed, 10 Sep 2025 13:31:01 -0700
> > > Jerry D <[email protected]> wrote:
> > >
> > >> On 9/2/25 2:51 AM, Andre Vehreschild wrote:
> > >>> Hi all,
> > >>>
> > >>> attached series of patches updates the coarray shmem gfortran series of
> > >>> patches. It now has support for building on Window's Cygwin and
> > Window's
> > >>> MSYS2/UCRT64. Building on the latter is quite tricky. When you want to
> > do
> > >>> that, I recommend getting the source package for gcc-15 from the msys
> > >>> website and adapting it. Nevertheless it is very fiddly to get it to
> > build.
> > >>> Most of the regression test on MSYS2/UCRT64 report "Excess errors" on
> > the
> > >>> compile step, which is due to gfortran emitting some escape codes,
> > that do
> > >>> not print, but "expect" regards them as output.
> > >>>
> > >>> I have deliberately (rebased and) updated the gfortran-test branch
> > also, so
> > >>> that you can get the newest version from there, too.
> > >>>
> > >>> Regtests ok on x86_64-pc-linux / F41 and x86_64-pc-cygwin / Win10.
> > >>>
> > >>> After hopefully having Windows wrestled down now, I will tackle MacOS
> > not
> > >>> having a sane process parallel mutex.
> > >>>
> > >>> Have fun testing.
> > >>>
> > >>> Regards,
> > >>> Andre
> > >>
> > >> Hi all,
> > >>
> > >> Pinging here as a reminder. I have managed to apply the new patches but
> > I
> > >> have not had time to test. I also found a Cygwin installation on one
> > of my
> > >> computers here but have not tried anything there yet.
> > >>
> > >> Andre,, this is going to take some time and I hope to get to this.
> > >>
> > >> Regards,
> > >>
> > >> Jerry
> > >
> > >
> > > --
> > > Andre Vehreschild * Email: vehre ad gmx dot de
> > >
> > <pr88076_v4_1.patch><pr88076_v4_2.patch><pr88076_v4_3.patch><pr88076_v4_4.patch><pr88076_v4_5.patch><pr88076_v4_6.patch><pr88076_v4_7.patch><pr88076_v4_8.patch><pr88076_v4_9.patch>
> >
> >
--
Andre Vehreschild * Email: vehre ad gmx dot de
