Patching the GCC build system to build MPICH and OpenCoarrays

Patching the GCC build system to build MPICH and OpenCoarrays

[Damian Rouson]

All,

Jerry DeLisle, Daniel Celis Garza, and I would greatly appreciate feedback on our approach to patching the GCC build system to build MPICH and OpenCoarrays after it builds gfortran (gfortran requires MPI and OpenCoarrays to support the parallel features of Fortran 2008 and Fortran 2018).  A diff of our work relative to the GCC trunk is at http://bit.ly/2pQuzvS.  Our steps so far include the following:

1. Jerry wrote an autotools build system for OpenCoarrays (on the OpenCoarrays issue-343-gnu-build branch.)
2. Jerry got MPICH and OpenCoarrays tar balls onto the GCC ftp server.  
3. I modified GCC’s contrib/download_prerequisites script to download the tar balls.
4. Daniel edited GCC’s Makefile.def, config.ac, and Makefile.tpl to incorporate MPICH.

Our current issue is that the Makefile produced as follows doesn’t create the desired “mpi" directory:

git clone -b build-mpich https://github.com/sourceryinstitute/gcc
mkdir -p gcc/build 
cd gcc/build
../configure --disable-bootstrap --enable-languages=fortran

whereupon "grep mpi Makefile” only returns comments and an echo statement.  Ultimately, our desired sequence is to build gfortran, then build MPICH, and then build OpenCoarrays.  All advice is welcome.

Damian

Re: Patching the GCC build system to build MPICH and OpenCoarrays

[Richard Biener]

On Sat, Mar 31, 2018 at 2:44 AM, Damian Rouson
<damian@sourceryinstitute.org> wrote:
> All,
>
> Jerry DeLisle, Daniel Celis Garza, and I would greatly appreciate feedback on our approach to patching the GCC build system to build MPICH and OpenCoarrays after it builds gfortran (gfortran requires MPI and OpenCoarrays to support the parallel features of Fortran 2008 and Fortran 2018).  A diff of our work relative to the GCC trunk is at http://bit.ly/2pQuzvS.  Our steps so far include the following:
>
> 1. Jerry wrote an autotools build system for OpenCoarrays (on the OpenCoarrays issue-343-gnu-build branch.)
> 2. Jerry got MPICH and OpenCoarrays tar balls onto the GCC ftp server.
> 3. I modified GCC’s contrib/download_prerequisites script to download the tar balls.
> 4. Daniel edited GCC’s Makefile.def, config.ac, and Makefile.tpl to incorporate MPICH.
>
> Our current issue is that the Makefile produced as follows doesn’t create the desired “mpi" directory:
>
> git clone -b build-mpich https://github.com/sourceryinstitute/gcc
> mkdir -p gcc/build
> cd gcc/build
> ../configure --disable-bootstrap --enable-languages=fortran
>
> whereupon "grep mpi Makefile” only returns comments and an echo statement.  Ultimately, our desired sequence is to build gfortran, then build MPICH, and then build OpenCoarrays.  All advice is welcome.

You probably only want a new target_module for the MPI library.  Note
it's name has to match that of the directory containing the sources
which
as far as I see is 'mpich', not 'libmpi'.

May I ask again why mpi/opencoarrays should be built together with
gfortran rather than separately?  Does gfortran or any of its current
target libraries
link against them?

Richard.

> Damian
>
>
>
>
>
>
>

Re: Patching the GCC build system to build MPICH and OpenCoarrays

[Damian Rouson]

On April 3, 2018 at 1:36:37 AM, Richard Biener (richard.guenther@gmail.com) wrote:

You probably only want a new target_module for the MPI library. Note 
it's name has to match that of the directory containing the sources 
which 
as far as I see is 'mpich', not 'libmpi'. 
Thanks!  I’ll ask Daniel to respond if he has further questions.

