Re: Possible funding of gfortran work
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? --- - 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) Exemplarily these codes make use of language paradigms or want to, but can not due to lack of support in gfortran: CP2K: https://www.cp2k.org/ -- Quantum chemistry and solid state physics ICAR: https://github.com/ncar/icar -- Simplified atmospheric model FEATS: https://github.com/sourceryinstitute/feats -- Asynchronous task scheduling framework FAVOR: https://www.nrc.gov/reading-rm/doc-collections/nuregs/staff/sr1795/index.html -- Reactor security NWChem: https://www.nwchem-sw.org/ -- Computational chemistry software FUN3D: https://fun3d.larc.nasa.gov/ -- Computational fluid dynamics software from NASA MSC NASTRAN: https://simulatemore.mscsoftware.com/category/products/msc-nastran/ -- Structural engineering software from MSC Software WRF: https://www.mmm.ucar.edu/models/wrf -- Weather forecasting software from NCAR FAST: ??? -- Nuclear fuel performance software from the U.S. Nuclear Regulatory Commission (NRC) Some 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. - 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 the 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) This project targets the high-performance computing community, esp. but not limited to fluid and thermo dynamics, wheater forecasting and climate models. Most if not all of those are Fortran codes. Maintaining them using explicit parallelism is tedious and deviates from the domain to address. Other users are aerospace, e.g. NASA or SpaceX, as well as aircraft and automotive manufacturers. - How was the project funded in the past (max 300 words) Foundational work on the coarray implementation was funded by Sourcery Institute. Small extensions and selected bug fixes have been donated by companies having a minor impact only. Most of the work was done on a voluntary basis. - 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 by modules that have not been compiled with coarray support (or are distributed in binary form only). Research and prototypical implementation in gfortran and the OpenCoarrays library 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 and failed images in coarrays 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
Re: Possible funding of gfortran work
On 1 June 2023 11:18:08 CEST, Andre Vehreschild via Fortran 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. Good point. There must be a ton fortran code running near ITER, maybe someone knows if any of that uses coarrays or would be inclined to do so if it would be improved? Just a thought..
Re: Possible funding of gfortran work
Hello, some more comments below: Le 01/06/2023 à 11:18, Andre Vehreschild a écrit : 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? --- - 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) Exemplarily these codes make use of language paradigms or want to, but can not due to lack of support in gfortran: CP2K: https://www.cp2k.org/ -- Quantum chemistry and solid state physics ICAR: https://github.com/ncar/icar -- Simplified atmospheric model FEATS: https://github.com/sourceryinstitute/feats -- Asynchronous task scheduling framework FAVOR: https://www.nrc.gov/reading-rm/doc-collections/nuregs/staff/sr1795/index.html -- Reactor security NWChem: https://www.nwchem-sw.org/ -- Computational chemistry software FUN3D: https://fun3d.larc.nasa.gov/ -- Computational fluid dynamics software from NASA MSC NASTRAN: https://simulatemore.mscsoftware.com/category/products/msc-nastran/ -- Structural engineering software from MSC Software WRF: https://www.mmm.ucar.edu/models/wrf -- Weather forecasting software from NCAR FAST: ??? -- Nuclear fuel performance software from the U.S. Nuclear Regulatory Commission (NRC) Some 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. - 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 the missing/incomplete features, that are too large to tackle for a single volunteer. Payed developers are to contribute a significant part of the features. 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 - Target of the projects in the sense of users (max 300 words) This project targets the high-performance computing community, esp. but not limited to fluid and thermo dynamics, wheater forecasting and climate models. Most if not all of those are Fortran codes. Maintaining them using explicit parallelism is tedious and deviates from the domain to address. Other users are aerospace, e.g. NASA or SpaceX, as well as aircraft and automotive manufacturers. - How was the project funded in the past (max 300 words) Foundational work on the coarray implementation was funded by Sourcery Institute. Small extensions and selected bug fixes have been donated by companies having a minor impact only. Most of the work was done on a voluntary basis. There is also Siemens (Tobias, etc) working on OMP and OpenACC. Not sure whether it should me mentioned here. - 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. I'm not very found of the last part of the senten
Re: Possible funding of gfortran work
On 6/1/23 12:18, 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? > > --- > - 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) > > Exemplarily these codes make use of language paradigms or want to, but can not > due to lack of support in gfortran: > > CP2K: https://www.cp2k.org/ -- Quantum chemistry and solid state physics > ICAR: https://github.com/ncar/icar -- Simplified atmospheric model > FEATS: https://github.com/sourceryinstitute/feats -- Asynchronous task > scheduling framework FAVOR: > https://www.nrc.gov/reading-rm/doc-collections/nuregs/staff/sr1795/index.html > -- Reactor security NWChem: https://www.nwchem-sw.org/ -- Computational > chemistry software FUN3D: https://fun3d.larc.nasa.gov/ -- Computational fluid > dynamics software from NASA MSC NASTRAN: > https://simulatemore.mscsoftware.com/category/products/msc-nastran/ -- > Structural engineering software from MSC Software WRF: > https://www.mmm.ucar.edu/models/wrf -- Weather forecasting software from NCAR > FAST: ??? -- Nuclear fuel performance software from the U.S. Nuclear > Regulatory > Commission (NRC) > Maybe add Quantum Espresso: https://www.quantum-espresso.org/ R and Octave may also be good examples of use cases. > Some 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. > > - 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. Perhaps computational chemistry rather than just quantum chemistry. > > 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 the 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) > > This project targets the high-performance computing community, esp. but not > limited to fluid and thermo dynamics, wheater forecasting and climate models. wheater->weather add computational chemistry as well > Most if not all of those are Fortran codes. Maintaining them using explicit > parallelism is tedious and deviates from the domain to address. Other users > are > aerospace, e.g. NASA or SpaceX, as well as aircraft and automotive > manufacturers. > Would expect for aerospace and automotive industry, it would mostly be for in house codes. Maybe someone for DLR may have input on this? Having end industry users involved in actively evaluating may be helpful in sustaining future improvements since they may be willing to support developer time. > - How was the project funded in the past (max 300 words) > > Foundational work on the coarray implementation was funded by Sourcery > Institute. Small extensions and selected bug fixes have been donated by > companies having a minor impact only. Most of the work was done on a > voluntary basis. > 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 t
[Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Hi All,
This started out as the search for a fix to pr109948 and evolved to roll in
5 other prs.
Basically parse_associate was far too clunky and, in anycase, existing
functions in resolve.cc were well capable of doing the determination of the
target expression rank. While I was checking the comments, the lightbulb
flashed with respect to prs 102109/112/190 and the chunk dealing with
function results of unknown type was born.
Thanks to the changes in parse.cc, the problem in pr99326 migrated
upstream to the resolution and the chunklet in resolve.cc was an obvious
fix.
I am minded to s/{ dg-do run}/{ dg-do compile } for all six testcases. At
the testing stage, I wanted to check that the testcases actually did what
they are supposed to do :-)
Bootstraps and regtests OK - good for head?
Paul
PS I need to do some housekeeping on pr87477 now. Some of the blockers have
"fixed themselves" and others are awaiting backporting. I think that there
are only 4 or so left, of which 89645 and 99065 are the most difficult to
deal with.
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 5e2a95688d2..3947444f17c 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -4919,6 +4919,7 @@ parse_associate (void)
gfc_state_data s;
gfc_statement st;
gfc_association_list* a;
+ gfc_array_spec *as;
gfc_notify_std (GFC_STD_F2003, "ASSOCIATE construct at %C");
@@ -4934,8 +4935,7 @@ parse_associate (void)
for (a = new_st.ext.block.assoc; a; a = a->next)
{
gfc_symbol* sym;
- gfc_ref *ref;
- gfc_array_ref *array_ref;
+ gfc_expr *target;
if (gfc_get_sym_tree (a->name, NULL, &a->st, false))
gcc_unreachable ();
@@ -4952,6 +4952,7 @@ parse_associate (void)
for parsing component references on the associate-name
in case of association to a derived-type. */
sym->ts = a->target->ts;
+ target = a->target;
/* Don’t share the character length information between associate
variable and target if the length is not a compile-time constant,
@@ -4971,31 +4972,37 @@ parse_associate (void)
&& sym->ts.u.cl->length->expr_type == EXPR_CONSTANT))
sym->ts.u.cl = gfc_new_charlen (gfc_current_ns, NULL);
- /* Check if the target expression is array valued. This cannot always
- be done by looking at target.rank, because that might not have been
- set yet. Therefore traverse the chain of refs, looking for the last
- array ref and evaluate that. */
- array_ref = NULL;
- for (ref = a->target->ref; ref; ref = ref->next)
- if (ref->type == REF_ARRAY)
- array_ref = &ref->u.ar;
- if (array_ref || a->target->rank)
+ /* Check if the target expression is array valued. This cannot be done
+ by calling gfc_resolve_expr because the context is unavailable.
+ However, the references can be resolved and the rank of the target
+ expression set. */
+ if (target->ref && gfc_resolve_ref (target)
+ && target->expr_type != EXPR_ARRAY
+ && target->expr_type != EXPR_COMPCALL)
+ gfc_expression_rank (target);
+
+ /* Determine whether or not function expressions with unknown type are
+ structure constructors. If so, the function result can be converted
+ to be a derived type.
+ TODO: Deal with references to sibling functions that have not yet been
+ parsed (PRs 89645 and 99065). */
+ if (target->expr_type == EXPR_FUNCTION && target->ts.type == BT_UNKNOWN)
{
- gfc_array_spec *as;
- int dim, rank = 0;
- if (array_ref)
+ gfc_symbol *derived;
+ /* The derived type has a leading uppercase character. */
+ gfc_find_symbol (gfc_dt_upper_string (target->symtree->name),
+ my_ns->parent, 1, &derived);
+ if (derived && derived->attr.flavor == FL_DERIVED)
{
- a->rankguessed = 1;
- /* Count the dimension, that have a non-scalar extend. */
- for (dim = 0; dim < array_ref->dimen; ++dim)
- if (array_ref->dimen_type[dim] != DIMEN_ELEMENT
- && !(array_ref->dimen_type[dim] == DIMEN_UNKNOWN
- && array_ref->end[dim] == NULL
- && array_ref->start[dim] != NULL))
- ++rank;
+ sym->ts.type = BT_DERIVED;
+ sym->ts.u.derived = derived;
}
- else
- rank = a->target->rank;
+ }
+
+ if (target->rank)
+ {
+ int rank = 0;
+ rank = target->rank;
/* When the rank is greater than zero then sym will be an array. */
if (sym->ts.type == BT_CLASS && CLASS_DATA (sym))
{
@@ -5006,8 +5013,8 @@ parse_associate (void)
/* Don't just (re-)set the attr and as in the sym.ts,
because this modifies the target's attr and as. Copy the
data and do a build_class_symbol. */
- symbol_attribute attr = CLASS_DATA (a->target)->attr;
- int corank = gfc_get_corank (a->target);
+ symbol_attribute attr = CLASS_DATA (target)->attr;
+ int corank = gfc_get_corank (target);
gfc_typespec type;
if (rank || corank)
@@ -5042,7 +5049,7 @@ parse_associate (void)
as = gfc_get_array_spec ();
as->type = AS_DEFERR
Re: [Patch, fortran] PR87477 - [meta-bug] [F03] issues concerning the ASSOCIATE statement
Le 01/06/2023 à 17:20, Paul Richard Thomas via Fortran a écrit :
Hi All,
This started out as the search for a fix to pr109948 and evolved to roll in
5 other prs.
Basically parse_associate was far too clunky and, in anycase, existing
functions in resolve.cc were well capable of doing the determination of the
target expression rank. While I was checking the comments, the lightbulb
flashed with respect to prs 102109/112/190 and the chunk dealing with
function results of unknown type was born.
Thanks to the changes in parse.cc, the problem in pr99326 migrated
upstream to the resolution and the chunklet in resolve.cc was an obvious
fix.
I am minded to s/{ dg-do run}/{ dg-do compile } for all six testcases.
Makes sense, the PRs were bogus errors and ICEs, so all compile time issues.
At
the testing stage, I wanted to check that the testcases actually did what
they are supposed to do :-)
Bootstraps and regtests OK - good for head?
OK. Thanks for this.
Paul
PS I need to do some housekeeping on pr87477 now. Some of the blockers have
"fixed themselves" and others are awaiting backporting. I think that there
are only 4 or so left, of which 89645 and 99065 are the most difficult to
deal with.
[PATCH] Fortran: force error on bad KIND specifier [PR88552]
Dear all,
we sometimes silently accept wrong declarations with unbalanced
parentheses, as the PR and testcases therein show.
It appears that the fix is obvious: use the existing error paths in
gfc_match_kind_spec and error return from gfc_match_decl_type_spec.
I'm still posting it here in case I have missed something not so
obvious.
The patch regtests cleanly on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From a30ff5af130c4d33c086fd136978d5f49cb8bde4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 1 Jun 2023 20:56:11 +0200
Subject: [PATCH] Fortran: force error on bad KIND specifier [PR88552]
gcc/fortran/ChangeLog:
PR fortran/88552
* decl.cc (gfc_match_kind_spec): Use error path on missing right
parenthesis.
(gfc_match_decl_type_spec): Use error return when an error occurred
during matching a KIND specifier.
gcc/testsuite/ChangeLog:
PR fortran/88552
* gfortran.dg/pr88552.f90: New test.
---
gcc/fortran/decl.cc | 4
gcc/testsuite/gfortran.dg/pr88552.f90 | 6 ++
2 files changed, 10 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/pr88552.f90
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 1de2b231242..deb20647fb9 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -3366,6 +3366,7 @@ close_brackets:
else
gfc_error ("Missing right parenthesis at %C");
m = MATCH_ERROR;
+ goto no_match;
}
else
/* All tests passed. */
@@ -4716,6 +4717,9 @@ get_kind:
return MATCH_ERROR;
}
+ if (m == MATCH_ERROR)
+return MATCH_ERROR;
+
/* Defer association of the KIND expression of function results
until after USE and IMPORT statements. */
if ((gfc_current_state () == COMP_NONE && gfc_error_flag_test ())
diff --git a/gcc/testsuite/gfortran.dg/pr88552.f90 b/gcc/testsuite/gfortran.dg/pr88552.f90
new file mode 100644
index 000..15e1b372f8f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr88552.f90
@@ -0,0 +1,6 @@
+! { dg-do compile }
+! PR fortran/88552
+! Contributed by G.Steinmetz
+
+integer(len((c)) :: n ! { dg-error "must be CHARACTER" }
+end
--
2.35.3
Re: [PATCH] Fortran: force error on bad KIND specifier [PR88552]
Hello,
Le 01/06/2023 à 21:05, Harald Anlauf via Fortran a écrit :
Dear all,
we sometimes silently accept wrong declarations with unbalanced
parentheses, as the PR and testcases therein show.
It appears that the fix is obvious: use the existing error paths in
gfc_match_kind_spec and error return from gfc_match_decl_type_spec.
I'm still posting it here in case I have missed something not so
obvious.
The patch regtests cleanly on x86_64-pc-linux-gnu. OK for mainline?
It looks good, but...
Thanks,
Harald
From a30ff5af130c4d33c086fd136978d5f49cb8bde4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 1 Jun 2023 20:56:11 +0200
Subject: [PATCH] Fortran: force error on bad KIND specifier [PR88552]
gcc/fortran/ChangeLog:
PR fortran/88552
* decl.cc (gfc_match_kind_spec): Use error path on missing right
parenthesis.
(gfc_match_decl_type_spec): Use error return when an error occurred
during matching a KIND specifier.
gcc/testsuite/ChangeLog:
PR fortran/88552
* gfortran.dg/pr88552.f90: New test.
---
gcc/fortran/decl.cc | 4
gcc/testsuite/gfortran.dg/pr88552.f90 | 6 ++
2 files changed, 10 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/pr88552.f90
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 1de2b231242..deb20647fb9 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -3366,6 +3366,7 @@ close_brackets:
else
gfc_error ("Missing right parenthesis at %C");
m = MATCH_ERROR;
+ goto no_match;
}
else
/* All tests passed. */
@@ -4716,6 +4717,9 @@ get_kind:
return MATCH_ERROR;
}
+ if (m == MATCH_ERROR)
+return MATCH_ERROR;
+
... can you move this up to the place where m is set?
OK with that change.
Thanks
Re: [PATCH] Fortran: force error on bad KIND specifier [PR88552]
Hi Mikael,
Am 01.06.23 um 22:33 schrieb Mikael Morin:
Hello,
Le 01/06/2023 à 21:05, Harald Anlauf via Fortran a écrit :
Dear all,
we sometimes silently accept wrong declarations with unbalanced
parentheses, as the PR and testcases therein show.
It appears that the fix is obvious: use the existing error paths in
gfc_match_kind_spec and error return from gfc_match_decl_type_spec.
I'm still posting it here in case I have missed something not so
obvious.
The patch regtests cleanly on x86_64-pc-linux-gnu. OK for mainline?
It looks good, but...
Thanks,
Harald
From a30ff5af130c4d33c086fd136978d5f49cb8bde4 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 1 Jun 2023 20:56:11 +0200
Subject: [PATCH] Fortran: force error on bad KIND specifier [PR88552]
gcc/fortran/ChangeLog:
PR fortran/88552
* decl.cc (gfc_match_kind_spec): Use error path on missing right
parenthesis.
(gfc_match_decl_type_spec): Use error return when an error occurred
during matching a KIND specifier.
gcc/testsuite/ChangeLog:
PR fortran/88552
* gfortran.dg/pr88552.f90: New test.
---
gcc/fortran/decl.cc | 4
gcc/testsuite/gfortran.dg/pr88552.f90 | 6 ++
2 files changed, 10 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/pr88552.f90
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 1de2b231242..deb20647fb9 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -3366,6 +3366,7 @@ close_brackets:
else
gfc_error ("Missing right parenthesis at %C");
m = MATCH_ERROR;
+ goto no_match;
}
else
/* All tests passed. */
@@ -4716,6 +4717,9 @@ get_kind:
return MATCH_ERROR;
}
+ if (m == MATCH_ERROR)
+ return MATCH_ERROR;
+
... can you move this up to the place where m is set?
OK with that change.
I was afraid that this would regress on the existing testcases
pr91660_[12].f90 that depend on an error message emitted just
before that hunk, but this turned out not to happen.
Adjusted version committed as:
r14-1477-gff8f45d20f9ea6acc99442ad29212d177f58e8fe .
Thanks
Thanks for the review!
Harald
Re: Possible funding of gfortran work
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
