Re: Possible funding of gfortran work
Hi Mikael, thanks for your valuable input. I have commented inline: > The latter paragraph seems more an answer to the question "why is it > critical for gfortran to get funding" than "why is it critical for a > funding body to choose gfortran"? > > One idea about the latter question: > so that there is always a free solution: > - for engineers to make best usage of the hardware available to them > without hassle and spend their time at what they are best: making science > - for decades-old proven science codes to be adapted to current > parallel computing architectures Agreed. Thank you very much. I have adapted and added it. > There is also Siemens (Tobias, etc) working on OMP and OpenACC. Not > sure whether it should me mentioned here. Well, I mean we don't ask for funding on OMP or OpenACC development. So do we need to confine ourself from these technologies? > I'm not very found of the last part of the sentence, which sounds like > the project is targetting half-unfinished state. I understand Thomas > not willing to engage to something without being sure it can be > delivered on time. But the goal is always to be somehow successful; I > mean, delivering something that doesn't happen to be useful can't be a goal. > > I propose this instead: > The goal is to improve and extend on the previous work on a > process-based shared memory coarray implementation, so that the feature > can be made available in the next release of gfortran. Taken w/o change. Thanks. > This is a goal, not a promise of succes. And remember that reallocation > on assignment was made available behind a flag for quite some time > before being enabled by default. We could do the same here if the > feature is not ready yet, so the above is not a great commitment. :thumbsup: > Regarding the time estimates, it's a bit difficult as we can't foresee > at this stage the amount of regressions that will need to be fixed, and > how difficult they will be. I'm not even sure that the process of > picking one regression and fixing it will eventually converge to a > zero-regression state. It doesn't mean much, but I expect to spend > between 3 and 6 months on every item I have proposed. But I expected > those items to be discussed, prioritized, and either acknowledged or > refused by the contributors before. You mean, you will 3 to 6 month full-time for the scalarizer rework, the API thingys and so on? Or is the estimate on how long it will take you to do the things in total, i.e. not working full-time on them? I am asking that specifically because we need to estimate the person days they pay for and time boundary up to when the project will be done. Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: Possible funding of gfortran work
Hi Benson, thank you for your input. Comments are inline: > Maybe add Quantum Espresso: > https://www.quantum-espresso.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? > 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? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: Possible funding of gfortran work
Hi Jerry, thanks. I switched from FAST to OpenFAST in the list of references. Strangely my google search never pointed me to OpenFAST. Regards, Andre On Thu, 1 Jun 2023 17:53:21 -0700 Jerry D wrote: > On 6/1/23 2:18 AM, Andre Vehreschild wrote: > > Hi Damian, all, > > > > thank you for your input. I have incorporated most of it. Due to Germany > > stepping out of nuclear use, I have reduced the cites on these to a > > minimum. I don't know anything about the people evaluating the proposal and > > don't want to be rejected just because of ideological reasons. Here is the > > proposal so far. Has any one a good url for the FAST project? > > > > I found this qhich does use Fortran > > https://github.com/OpenFAST/openfast/tree/main/modules/beamdyn/src > > Is this the one you were referring to? > > Also here: > > https://www.nrel.gov/wind/nwtc/openfast.html > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: Possible funding of gfortran work
Hi Thomas, thanks for the idea. My doctor father will like it, because he is one of the authors. - Andre On Sun, 4 Jun 2023 09:49:51 +0200 Thomas Koenig wrote: > On 01.06.23 13:12, Benson Muite via Fortran wrote: > > > R and Octave may also be good examples of use cases. > > More generally, Lapack is written in Fortran, and R uses Lapack > (as we found out the hard way with PR 90329). And Lapack is really > a foundation of linear algebra, which is at the heart of a _lot_ > of scientific software. -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: Possible funding of gfortran work
Le 05/06/2023 à 10:08, Andre Vehreschild a écrit : Regarding the time estimates, it's a bit difficult as we can't foresee at this stage the amount of regressions that will need to be fixed, and how difficult they will be. I'm not even sure that the process of picking one regression and fixing it will eventually converge to a zero-regression state. It doesn't mean much, but I expect to spend between 3 and 6 months on every item I have proposed. But I expected those items to be discussed, prioritized, and either acknowledged or refused by the contributors before. You mean, you will 3 to 6 month full-time for the scalarizer rework, the API thingys and so on? Or is the estimate on how long it will take you to do the things in total, i.e. not working full-time on them? The latter, 3-6 months delivery time each item at 60% working time. I am asking that specifically because we need to estimate the person days they pay for and time boundary up to when the project will be done. Yes, I don't like it but I understand the need for estimating. I have looked at the evaluation criteria at [1]. There is among other things: Furthermore, we look at how well the planning for the project is laid out. Are the activities well-structured, appropriate and feasible? I think we are far from having a "well laid out planning". Even if it's difficult to estimate the amount of days of work, we should probably at least try to decompose the project into milestones, that is (small) steps proving progress toward the target. [1] https://sovereigntechfund.de/en/applications/
Re: Possible funding of gfortran work
On 05.06.23 12:07, Andre Vehreschild wrote: R and Octave may also be good examples of use cases. Mhhh, both are not written in Fortran, right? They are not, but at least R uses Lapack, which is written in Fortran. And Lapack is about as central to scientific computing as you can be. Best regards Thomas
Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'
Hi!
OK to push the attached
"Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'"?
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 0d5095d8cd2d68113890a39a7fdb649198e576c1 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'
gcc/testsuite/
* gfortran.fortran-torture/execute/math.f90: Enhance for optional
OpenACC, 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 | 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.
+
subroutine dotest (n, val4, val8, known)
implicit none
real(kind=4) val4, known
real(kind=8) val8
integer n
+ !$acc routine seq
if (abs (val4 - known) .gt. 0.001) STOP 1
if (abs (real (val8, kind=4) - known) .gt. 0.001) STOP 2
@@ -14,17 +19,20 @@ subroutine dotestc (n, val4, val8, known)
complex(kind=4) val4, known
complex(kind=8) val8
integer n
+ !$acc routine seq
+
if (abs (val4 - known) .gt. 0.001) STOP 3
if (abs (cmplx (val8, kind=4) - known) .gt. 0.001) STOP 4
end subroutine
-program testmath
+subroutine testmath
implicit none
real(kind=4) r, two4, half4
real(kind=8) q, two8, half8
complex(kind=4) cr
complex(kind=8) cq
external dotest, dotestc
+ !$acc routine seq
two4 = 2.0
two8 = 2.0_8
@@ -96,5 +104,16 @@ program testmath
cq = log ((-1.0_8, -1.0_8))
call dotestc (21, cr, cq, (0.3466, -2.3562))
-end program
+end subroutine
+program main
+ implicit none
+ external testmath
+
+ !$acc serial
+ !$omp target
+ call testmath
+ !$acc end serial
+ !$omp end target
+
+end program
diff --git a/libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90 b/libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90
new file mode 100644
index 000..3348a0bb3ad
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/fortran-torture_execute_math.f90
@@ -0,0 +1,4 @@
+! { dg-do run }
+! { dg-additional-options -foffload-options=-lm }
+
+include '../../../gcc/testsuite/gfortran.fortran-torture/execute/math.f90'
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90 b/libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90
new file mode 100644
index 000..1b2ac440762
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90
@@ -0,0 +1,5 @@
+! { dg-do run }
+!TODO { dg-prune-output {using 'vector_length \(32\)', ignoring 1} }
+! { dg-additional-options -foffload-options=-lm }
+
+include '../../../gcc/testsuite/gfortran.fortran-torture/execute/math.f90'
--
2.34.1
Re: Possible funding of gfortran work
I have referenced LAPACK now. I hope this is ok? - Andre On Mon, 5 Jun 2023 14:16:43 +0200 Thomas Koenig wrote: > On 05.06.23 12:07, Andre Vehreschild wrote: > >> R and Octave may also be good examples of use cases. > > Mhhh, both are not written in Fortran, right? > > They are not, but at least R uses Lapack, which is written in Fortran. > And Lapack is about as central to scientific computing as you can > be. > > Best regards > > Thomas -- Andre Vehreschild * Email: vehre ad gmx dot de
driver: Forward '-lgfortran', '-lm' to offloading compilation
Hi!
OK to push the attached
"driver: Forward '-lgfortran', '-lm' to offloading compilation"?
(We didn't have a PR open for that, or did we?)
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 5d3cb866cad3bbcf47c5e66825e5710e86cc017e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Mon, 5 Jun 2023 11:26:37 +0200
Subject: [PATCH] driver: Forward '-lgfortran', '-lm' to offloading compilation
..., so that users don't manually need to specify
'-foffload-options=-lgfortran', '-foffload-options=-lm' in addition to
'-lgfortran', '-lm' (specified manually, or implicitly by the driver).
gcc/
* gcc.cc (driver_handle_option): Forward host '-lgfortran', '-lm'
to offloading compilation.
* config/gcn/mkoffload.cc (main): Adjust.
* config/nvptx/mkoffload.cc (main): Likewise.
* doc/invoke.texi (foffload-options): Update example.
libgomp/
* testsuite/libgomp.fortran/fortran.exp (lang_link_flags): Don't
set.
* testsuite/libgomp.oacc-fortran/fortran.exp (lang_link_flags):
Likewise.
* testsuite/libgomp.c/simd-math-1.c: Remove
'-foffload-options=-lm'.
* testsuite/libgomp.fortran/fortran-torture_execute_math.f90:
Likewise.
* testsuite/libgomp.oacc-fortran/fortran-torture_execute_math.f90:
Likewise.
---
gcc/config/gcn/mkoffload.cc | 12
gcc/config/nvptx/mkoffload.cc | 12
gcc/doc/invoke.texi | 5 +-
gcc/gcc.cc| 56 +++
libgomp/testsuite/libgomp.c/simd-math-1.c | 1 -
.../fortran-torture_execute_math.f90 | 1 -
libgomp/testsuite/libgomp.fortran/fortran.exp | 2 -
.../fortran-torture_execute_math.f90 | 1 -
.../libgomp.oacc-fortran/fortran.exp | 2 -
9 files changed, 82 insertions(+), 10 deletions(-)
diff --git a/gcc/config/gcn/mkoffload.cc b/gcc/config/gcn/mkoffload.cc
index 988c12318fd..8b608bf024e 100644
--- a/gcc/config/gcn/mkoffload.cc
+++ b/gcc/config/gcn/mkoffload.cc
@@ -946,6 +946,18 @@ main (int argc, char **argv)
else if (startswith (argv[i], STR))
gcn_stack_size = atoi (argv[i] + strlen (STR));
#undef STR
+ /* Translate host into offloading libraries. */
+ else if (strcmp (argv[i], "-l_GCC_gfortran") == 0
+ || strcmp (argv[i], "-l_GCC_m") == 0)
+ {
+ /* Elide '_GCC_'. */
+ size_t i_dst = strlen ("-l");
+ size_t i_src = strlen ("-l_GCC_");
+ char c;
+ do
+ c = argv[i][i_dst++] = argv[i][i_src++];
+ while (c != '\0');
+ }
}
if (!(fopenacc ^ fopenmp))
diff --git a/gcc/config/nvptx/mkoffload.cc b/gcc/config/nvptx/mkoffload.cc
index 6cdea45cffe..aaea9fb320d 100644
--- a/gcc/config/nvptx/mkoffload.cc
+++ b/gcc/config/nvptx/mkoffload.cc
@@ -649,6 +649,18 @@ main (int argc, char **argv)
else if (strcmp (argv[i], "-dumpbase") == 0
&& i + 1 < argc)
dumppfx = argv[++i];
+ /* Translate host into offloading libraries. */
+ else if (strcmp (argv[i], "-l_GCC_gfortran") == 0
+ || strcmp (argv[i], "-l_GCC_m") == 0)
+ {
+ /* Elide '_GCC_'. */
+ size_t i_dst = strlen ("-l");
+ size_t i_src = strlen ("-l_GCC_");
+ char c;
+ do
+ c = argv[i][i_dst++] = argv[i][i_src++];
+ while (c != '\0');
+ }
}
if (!(fopenacc ^ fopenmp))
fatal_error (input_location, "either %<-fopenacc%> or %<-fopenmp%> "
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index d2d639c92d4..7b3a2a74459 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2716,9 +2716,8 @@ the @option{-foffload-options=@var{target-list}=@var{options}} form. The
Typical command lines are
@smallexample
--foffload-options=-lgfortran -foffload-options=-lm
--foffload-options="-lgfortran -lm" -foffload-options=nvptx-none=-latomic
--foffload-options=amdgcn-amdhsa=-march=gfx906 -foffload-options=-lm
+-foffload-options='-fno-math-errno -ffinite-math-only' -foffload-options=nvptx-none=-latomic
+-foffload-options=amdgcn-amdhsa=-march=gfx906 -foffload-options=-O3
@end smallexample
@opindex fopenacc
diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 2ccca00d603..15995206856 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -47,6 +47,9 @@ compilation is specified by a string called a "spec". */
#include "opts-jobserver.h"
#include "common/common-target.h"
+#ifndef MATH_LIBRARY
+#define MATH_LIBRARY "m"
+#endif
/* Manage the manipulation of env vars.
@@ -4117,6 +4120,48 @@ next_item:
}
}
+/* Forward certain options to offloading compilation. */
+
+static void
+forward_offload_option (size_t opt_index, const char *arg, bool validated)
+{
+ switch (opt_index)
+{
+case OPT_l:
+ /* Use a '_GCC_' prefix and standard name ('-l_GCC_m' irrespective of the
+ host's 'MATH_LIBRARY', for example), so that the 'mkoffload's can tell
+ this ha
Fwd: GNU Tools Cauldron 2023
FYI — in case you want to come to Cambridge in September. (I intent to be there.) - Tobias Forwarded Message Subject:GNU Tools Cauldron 2023 Date: Mon, 5 Jun 2023 14:59:05 +0100 From: Richard Earnshaw To: GCC Development We are pleased to invite you all to the next GNU Tools Cauldron, taking place in Cambridge, UK, on September 22-24, 2023. As for the previous instances, we have setup a wiki page for details: https://gcc.gnu.org/wiki/cauldron2023> Like last year, we are having to charge for attendance. We are still working out what we will need to charge, but it will be no more than £250. Attendance will remain free for community volunteers and others who do not have a commercial backer and we will be providing a small number of travel bursaries for students to attend. For all details of how to register, and how to submit a proposal for a track session, please see the wiki page. The Cauldron is organized by a group of volunteers. We are keen to add some more people so others can stand down. If you'd like to be part of that organizing committee, please email the same address. This announcement is being sent to the main mailing list of the following groups: GCC, GDB, binutils, CGEN, DejaGnu, newlib and glibc. Please feel free to share with other groups as appropriate. Richard (on behalf of the GNU Tools Cauldron organizing committee). - 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
