From: Iain Sandoe <idsandoe@googlemail.com>
To: Rosemary Mardling <rosemary.mardling@monash.edu>,
James Secan <james.secan@gmail.com>,
Jerry DeLisle <jvdelisle2@gmail.com>
Cc: Fortran List <fortran@gcc.gnu.org>
Subject: Re: apple silicon fortran
Date: Fri, 8 Jan 2021 09:56:44 +0000 [thread overview]
Message-ID: <707CA4B6-DAAE-4DA6-A954-1E3ADE0CDA6B@googlemail.com> (raw)
In-Reply-To: <E44A1462-FE41-4F51-AB24-A107200E747D@monash.edu>
Hi Rosemay, Jim, Jerry, interested folks…
Rosemary Mardling via Fortran <fortran@gcc.gnu.org> wrote:
>
> Apple might be happy to lend you a machine if the absence of fortran is
> holding enough people back from buying them…
For the record, Apple have been very supportive of the GCC/gfortran effort
- by making DTK access available to me - it was just rather late in the
GCC11 cycle ...
In fact, none of the issues Jerry mentions are really the blockers:
- you can already get builds of the experimental branch from homebrew and macports
- ( and I would surely be willing to release mine, which are generally weekly, if someone has a suitable hosting site ).
The key problems are:
(1) macOS/Darwin support, like gfortran, is a volunteer effort and there’s
just not enough free time to progress it as if it was $dayjob
(2) the phasing of the macOS11 / Arm64 release was almost exactly on the
switch to stage #3 for GCC and we’re only a week away from stage #4 for
GCC11.
(3) The issues we face are not really gfortran ones; there are
approximately three tricky ones : two relate to removal of OS facilities
present in X86 Darwin (because the Arm64 port is more restrictive in the
name of security) and the third is just because the ABI for Arm64 has
differences from other cases which mean changes to common code for lowering
of function calls.
So, there are (and will continue to be) experimental compiler builds based
of master (and the 10 branch at some point) - but there’s still work to be
done before this can be presented for review and inclusion - which is not
likely to be until GCC12.
In the meantime - I’ve been working on including
(a) the fixes needed for macOS11 (common to X86 and Arm64)
(b) enabling fixes for the Arm64 port where those are suitable for posting at present
(c) looking at solutions to the known issues with the existing branch.
FWIW, GCC on macOS is not really so much an “odd duck” - indications via
the “distros” are that there are, in fact, a lot of GCC users (most GCC
installations are made that way, rather than built from source, I expect).
cheers
Iain
>> On 8 Jan 2021, at 1:32 pm, Jerry DeLisle <jvdelisle2@gmail.com> wrote:
>>
>>
>>
>> On 1/6/21 11:38 AM, James Secan via Fortran wrote:
>>> Thanks - I had already begun to suspect I’ll need to hold off a bit on
>>> getting an Apple Silicon machine, and this confirms it. I need
>>> gfortran to be working on whatever hardware I’m using.
>>>
>>> Jim
>> That may be the wise approach. Depending on how many users it may be
>> possible to get an unoffcial build if the branch gets far enough a
>> long. There was a time when we were doing daily or weekly builds for
>> odd ducks like Cygwin on Windows. This was back at the initial phases
>> of the F95 compiler.
>>
>> One of the big problems is not having hardware for us to test on. I
>> expect Iain and some the gcc other gcc gurus may have this access sooner
>> than the "Fortraners". If the OS is fairly compliant to standards, the
>> runtime libraries for gfortran should mostly work, its the nuances and
>> corner cases that catch us off guard usually.
>>
>> It would be helpful if we somehow could get an apple on silicon machine
>> tied into the gcc compile farm. I do not know how well that would work
>> if it is only laptops, it would be on 24/7, but I expect it could
>> support a few users well enough to allow developers to start working
>> with it and seeing the problems.
>>
>> Another thought, is there some sort of virtual machine or emulator that
>> could be used on other machines, but apple is usually very closed about
>> such things.
>>
>> Regards,
>>
>> Jerry
next prev parent reply other threads:[~2021-01-08 9:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 5:58 Rosemary Mardling
2021-01-06 8:53 ` Iain Sandoe
2021-01-06 17:11 ` James Secan
2021-01-06 17:28 ` Iain Sandoe
2021-01-06 19:38 ` James Secan
2021-01-08 2:32 ` Jerry DeLisle
2021-01-08 3:26 ` Rosemary Mardling
2021-01-08 9:56 ` Iain Sandoe [this message]
2021-01-08 10:05 ` Richard Biener
2021-01-08 19:28 ` James Secan
2021-01-08 19:57 ` Iain Sandoe
2021-01-08 22:18 ` Thomas Koenig
2021-01-09 17:29 ` Jerry DeLisle
2021-01-09 17:37 ` Jerry DeLisle
2021-01-09 19:07 ` Iain Sandoe
2021-01-09 19:21 ` James Secan
2021-01-09 19:30 ` Iain Sandoe
2021-01-12 22:13 ` Iain Sandoe
2021-01-15 20:36 ` James Secan
2021-02-26 22:24 ` Rosemary Mardling
2021-01-09 19:26 ` Jerry DeLisle
2021-01-06 23:26 ` Rosemary Mardling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=707CA4B6-DAAE-4DA6-A954-1E3ADE0CDA6B@googlemail.com \
--to=idsandoe@googlemail.com \
--cc=fortran@gcc.gnu.org \
--cc=james.secan@gmail.com \
--cc=jvdelisle2@gmail.com \
--cc=rosemary.mardling@monash.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).