public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
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



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