runtime failure at the start of a job with gfortran-mp-14

[Dave Allured - NOAA Affiliate]

Paolo, you mentioned dealing with large matrices.  Some modern platforms do
not correctly handle extremely large static arrays.  This matches your
scenario very nicely.  Most programs run fine, but nisclue.f is
consistently the rogue.  This is discussed competently in this post.
Scroll down to "Your third-party tooling is generating a huge static data
structure, something that’s not compatible with the Apple silicon runtime
model".  They are specifically discussing M1's, but I suspect it is about
the same for all modern macs.

      https://developer.apple.com/forums/thread/722360

I have run into this myself.  The cure is absurdly simple, even with
ancient fortran code.  Locate your most gigantic arrays, and switch them
from static to dynamic allocation at the start of the program.  Probably
you only need to change few of the worst offenders, leave all the small
ones alone.  The magic number on modern macs seems to be 2 GBYTES, and that
is probably TOTAL static allocation.  For example:

      <    real monster(5000,1000,1000)

      >    real, allocatable :: monster(:,:,:)             ! in declarations
      >    allocate (monster(5000,1000,1000))     ! in executable area

Yes, you are contaminating archaic fortran with a little bit of fortran 90,
but gfortran and others handle this very well.  You may also see collateral
benefits such as smaller executable, and faster compile and run startup
times.  BTW this works the same for both C and fortran arrays, IIRC.  I use
modern gfortran's on Mac all the time, and they continue to work fine for
complex projects.


On Tue, Oct 1, 2024 at 10:36 AM P. Denti via macports-users <
macports-users at lists.macports.org> wrote:
Subject: Reply to Maxim Abalenkov + a pair of sad reflections

Hello Maxim,
> thank you very much for indicating the article on Apple Developer.
> I am final user of Fortran as a  physicist who developed some research
> software just in Fortran.
> The hardware based on Intel CPU i7 is about nine-years-old, so that I
> bought a new iMac M3.
> The new software Sonoma, now Sequoia, according to the article have an
> architecture that is responsible for the signaled failure.
>
> It is a pity that, attempting to work around the difficulty on Fortran
> changing gcc port, I found all gcc's  branded as notoriously not working,
> with the (apparent!) exception of gcc14.
> As a naive user, I now think that problems with Fortran could be overcome
> with appropriate patches to the linker. But, according to article, the
> problem is rather old…
>
> Otherwise inconvenient is the building procedure of gcc and its library:
> for around an hour the cpu cores temperature is 100-108 Kelvin, on account
> that no fan is present in iMac ...
>
> Thank you,
> best wishes,
> Paolo



On Tue, Oct 1, 2024 at 3:27 AM Maxim Abalenkov <maxim.abalenkov at gmail.com>
wrote:

> Hello Paolo,
>
> How are you? A quick search on the Internet results in the following links:
>
>
> https://stackoverflow.com/questions/74909796/missing-libsystem-b-dylib-file-on-macos
>
> https://stackoverflow.com/questions/70549365/why-are-my-system-libraries-and-frameworks-not-visible-in-macos-monterey
> https://developer.apple.com/forums/thread/655588
>
> The article on the Apple Developer forum may be most helpful for you.
> Thank you and have a great day ahead!
> —
> Best wishes,
> Maxim
>
> Maxim Abalenkov \\ maxim.abalenkov at gmail.com
> +44 7 486 486 505 \\ www.maxim.abalenkov.uk
>
> On 1 Oct 2024, at 10:16, P. Denti via macports-users <
> macports-users at lists.macports.org> wrote:
>
> Failure starting with OS Sonoma, now with Sequoia.
> Processor is M3 on iMac.
>
> The following message in Sonoma:
>
> paolo in ~/Desktop/nisclue240 $ ./nisclue
> dyld[78445]: dyld cache '(null)' not loaded: syscall to map cache into
> shared region failed
> dyld[78445]: Library not loaded: /usr/lib/libSystem.B.dylib
>  Referenced from: <A5EF4235-E54A-3375-A9DC-4278E534593E>
> /Users/paolo/Desktop/nisclue240/nisclue
>  Reason: tried: 'usr/lib/libSystem.B.dylib' (no such file),
> '/System/Volumes/Preboot/Cryptexes/O/uS/usr/lib/libSystem.B.dylib' (no such
> file), '/usr/lib/libSystem.B.dylib' (no such file, no dyld cache)
> Abort trap: 6
>
> Analogous response in Sequoia.
>
> Additional information:
> The same job runs until completion on a  previous iMac with processor i7
> with OS Monterey.
>
> nisclue from nisclue.f is the only job in a dozen of similar jobs that
> refuses to work;
> a common feature of these jobs is  dealing with large matrices.
>
> If this information is insufficient, and sources and data involved are
> required, I  will post.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20241001/5a3ec561/attachment.htm>