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

Reply via email to