OpenCoarrays integration with gfortran

[Richard Biener]

On September 21, 2018 6:24:45 PM GMT+02:00, Jerry DeLisle <jvdelisle@charter.net> wrote:
>My apologies for kidnapping this thread:
>On 9/20/18 1:01 PM, Thomas Koenig wrote:
>> Hi Damian,
>> 
>>> On a related note, two Sourcery Institute developers have attempted
>to 
>>> edit
>>> the GCC build system to make the downloading and building of
>OpenCoarrays
>>> automatically part of the gfortran build process.  Neither developer
>>> succeeded.
>> 
>> We addressed integrating OpenCoarray into the gcc source tree at the
>> recent Gcc summit during the gfortran BoF session.
>> 
>> Feedback from people working for big Linux distributions was that
>they
>> would prefer to package OpenCoarrays as a separate library.
>> (They also mentioned it was quite hard to build.)
>
>I would like to put in my humble 2 cents worth here.
>
>OpenCoarrays was/is intended for a very broad audience, various large 
>systems such as Cray, etc. I think this influenced heavily the path of 
>its development, which is certainly OK.
>
>It was/is intended to interface libraries such as OpenMPI or MPICH to 
>gfortran as well as other Fortran compilers.
>
>The actual library source code is contained mostly in one source file. 
>After all the attempts to integrate into the GNU build systems without 
>much success my thinking has shifted. Keep in mind that the
>OpenCoarrays 
>implementation is quite dependent on gfortran and in fact has to do 
>special things in the build dependent on the version of gcc/gfortran a 
>user happens to use.  I dont think this is a good situation.
>
>So I see two realistic strategies.  The first is already talked about a
>
>lot and is the cleanest approach for gfortran:
>
>1) Focus on distribution packages such as Fedora, Debian, Ubuntu, 
>Windows, etc. Building of these packages needs to be automated into the
>
>distributions. I think mostly this is what is happening and relies on 
>the various distribution maintainers to do so.  Their support is
>greatly 
>appreciated and this really is the cleanest approach.
>
>The second option is not discussed as much because it leaves 
>OpenCoarrays behind in a sense and requires an editing cycle in two 
>places to fix bugs or add features.
>
>2) Take the one source file, edit out all the macros that define 
>prefixes to function calls, hard code the gfortran prefixes etc and
>fork 
>it directly into the libgfortran library under GPL with attributions to
>
>the original developers as appropriate.
>
>Strategy 2 would lock into specific current standard versions of the
>MPI 
>interface and would support less bleeding edge changes.  It would also 
>require either OpenMPI or MPICH as a new gfortran dependency for 
>building, which not all users may need. So we would need some 
>configuration magic to enable or disable this portion of the build. 
>Something like --with-MPI-support would do the trick.
>
>Strategy 2 does add burden to gfortran maintainers who are already 
>overloaded. But, as the code matures the burden would decrease, 
>particularly once TEAMS are finished.
>
>Strategy 2 does have some advantages. For example, eliminating the need
>
>for separate CAF and CAFRUN scripts which are a wrapper on gfortran. 
>The coarray features are part of the Fortran language and gfortran 
>should just "handle it" transparently using an environment variable to 
>define the number of images at run time. It would also actually 
>eliminate the need to manage all of the separate distribution packages.
>
>So from a global point of view the overall maintanance effort would be 
>reduced.
>
>Strategy 2 would enable a set of users who are not focused so much on 
>distributions and loading packages, etc etc and those who are dependent
>
>on getting through bureaucratic administrations who already are loading
>
>gfortran on systems and would not have to also get another package 
>approved.  People would just have to stop thinking about it and just
>use it.
>
>So I think there are real advantages to Strategy 2 as well as Strategy
>1 
>and think it should be at least included in discussions. I would even 
>suggest there is likely a combination of 1 and 2 that may hit the mark.
>
>For example, keeping OpenCoarrays as a separate package for bleeding 
>edge development and migrating the stable features into libgfortran on
>a 
>less frequent cycle.

Sounds reasonable to me. License issues will be the most difficult here given integration with libgfortran likely requires a FSF copyright rather than just a compatible license. 

Richard. 

>As I said, my 2 cents worth.
>
>Regards to all,
>
>Jerry