May I ask again why mpi/opencoarrays should be built together with 
gfortran rather than separately? Does gfortran or any of its current 
target libraries 
link against them? 
Yes, gfortran links to OpenCoarrays via the -fcoarray=lib argument. OpenCoarrays provides the only parallel implementations of gfortran’s Coarray ABI (http://bit.ly/Coarray-ABI). Any Fortran program that uses the large set of parallel features in Fortran 2008 and Fortran 2018 must have OpenCoarrays installed in order for the code to execute in parallel. 

We have found MPICH to be the most robust option and it has the only released support for some of the more advanced requirements such as the Fortran 2018 fault-tolerance features.  However, there will be configure options for using MPI implementations other than MPICH. 


Damian

Re: Patching the GCC build system to build MPICH and OpenCoarrays

[Richard Biener]

On Wed, Apr 4, 2018 at 8:24 AM, Damian Rouson
<damian@sourceryinstitute.org> wrote:
> On April 3, 2018 at 1:36:37 AM, Richard Biener (richard.guenther@gmail.com)
> wrote:
>
>
> You probably only want a new target_module for the MPI library. Note
> it's name has to match that of the directory containing the sources
> which
> as far as I see is 'mpich', not 'libmpi'.
>
> Thanks!  I’ll ask Daniel to respond if he has further questions.
>
> May I ask again why mpi/opencoarrays should be built together with
> gfortran rather than separately? Does gfortran or any of its current
> target libraries
> link against them?
>
> Yes, gfortran links to OpenCoarrays via the -fcoarray=lib argument.

In that case user programs compiled with -fcoarray=lib are but gfortran
or libgfortran itself is not linked against OpenCoarrays?

> OpenCoarrays provides the only parallel implementations of gfortran’s
> Coarray ABI (http://bit.ly/Coarray-ABI). Any Fortran program that uses the
> large set of parallel features in Fortran 2008 and Fortran 2018 must have
> OpenCoarrays installed in order for the code to execute in parallel.

I see.  So if we consider OpenCoarrays part of the gfortran runtime then
it makes sense to build it in-tree...

> We have found MPICH to be the most robust option and it has the only
> released support for some of the more advanced requirements such as the
> Fortran 2018 fault-tolerance features.  However, there will be configure
> options for using MPI implementations other than MPICH.

... but building an mpi library in-tree might not?

I'm still lacking an idea of what it takes to enable coarrays with gfortran
since install.texi doesn't talk about this at all, neither in the prerequesites
section nor in a fortran/coarray specific section.

In fact the only thing I find is in invoke.texi which says

@item -fcoarray=@var{<keyword>}
@opindex @code{fcoarray}
...
@item @samp{lib}
Library-based coarray parallelization; a suitable GNU Fortran coarray
library needs to be linked.
@end table

which suggests linking to the coarray library doesn't happen automatically
but the user is supposed to link a suitable library?

I'd love to "enable" coarray support for openSUSE but as said I have a hard
time assessing what I'd need to do here.

Thanks,
Richard.

>
> Damian

Re: Patching the GCC build system to build MPICH and OpenCoarrays

[Toon Moene]

On 04/04/2018 08:24 AM, Damian Rouson wrote:

> On April 3, 2018 at 1:36:37 AM, Richard Biener (richard.guenther@gmail.com) wrote:
> 
> You probably only want a new target_module for the MPI library. Note
> it's name has to match that of the directory containing the sources
> which
> as far as I see is 'mpich', not 'libmpi'.
> Thanks!  I’ll ask Daniel to respond if he has further questions.
> 
> May I ask again why mpi/opencoarrays should be built together with
> gfortran rather than separately? Does gfortran or any of its current
> target libraries
> link against them?
> Yes, gfortran links to OpenCoarrays via the -fcoarray=lib argument. OpenCoarrays provides the only parallel implementations of gfortran’s Coarray ABI (http://bit.ly/Coarray-ABI). Any Fortran program that uses the large set of parallel features in Fortran 2008 and Fortran 2018 must have OpenCoarrays installed in order for the code to execute in parallel.
> 
> We have found MPICH to be the most robust option and it has the only released support for some of the more advanced requirements such as the Fortran 2018 fault-tolerance features.  However, there will be configure options for using MPI implementations other than MPICH.

My experience using various MPI implementations is: use the variant that 
is itself compiled with the compiler *you* are using to compile your 
code. The foremost obstacle to prevent other combinations is .mod files, 
but also having libraries compiled with different compilers than the one 
your "MAIN" program is compiled with (plus *its* libraries) will result 
in a bewildering spree of "unsatisfied external references", because 
only *one* Fortran compiler will do the link - and include *its* run 
time libraries, not knowing anything about the other compiler's run time 
libraries.

So "one compiler to compile them all".

:-)

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news

Re: Patching the GCC build system to build MPICH and OpenCoarrays

[Damian Rouson]

On April 4, 2018 at 3:09:39 AM, Toon Moene (toon@moene.org) wrote:

So "one compiler to compile them all". 
I have encountered similar difficulties. This is another good to consider building everything at once.

Damian

Re: Patching the GCC build system to build MPICH and OpenCoarrays

[Damian Rouson]

On April 4, 2018 at 1:12:25 AM, Richard Biener (richard.guenther@gmail.com(mailto:richard.guenther@gmail.com)) wrote:
 
> In that case user programs compiled with -fcoarray=lib are but gfortran
> or libgfortran itself is not linked against OpenCoarrays?

Yes.  OpenCoarrays produces the parallel runtime library libcaf_mpi using MPI.

> So if we consider OpenCoarrays part of the gfortran runtime then
> it makes sense to build it in-tree…

Yes.  Many gfortran users and developers who will be glad to see this both because it enables the Fortran 2008/2018 parallel features and because it facilitates building related tests.

> ... but building an mpi library in-tree might not?

OpenCoarrays requires an underlying parallel programming model.  MPI is the default model because it provides the broadest coverage of the required features.  OpenCoarrays also offers alternatives to MPI, but those are experimental and support a more restricted subset of Fortran 2008/2018.

> I'm still lacking an idea of what it takes to enable coarrays with gfortran

We will mimic the OpenCoarrays build system, which installs “caf" and “cafrun" scripts analogous to MPI's "mpifort" and “mpirun,” respectively.  These are used to compile and launch parallel programs: 

$ cat hello.f90
print *,”Hello from image “,this_image(),” of “,num_images()
end
$ caf hello.f90
$ cafrun -n 4 ./a.out
  Hello from image 2 of 4
  Hello from image 1 of 4
  Hello from image 4 of 4
  Hello from image 3 of 4

> since install.texi doesn't talk about this at all, neither in the prerequesites
> section nor in a fortran/coarray specific section.

If there are guidelines for modifying install.texi and invoke.texi, please send a link.  It appears install.texi is written in raw TeX.  I use LaTeX regularly but haven’t touched TeX in decades. I’ll give it a shot.  I also don’t understand how those files are used

> In fact the only thing I find is in invoke.texi which says
>  
> @item -fcoarray=@var{}
> @opindex @code{fcoarray}
> ...
> @item @samp{lib}
> Library-based coarray parallelization; a suitable GNU Fortran coarray
> library needs to be linked.
> @end table
>  
> which suggests linking to the coarray library doesn't happen automatically
> but the user is supposed to link a suitable library?

caf invokes gfortran and links against libcaf_mpi and the MPI libraries.  The OpenCoarrays build system customizes caf to ensure a consistent tool chain (e.g., ensuring the employed MPI was built by the employed compiler). This allows for reusing one gfortran installation with multiple parallel programming models.

> I'd love to "enable" coarray support for openSUSE but as said I have a hard
> time assessing what I'd need to do here.

Until we figure out how to get the GCC build system to build MPICH and OpenCoarrays, enabling coarray support requires downloading and building MPICH and OpenCoarrays separately.  Please see the instructions for GCC developers: https://github.com/sourceryinstitute/opencoarrays/blob/master/INSTALL. 

Thanks for your feedback.  I’m hopeful that your advice will be helpful for Daniel in figuring out how to modify the GCC build system. 

Damian

Re: Patching the GCC build system to build MPICH and OpenCoarrays

[Richard Biener]

On Sun, Apr 8, 2018 at 8:56 PM, Damian Rouson
<damian@sourceryinstitute.org> wrote:
> On April 4, 2018 at 1:12:25 AM, Richard Biener (richard.guenther@gmail.com(mailto:richard.guenther@gmail.com)) wrote:
>
>> In that case user programs compiled with -fcoarray=lib are but gfortran
>> or libgfortran itself is not linked against OpenCoarrays?
>
> Yes.  OpenCoarrays produces the parallel runtime library libcaf_mpi using MPI.
>
>> So if we consider OpenCoarrays part of the gfortran runtime then
>> it makes sense to build it in-tree…
>
> Yes.  Many gfortran users and developers who will be glad to see this both because it enables the Fortran 2008/2018 parallel features and because it facilitates building related tests.
>
>> ... but building an mpi library in-tree might not?
>
> OpenCoarrays requires an underlying parallel programming model.  MPI is the default model because it provides the broadest coverage of the required features.  OpenCoarrays also offers alternatives to MPI, but those are experimental and support a more restricted subset of Fortran 2008/2018.
>
>> I'm still lacking an idea of what it takes to enable coarrays with gfortran
>
> We will mimic the OpenCoarrays build system, which installs “caf" and “cafrun" scripts analogous to MPI's "mpifort" and “mpirun,” respectively.  These are used to compile and launch parallel programs:
>
> $ cat hello.f90
> print *,”Hello from image “,this_image(),” of “,num_images()
> end
> $ caf hello.f90
> $ cafrun -n 4 ./a.out
>   Hello from image 2 of 4
>   Hello from image 1 of 4
>   Hello from image 4 of 4
>   Hello from image 3 of 4

I see.  So it's more like OpenCoarrays is in control of everything
rather than GCC...

>> since install.texi doesn't talk about this at all, neither in the prerequesites
>> section nor in a fortran/coarray specific section.
>
> If there are guidelines for modifying install.texi and invoke.texi, please send a link.  It appears install.texi is written in raw TeX.  I use LaTeX regularly but haven’t touched TeX in decades. I’ll give it a shot.  I also don’t understand how those files are used

There are no guidelines - simply follow surrounding code.  Note this
is texinfo, not tex.  We generate
man pages, html documentation and pdf docs from these sources.  See for example
https://gcc.gnu.org/install/

>> In fact the only thing I find is in invoke.texi which says
>>
>> @item -fcoarray=@var{}
>> @opindex @code{fcoarray}
>> ...
>> @item @samp{lib}
>> Library-based coarray parallelization; a suitable GNU Fortran coarray
>> library needs to be linked.
>> @end table
>>
>> which suggests linking to the coarray library doesn't happen automatically
>> but the user is supposed to link a suitable library?
>
> caf invokes gfortran and links against libcaf_mpi and the MPI libraries.  The OpenCoarrays build system customizes caf to ensure a consistent tool chain (e.g., ensuring the employed MPI was built by the employed compiler). This allows for reusing one gfortran installation with multiple parallel programming models.
>
>> I'd love to "enable" coarray support for openSUSE but as said I have a hard
>> time assessing what I'd need to do here.
>
> Until we figure out how to get the GCC build system to build MPICH and OpenCoarrays, enabling coarray support requires downloading and building MPICH and OpenCoarrays separately.  Please see the instructions for GCC developers: https://github.com/sourceryinstitute/opencoarrays/blob/master/INSTALL.

Thanks - I expected to find sth in the GCC manual or on the GCC wiki
;)  I'll have a look when I have some spare cycles.

> Thanks for your feedback.  I’m hopeful that your advice will be helpful for Daniel in figuring out how to modify the GCC build system.

As said I'm still not convinced building those libraries in-tree is
the best way forward.  I won't stand in the way of making that
work though.

Richard.

> Damian
>
>