gfortran compiler statistics
Hi, I have just discovered gfortran and have been playing with it all weekend. One thing I am missing is can I, in gfortran, generate compiler statistics like source listing with errors, like using a /list directive, variable map, size of object etc. Many thanks, Simon Cole
Re: Possible funding of gfortran work
Hi all, thank you for all your input. I have read the funding requirements and checked out the application form. We have to agree on a project goal and describe why it is critical to fund this project. Let me try a first shot on this: - 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) Does any one have a convincing project that uses contemporary Fortran? Project goal (max 900 words!): * 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). * Complete 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. Why is it critical to fund this project (300 words max)? Improving the freely available gfortran compiler to support state of the art parallelism and language paradigms as well as removing bugs and ensuring standard compliance will allow existing codes to be compiled more reliably. Furthermore is the lack of support for the newer language paradigms preventing the use of Fortran in current projects. Developing in contemporary Fortran needs commercial compilers (that support these paradigms already), which leads to dependencies on those. This is what I propose for a start. I welcome everyone to participate and make the goal or the reasoning more elaborate. We may propose the funding request in English or in German. When no one participates, I am tempted to propose it in German, as that being my first language, I feel more confident in it. The company Badger Systems GmbH, Cologne, DE, I am working for will support in project and bureaucratic management and is willing to act as the proposer of this funding request. We of course will be profiting from this. Any input is welcome. Feel free to ask, comment, agree, disagree (only when you propose something better) or just acknowledge. Regards, Andre On Sun, 28 May 2023 13:53:04 -0700 Jerry D wrote: > On 5/28/23 12:25 PM, Mikael Morin wrote: > > Hello, > > > > I would like to apply for 60% of my work time if there is funding for it. > > > > These are the projects that I would like to push (in no particular order): > > - Simplify scalarizer API and usage, > > - Create internal APIs (basically split gfortran.h and/or trans.h to > > different pieces) and add unit testing for them, > > - Move code from class.cc to a trans-class.cc and get rid of the class > > artifacts around the class descriptor and vtable in the whole frontend. > > - Defer all work done at parsing time to resolution time, so that the > > parser's job reduces to just recognizing and recording statements, > > - Avoid simplifying intrinsics before checking they are valid, > > - Improve module loading (there is PR98426, possibly a few others), > > - Array descriptor reform (does it still apply?). > > > > The above are, I think, long and/or difficult, and a bit unrewarding as > > they have virtually no user-visible impact, and it's unlikely to get > > funding for them. But maybe we could apply for a package project > > including user-visible changes and less visible ones. > > > > The projects proposed by Paul all seem worth pursuing. If there is only > > one, my vote goes for fixing the PDTs. > > > > Cheers. > > Mikael > > The original person who contacted me at FortranDiscourse already > submitted a proposal for something to do with Fortran-Lang and is > offering to assist with a gfortran proposal. I asked for a direct email > address so I could relay this to you if you do not have it. I also gave > saveral of your emails to him asking to contact you directly. > > Regards, > > Jerry -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: Possible funding of gfortran work
On 30.05.23 15:32, Andre Vehreschild wrote: Hi all, thank you for all your input. I have read the funding requirements and checked out the application form. We have to agree on a project goal and describe why it is critical to fund this project. Let me try a first shot on this: - 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) Does any one have a convincing project that uses contemporary Fortran? CP2K is an example, it's open source and written in Fortran. https://www.cp2k.org/ Project goal (max 900 words!): * 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). The current work is process-based, and there is no problem that we see about library code. What about this? * Fortran has a safe and intuitive method for parallel execution, coarrays. There is currently no 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 an experimental, but useful feature. I also would not promise complete coarray support by project's end. This would include teams, which are scary :-) Having a useful (There is Intel, which is dog-slow, and there is NAG, which costs money). * Complete standard compliance from Fortran 2003 onwards. Esp. fixing finalization of partially derived types (PDTs) and issues in the associate command. Again, we should not promise what we cannot deliver. * 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. Why is it critical to fund this project (300 words max)? Improving the freely available gfortran compiler to support state of the art parallelism and language paradigms as well as removing bugs and ensuring standard compliance will allow existing codes to be compiled more reliably. Furthermore is the lack of support for the newer language paradigms preventing the use of Fortran in current projects. Developing in contemporary Fortran needs commercial compilers (that support these paradigms already), which leads to dependencies on those. 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. This is what I propose for a start. I welcome everyone to participate and make the goal or the reasoning more elaborate. We may propose the funding request in English or in German. When no one participates, I am tempted to propose it in German, as that being my first language, I feel more confident in it. Make it English, all people here on the list should be able to follow. The company Badger Systems GmbH, Cologne, DE, I am working for will support in project and bureaucratic management and is willing to act as the proposer of this funding request. We of course will be profiting from this. Any input is welcome. Feel free to ask, comment, agree, disagree (only when you propose something better) or just acknowledge. One thing I did not find at a cursory glance is how the project funding would be distributed, and under which conditions. Did you find anything on the website? Best regards Thomas
Re: Possible funding of gfortran work
On 5/30/23 23:08, Thomas Koenig via Fortran wrote: > On 30.05.23 15:32, Andre Vehreschild wrote: >> Hi all, >> >> thank you for all your input. I have read the funding requirements and >> checked >> out the application form. We have to agree on a project goal and >> describe why >> it is critical to fund this project. >> >> Let me try a first shot on this: >> >> - 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) >> >> Does any one have a convincing project that uses contemporary Fortran? > > CP2K is an example, it's open source and written in Fortran. > > https://www.cp2k.org/ > > >> Project goal (max 900 words!): >> >> * 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. > The current work is process-based, and there is no problem that we see > about library code. > > What about this? > > * Fortran has a safe and intuitive method for parallel execution, > coarrays. There is currently no 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 an experimental, but useful feature. > > I also would not promise complete coarray support by project's end. > This would include teams, which are scary :-) > > Having a useful > > (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. > >> * Complete standard compliance from Fortran 2003 onwards. Esp. fixing >> finalization of partially derived types (PDTs) and issues in the >> associate >> command. > > Again, we should not promise what we cannot deliver. > >> * 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. >> >> Why is it critical to fund this project (300 words max)? > >> Improving the freely available gfortran compiler to support state of >> the art >> parallelism and language paradigms as well as removing bugs and ensuring >> standard compliance will allow existing codes to be compiled more >> reliably. >> Furthermore is the lack of support for the newer language paradigms >> preventing >> the use of Fortran in current projects. Developing in contemporary >> Fortran needs >> commercial compilers (that support these paradigms already), which >> leads to >> dependencies on those. > > 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? >> This is what I propose for a start. I welcome everyone to participate >> and make >> the goal or the reasoning more elaborate. We may propose the funding >> request in >> English or in German. When no one participates, I am tempted to >> propose it in >> German, as that being my first language, I feel more confident in it. > > Make it English, all people here on the list should be able to follow. > >> The company Badger Systems GmbH, Cologne, DE, I am working for will >> support in >> project and bureaucratic management and is willing to act as the >> proposer of >> this funding request. We of course will be profiting from this. >> >> Any input is welcome. Feel free to ask, comment,
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
