apple silicon fortran

apple silicon fortran

[Rosemary Mardling]

Hi,

I am keen to buy the new Apple Macbook Air which uses their new M1 chip, but as yet there is no Fortran compiler.
Do you have plans for a compiler for this new chip?

Thanks,
Rosemary Mardling

Re: apple silicon fortran

[Iain Sandoe]

Hi Rosemary,

Rosemary Mardling via Fortran <fortran@gcc.gnu.org> wrote:

> I am keen to buy the new Apple Macbook Air which uses their new M1 chip,  
> but as yet there is no Fortran compiler.
> Do you have plans for a compiler for this new chip?

see :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168
and :
https://github.com/iains/gcc-darwin-arm64

It’s (very) experimental at present - but … I believe that both macports  
and homebrew have packages based off this work.

macOS (Darwin) support is on a volunteer basis, so time is limited - we  
will do our best (but it’s more likely to be ‘official’ in GCC 12 than 11).

cheers
Iain

Re: apple silicon fortran

[James Secan]

Not having had a need to track the gfortran compiler at this level of detail in the past, I’ve got two questions:

1.  What’s the nominal timing for gcc releases?  From looking at recent history it looks to me like gcc 11 will show up in a few months and gcc 12 in Spring 2022.  Is this about right?

2.  Once there is a release that supports Apple’s ARM chips where (if anywhere) would I be able to find a list of things either not yet implemented in gfortran or implemented-but-funky?

And thanks for all the work you’re doing on this.

Jim Secan
Seattle, WA

> On Jan 6, 2021, at 12:53 AM, Iain Sandoe via Fortran <fortran@gcc.gnu.org> wrote:
> 
> Hi Rosemary,
> 
> Rosemary Mardling via Fortran <fortran@gcc.gnu.org> wrote:
> 
>> I am keen to buy the new Apple Macbook Air which uses their new M1 chip, but as yet there is no Fortran compiler.
>> Do you have plans for a compiler for this new chip?
> 
> see :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168
> and :
> https://github.com/iains/gcc-darwin-arm64
> 
> It’s (very) experimental at present - but … I believe that both macports and homebrew have packages based off this work.
> 
> macOS (Darwin) support is on a volunteer basis, so time is limited - we will do our best (but it’s more likely to be ‘official’ in GCC 12 than 11).
> 
> cheers
> Iain
> 

Re: apple silicon fortran

[Iain Sandoe]

James Secan <james.secan@gmail.com> wrote:

> Not having had a need to track the gfortran compiler at this level of  
> detail in the past, I’ve got two questions:
>
> 1.  What’s the nominal timing for gcc releases?  From looking at recent  
> history it looks to me like gcc 11 will show up in a few months and gcc  
> 12 in Spring 2022.  Is this about right?

Yes, that’s about right.

----

This is an odd case, in that the OS [macOS 11 + Arm64 changes] release  
happened almost exactly at the same time as we closed GCC11 for new  
features.  Having said that, new ports have a bit more lattitude (but I am  
far from confident that we could get sufficient polish on this one to have  
it in 11).

— in this case, because the relative schedule of the OS and compiler  
release are so unfortunately out of phase, I’m trying to think of suitable  
work-arounds (something more official than my github anyway!).

> 2.  Once there is a release that supports Apple’s ARM chips where (if  
> anywhere) would I be able to find a list of things either not yet  
> implemented in gfortran or implemented-but-funky?

Prior to release:

