[Patch] OpenMP/Fortran: Permit pure directives inside PURE
I intent to commit the attached patch soon.
However, I want to give anyone the chance to comment on any aspect before
committing. Comments after the commit are welcome as well :-)
OpenMP 5.2 now uses properties to clauses and "pure" is among those properties.
Note that pure-2.f90 contains also stubs for directives only added in TR11 or
TR12
to reduce the chance of missing those once they get implemented.
Additionally, 'scan' is 'pure' only since very recently - which I read
as bug fix; hence, it is accepted with the attached patch.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
OpenMP/Fortran: Permit pure directives inside PURE
Update permitted directives for directives marked in OpenMP's 5.2 as pure.
To ensure that list is updated, unimplemented directives are placed into
pure-2.f90 such the test FAILs once a known to be pure directive is
implemented without handling its pureness.
gcc/fortran/ChangeLog:
* parse.cc (decode_omp_directive): Accept all pure directives
inside a PURE procedures; handle 'error at(execution).
libgomp/ChangeLog:
* libgomp.texi (OpenMP 5.2): Mark pure-directive handling as 'Y'.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/nothing-2.f90: Remove one dg-error.
* gfortran.dg/gomp/pr79154-2.f90: Update expected dg-error wording.
* gfortran.dg/gomp/pr79154-simd.f90: Likewise.
* gfortran.dg/gomp/pure-1.f90: New test.
* gfortran.dg/gomp/pure-2.f90: New test.
* gfortran.dg/gomp/pure-3.f90: New test.
* gfortran.dg/gomp/pure-4.f90: New test.
gcc/fortran/parse.cc| 50 +-
gcc/testsuite/gfortran.dg/gomp/nothing-2.f90| 2 +-
gcc/testsuite/gfortran.dg/gomp/pr79154-2.f90| 24 +++
gcc/testsuite/gfortran.dg/gomp/pr79154-simd.f90 | 2 +-
gcc/testsuite/gfortran.dg/gomp/pure-1.f90 | 88 +
gcc/testsuite/gfortran.dg/gomp/pure-2.f90 | 73
gcc/testsuite/gfortran.dg/gomp/pure-3.f90 | 31 +
gcc/testsuite/gfortran.dg/gomp/pure-4.f90 | 35 ++
libgomp/libgomp.texi| 2 +-
9 files changed, 277 insertions(+), 30 deletions(-)
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 9730ab095e2..733294c8cfa 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -934,7 +934,16 @@ decode_omp_directive (void)
first (those also shall not turn off implicit pure). */
switch (c)
{
+case 'a':
+ /* For -fopenmp-simd, ignore 'assumes'; note no clause starts with 's'. */
+ if (!flag_openmp && gfc_match ("assumes") == MATCH_YES)
+ break;
+ matcho ("assumes", gfc_match_omp_assumes, ST_OMP_ASSUMES);
+ matchs ("assume", gfc_match_omp_assume, ST_OMP_ASSUME);
+ break;
case 'd':
+ matchds ("declare reduction", gfc_match_omp_declare_reduction,
+ ST_OMP_DECLARE_REDUCTION);
matchds ("declare simd", gfc_match_omp_declare_simd,
ST_OMP_DECLARE_SIMD);
matchdo ("declare target", gfc_match_omp_declare_target,
@@ -942,16 +951,25 @@ decode_omp_directive (void)
matchdo ("declare variant", gfc_match_omp_declare_variant,
ST_OMP_DECLARE_VARIANT);
break;
+case 'e':
+ matchs ("end assume", gfc_match_omp_eos_error, ST_OMP_END_ASSUME);
+ matchs ("end simd", gfc_match_omp_eos_error, ST_OMP_END_SIMD);
+ matcho ("error", gfc_match_omp_error, ST_OMP_ERROR);
+ break;
case 's':
+ matchs ("scan", gfc_match_omp_scan, ST_OMP_SCAN);
matchs ("simd", gfc_match_omp_simd, ST_OMP_SIMD);
break;
+case 'n':
+ matcho ("nothing", gfc_match_omp_nothing, ST_NONE);
+ break;
}
pure_ok = false;
if (flag_openmp && gfc_pure (NULL))
{
- gfc_error_now ("OpenMP directives other than SIMD or DECLARE TARGET "
- "at %C may not appear in PURE procedures");
+ gfc_error_now ("OpenMP directive at %C is not pure and thus may not "
+ "appear in a PURE procedure");
gfc_error_recovery ();
return ST_NONE;
}
@@ -967,11 +985,6 @@ decode_omp_directive (void)
else
matcho ("allocate", gfc_match_omp_allocate, ST_OMP_ALLOCATE);
matcho ("allocators", gfc_match_omp_allocators, ST_OMP_ALLOCATORS);
- /* For -fopenmp-simd, ignore 'assumes'; note no clause starts with 's'. */
- if (!flag_openmp && gfc_match ("assumes") == MATCH_YES)
- break;
- matcho ("assumes", gfc_match_omp_assumes, ST_OMP_ASSUMES);
- matchs ("assume", gfc_match_omp_assume, ST_OMP_ASSUME);
matcho ("atomic", gfc_match_omp_atomic, ST_OMP_ATOMIC);
break;
case 'b':
@@ -984,8 +997,6 @@ decode_omp_directive (void)
matcho ("critical", gfc_match_omp_critical, ST_OMP_CRITICAL);
break;
case 'd':
- matchds ("declare
Re: Possible funding of gfortran work
Thanks for working on this, guys. I made a few suggestions below. Damian On Wed, May 31, 2023 at 5:25 AM Andre Vehreschild via Fortran < fortran@gcc.gnu.org> wrote: > > - Dependencies (on the project as well as projects that depend on the > technology; max 300 words) > > CP2K https://www.cp2k.org/ Coarray codes: ICAR: https://github.com/ncar/icar FEATS: https://github.com/sourceryinstitute/feats FAVOR*: https://www.nrc.gov/reading-rm/doc-collections/nuregs/staff/sr1795/index.html * This is a closed-source project that will feature parallel execution with coarrays in an upcoming release. For additional coarray codes, check out these references: Mozdzynski, G., Hamrud, M., & Wedi, N. (2015) A Partitioned Global Address Space implementation of the European Centre for Medium Range Weather Forecasts Integrated Forecasting System. International Journal of High Performance Computing Applications. Garain, S., Balsara, D. S., & Reid, J. (2015) Comparing Coarray Fortran (CAF) with MPI for several structured mesh PDE applications. Journal of Computational Physics. Preissl, R., Wichmann, N., Long, B., Shalf, J., Ethier, S., & Koniges, A. (2011) Multithreaded global address space communication techniques for gyrokinetic fusion applications on ultra-scale platforms. In Proceedings of 2011 International Conference for High Performance Computing, Networking, Storage and Analysis (p. 78). ACM. Other important Fortran codes that don't necessarily use coarrays: NWChem computational chemistry software FUN3D computational fluid dynamics software from NASA MSC NASTRAN structural engineering software from MSC Software WRF weather forecasting software from NCAR FAST nuclear fuel performance software from the U.S. Nuclear Regulatory Commission (NRC) > - Why is it critical to fund this project (300 words max)? > > Fortran remains one of the premier language for science, especially for > high-performance computing and fields like quantum chemistry or > computational fluid dynamics. > If you want some usage data, I can provide PDF slides, but I don't think the gfortran mailing list takes attachments so you'll have to contact me directly. > gfortran is the default Fortran compiler on many Linux systems, and lack of > features and bugs in gfortran hinder adoption of more modern, safer and > more > efficient language features. The project has been almost entirely > volunteer-driven so far, but is currently suffering from a lack of active > developers for larger features. Funding will enable the project to pay some > gfortran experienced developers to implement some of missing/incomplete > features, that are too large to tackle for a single volunteer. Payed > developers > are to contribute a significant part of the features. > > - Target of the projects in the sense of users (max 300 words) > > High-performance computing community, esp. but not limited to fluid and > thermo > dynamics, wheater forecasting > I would mention the worldwide impact of weather and climate models, all of which are Fortran codes. I would also mention nuclear energy. All of the codes developed by the U.S. Nuclear Regulatory Commission and used for licensing power plants are Fortran codes. Also aerospace, e.g., FUN3D developed by NASA and used by SpaceX and several aircraft manufcaturers. And automotive engineering (mention NASTRAN developed by MSC Software and used by several automotive companies). > > - How was the project funded in the past (max 300 words) > If you don't mind mentioning that the foundational work on the front-end was partly funded by Sourcery Institute with the remainder being the work of volunteers, that would be appreciated. Of course, none of the work on the shared-memory library was funded by Sourcery Institute so maybe the Sourcery Institute is not relevant. Your call. > > - Project goal (max 900 words!): > > * Fortran has a safe and intuitive method for parallel execution, > coarrays. There is currently no complete and efficient implementation for > multi-core CPUs on a freely available compiler. The goal is to bring > the existing, process-based shared memory implementation on a branch > into gfortran mainline as a feature for further evaluation and hardening. > This is good. I think I saw an earlier version without the "on a freely available compiler" text. This version is accurate. > > * GFortran's coarrays for distributed memory lack support for data > structures > provided modules that have not been compiled with coarray support (or are > distributed in binary form only). Research and prototypical > implementation > shall be conducted with the goal to find a general and well performing > solution. This could become an outstanding feature for a free compiler. > Will this work also require working inside OpenCoarrays? If so, that would be great and it's probably important to mention OpenCoarrays directly here because it's separate software with a different license. > > * Enhance
Re: Possible funding of gfortran work
Hi Thomas, I have revamp the proposal a bit more. Thank you for your input. I took some of it "as is", but I also rephrased some of it. I hope you are ok with that. Here is what I have so far: --- - Title: GFortran-Improvement - Abstract: Enable the free gfortran compiler to support contemporary language paradigms. - Dependencies (on the project as well as projects that depend on the technology; max 300 words) CP2K https://www.cp2k.org/ - Why is it critical to fund this project (300 words max)? Fortran remains one of the premier language for science, especially for high-performance computing and fields like quantum chemistry or computational fluid dynamics. gfortran is the default Fortran compiler on many Linux systems, and lack of features and bugs in gfortran hinder adoption of more modern, safer and more efficient language features. The project has been almost entirely volunteer-driven so far, but is currently suffering from a lack of active developers for larger features. Funding will enable the project to pay some gfortran experienced developers to implement some of missing/incomplete features, that are too large to tackle for a single volunteer. Payed developers are to contribute a significant part of the features. - Target of the projects in the sense of users (max 300 words) High-performance computing community, esp. but not limited to fluid and thermo dynamics, wheater forecasting - How was the project funded in the past (max 300 words) - Project goal (max 900 words!): * Fortran has a safe and intuitive method for parallel execution, coarrays. There is currently no complete and efficient implementation for multi-core CPUs on a freely available compiler. The goal is to bring the existing, process-based shared memory implementation on a branch into gfortran mainline as a feature for further evaluation and hardening. * GFortran's coarrays for distributed memory lack support for data structures provided modules that have not been compiled with coarray support (or are distributed in binary form only). Research and prototypical implementation shall be conducted with the goal to find a general and well performing solution. This could become an outstanding feature for a free compiler. * Enhance the support for teams in coarray to a level where it gets usable. Teams in coarrays allow for grouping workers logically. These then can colaborate without interference or the user needing to take care. The support is rather basic and shall be made usable to a level where the most popular calls work. * Enhance standard compliance from Fortran 2003 onwards. Esp. fixing finalization of partially derived types (PDTs) and issues in the associate command. * Ensure maintainability of gfortran by cleaning up/refactoring APIs including the scalarizer. Improve the single responsibility pattern's (SRP) use by, e.g., ensuring the parser does no longer parts of the resolve stage. The goal is not only to separate responsibilities but also to get clearer error messages and with that improve user-friendliness. - How many FTEs are you requesting? - What is the amount of funding you are requesting, approximately? - In what timeframe will you perform the activities? - Who (maintainer, contributor, organization) would be most qualified to implement this work/receive the support and why? --- The questions in there are more or less the questions that have to be answered for the proposal. The following is still open: * I would be nice to have some more dependencies. * Estimates for Nicolas and Mikael work would be good. (You can do them also as private mail if you like). * Any polishing. Feel free to comment. - Andre On Wed, 31 May 2023 08:08:49 +0200 Thomas Koenig wrote: > On 31.05.23 05:46, Benson Muite wrote: > > On 5/30/23 23:08, Thomas Koenig via Fortran wrote: > > > >>> * Complete language intrinsic parallel programming paradigm coarrays. > >>> This > >>> includes completing native coarray support (thread based). As > well as > >>> refactoring of the library based coarray approach to support > >>> coarrays in > >>> modules. I.e. research on how to support the use of coarrays in > >>> modules that > >>> are not aware of coarrays (not compiled with its support enabled). > >> > > Is distributed memory support for co-arrays of interest as well? There > > is a lot of code that uses MPI (for which there is some push for using > > more modern Fortran features), and there are also other libraries such > > as GASPI. > > We already support OpenCoarrays via -fcoarray=lib, which is MPI-based > (or at least can use MPI). I guess that OpenCoarrays could be modified > to use GASPI, but this would likely be a separate (if related) project. > > We would have to check about license requirements, though - I'm not sure > if the implementation of GASPI is free enough for the Soverereign Tech > Fund (at least Wikipedia claims it's "pay for
Re: Possible funding of gfortran work
On 5/31/23 09:08, Thomas Koenig wrote: > On 31.05.23 05:46, Benson Muite wrote: >> On 5/30/23 23:08, Thomas Koenig via Fortran wrote: > > * Complete language intrinsic parallel programming paradigm coarrays. This includes completing native coarray support (thread based). As > well as refactoring of the library based coarray approach to support coarrays in modules. I.e. research on how to support the use of coarrays in modules that are not aware of coarrays (not compiled with its support enabled). >>> >> Is distributed memory support for co-arrays of interest as well? There >> is a lot of code that uses MPI (for which there is some push for using >> more modern Fortran features), and there are also other libraries such >> as GASPI. > > We already support OpenCoarrays via -fcoarray=lib, which is MPI-based > (or at least can use MPI). I guess that OpenCoarrays could be modified > to use GASPI, but this would likely be a separate (if related) project. > Ok. One of the large use cases for Fortran is high performance computing. Other distributed memory efforts include: http://dvm-system.org/en/ https://xcalablemp.org/ MPI seems like it will evolve to use many new Fortran features so that Fortran and C bindings are similar, though it maybe the case that most Fortran codes will evolve to use co-arrays. GPU and other accelerator support may also be worth improving. > We would have to check about license requirements, though - I'm not sure > if the implementation of GASPI is free enough for the Soverereign Tech > Fund (at least Wikipedia claims it's "pay for commercial users", > which would be consistent with the business model of the Fraunhofer > Institutes.) > > >>> (There is Intel, which is dog-slow, and there is NAG, which costs >>> money). >> Is this also expected in Flang? See: >> > https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/ >> > https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/ >> Probably good to make a case for two open source compilers. > > We're concerned with gfortran here. A lot of work and money has gone > into flang that I sometimes think would have been better spent on > gfortran, then we would be in a better position overall today. > > But I am hoping that this initiative can cure at least part of that. May need to convince reviewers why Flang alone is insufficient. > >>> Fortran remains one of the premier language for science, especially for >>> high-performance computing and fields like quantum chemistry or >>> computational fluid dynamics. >>> >>> gfortran is the default Fortran compiler on Linux systems, and lack of >>> features and bugs in in gfortran hinder adoption of more modern, safer >>> and more efficient language features. The project has been almost >>> entirely volunteer-driven so far, but is currently suffering from >>> a lack of active developers. Funding will motivate experienced >>> gfortran developers who have reduced their contributions to return >>> to the project and advance it substantially. >>> Maybe worth mentioning tools like R which use many Fortran libraries. Most use Fortran 77 though. >>> >> Any possibilities for new contributors to participate? > > We should avoid bringing people in who spend all the money just > familiarizing themselves with the compiler, producing no useful > output in the end. > > I think that contributors should have demonstrated that they are > capable of working productively with gfortran, and the best way > to demonstrate that is to already have a track record of accepted > patches (preferably gfortran, but also gcc in general). That does not > mean that this track record needs to be years or decades old, but it > should exist. > > Also, people recommended by a current contributor should be able > to participate; but we should probably discuss people who apply > on a case-by-case basis. This is ok. But many new developers are looking at Julia and Python, comfortably retired developers may not be as motivated to return by funding, but might mentor in critical areas. > > (The above is my personal opinion, please discuss if anybody has > a different opinion). > > Best regards > > Thomas
Re: Possible funding of gfortran work
On 31.05.23 05:46, Benson Muite wrote: > On 5/30/23 23:08, Thomas Koenig via Fortran wrote: >>> * Complete language intrinsic parallel programming paradigm coarrays. >>> This >>> includes completing native coarray support (thread based). As well as >>> refactoring of the library based coarray approach to support >>> coarrays in >>> modules. I.e. research on how to support the use of coarrays in >>> modules that >>> are not aware of coarrays (not compiled with its support enabled). >> > Is distributed memory support for co-arrays of interest as well? There > is a lot of code that uses MPI (for which there is some push for using > more modern Fortran features), and there are also other libraries such > as GASPI. We already support OpenCoarrays via -fcoarray=lib, which is MPI-based (or at least can use MPI). I guess that OpenCoarrays could be modified to use GASPI, but this would likely be a separate (if related) project. We would have to check about license requirements, though - I'm not sure if the implementation of GASPI is free enough for the Soverereign Tech Fund (at least Wikipedia claims it's "pay for commercial users", which would be consistent with the business model of the Fraunhofer Institutes.) >> (There is Intel, which is dog-slow, and there is NAG, which costs >> money). > Is this also expected in Flang? See: > https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/ > https://crd.lbl.gov/divisions/amcr/computer-science-amcr/class/research/caffeine/ > Probably good to make a case for two open source compilers. We're concerned with gfortran here. A lot of work and money has gone into flang that I sometimes think would have been better spent on gfortran, then we would be in a better position overall today. But I am hoping that this initiative can cure at least part of that. >> Fortran remains one of the premier language for science, especially for >> high-performance computing and fields like quantum chemistry or >> computational fluid dynamics. >> >> gfortran is the default Fortran compiler on Linux systems, and lack of >> features and bugs in in gfortran hinder adoption of more modern, safer >> and more efficient language features. The project has been almost >> entirely volunteer-driven so far, but is currently suffering from >> a lack of active developers. Funding will motivate experienced >> gfortran developers who have reduced their contributions to return >> to the project and advance it substantially. >> >> > Any possibilities for new contributors to participate? We should avoid bringing people in who spend all the money just familiarizing themselves with the compiler, producing no useful output in the end. I think that contributors should have demonstrated that they are capable of working productively with gfortran, and the best way to demonstrate that is to already have a track record of accepted patches (preferably gfortran, but also gcc in general). That does not mean that this track record needs to be years or decades old, but it should exist. Also, people recommended by a current contributor should be able to participate; but we should probably discuss people who apply on a case-by-case basis. (The above is my personal opinion, please discuss if anybody has a different opinion). Best regards Thomas
