Re: Possible funding of gfortran work
Hi Benson, thanks for the input. I will incorporate it. Regards, Andre On Thu, 8 Jun 2023 08:34:54 +0300 Benson Muite wrote: > On 6/5/23 13:07, Andre Vehreschild wrote: > > Hi Benson, > > > > thank you for your input. Comments are inline: > > > >> Maybe add Quantum Espresso: > >> https://www.quantum-espresso.org/ > > > Another code: > https://github.com/openmopac/mopac > currently being supported by > https://molssi.org/ > > > done > > > >> R and Octave may also be good examples of use cases. > > > > Mhhh, both are not written in Fortran, right? I don't feel tempted to > > include other programming languages into the references list. It feels odd > > to me. Any thoughts, anyone? > > > In addition to use of Lapack, many subroutines are written in Fortran. > They have many users in a variety of sectors. Path to parallelization > is unclear, even multicore parallelization will benefit many users. > People in these projects may be willing to give input if asked. > > > >> Some gfortran work has been done as company sponsored in that > >> individuals using the compiler needed it for company work and could work > >> on the compiler on company time. If a large proportion is voluntary and > >> companies only sponsor small extensions and bug fixes, one might assume > >> that if the funding is given, once it is finished, the chances of > >> further work will be very limited. Maybe one can tie into the GNU > >> compiler collection as well, emphasizing the longevity of the project > >> and usefulness of the funding in adding additional capabilities and > >> cleaning up code contributions. Then indicate that new parts that this > >> proposal addresses have primarily been voluntary because they are not > >> yet ready for production use, and this project would make them ready for > >> production use so that in future maintenance efforts can be made by the > >> community (both voluntary and sponsored). > > > > I have added a paragraph about sponsoring of general gfortran work: > > > > GFortran in general stems from a merge of projects that have been supported > > by academic research, commercial needs and in large parts volunteers. > > Funding by companies was mostly done by allowing employees to work on > > features required for the company and donating the code. > > > > Is that what you were trying to add? > > > That seems good. Maybe something like: > > GFortran is a portion of the long lived GCC compiler suite and has > gotten contributions due to academic research needs, commercial needs > and volunteer interest. Industry funding primarily enables employees to > work on features required by the company, for example to support new > processors or ensure performance in a critical company code section. > > Regards, > > Andre > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: Possible funding of gfortran work
Hi Mikael, please find my answers inline. > > I understand. I would have been happy in the past when a client had as much > > knowledge and structure than we already have. Under "Project goal" we now > > have about 300 words. So we could add more. > Well, It wouldn't be really part of the goal, more how to reach that > goal. The "timeframe" question is possibly where it should go. Or if > you consider that the planning is a goal itself, it could be put here. The timeframe question accepts only a number. I.e. we can't plan there. > > What do you have in mind? > Something that breaks a big, risky thing to a set of smaller, manageable > ones. Something showing that the main problems (or some of them at > least) have been identified and that we have a path to solve them one by > one. > > > Like adding > > more bullet points to each item in the form of: > >- rebase existing implementation to current master > >- identify missing requirements > >- add tests for missing requirements > >- implement missing requirements to pass tests. > >... > Well, this is a bit too general to be useful. Mhh, I don't suppose that the planning will be evaluated by software specialist. I therefore propose not to be too technical, but to stay on a project manager level. So how about we enumerate the bullets so that we then can put a project/milestone structure under each one like this (PD: person day): 1.M1 assess open issues and refine planning (1-3 PDs) 1.M2 rebase to current master and adapt to recent changes in gfortran (1-3 PDs) 1.M3 identify missing requirements ... I need input here from Nicolas as I don't have an overview of what is needed. Therefore I am quite general. > > > Or are your targeting a more time based approach like: > >Milestone 1: shared mem coarrays merge to master in week 2 of project > >Milestone 2: finish research on general way for doing remote coarray > > access in alien structures to finish in week 1 of project > >... > Maybe, but I would not emphasize the time constraints that much. I understand. But for our own planning we need a rough estimate. Therefore putting numbers to each milestone, will help a lot in planning. > I have done it below for the scalarizer simplification, which is what > for which the picture is the most clear in my mind regarding what to do > and how to do it. > Here it is, with the expected number of weeks (that's 3 days for me) to > do it: > - Add optional scalarization block. (1 week) > - Setup multiple expression usage (in case of multiple loops) in a > more clear way. (3 weeks) > - Move array and loop bounds setup to an opaque "start scalarization" > function (3 weeks) > - Make scalarization independant on previous setup of array > information and move setup code from "start scalarization" to "finish > scalarization" (5 weeks) > - Initialize array information inside the gfc_conv_expr* functions and > remove preliminary walking of expressions (4 weeks) > > I hope that's not too technical to be put in the application form. :-) Removing technical speech is not the problem... But I like the plan although I wouldn't know what to do in each case. > > Mikael Morin @ ??? -- Maintained/Contributed to the scalarizer. Experienced > > in gfortran development and component dependencies. > > > I'm not affiliated to any company, university or organization. Just > myself. :-) Sorry, I did not mean any insult. What do you prefer? "not affiliated" or "private", ...? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: Possible funding of gfortran work
Le 14/06/2023 à 10:28, Andre Vehreschild a écrit : Hi Mikael, please find my answers inline. I understand. I would have been happy in the past when a client had as much knowledge and structure than we already have. Under "Project goal" we now have about 300 words. So we could add more. Well, It wouldn't be really part of the goal, more how to reach that goal. The "timeframe" question is possibly where it should go. Or if you consider that the planning is a goal itself, it could be put here. The timeframe question accepts only a number. I.e. we can't plan there. What do you have in mind? Something that breaks a big, risky thing to a set of smaller, manageable ones. Something showing that the main problems (or some of them at least) have been identified and that we have a path to solve them one by one. Like adding more bullet points to each item in the form of: - rebase existing implementation to current master - identify missing requirements - add tests for missing requirements - implement missing requirements to pass tests. ... Well, this is a bit too general to be useful. Mhh, I don't suppose that the planning will be evaluated by software specialist. I therefore propose not to be too technical, but to stay on a project manager level. So how about we enumerate the bullets so that we then can put a project/milestone structure under each one like this (PD: person day): 1.M1 assess open issues and refine planning (1-3 PDs) 1.M2 rebase to current master and adapt to recent changes in gfortran (1-3 PDs) 1.M3 identify missing requirements ... I need input here from Nicolas as I don't have an overview of what is needed. Therefore I am quite general. OK, let's wait for Nicolas' input, as it sounds scary as is. Identifying the missing requirements should be done before the submission, and saying that you have to do it as part of the project sounds very much like you don't know where you are going. Same goes for the planning, it should already be clear enough beforehand. I mean, counting the time spent in identifying the requirements etc can be done internally, because it's time spent working, but I think it should not be part of the planning submitted because it's time that will be already spent at the time the application form is submitted. Regarding my own work, there was no additional discussion regarding the different items I proposed, so I will pick the two or three I'm most interested in (additionally to the scalarizer) and try to produce a plan for them as well. Mikael Morin @ ??? -- Maintained/Contributed to the scalarizer. Experienced in gfortran development and component dependencies. I'm not affiliated to any company, university or organization. Just myself. :-) Sorry, I did not mean any insult. I didn't see any insult. I was just trying to answer the three question marks (???). What do you prefer? "not affiliated" or "private", ...? Yes, that's fine. Nothing. Whatever.
Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'
Hi!
On 2023-06-13T13:11:38+0200, Tobias Burnus wrote:
> On 13.06.23 12:42, Thomas Schwinge wrote:
>> On 2023-06-05T14:18:48+0200, I wrote:
>>> OK to push the attached
>>> "Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'"?
>>
>> Subject: [PATCH] Add
>> 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'
>>
>> gcc/testsuite/
>> * gfortran.fortran-torture/execute/math.f90: Enhance for optional
>> OpenACC, OpenMP 'target' usage.
>
> I think it is more readable with a linebreak here and with "OpenACC
> 'serial' and OpenMP ..." instead of "OpenACC, OpenMP".
>
> What I would like to see a hint somewhere in the commit log that the
> libgomp files include the gfortran.fortran-torture file. I don't care
> whether you add the hint before the changelog items as free text – or in
> the bullet above (e.g. "as it is included in libgomp/testsuite") – or
> after "New." in the following bullet list.
>
>> libgomp/
>> * testsuite/libgomp.fortran/fortran-torture_execute_math.f90: New.
>> * testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90:
>> Likewise.
>
>> ---
>> .../gfortran.fortran-torture/execute/math.f90 | 23 +--
>> .../fortran-torture_execute_math.f90 | 4
>> .../fortran-torture_execute_math.f90 | 5
>> 3 files changed, 30 insertions(+), 2 deletions(-)
>> create mode 100644
>> libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90
>> create mode 100644
>> libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90
>>
>> diff --git a/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
>> b/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
>> index 17cc78f7a10..e71f669304f 100644
>> --- a/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
>> +++ b/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
>> @@ -1,9 +1,14 @@
>> ! Program to test mathematical intrinsics
>> +
>> +! See also
>> 'libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90'; thus
>> the '!$omp' directives.
>> +! See also
>> 'libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90';
>> thus the '!$acc' directives.
>
> Likewise here: it is not completely obvious that this file is 'include'd
> by the other testcases.
>
> Maybe add a line "! This file is also included in:" and remove the "See
> also" or some creative variant of it.
>
> Minor remark: The OpenMP part is OK, but strict reading of the spec
> requires an "omp declare target' if a subroutine is in a different
> compilation unit. And according the glossary, that's the case here. In
> practice, it also works without as it is in the same translation unit.
> (compilation unit = for C/C++: translation unit, for Fortran:
> subprogram). I think the HPE/Cray compiler will complain, but maybe only
> when used with modules and not with subroutine subprograms. (As many
> compilers write a .mod file for modules, a late change of attributes can
> be more problematic.)
>
> Otherwise LGTM.
Thanks for the review. I've now pushed
commit e76af2162c7b768ef0a913d485c51a80b08a1020
"Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'", see
attached.
> PS: I assume that you have check it with both with an in-build-tree and
> an in-install-tree testsuite run.
I happened to have (..., but don't think it'd make a relevant difference
here?)
Grüße
Thomas
-
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
>From e76af2162c7b768ef0a913d485c51a80b08a1020 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Fri, 2 Jun 2023 23:11:00 +0200
Subject: [PATCH] Add
'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'
..., via 'include'ing the existing 'gfortran.fortran-torture/execute/math.f90',
which therefore is enhanced for optional OpenACC 'serial', OpenMP 'target'
usage.
gcc/testsuite/
* gfortran.fortran-torture/execute/math.f90: Enhance for optional
OpenACC 'serial', OpenMP 'target' usage.
libgomp/
* testsuite/libgomp.fortran/fortran-torture_execute_math.f90: New.
* testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90:
Likewise.
---
.../gfortran.fortran-torture/execute/math.f90 | 24 +--
.../fortran-torture_execute_math.f90 | 4
.../fortran-torture_execute_math.f90 | 5
3 files changed, 31 insertions(+), 2 deletions(-)
create mode 100644 libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90
create mode 100644 libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90
diff --git a/gcc/testsuite/gfortran.fortran-torture/execute/math.f90 b/gcc/testsuite/gfortran.fortran-torture/execute/math.f90
index 17cc78f7a105..6c97eba3f8ff 100644
--- a/gcc/testsuite/gfortran.fortran-torture/execute/math.f
Re: Possible funding of gfortran work
On 14 June 2023 11:40:06 CEST, Mikael Morin wrote: >> What do you prefer? "not affiliated" or >> "private", ...? >> >Yes, that's fine. Nothing. Whatever. IMHO that usually would be not applicable / n/a