the referenced github branch below, and the “homebrew” and “macports”  
distributions based off it (homebrew, in fact, uses a backport of the  
changes to GCC-10 stable branch ( a branch on  
https://github.com/fxcoudert/gcc )

… as for issues, the known ones are described here :

https://github.com/iains/gcc-darwin-arm64/issues

====

Once support is in a released GCC version:

Then the [GCC] release documentation and the GCC bugzilla would contain the  
information
(one would not expect there to be too many departures from the ‘default’ -  
but, perhaps in handling IEEE stuff and in the REAL*16).

>> Rosemary Mardling via Fortran <fortran@gcc.gnu.org> wrote:
>>
>>> I am keen to buy the new Apple Macbook Air which uses their new M1  
>>> chip, but as yet there is no Fortran compiler.
>>> Do you have plans for a compiler for this new chip?
>>
>> see :
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168
>> and :
>> https://github.com/iains/gcc-darwin-arm64
>>
>> It’s (very) experimental at present - but … I believe that both macports  
>> and homebrew have packages based off this work.
>>
>> macOS (Darwin) support is on a volunteer basis, so time is limited - we  
>> will do our best (but it’s more likely to be ‘official’ in GCC 12 than  
>> 11).

cheers
Iain

Re: apple silicon fortran

[James Secan]

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

> On Jan 6, 2021, at 9:28 AM, Iain Sandoe <idsandoe@googlemail.com> wrote:
> 
> James Secan <james.secan@gmail.com> wrote:
> 
>> Not having had a need to track the gfortran compiler at this level of detail in the past, I’ve got two questions:
>> 
>> 1.  What’s the nominal timing for gcc releases?  From looking at recent history it looks to me like gcc 11 will show up in a few months and gcc 12 in Spring 2022.  Is this about right?
> 
> Yes, that’s about right.
> 
> ----
> 
> This is an odd case, in that the OS [macOS 11 + Arm64 changes] release happened almost exactly at the same time as we closed GCC11 for new features.  Having said that, new ports have a bit more lattitude (but I am far from confident that we could get sufficient polish on this one to have it in 11).
> 
> — in this case, because the relative schedule of the OS and compiler release are so unfortunately out of phase, I’m trying to think of suitable work-arounds (something more official than my github anyway!).
> 
>> 2.  Once there is a release that supports Apple’s ARM chips where (if anywhere) would I be able to find a list of things either not yet implemented in gfortran or implemented-but-funky?
> 
> Prior to release:
> 
> the referenced github branch below, and the “homebrew” and “macports” distributions based off it (homebrew, in fact, uses a backport of the changes to GCC-10 stable branch ( a branch on https://github.com/fxcoudert/gcc )
> 
> … as for issues, the known ones are described here :
> 
> https://github.com/iains/gcc-darwin-arm64/issues
> 
> ====
> 
> Once support is in a released GCC version:
> 
> Then the [GCC] release documentation and the GCC bugzilla would contain the information
> (one would not expect there to be too many departures from the ‘default’ - but, perhaps in handling IEEE stuff and in the REAL*16).
> 
>>> Rosemary Mardling via Fortran <fortran@gcc.gnu.org> wrote:
>>> 
>>>> I am keen to buy the new Apple Macbook Air which uses their new M1 chip, but as yet there is no Fortran compiler.
>>>> Do you have plans for a compiler for this new chip?
>>> 
>>> see :
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168
>>> and :
>>> https://github.com/iains/gcc-darwin-arm64
>>> 
>>> It’s (very) experimental at present - but … I believe that both macports and homebrew have packages based off this work.
>>> 
>>> macOS (Darwin) support is on a volunteer basis, so time is limited - we will do our best (but it’s more likely to be ‘official’ in GCC 12 than 11).
> 
> cheers
> Iain
> 
> 

Re: apple silicon fortran

[Rosemary Mardling]

Thanks Iain - much appreciated!

Sounds like I should wait - I write simple astrophysics codes but know essentially nothing about what’s `under the hood' :-).

Best wishes,
Rosemary
Melbourne, Australia

> On 6 Jan 2021, at 7:53 pm, Iain Sandoe <idsandoe@googlemail.com> wrote:
> 
> Hi Rosemary,
> 
> Rosemary Mardling via Fortran <fortran@gcc.gnu.org> wrote:
> 
>> I am keen to buy the new Apple Macbook Air which uses their new M1 chip, but as yet there is no Fortran compiler.
>> Do you have plans for a compiler for this new chip?
> 
> see :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168
> and :
> https://github.com/iains/gcc-darwin-arm64
> 
> It’s (very) experimental at present - but … I believe that both macports and homebrew have packages based off this work.
> 
> macOS (Darwin) support is on a volunteer basis, so time is limited - we will do our best (but it’s more likely to be ‘official’ in GCC 12 than 11).
> 
> cheers
> Iain
> 

Re: apple silicon fortran

[Jerry DeLisle]

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

Re: apple silicon fortran

[Rosemary Mardling]

Hi Jerrry,

It seems NAG have a fortran compiler but it is quite expensive (GBP250 - I enquired):

https://www.nag.com/news/first-fortran-compiler-apple-silicon-macs

Apple might be happy to lend you a machine if the absence of fortran is holding enough people back from buying them…

Cheers,
Rosemary



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

Re: apple silicon fortran

[Iain Sandoe]

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

Re: apple silicon fortran

[Richard Biener]

On Fri, Jan 8, 2021 at 10:57 AM Iain Sandoe via Fortran
<fortran@gcc.gnu.org> wrote:
>
> 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.

Note that the changes required might be backported to GCC11 though
(depending on how intrusive they are, of course - further backports increase
the non-intrusiveness requirement).  Technically OS/target specific support
can be done in stage4 in case it does not affect a primary or secondary
platform (aarch64-darwin is none of those).

> In the meantime - I’ve been working on including
>   (a) the fixes needed for macOS11 (common to X86 and Arm64)

I'd say those have priority (also for GCC 11), at least to the level to
get the compiler built and working.

Richard.

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

Re: apple silicon fortran

[James Secan]

> On Jan 8, 2021, at 1:56 AM, Iain Sandoe <idsandoe@googlemail.com> wrote:
> 
> 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 ).

Are these ready to run on Apple silicon, or on Big Sur on Intel silicon?  Have the ABI changes you mention been implemented on the back end?  That to me seems like the big issue here.

Jim

Re: apple silicon fortran

[Iain Sandoe]

Hi Jim,

James Secan via Fortran <fortran@gcc.gnu.org> wrote:

>> On Jan 8, 2021, at 1:56 AM, Iain Sandoe <idsandoe@googlemail.com> wrote:
>>
>> 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 ).
>
> Are these ready to run on Apple silicon,

Yes, I was talking about Arm64/aarch64/Apple Si native/self-hosted on macOS  
11 (Big Sur)

> or on Big Sur on Intel silicon?

macOS 11 on Intel x86_64 will be supported in GCC11 (in fact, is already  
supported and in respectable condition for this stage of the development  
cycle - see [1]); that would be expected to release to the same standard as  
macOS 10.15 (Catalina).

Actually, for the record, there’s a third permutation [2] , but I’ve not  
personally evaluated it.

=====

As for self-hosted, Arm64 native macOS11 ….

> Have the ABI changes you mention been implemented on the back end?

Enough of them have been addressed to be able to bootstrap the compiler and  
get reasonable test output (for Fortran, anyway), but several challenges  
remain…

> That to me seems like the big issue here.

… that is why the branches are described as “experimental”, they certainly  
have limitations (as listed in the issues), but are available to people  
wanting to experiment.

====

I fully understand the need for stability in production platforms (  
although we are of course obliged to develop and test on the ‘bleeding  
edge’  - my production machines stay well away from it too ;) )

cheers
Iain

---

[1] https://gcc.gnu.org/pipermail/gcc-testresults/2021-January/643049.html

---

[2] In principle, an X86_64 compiler can be executed on Arm64 macOS 11  
using “Rosetta 2”.  I haven’t tried this to see how well it works (perhaps  
I will give it a try at some point, both in terms of function and  
performance).

Re: apple silicon fortran

[Thomas Koenig]

Hi Rosemary,

> It seems NAG have a fortran compiler but it is quite expensive (GBP250 - I enquired):
> 
> https://www.nag.com/news/first-fortran-compiler-apple-silicon-macs

Well, NAG sort of cheat - they compile Fortran to C and then use the
native C compiler.  Makes it easier if there is already a C compiler
on the target, no need to worry about ABIs and such.  (Interestingly
enough, the whole NAG compiler has a similar scope as the gfortran
front end and library).

It would be interesteing to see the C code they emit for certain
constructs, for example for code accessing variables in an outer
scope from contained procedures. Not sure if there is an option to
do this.

Best regards

	Thomas

Re: apple silicon fortran

[Jerry DeLisle]

Hi all,

https://jaimyn.com.au/how-to-build-multi-architecture-docker-images-on-an-m1-mac/

Above link build a docker containers on the subject machine.

I have a DockerFile that as all the good working.

Ask if you would like a copy.  I will post to my gfortran-dev slack channel.

https://gfortran.slack.com/archives/C013YLPNVS8/p1610212997054700

To build:   sudo docker build . -t fed1

To run:  sudo docker run -it fed1 /bin/bash

Cheers,

Jerry

On 1/8/21 2:18 PM, Thomas Koenig wrote:
> Hi Rosemary,
>
>> It seems NAG have a fortran compiler but it is quite expensive 
>> (GBP250 - I enquired):
>>
>> https://www.nag.com/news/first-fortran-compiler-apple-silicon-macs
>
> Well, NAG sort of cheat - they compile Fortran to C and then use the
> native C compiler.  Makes it easier if there is already a C compiler
> on the target, no need to worry about ABIs and such. (Interestingly
> enough, the whole NAG compiler has a similar scope as the gfortran
> front end and library).
>
> It would be interesteing to see the C code they emit for certain
> constructs, for example for code accessing variables in an outer
> scope from contained procedures. Not sure if there is an option to
> do this.
>
> Best regards
>
>     Thomas

Re: apple silicon fortran

[Jerry DeLisle]

Hi all, 
https://jaimyn.com.au/how-to-build-multi-architecture-docker-images-on-an-m1-mac/

Above link build a docker containers on the subject machine.

I have a DockerFile that as all the good working.

Ask if you would like a copy.  I will post to my gfortran-dev slack channel.

https://gfortran.slack.com/archives/C013YLPNVS8/p1610212997054700

  To build:   sudo docker build . -t fed1

  To run:  sudo docker run -it fed1 /bin/bash

Cheers,

Jerry
>
> On 1/8/21 2:18 PM, Thomas Koenig wrote:
>> Hi Rosemary,
>>
>>> It seems NAG have a fortran compiler but it is quite expensive 
>>> (GBP250 - I enquired):
>>>
>>> https://www.nag.com/news/first-fortran-compiler-apple-silicon-macs
>>
>> Well, NAG sort of cheat - they compile Fortran to C and then use the
>> native C compiler.  Makes it easier if there is already a C compiler
>> on the target, no need to worry about ABIs and such. (Interestingly
>> enough, the whole NAG compiler has a similar scope as the gfortran
>> front end and library).
>>
>> It would be interesteing to see the C code they emit for certain
>> constructs, for example for code accessing variables in an outer
>> scope from contained procedures. Not sure if there is an option to
>> do this.
>>
>> Best regards
>>
>>     Thomas
>

Re: apple silicon fortran

[Iain Sandoe]

Hi Jerry,

Jerry DeLisle <jvdelisle@charter.net> wrote:

> https://gfortran.slack.com/archives/C013YLPNVS8/p1610212997054700
>
>  To build:   sudo docker build . -t fed1
>
>  To run:  sudo docker run -it fed1 /bin/bash

FAOD, I assume that this produces a Linux GCC which is run inside the  
docker container which is virtualising a suitable linux distribution?

(assuming that’s the case) It would be interesting to know which Linux was  
being virtualised - and some idea of the performance impact.

---

I am testing out the Rosetta 2 alternative (which is, AFAIU, a  
binary-conversion done at install-time native on macOS).

Useful to have some fall-back solutions in the short-term, but a native  
compiler is still the eventual objective.

thanks
Iain

Re: apple silicon fortran

[James Secan]

> On Jan 9, 2021, at 11:07 AM, Iain Sandoe via Fortran <fortran@gcc.gnu.org> wrote:
> 
> Hi Jerry,
> 
> I am testing out the Rosetta 2 alternative (which is, AFAIU, a binary-conversion done at install-time native on macOS).
> 
> Useful to have some fall-back solutions in the short-term, but a native compiler is still the eventual objective.
> 
> thanks
> Iain

Iain,

I would think that running the compiler under Rosetta 2 would still produce a binary that is not compatible with the M1 processor (would it run on a Mac Intel box?).  Can you run the binary on M1 using Rosetta 2 again?

And my admittedly-shallow understanding of Rosetta 2, isn’t it supposed to generate a new binary the first time a code is run using it, said new binary then being run directly in a subsequent invocation of Rosetta2+userApp?

I am interested to hear the results of your testing with Rosetta 2.

Jim

Re: apple silicon fortran

[Jerry DeLisle]

On 1/9/21 11:07 AM, Iain Sandoe wrote:
> Hi Jerry,
>
> Jerry DeLisle <jvdelisle@charter.net> wrote:
>
>> https://gfortran.slack.com/archives/C013YLPNVS8/p1610212997054700
>>
>>  To build:   sudo docker build . -t fed1
>>
>>  To run:  sudo docker run -it fed1 /bin/bash
>
> FAOD, I assume that this produces a Linux GCC which is run inside the 
> docker container which is virtualising a suitable linux distribution?
>
> (assuming that’s the case) It would be interesting to know which Linux 
> was being virtualised - and some idea of the performance impact.
>
If you look at the first line of the DockerFile you will see a FROM 
command that specifies Fedore:latest which in this case bases it on 
Fedora 33.

I have also done this with one based on Ubuntu 18.04

These have been confirmed by a friend to work on a Mac laptop. There are 
some nuance bewteen Fedora and Ubuntu as they uas different package 
managers.  The one I posted happens to install gtk-fortran support for 
GTK3 and GTK4 as this is what was needed initially.  One can install any 
packages you want either by modifying the DockerFile and rebuilding or 
doing so inside the container.

Another thing you do need to know is the container ID created so that 
you can restart it at will and have it retain any work you have done.  
Anyone intending to use this needs to get up on the Docker learning 
curve a little, the container ID is the "hostname" in the environment 
and you will see that in the bash prompt.  I usually copy and paste this 
to a bash script on my host machine and use that to restart it.

For example:

$ cat ~/bin/runit.sh
#! /bin/bash
sudo docker exec -it c9b60c30d2c8 /bin/bash

On my system the docker daemon needs to be running:

I use:

sudo systemctl enable docker
sudo systemctl start docker.

One this is going, the exec command will work as shown above.  On some 
systems, the docker system allows gui apps to run in the container and 
they are displayed on the HOST machine. Very handy!  I have not learned 
to do this with my Fedora 33 Host yet, but it definitely works on MacOS 
and probably Windows.

See docker docs to get up to speed or google some.

Regards,

Jerry

Re: apple silicon fortran

[Iain Sandoe]

Hi Jim,

James Secan <james.secan@gmail.com> wrote:
>> On Jan 9, 2021, at 11:07 AM, Iain Sandoe via Fortran  
>> <fortran@gcc.gnu.org> wrote:

>> I am testing out the Rosetta 2 alternative (which is, AFAIU, a  
>> binary-conversion done at install-time native on macOS).
>>
>> Useful to have some fall-back solutions in the short-term, but a native  
>> compiler is still the eventual objective.
>

> I would think that running the compiler under Rosetta 2 would still  
> produce a binary that is not compatible with the M1 processor (would it  
> run on a Mac Intel box?).

Yes, that’s right - it would be an x86_64 compiler, running via Rosetta on  
Arm64, producing X86_64 object ...

>  Can you run the binary on M1 using Rosetta 2 again?

… it would seem to defeat some use-case if not - given that the bootstrap  
succeeded, evidently yes (but perhaps using the JIT mechanism, which might  
not perform so well)..

> And my admittedly-shallow understanding of Rosetta 2, isn’t it supposed  
> to generate a new binary the first time a code is run using it, said new  
> binary then being run directly in a subsequent invocation of  
> Rosetta2+userApp?

Actually, (from limited reading, and likely equally shallow understaning),  
it seems that this operates two ways;  a one-off when something is  
installed (so that from then-on one is running native code, with no  
translation phase).  That’s different from the Rosetta 1 (PowerPC=>X86).

The second mode is more akin to the Rosetta 1 case, a JIT that is run as  
needed...

> I am interested to hear the results of your testing with Rosetta 2.

I bootstrapped x86_64-apple-darwin20 on aarch64-darwin20.3, and currently  
running the Fortran testsuite - it’s not clear to me if some of the issues  
(PIE and no-executable stack) will be sidestepped or not.  We shall see.

Iain

Re: apple silicon fortran

[Iain Sandoe]

Hi Folks,

Iain Sandoe via Fortran <fortran@gcc.gnu.org> wrote:
> James Secan <james.secan@gmail.com> wrote:
>>> On Jan 9, 2021, at 11:07 AM, Iain Sandoe via Fortran  
>>> <fortran@gcc.gnu.org> wrote:
>
>>> I am testing out the Rosetta 2 alternative (which is, AFAIU, a  
>>> binary-conversion done at install-time native on macOS).

OK so I haven’t yet found a way to trigger the install-time translation,  
perhaps it only works on a fully packaged and signed app.

- however, the “on demand” conversion clearly works.

>> I am interested to hear the results of your testing with Rosetta 2.
>
> I bootstrapped x86_64-apple-darwin20 on aarch64-darwin20.3, and currently  
> running the Fortran testsuite - it’s not clear to me if some of the  
> issues (PIE and no-executable stack) will be sidestepped or not.  We  
> shall see.

Summary : some pretty good parts, but not enough to be a drop-in replacement.

[ disclaimer : the testsuite is somewhat ‘noisy’ at the moment, we have  
some tidying to do before release…]

here’s the native (x86_64-darwin20, on an Intel skylake processor):

https://gcc.gnu.org/pipermail/gcc-testresults/2021-January/644184.html

here’s the same branch bootstrapped for aarch64 and x86_64 using Rosetta 2  
on an A12Z processor (I don’t have access to an actual M1 yet).

https://github.com/iains/gcc-darwin-arm64/issues/30#issuecomment-758890255

— inferences and testing:

* It seems that Rosetta 2 + whatver sandboxing is in place is allowing  
diabling PIE (which means that PCH works again) but *NOT* allowing  
executable stack, which means that [GCC default implementation] nested  
functions are still broken (and gfortran uses nested functions ‘under the  
hood’ so to speak)

* informal testing on a couple of random Fortran benchmarks I have on that  
machine suggest that the binary translation gives pretty good performance  
for numerically intensive stuff (but again, disclaimer - that was [a] on an  
A12Z and [b] not carried out in any strictly controlled manner).  OTOH, I  
expect it’s not completely misleading.

Conclusion.

Rosetta 2 + Arm64 is not a drop-in replacement for x86_64 gfortran, we  
still need an ABI-compliant solution to the nested function issue - I do  
have an idea - but it isn’t a stage4 kind of thing.

If your machine breaks and you have to replace it, or your employer  
requires you to use an arm64 model, then I would suggest that the native  
branch is probably a better bet in the short-term - that has a workaround  
for the nested function issue (but that can give challenges in interworking  
with C, although those might not be insurmountable) ..

We’ll get there, I am sure - but not this week ;)

cheers
Iain

Re: apple silicon fortran

[James Secan]

Iain,

Thanks for the update and all the work.  I’m looking forward to seeing all this working natively on Apple’s new architecture.

Jim
Seattle, WA
> On Jan 12, 2021, at 2:13 PM, Iain Sandoe <idsandoe@googlemail.com> wrote:
> 
> Hi Folks,
> 
> Iain Sandoe via Fortran <fortran@gcc.gnu.org> wrote:
>> James Secan <james.secan@gmail.com> wrote:
>>>> On Jan 9, 2021, at 11:07 AM, Iain Sandoe via Fortran <fortran@gcc.gnu.org> wrote:
>> 
>>>> I am testing out the Rosetta 2 alternative (which is, AFAIU, a binary-conversion done at install-time native on macOS).
> 
> OK so I haven’t yet found a way to trigger the install-time translation, perhaps it only works on a fully packaged and signed app.
> 
> - however, the “on demand” conversion clearly works.
> 
>>> I am interested to hear the results of your testing with Rosetta 2.
>> 
>> I bootstrapped x86_64-apple-darwin20 on aarch64-darwin20.3, and currently running the Fortran testsuite - it’s not clear to me if some of the issues (PIE and no-executable stack) will be sidestepped or not.  We shall see.
> 
> Summary : some pretty good parts, but not enough to be a drop-in replacement.
> 
> [ disclaimer : the testsuite is somewhat ‘noisy’ at the moment, we have some tidying to do before release…]
> 
> here’s the native (x86_64-darwin20, on an Intel skylake processor):
> 
> https://gcc.gnu.org/pipermail/gcc-testresults/2021-January/644184.html
> 
> here’s the same branch bootstrapped for aarch64 and x86_64 using Rosetta 2 on an A12Z processor (I don’t have access to an actual M1 yet).
> 
> https://github.com/iains/gcc-darwin-arm64/issues/30#issuecomment-758890255
> 
> — inferences and testing:
> 
> * It seems that Rosetta 2 + whatver sandboxing is in place is allowing diabling PIE (which means that PCH works again) but *NOT* allowing executable stack, which means that [GCC default implementation] nested functions are still broken (and gfortran uses nested functions ‘under the hood’ so to speak)
> 
> * informal testing on a couple of random Fortran benchmarks I have on that machine suggest that the binary translation gives pretty good performance for numerically intensive stuff (but again, disclaimer - that was [a] on an A12Z and [b] not carried out in any strictly controlled manner).  OTOH, I expect it’s not completely misleading.
> 
> Conclusion.
> 
> Rosetta 2 + Arm64 is not a drop-in replacement for x86_64 gfortran, we still need an ABI-compliant solution to the nested function issue - I do have an idea - but it isn’t a stage4 kind of thing.
> 
> If your machine breaks and you have to replace it, or your employer requires you to use an arm64 model, then I would suggest that the native branch is probably a better bet in the short-term - that has a workaround for the nested function issue (but that can give challenges in interworking with C, although those might not be insurmountable) ..
> 
> We’ll get there, I am sure - but not this week ;)
> 
> cheers
> Iain
> 

Re: apple silicon fortran

[Rosemary Mardling]

Hi everyone,

Still dreaming of buying a MacBook Air with the M1 chip, but still worried I won’t be able to run my fortran codes on it.

Just wondering if you have made progress with a fortran compiler for this new machine? I sure appreciate all your help in January!

Best wishes,
Rosemary



> On 10 Jan 2021, at 6:30 am, Iain Sandoe <idsandoe@googlemail.com> wrote:
> 
> Hi Jim,
> 
> James Secan <james.secan@gmail.com> wrote:
>>> On Jan 9, 2021, at 11:07 AM, Iain Sandoe via Fortran <fortran@gcc.gnu.org> wrote:
> 
>>> I am testing out the Rosetta 2 alternative (which is, AFAIU, a binary-conversion done at install-time native on macOS).
>>> 
>>> Useful to have some fall-back solutions in the short-term, but a native compiler is still the eventual objective.
>> 
> 
>> I would think that running the compiler under Rosetta 2 would still produce a binary that is not compatible with the M1 processor (would it run on a Mac Intel box?).
> 
> Yes, that’s right - it would be an x86_64 compiler, running via Rosetta on Arm64, producing X86_64 object ...
> 
>> Can you run the binary on M1 using Rosetta 2 again?
> 
> … it would seem to defeat some use-case if not - given that the bootstrap succeeded, evidently yes (but perhaps using the JIT mechanism, which might not perform so well)..
> 
>> And my admittedly-shallow understanding of Rosetta 2, isn’t it supposed to generate a new binary the first time a code is run using it, said new binary then being run directly in a subsequent invocation of Rosetta2+userApp?
> 
> Actually, (from limited reading, and likely equally shallow understaning), it seems that this operates two ways;  a one-off when something is installed (so that from then-on one is running native code, with no translation phase).  That’s different from the Rosetta 1 (PowerPC=>X86).
> 
> The second mode is more akin to the Rosetta 1 case, a JIT that is run as needed...
> 
>> I am interested to hear the results of your testing with Rosetta 2.
> 
> I bootstrapped x86_64-apple-darwin20 on aarch64-darwin20.3, and currently running the Fortran testsuite - it’s not clear to me if some of the issues (PIE and no-executable stack) will be sidestepped or not.  We shall see.
> 
> Iain
>