Message ID | 024e798b9539b765a1259cfc9cb2f1dc480b24ca.1536144068.git.ams@codesourcery.com |
---|---|
State | New |
Headers | show |
Series | AMD GCN Port | expand |
Please send fortran patches to the fortran list as well! On Wed, Sep 5, 2018 at 7:54 PM Toon Moene <toon@moene.org> wrote: > > > > -------- Forwarded Message -------- > Subject: [PATCH 08/25] Fix co-array allocation > Date: Wed, 5 Sep 2018 12:49:40 +0100 > From: ams@codesourcery.com > To: gcc-patches@gcc.gnu.org > > > The Fortran front-end has a bug in which it uses "int" values for "size_t" > parameters. I don't know why this isn't problem for all 64-bit > architectures, > but GCN ends up with the data in the wrong argument register and/or > stack slot, > and bad things happen. > > This patch corrects the issue by setting the correct type. > > 2018-09-05 Kwok Cheung Yeung <kcy@codesourcery.com> > > gcc/fortran/ > * trans-expr.c (gfc_trans_structure_assign): Ensure that > integer_zero_node is of sizetype when used as the first > argument of a call to _gfortran_caf_register. > The argument must be of type size_type_node, not sizetype. Please instead use size = build_zero_cst (size_type_node); > * trans-intrinsic.c (conv_intrinsic_event_query): Convert computed > index to a size_t type. > Using integer_type_node is wrong, but the correct type for calculating array indices (lbound, ubound, etc.) is not size_type_node but rather gfc_array_index_type (which in practice maps to ptrdiff_t). So please use that, and then fold_convert index to size_type_node just before generating the call to event_query. > * trans-stmt.c (gfc_trans_event_post_wait): Likewise. > Same here as above. Thanks,
On 05/09/18 19:07, Janne Blomqvist wrote: > The argument must be of type size_type_node, not sizetype. Please instead > use > > size = build_zero_cst (size_type_node); > > >> * trans-intrinsic.c (conv_intrinsic_event_query): Convert computed >> index to a size_t type. >> > > Using integer_type_node is wrong, but the correct type for calculating > array indices (lbound, ubound, etc.) is not size_type_node but rather > gfc_array_index_type (which in practice maps to ptrdiff_t). So please use > that, and then fold_convert index to size_type_node just before generating > the call to event_query. > > >> * trans-stmt.c (gfc_trans_event_post_wait): Likewise. >> > > Same here as above. How is the attached? I retested and found no regressions. Andrew Fix co-array allocation The Fortran front-end has a bug in which it uses "int" values for "size_t" parameters. I don't know why this isn't problem for all 64-bit architectures, but GCN ends up with the data in the wrong argument register and/or stack slot, and bad things happen. This patch corrects the issue by setting the correct type. 2018-09-19 Andrew Stubbs <ams@codesourcery.com> Kwok Cheung Yeung <kcy@codesourcery.com> gcc/fortran/ * trans-expr.c (gfc_trans_structure_assign): Ensure that the first argument of a call to _gfortran_caf_register is of size_type_node. * trans-intrinsic.c (conv_intrinsic_event_query): Convert computed index to a size_type_node type. * trans-stmt.c (gfc_trans_event_post_wait): Likewise. diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c index 56ce98c..28079ac 100644 --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -7729,7 +7729,7 @@ gfc_trans_structure_assign (tree dest, gfc_expr * expr, bool init, bool coarray) suffices to recognize the data as array. */ if (rank < 0) rank = 1; - size = integer_zero_node; + size = build_zero_cst (size_type_node); desc = field; gfc_add_modify (&block, gfc_conv_descriptor_rank (desc), build_int_cst (signed_char_type_node, rank)); diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c index b2cea93..569435d 100644 --- a/gcc/fortran/trans-intrinsic.c +++ b/gcc/fortran/trans-intrinsic.c @@ -10732,7 +10732,9 @@ conv_intrinsic_event_query (gfc_code *code) tmp = fold_build2_loc (input_location, MULT_EXPR, integer_type_node, extent, tmp); index = fold_build2_loc (input_location, PLUS_EXPR, - integer_type_node, index, tmp); + gfc_array_index_type, index, + fold_convert (gfc_array_index_type, + tmp)); if (i < ar->dimen - 1) { ubound = gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[i]); @@ -10756,6 +10758,7 @@ conv_intrinsic_event_query (gfc_code *code) stat = gfc_create_var (integer_type_node, "stat"); } + index = fold_convert (size_type_node, index); tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_event_query, 5, token, index, image_index, count ? gfc_build_addr_expr (NULL, count) : count, diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c index 795d3cc..92d9c37 100644 --- a/gcc/fortran/trans-stmt.c +++ b/gcc/fortran/trans-stmt.c @@ -1096,7 +1096,8 @@ gfc_trans_event_post_wait (gfc_code *code, gfc_exec_op op) tmp = fold_build2_loc (input_location, MULT_EXPR, integer_type_node, extent, tmp); index = fold_build2_loc (input_location, PLUS_EXPR, - integer_type_node, index, tmp); + gfc_array_index_type, index, + fold_convert (gfc_array_index_type, tmp)); if (i < ar->dimen - 1) { ubound = gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[i]); @@ -1130,6 +1131,7 @@ gfc_trans_event_post_wait (gfc_code *code, gfc_exec_op op) stat = gfc_create_var (integer_type_node, "stat"); } + index = fold_convert (size_type_node, index); if (op == EXEC_EVENT_POST) tmp = build_call_expr_loc (input_location, gfor_fndecl_caf_event_post, 6, token, index, image_index,
Has this been tested in multi-image execution using OpenCoarrays? If not, I would be glad to assist with installing OpenCoarrays so that it can be part of the testing process. 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. If anyone has any interest in figuring out how to do this, it will prevent a lot of potential regressions when single-image testing doesn't expose issues that only arise with multi-image execution. Damian On Wed, Sep 19, 2018 at 9:25 AM Andrew Stubbs <ams@codesourcery.com> wrote: > On 05/09/18 19:07, Janne Blomqvist wrote: > > The argument must be of type size_type_node, not sizetype. Please instead > > use > > > > size = build_zero_cst (size_type_node); > > > > > >> * trans-intrinsic.c (conv_intrinsic_event_query): Convert > computed > >> index to a size_t type. > >> > > > > Using integer_type_node is wrong, but the correct type for calculating > > array indices (lbound, ubound, etc.) is not size_type_node but rather > > gfc_array_index_type (which in practice maps to ptrdiff_t). So please use > > that, and then fold_convert index to size_type_node just before > generating > > the call to event_query. > > > > > >> * trans-stmt.c (gfc_trans_event_post_wait): Likewise. > >> > > > > Same here as above. > > How is the attached? I retested and found no regressions. > > Andrew >
On 19/09/18 22:18, Damian Rouson wrote: > Has this been tested in multi-image execution using OpenCoarrays? If > not, I would be glad to assist with installing OpenCoarrays so that it > can be part of the testing process. It's been tested with the GCC testsuite -- the same suite that found the issue in the first place. If you want to port your tool to GCN that would be cool, but I suspect non-trivial. > 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. If anyone has any interest in figuring out how to > do this, it will prevent a lot of potential regressions when > single-image testing doesn't expose issues that only arise with > multi-image execution. I suggest you post this question in a fresh thread. Andrew
On Wed, Sep 19, 2018 at 3:30 PM Andrew Stubbs <ams@codesourcery.com> wrote: > > If you want to port your tool to GCN that would be cool, but I suspect > non-trivial. > To clarify, OpenCoarrays is not a tool. It is the parallel ABI required to create executable programs capable of executing in multiple images as required by the Fortran 2008 standard. Multi-image execution is the reason coarray features exist so I hope the maintainers won't approve a patch that impacts coarray features but has not been tested against OpenCoarrays, which has its own test suite. Again, I would be glad to assist with installing OpenCoarrays on your system. Whether it's trivial or not, it's essential to protect against breaking a large feature set that is part of Fortran 2008 and 2018. Damian
On Wed, Sep 19, 2018 at 7:24 PM Andrew Stubbs <ams@codesourcery.com> wrote: > On 05/09/18 19:07, Janne Blomqvist wrote: > > The argument must be of type size_type_node, not sizetype. Please instead > > use > > > > size = build_zero_cst (size_type_node); > > > > > >> * trans-intrinsic.c (conv_intrinsic_event_query): Convert > computed > >> index to a size_t type. > >> > > > > Using integer_type_node is wrong, but the correct type for calculating > > array indices (lbound, ubound, etc.) is not size_type_node but rather > > gfc_array_index_type (which in practice maps to ptrdiff_t). So please use > > that, and then fold_convert index to size_type_node just before > generating > > the call to event_query. > > > > > >> * trans-stmt.c (gfc_trans_event_post_wait): Likewise. > >> > > > > Same here as above. > > How is the attached? I retested and found no regressions. > > Andrew > Ok, looks good. There are some other remaining incorrect uses of integer_type_node (at least one visible in the diff), but that can be done as a separate patch (not saying you must do it as a precondition for anything, though it would of course be nice if you would. :) )
On 20/09/18 16:56, Janne Blomqvist wrote: > Ok, looks good. Thanks. > There are some other remaining incorrect uses of integer_type_node (at > least one visible in the diff), but that can be done as a separate patch > (not saying you must do it as a precondition for anything, though it > would of course be nice if you would. :) ) I'm not confident I can tell what should be integer_type_node, and what should not? Once it gets to build_call_expr_loc it's clear that the types should match the function signature, but the intermediate values' types are not obvious to me. Andrew
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.) Maybe these people could use some help from you. Regards Thomas
On Thu, Sep 20, 2018 at 1:01 PM Thomas Koenig <tkoenig@netcologne.de> wrote: > > We addressed integrating OpenCoarray into the gcc source tree at the > recent Gcc summit during the gfortran BoF session. > I agree with keeping it as a separate code base, but comments from some gfortran developers on the gfortran mailing list suggest that they liked the idea of integrating the building of OpenCoarrays into the GCC build system to simplify multi-image testing. > 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.) > > Maybe these people could use some help from you. > Thanks for the feedback. Please feel free to put me in touch with them or suggest that they submit issues on the OpenCoarrays repository. We would be glad to help. We've put a lot of time into addressing installation issues that have been submitted to us and we'll continue to do so if we receive reports. Damian
On 09/20/2018 10: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.) Well, Linux distributors have to fit the build of OpenCoarrays into *their* build system, which might be just as complicated as we trying it to force it into *gcc's* build system ... For an individual, OpenCoarrays is not hard to build, and the web page www.opencoarrays.org offers multiple solutions: "Installation via package management is generally the easiest and most reliable option. See below for the package-management installation options for Linux, macOS, and FreeBSD. Alternatively, download and build the latest OpenCoarrays release via the contained installation scripts or with CMake." I choose the cmake based one, because I already had cmake installed to be able to build ECMWF's (ecmwf.int) eccodes package. It probably helped that I also already had openmpi installed. From my command history: 1754 tar zxvf ~/Downloads/OpenCoarrays-2.2.0.tar.gz 1755 cd OpenCoarrays-2.2.0/ 1756 ls 1757 less README.md 1758 cd .. 1759 mkdir opencoarrays-build 1760 cd opencoarrays-build 1761 (export FC=gfortran; export CC=gcc; cmake ../OpenCoarrays-2.2.0/ -DCMAKE_INSTALL_PREFIX=$HOME/opencoarrays) 1762 make 1763 make test 1764 make install After that, it was a breeze to test my mock weather program (moene.org/~toon/random-weather.f90), that I had built until then only with -fcoarray=single.
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. As I said, my 2 cents worth. Regards to all, Jerry
On Fri, Sep 21, 2018 at 7:25 PM 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. > > As I said, my 2 cents worth. > > Regards to all, > > Jerry > > I recall one motivation for the current sort-of loose coupling between the coarray library and gfortran was to support, at runtime, different MPI libraries. This can be useful on cluster and supercomputers, where it's important to use a MPI library that can use the high-performance cluster network. If libgfortran includes the coarray library which links against a MPI library, it means libgfortran has to be rebuilt against every MPI library in use on a system, and most likely, one cannot use the distro-provided gfortran. This might not be insurmountable on cluster using some kind of module system, but still. I guess it might be possible to use weak symbols, like we currently use for some things in libgfortran (e.g. clock_gettime), but that would mean a quite big diff compared to upstream OpenCoarrays. And how to handle targets that don't support weak symbols in some sane fashion, etc.
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
On Fri, Sep 21, 2018 at 9:25 AM Jerry DeLisle <jvdelisle@charter.net> wrote: > The actual library source code is contained mostly in one source file. There are as many files as there are options for the underlying parallel programming model. The default is MPI, but I've co-authored conference papers last year and this year in which the OpenCoarrays OpenSHEM option outperformed MPI. One paper even described a platform on which OpenSHMEM was the only option beyond a few thousand cores because the required MPI features were immature on that platform. Early versions of OpenCoarrays also provided GASNet and ARMCI options. I recommend against tying gfortran to MPI only. > After all the attempts to integrate into the GNU build systems without > much success my thinking has shifted. Thanks for all your efforts! > 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. I agree. Possibly OpenCoarrays could drop support for older gfortran versions at some point to avoid maintaining code that exists solely to support compiler versions that are several years old. > > 1) Focus on distribution packages such as Fedora, Debian, Ubuntu, > Windows, etc. Building of these packages needs to be automated into the > distributions. This is the option that the OpenCoarrays documentation recommends as easiest for most users. > 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. See above. Also, this means that changes in the gfortran repository would not propagate back upstream unless each gfortran developer agrees to distribute his or her work under both GPL and BSD. Even that is only feasible if the copied files stay cohesive and don't reference code outside the copied file. I think it's more likely that copying the code into gfortran would be a branch point, after which the relevant files would diverge and work on the GPL side would be harder to fund than the BSD side. Most commercial entities are more likely to contribute to a BSD-licensed project than a GPL-licensed one. Over the past several months, one commercial compiler vendor authorized one of their developers to contribute to OpenCoarrays. and another commercial compiler vendor invited community input on whether to use OpenCoarrays during a public teleconference. The prospect of commercial support is the motivation for using BSD. > Strategy 2 does have some advantages. For example, eliminating the need > for separate CAF and CAFRUN scripts which are a wrapper on gfortran. Even in the case of just one underlying parallel programming model, this is tricky. To wit, Cray uses a compiler wrapper and a program launcher. Intel was able to eliminate the compiler wrapper, but still required a program launcher for distributed-memory execution until recently. I don't know the details, but I've heard it was not trivial for Intel to accomplish this and I imagine it would be even more complicated if they weren't hardwiring Intel MPI into their back-end. > People would just have to stop thinking about it and just use it. The same would be true if someone could coax the GCC build system to build OpenCoarrays just as it builds other prerequisites. The big difference is that OpenCoarrays is a prerequisite for using gfortran rather than for building gfortran so it needs to be built after gfortran rather than before like other prerequisites. The real problem is finding anyone who can work the proper magic in the GCC build system. Thanks for your input. I hope my response is helpful. Damian
On 9/21/18 1:16 PM, Damian Rouson wrote:> On Fri, Sep 21, 2018 at 9:25 AM Jerry DeLisle <jvdelisle@charter.net> wrote: > >> The actual library source code is contained mostly in one source file. > > There are as many files as there are options for the underlying > parallel programming > model. The default is MPI, but I've co-authored conference papers last year > and this year in which the OpenCoarrays OpenSHEM option outperformed MPI. > One paper even described a platform on which OpenSHMEM was the only option > beyond a few thousand cores because the required MPI features were immature on > that platform. Early versions of OpenCoarrays also provided GASNet > and ARMCI options. > I recommend against tying gfortran to MPI only. I agree with you on this point. Perhaps the Opencoarrays implementation should somehow do some runtime introspection to allow the library to sync to whatever is desired on a given system. The gfortran interface was designed to be generic. Implementation should be more dynamic in run time linking and abstracted in such a way that OpenCoarrays could be compiled stand alone and use something like "plugins" to allow post build the determination of what which interface to use. I am by no means a software expert in these techniques, but they are becoming common practice in other areas, for example linux/Gnu kernel modules > >> After all the attempts to integrate into the GNU build systems without >> much success my thinking has shifted. > > Thanks for all your efforts! > >> 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. > > I agree. Possibly OpenCoarrays could drop support for older gfortran versions > at some point to avoid maintaining code that exists solely to support compiler > versions that are several years old. See my comments above about pluggable modules. Maybe libgfortran should have this pluggable interface and Opencoarrays provide the plugins. Think how useful it would be to be able to choose the backend at time of execution based on a simple envoronment variable set by the user. > >> >> 1) Focus on distribution packages such as Fedora, Debian, Ubuntu, >> Windows, etc. Building of these packages needs to be automated into the >> distributions. > > This is the option that the OpenCoarrays documentation recommends as easiest for > most users. Agree. > >> 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. > > See above. Also, this means that changes in the gfortran repository would not > propagate back upstream unless each gfortran developer agrees to > distribute his or her > work under both GPL and BSD. Even that is only feasible if the copied > files stay cohesive The flip of this would be to have the OpenCorrays developers to agree to the GPL and release under both. The libgfortran license says: "Under Section 7 of GPL version 3, you are granted additional permissions described in the GCC Runtime Library Exception, version 3.1, as published by the Free Software Foundation." Probably worth a fresh look. > and don't reference code outside the copied file. I think it's more > likely that copying the code > into gfortran would be a branch point, after which the relevant files > would diverge and > work on the GPL side would be harder to fund than the BSD side. > > Most commercial entities are more likely to contribute to a > BSD-licensed project than a > GPL-licensed one. Over the past several months, one commercial compiler vendor > authorized one of their developers to contribute to OpenCoarrays. and > another commercial > compiler vendor invited community input on whether to use OpenCoarrays > during a public > teleconference. The prospect of commercial support is the motivation > for using BSD. I really have no commercial interest. So I will not comment on GPL vs BSD other than referring to the multitude of FSF recommendations about why one should choose one of the FSF flavors rather than BSD. > >> Strategy 2 does have some advantages. For example, eliminating the need >> for separate CAF and CAFRUN scripts which are a wrapper on gfortran. > > Even in the case of just one underlying parallel programming model, > this is tricky. To wit, Cray uses > a compiler wrapper and a program launcher. Intel was able to > eliminate the compiler wrapper, > but still required a program launcher for distributed-memory execution > until recently. I don't > know the details, but I've heard it was not trivial for Intel to > accomplish this and I imagine it would be > even more complicated if they weren't hardwiring Intel MPI into their back-end. Well here is one commercial entity that did not shy away from 'hardwiring' MPI, Regardless, using plugins would resolve concerns about which MPI to use or whether to use shared memory or some other model. > >> People would just have to stop thinking about it and just use it. > > The same would be true if someone could coax the GCC build system to > build OpenCoarrays > just as it builds other prerequisites. The big difference is that > OpenCoarrays is a prerequisite > for using gfortran rather than for building gfortran so it needs to be > built after gfortran rather > than before like other prerequisites. The real problem is finding > anyone who can work the > proper magic in the GCC build system. I dont see this as the real problem. The forking idea would resolve this fairly easily. Above, you mentioned concern about locking into MPI. Do the packaged versions of OpenCoarrays not lock into MPI, either OpenMPI or MPICH? I have not tried one yet since I am waiting for the Fedora one to hit the release. If the tight coupling is needed maybe there ought to be a set of libraries or modules, one for each "backend". (Back to my pluggable modules concept) The more I think about it the more I think this is the fundamental design issue. > > Thanks for your input. I hope my response is helpful. > > Damian > As always, best regards. Jerry
On 09/22/2018 01:23 AM, Jerry DeLisle wrote: > On 9/21/18 1:16 PM, Damian Rouson wrote:> On Fri, Sep 21, 2018 at 9:25 > AM Jerry DeLisle <jvdelisle@charter.net> wrote: > >> 1) Focus on distribution packages such as Fedora, Debian, Ubuntu, > >> Windows, etc. Building of these packages needs to be automated into the > >> distributions. > > > > This is the option that the OpenCoarrays documentation recommends as > easiest for > > most users. > > Agree. I just installed opencoarrays on my system at home (Debian Testing): root@moene:~# apt-get install libcoarrays-openmpi-dev Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libcaf-openmpi-3 The following NEW packages will be installed: libcaf-openmpi-3 libcoarrays-openmpi-dev 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 107 kB of archives. After this operation, 317 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://ftp.nl.debian.org/debian testing/main amd64 libcaf-openmpi-3 amd64 2.2.0-3 [38.2 kB] Get:2 http://ftp.nl.debian.org/debian testing/main amd64 libcoarrays-openmpi-dev amd64 2.2.0-3 [68.9 kB] Fetched 107 kB in 0s (634 kB/s) Selecting previously unselected package libcaf-openmpi-3:amd64. (Reading database ... 212249 files and directories currently installed.) Preparing to unpack .../libcaf-openmpi-3_2.2.0-3_amd64.deb ... Unpacking libcaf-openmpi-3:amd64 (2.2.0-3) ... Selecting previously unselected package libcoarrays-openmpi-dev:amd64. Preparing to unpack .../libcoarrays-openmpi-dev_2.2.0-3_amd64.deb ... Unpacking libcoarrays-openmpi-dev:amd64 (2.2.0-3) ... Setting up libcaf-openmpi-3:amd64 (2.2.0-3) ... Setting up libcoarrays-openmpi-dev:amd64 (2.2.0-3) ... Processing triggers for libc-bin (2.27-6) ... [ previously this led to apt errors, but not now. ] and moved my own installation of the OpenCoarrays-2.2.0.tar.gz out of the way: toon@moene:~$ ls -ld *pen* drwxr-xr-x 6 toon toon 4096 Aug 10 16:01 OpenCoarrays-2.2.0.opzij drwxr-xr-x 8 toon toon 4096 Sep 15 11:26 opencoarrays-build.opzij drwxr-xr-x 6 toon toon 4096 Sep 15 11:26 opencoarrays.opzij and recompiled my stuff: gfortran -g -fbacktrace -fcoarray=lib random-weather.f90 -L/usr/lib/x86_64-linux-gnu/open-coarrays/openmpi/lib -lcaf_mpi [ Yes, the location of the libs is quite experimental, but OK for the "Testing" variant of Debian ... ] I couldn't find cafrun, but mpirun works just fine: toon@moene:~/src$ echo ' &config /' | mpirun --oversubscribe --bind-to none -np 20 ./a.out Decomposition information on image 7 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 6 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 11 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 15 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 1 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 13 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 12 is 4 * 5 slabs with 21 * 18 grid cells on this image. Decomposition information on image 20 is 4 * 5 slabs with 21 * 18 grid cells on this image. Decomposition information on image 9 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 14 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 16 is 4 * 5 slabs with 21 * 18 grid cells on this image. Decomposition information on image 17 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 18 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 2 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 4 is 4 * 5 slabs with 21 * 18 grid cells on this image. Decomposition information on image 5 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 3 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 8 is 4 * 5 slabs with 21 * 18 grid cells on this image. Decomposition information on image 10 is 4 * 5 slabs with 23 * 18 grid cells on this image. Decomposition information on image 19 is 4 * 5 slabs with 23 * 18 grid cells on this image. ... etc. (see http://moene.org/~toon/random-weather.f90). I presume other Linux distributors will follow shortly (this *is* Debian Testing, which can be a bit testy at times - but I do trust my main business at home on it for over 15 years now). Kind regards,
On Fri, Sep 21, 2018 at 10:33 AM Toon Moene <toon@moene.org> wrote: > On 09/20/2018 10: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.) > > Well, Linux distributors have to fit the build of OpenCoarrays into > *their* build system, which might be just as complicated as we trying it > to force it into *gcc's* build system ... > > For an individual, OpenCoarrays is not hard to build, and the web page > www.opencoarrays.org offers multiple solutions: > > "Installation via package management is generally the easiest and most > reliable option. See below for the package-management installation > options for Linux, macOS, and FreeBSD. Alternatively, download and > build the latest OpenCoarrays release via the contained installation > scripts or with CMake." > > I choose the cmake based one, because I already had cmake installed to > be able to build ECMWF's (ecmwf.int) eccodes package. It probably helped > that I also already had openmpi installed. From my command history: > > 1754 tar zxvf ~/Downloads/OpenCoarrays-2.2.0.tar.gz > 1755 cd OpenCoarrays-2.2.0/ > 1756 ls > 1757 less README.md > 1758 cd .. > 1759 mkdir opencoarrays-build > 1760 cd opencoarrays-build > 1761 (export FC=gfortran; export CC=gcc; cmake ../OpenCoarrays-2.2.0/ > -DCMAKE_INSTALL_PREFIX=$HOME/opencoarrays) > 1762 make > 1763 make test > 1764 make install > FWIW, this didn't work for me, as I want to use my own build of gfortran trunk. It did correctly use the correct gfortran binary as specified by the FC env. variable, but it still insists on linking against libgfortran.so.4 (installed by the system package manager) and not the libgfortran.so.5 from my own gfortran installation (found both on LD_RUN_PATH and LD_LIBRARY_PATH). I tried -DCMAKE_PREFIX_PATH=... but that didn't work any better. Gah, I hate cmake.. Any ideas?
On 23 September 2018 11:46:57 CEST, Toon Moene <toon@moene.org> wrote: >On 09/22/2018 01:23 AM, Jerry DeLisle wrote: > >> On 9/21/18 1:16 PM, Damian Rouson wrote:> On Fri, Sep 21, 2018 at >9:25 >> AM Jerry DeLisle <jvdelisle@charter.net> wrote: > >> >> 1) Focus on distribution packages such as Fedora, Debian, Ubuntu, >> >> Windows, etc. Building of these packages needs to be automated >into the >> >> distributions. >> > >> > This is the option that the OpenCoarrays documentation recommends >as >> easiest for >> > most users. >> >> Agree. > >I just installed opencoarrays on my system at home (Debian Testing): > >root@moene:~# apt-get install libcoarrays-openmpi-dev >Reading package lists... Done >Building dependency tree >Reading state information... Done >The following additional packages will be installed: > libcaf-openmpi-3 >The following NEW packages will be installed: > libcaf-openmpi-3 libcoarrays-openmpi-dev >0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. >Need to get 107 kB of archives. >After this operation, 317 kB of additional disk space will be used. >Do you want to continue? [Y/n] >Get:1 http://ftp.nl.debian.org/debian testing/main amd64 >libcaf-openmpi-3 amd64 2.2.0-3 [38.2 kB] >Get:2 http://ftp.nl.debian.org/debian testing/main amd64 >libcoarrays-openmpi-dev amd64 2.2.0-3 [68.9 kB] >Fetched 107 kB in 0s (634 kB/s) >Selecting previously unselected package libcaf-openmpi-3:amd64. >(Reading database ... 212249 files and directories currently >installed.) >Preparing to unpack .../libcaf-openmpi-3_2.2.0-3_amd64.deb ... >Unpacking libcaf-openmpi-3:amd64 (2.2.0-3) ... >Selecting previously unselected package libcoarrays-openmpi-dev:amd64. >Preparing to unpack .../libcoarrays-openmpi-dev_2.2.0-3_amd64.deb ... >Unpacking libcoarrays-openmpi-dev:amd64 (2.2.0-3) ... >Setting up libcaf-openmpi-3:amd64 (2.2.0-3) ... >Setting up libcoarrays-openmpi-dev:amd64 (2.2.0-3) ... >Processing triggers for libc-bin (2.27-6) ... > >[ previously this led to apt errors, but not now. ] > >and moved my own installation of the OpenCoarrays-2.2.0.tar.gz out of >the way: > >toon@moene:~$ ls -ld *pen* >drwxr-xr-x 6 toon toon 4096 Aug 10 16:01 OpenCoarrays-2.2.0.opzij >drwxr-xr-x 8 toon toon 4096 Sep 15 11:26 opencoarrays-build.opzij >drwxr-xr-x 6 toon toon 4096 Sep 15 11:26 opencoarrays.opzij > >and recompiled my stuff: > >gfortran -g -fbacktrace -fcoarray=lib random-weather.f90 >-L/usr/lib/x86_64-linux-gnu/open-coarrays/openmpi/lib -lcaf_mpi > >[ Yes, the location of the libs is quite experimental, but OK for the >"Testing" variant of Debian ... ] Are you sure you need the -L? For me a simple -fcoarray=lib -lcaf_mpi links fine. Along the same lines a simple $ mpirun -np 4 ./a.out runs fine as expected, like any other mpi program. Cheers, > >I couldn't find cafrun, but mpirun works just fine: > >toon@moene:~/src$ echo ' &config /' | mpirun --oversubscribe --bind-to >none -np 20 ./a.out >Decomposition information on image 7 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 6 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 11 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 15 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 1 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 13 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 12 is 4 * 5 slabs with 21 >* > 18 grid cells on this image. >Decomposition information on image 20 is 4 * 5 slabs with 21 >* > 18 grid cells on this image. >Decomposition information on image 9 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 14 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 16 is 4 * 5 slabs with 21 >* > 18 grid cells on this image. >Decomposition information on image 17 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 18 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 2 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 4 is 4 * 5 slabs with 21 >* > 18 grid cells on this image. >Decomposition information on image 5 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 3 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 8 is 4 * 5 slabs with 21 >* > 18 grid cells on this image. >Decomposition information on image 10 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. >Decomposition information on image 19 is 4 * 5 slabs with 23 >* > 18 grid cells on this image. > >... etc. (see http://moene.org/~toon/random-weather.f90). > >I presume other Linux distributors will follow shortly (this *is* >Debian >Testing, which can be a bit testy at times - but I do trust my main >business at home on it for over 15 years now). > >Kind regards,
On 23/09/2018 10:46, Toon Moene wrote: > On 09/22/2018 01:23 AM, Jerry DeLisle wrote: > > I just installed opencoarrays on my system at home (Debian Testing): > > root@moene:~# apt-get install libcoarrays-openmpi-dev > ... > Setting up libcaf-openmpi-3:amd64 (2.2.0-3) ... > Setting up libcoarrays-openmpi-dev:amd64 (2.2.0-3) ... > Processing triggers for libc-bin (2.27-6) ... > > [ previously this led to apt errors, but not now. ] > > and moved my own installation of the OpenCoarrays-2.2.0.tar.gz out of > the way: > > toon@moene:~$ ls -ld *pen* > drwxr-xr-x 6 toon toon 4096 Aug 10 16:01 OpenCoarrays-2.2.0.opzij > drwxr-xr-x 8 toon toon 4096 Sep 15 11:26 opencoarrays-build.opzij > drwxr-xr-x 6 toon toon 4096 Sep 15 11:26 opencoarrays.opzij > > and recompiled my stuff: > > gfortran -g -fbacktrace -fcoarray=lib random-weather.f90 > -L/usr/lib/x86_64-linux-gnu/open-coarrays/openmpi/lib -lcaf_mpi > > [ Yes, the location of the libs is quite experimental, but OK for the > "Testing" variant of Debian ... ] > > I couldn't find cafrun, but mpirun works just fine: > > toon@moene:~/src$ echo ' &config /' | mpirun --oversubscribe --bind-to > none -np 20 ./a.out > Decomposition information on image 7 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 6 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 11 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 15 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 1 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 13 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 12 is 4 * 5 slabs with 21 > * 18 grid cells on this image. > Decomposition information on image 20 is 4 * 5 slabs with 21 > * 18 grid cells on this image. > Decomposition information on image 9 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 14 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 16 is 4 * 5 slabs with 21 > * 18 grid cells on this image. > Decomposition information on image 17 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 18 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 2 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 4 is 4 * 5 slabs with 21 > * 18 grid cells on this image. > Decomposition information on image 5 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 3 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 8 is 4 * 5 slabs with 21 > * 18 grid cells on this image. > Decomposition information on image 10 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > Decomposition information on image 19 is 4 * 5 slabs with 23 > * 18 grid cells on this image. > > ... etc. (see http://moene.org/~toon/random-weather.f90). > > I presume other Linux distributors will follow shortly (this *is* > Debian Testing, which can be a bit testy at times - but I do trust my > main business at home on it for over 15 years now). > > Kind regards, > Thanks, good to see it being tested (I'm the Debian/Ubuntu packager). caf /cafrun has been dropped (for the moment ? ) in favour of mpirun, but I've added pkg-config caf packages so that becomes an option. $ pkg-config caf-mpich --libs -L/usr/lib/x86_64-linux-gnu/open-coarrays/mpich/lib -lcaf_mpich -Wl,-z,relro -lmpich -lm -lbacktrace -lpthread -lrt (My thinking is that for libraries in particular, the user need not know whether CAF is being used, and if lib foobar uses CAF, then adding a: Requires: caf into the pkg-config file gives you the correct linking transparently. The "strange" paths are due to Debians multiarch : it is possible to include libraries for multiple architectures simultaneously. This works ok with pkg-config and cmake , etc (which allow you to set PKG_CONFIG_PATH and have multiple pkgconfig files for different libs simultaneously) , but currently break wrappers such as caf / cafrun. I can add a new package for caf / cafrun but would rather not. (W e currently don't do non-MPI CAF builds). There is currently pkg-config files 'caf-mpich' and 'caf-openmpi' for testing, and I'm adding a default alias caf -> caf-$(default-MPI) regards Alastair
On Mon, Sep 24, 2018 at 12:58 PM Alastair McKinstry <mckinstry@debian.org> wrote: > > > On 23/09/2018 10:46, Toon Moene wrote: > > On 09/22/2018 01:23 AM, Jerry DeLisle wrote: > > > > I just installed opencoarrays on my system at home (Debian Testing): > > > > root@moene:~# apt-get install libcoarrays-openmpi-dev > > ... > > Setting up libcaf-openmpi-3:amd64 (2.2.0-3) ... > > Setting up libcoarrays-openmpi-dev:amd64 (2.2.0-3) ... > > Processing triggers for libc-bin (2.27-6) ... > > > > [ previously this led to apt errors, but not now. ] > > > > and moved my own installation of the OpenCoarrays-2.2.0.tar.gz out of > > the way: > > > > toon@moene:~$ ls -ld *pen* > > drwxr-xr-x 6 toon toon 4096 Aug 10 16:01 OpenCoarrays-2.2.0.opzij > > drwxr-xr-x 8 toon toon 4096 Sep 15 11:26 opencoarrays-build.opzij > > drwxr-xr-x 6 toon toon 4096 Sep 15 11:26 opencoarrays.opzij > > > > and recompiled my stuff: > > > > gfortran -g -fbacktrace -fcoarray=lib random-weather.f90 > > -L/usr/lib/x86_64-linux-gnu/open-coarrays/openmpi/lib -lcaf_mpi > > > > [ Yes, the location of the libs is quite experimental, but OK for the > > "Testing" variant of Debian ... ] > > > > I couldn't find cafrun, but mpirun works just fine: > > > > toon@moene:~/src$ echo ' &config /' | mpirun --oversubscribe --bind-to > > none -np 20 ./a.out > > Decomposition information on image 7 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 6 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 11 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 15 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 1 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 13 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 12 is 4 * 5 slabs with 21 > > * 18 grid cells on this image. > > Decomposition information on image 20 is 4 * 5 slabs with 21 > > * 18 grid cells on this image. > > Decomposition information on image 9 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 14 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 16 is 4 * 5 slabs with 21 > > * 18 grid cells on this image. > > Decomposition information on image 17 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 18 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 2 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 4 is 4 * 5 slabs with 21 > > * 18 grid cells on this image. > > Decomposition information on image 5 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 3 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 8 is 4 * 5 slabs with 21 > > * 18 grid cells on this image. > > Decomposition information on image 10 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > Decomposition information on image 19 is 4 * 5 slabs with 23 > > * 18 grid cells on this image. > > > > ... etc. (see http://moene.org/~toon/random-weather.f90). > > > > I presume other Linux distributors will follow shortly (this *is* > > Debian Testing, which can be a bit testy at times - but I do trust my > > main business at home on it for over 15 years now). > > > > Kind regards, > > > Thanks, good to see it being tested (I'm the Debian/Ubuntu packager). > > caf /cafrun has been dropped (for the moment ? ) in favour of mpirun, > but I've added pkg-config caf packages so that becomes an option. > > $ pkg-config caf-mpich --libs > > -L/usr/lib/x86_64-linux-gnu/open-coarrays/mpich/lib -lcaf_mpich -Wl,-z,relro -lmpich -lm -lbacktrace -lpthread -lrt > > (My thinking is that for libraries in particular, the user need not know > whether CAF is being used, and if lib foobar uses CAF, then adding a: > > Requires: caf > > into the pkg-config file gives you the correct linking transparently. > > The "strange" paths are due to Debians multiarch : it is possible to > include libraries for multiple architectures simultaneously. This works > ok with pkg-config and cmake , etc (which allow you to set > PKG_CONFIG_PATH and have multiple pkgconfig files for different libs > simultaneously) , but currently break wrappers such as caf / cafrun. > > I can add a new package for caf / cafrun but would rather not. (W e > currently don't do non-MPI CAF builds). > > There is currently pkg-config files 'caf-mpich' and 'caf-openmpi' for > testing, and I'm adding a default alias caf -> caf-$(default-MPI) So I've tried packaging of OpenCoarrays for SUSE and noticed a few things: - caf by default links libcaf_mpi static (why?) - the build system makes the libcaf_mpi SONAME dependent on the compiler version(?), I once got libcaf_mpi2 and once libcaf_mpi3 (gcc7 vs. gcc8) different SONAMEs definitely makes packaging difficult. Of course since there's the first point I may very well elide the shared library alltogether....? Other than that it seems to "work" (OBS home:rguenther/OpenCoarrays). Richard. > regards > > Alastair > > > > > -- > Alastair McKinstry, <alastair@sceal.ie>, <mckinstry@debian.org>, https://diaspora.sceal.ie/u/amckinstry > Misentropy: doubting that the Universe is becoming more disordered. >
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c index 56ce98c..91be3fb 100644 --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -7729,7 +7729,7 @@ gfc_trans_structure_assign (tree dest, gfc_expr * expr, bool init, bool coarray) suffices to recognize the data as array. */ if (rank < 0) rank = 1; - size = integer_zero_node; + size = fold_convert (sizetype, integer_zero_node); desc = field; gfc_add_modify (&block, gfc_conv_descriptor_rank (desc), build_int_cst (signed_char_type_node, rank)); diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c index b2cea93..23c13da 100644 --- a/gcc/fortran/trans-intrinsic.c +++ b/gcc/fortran/trans-intrinsic.c @@ -10732,7 +10732,8 @@ conv_intrinsic_event_query (gfc_code *code) tmp = fold_build2_loc (input_location, MULT_EXPR, integer_type_node, extent, tmp); index = fold_build2_loc (input_location, PLUS_EXPR, - integer_type_node, index, tmp); + size_type_node, index, + fold_convert (size_type_node, tmp)); if (i < ar->dimen - 1) { ubound = gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[i]); diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c index 795d3cc..2c59675 100644 --- a/gcc/fortran/trans-stmt.c +++ b/gcc/fortran/trans-stmt.c @@ -1096,7 +1096,8 @@ gfc_trans_event_post_wait (gfc_code *code, gfc_exec_op op) tmp = fold_build2_loc (input_location, MULT_EXPR, integer_type_node, extent, tmp); index = fold_build2_loc (input_location, PLUS_EXPR, - integer_type_node, index, tmp); + size_type_node, index, + fold_convert (size_type_node, tmp)); if (i < ar->dimen - 1) { ubound = gfc_conv_descriptor_ubound_get (desc, gfc_rank_cst[i]);