Re: Team Collaboration Considerations
On 12/8/22 20:14, Holcomb, Katherine A (kah3f) via Fortran wrote: I was thinking I might try to contribute when I retire, though that may be in a year or two. But it's been a very long time since I dove into a large software project and it's intimidating. I do know C (really C++, I haven't used plain C for a long time). I am one of those "aging" types but I am familiar at least superficially with newer tools because I must use them for work, specifically git and Slack (Mattermost seems to be an open-source Slack alternative) -- we make heavy use of Slack in particular. Is there some kind of "getting started" guide? Thanks, Katherine, for your thoughts on this side of support (i.e., fixing compiler bugs, and how to get people interested in contributing). Based on that, I thought of another approach, namely: interesting *users* of gfortran to provide us with useful information on their experiences with it (lest we only look at the depressing list of PRs). Would it help if we created a fortran-h...@gcc.gnu.org list (a loose parallel of gcc-h...@gcc.gnu.org) for *questions* from our user base ? I just have to look at the questions I get at work from my colleagues: 1. I get this message while compiling XYZ weather forecasting model (HELP, what does it mean ?). How do I solve it ? Do I need ABC (mega-corporation chip manufacturing's) fortran compiler ? 2. gfortran gives me a "internal compiler error", but this code compiled perfectly just a year ago (an ICE is never a user's problem). How can I work around it ? 3. Is this (source code provided) code conformant ? gfortran complains about it, but XYZ compiler just compiles it fine. etc. This might not result in many new contributors, but it shows to the broader GCC development community what gfortran is used for, and how *we* deal with their questions and problems (and, thus, how important this part of the GNU Compiler *Collection* is). Oh, BTW, I retire in nine months, which would give me loads of time to deal with such a mailing list. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
[Patch] Fortran/OpenMP: align/allocator modifiers to the allocate clause
Implementing the 5.1 syntax inside the 'allocate' clause. That's a
fallout of working on something else...
OK for mainline?
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
Fortran/OpenMP: align/allocator modifiers to the allocate clause
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (show_omp_namelist): Improve OMP_LIST_ALLOCATE
output.
* gfortran.h (struct gfc_omp_namelist): Add 'align' to 'u'.
(gfc_free_omp_namelist): Add bool arg.
* match.cc (gfc_free_omp_namelist): Likewise; free 'u.align'.
* openmp.cc (gfc_free_omp_clauses, gfc_match_omp_clause_reduction,
gfc_match_omp_flush): Update call.
(gfc_match_omp_clauses): Match 'align/allocate modifers in
'allocate' clause.
(resolve_omp_clauses): Resolve align.
* st.cc (gfc_free_statement): Update call
* trans-openmp.cc (gfc_trans_omp_clauses): Handle 'align'.
libgomp/ChangeLog:
* libgomp.texi (5.1 Impl. Status): Split allocate clause/directive
item about 'align'; mark clause as 'Y' and directive as 'N'.
* testsuite/libgomp.fortran/allocate-2.f90: New test.
* testsuite/libgomp.fortran/allocate-3.f90: New test.
gcc/fortran/dump-parse-tree.cc | 23 +
gcc/fortran/gfortran.h | 3 +-
gcc/fortran/match.cc | 4 +-
gcc/fortran/openmp.cc| 106 +++
gcc/fortran/st.cc| 2 +-
gcc/fortran/trans-openmp.cc | 8 ++
libgomp/libgomp.texi | 4 +-
libgomp/testsuite/libgomp.fortran/allocate-2.f90 | 25 ++
libgomp/testsuite/libgomp.fortran/allocate-3.f90 | 28 ++
9 files changed, 163 insertions(+), 40 deletions(-)
diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 2f042ab5142..5ae72dc1cac 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -1357,6 +1357,29 @@ show_omp_namelist (int list_type, gfc_omp_namelist *n)
}
ns_iter = n->u2.ns;
}
+ if (list_type == OMP_LIST_ALLOCATE)
+ {
+ if (n->expr)
+ {
+ fputs ("allocator(", dumpfile);
+ show_expr (n->expr);
+ fputc (')', dumpfile);
+ }
+ if (n->expr && n->u.align)
+ fputc (',', dumpfile);
+ if (n->u.align)
+ {
+ fputs ("allocator(", dumpfile);
+ show_expr (n->u.align);
+ fputc (')', dumpfile);
+ }
+ if (n->expr || n->u.align)
+ fputc (':', dumpfile);
+ fputs (n->sym->name, dumpfile);
+ if (n->next)
+ fputs (") ALLOCATE(", dumpfile);
+ continue;
+ }
if (list_type == OMP_LIST_REDUCTION)
switch (n->u.reduction_op)
{
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index b541a07e2c7..5f8a81ae4a1 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -1349,6 +1349,7 @@ typedef struct gfc_omp_namelist
gfc_omp_reduction_op reduction_op;
gfc_omp_depend_doacross_op depend_doacross_op;
gfc_omp_map_op map_op;
+ gfc_expr *align;
struct
{
ENUM_BITFIELD (gfc_omp_linear_op) op:4;
@@ -3572,7 +3573,7 @@ void gfc_free_iterator (gfc_iterator *, int);
void gfc_free_forall_iterator (gfc_forall_iterator *);
void gfc_free_alloc_list (gfc_alloc *);
void gfc_free_namelist (gfc_namelist *);
-void gfc_free_omp_namelist (gfc_omp_namelist *, bool);
+void gfc_free_omp_namelist (gfc_omp_namelist *, bool, bool);
void gfc_free_equiv (gfc_equiv *);
void gfc_free_equiv_until (gfc_equiv *, gfc_equiv *);
void gfc_free_data (gfc_data *);
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 8b8b6e79c8b..7ba0f349993 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -5524,13 +5524,15 @@ gfc_free_namelist (gfc_namelist *name)
/* Free an OpenMP namelist structure. */
void
-gfc_free_omp_namelist (gfc_omp_namelist *name, bool free_ns)
+gfc_free_omp_namelist (gfc_omp_namelist *name, bool free_ns, bool free_align)
{
gfc_omp_namelist *n;
for (; name; name = n)
{
gfc_free_expr (name->expr);
+ if (free_align)
+ gfc_free_expr (name->u.align);
if (free_ns)
gfc_free_namespace (name->u2.ns);
else if (name->u2.udr)
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 862c649b0b6..4b4e6ac6947 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -187,7 +187,8 @@ gfc_free_omp_clauses (gfc_omp_clauses *c)
gfc_free_expr (c->vector_length_expr);
for (i = 0; i < OMP_LIST_NUM; i++)
gfc_free_omp_namelist (c->lists[i],
- i == OMP_LIST_AFFINITY || i == OMP_LIST_DEPEND);
+ i == OMP_LIST_AFFINITY || i == OMP_LIST_DEPEND,
+ i == OMP_LIST_ALLOCATE);
gfc_free_expr_list (c->wait_list);
gfc_free_expr_list (c->tile_list);
free (CONST_CAST (char *, c->critical_name));
@@ -542,7 +543
Re: [Patch] Fortran/OpenMP: align/allocator modifiers to the allocate clause
On Fri, Dec 09, 2022 at 09:14:55PM +0100, Tobias Burnus wrote: > Implementing the 5.1 syntax inside the 'allocate' clause. That's a > fallout of working on something else... > > OK for mainline? > > 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 > Fortran/OpenMP: align/allocator modifiers to the allocate clause > > gcc/fortran/ChangeLog: > > * dump-parse-tree.cc (show_omp_namelist): Improve OMP_LIST_ALLOCATE > output. > * gfortran.h (struct gfc_omp_namelist): Add 'align' to 'u'. > (gfc_free_omp_namelist): Add bool arg. > * match.cc (gfc_free_omp_namelist): Likewise; free 'u.align'. > * openmp.cc (gfc_free_omp_clauses, gfc_match_omp_clause_reduction, > gfc_match_omp_flush): Update call. > (gfc_match_omp_clauses): Match 'align/allocate modifers in > 'allocate' clause. > (resolve_omp_clauses): Resolve align. > * st.cc (gfc_free_statement): Update call > * trans-openmp.cc (gfc_trans_omp_clauses): Handle 'align'. > > libgomp/ChangeLog: > > * libgomp.texi (5.1 Impl. Status): Split allocate clause/directive > item about 'align'; mark clause as 'Y' and directive as 'N'. > * testsuite/libgomp.fortran/allocate-2.f90: New test. > * testsuite/libgomp.fortran/allocate-3.f90: New test. LGTM, thanks. Jakub
[Patch] Fortran: Replace simple '.' quotes by %<.%>
Found when working on the just submitted/committed patch.
I intent to commit it to mainline as obvious tomorrow (or Sun or Mon),
unless there are comments.
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
Fortran: Replace simple '.' quotes by %<.%>
When using %qs instead of '%s' or %<=%> instead of '=' looks nicer
by having nicer quotes and bold text, if the terminal supports it;
otherwise, plain quotes are used.
gcc/fortran/ChangeLog:
* match.cc (gfc_match_member_sep): Use %<...%> in gfc_error.
* openmp.cc (gfc_match_oacc_routine, gfc_match_omp_context_selector,
gfc_match_omp_context_selector_specification,
gfc_match_omp_declare_variant, resolve_omp_clauses): Likewise;
use %qs instead of '%s'.
* primary.cc (match_real_constant, gfc_match_varspec): Likewise.
* resolve.cc (gfc_resolve_formal_arglist, resolve_operator,
resolve_ordinary_assign): Likewise.
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 7ba0f349993..89fb115c0f6 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -195,3 +195,3 @@ gfc_match_member_sep(gfc_symbol *sym)
gfc_error ("Expected structure component or operator name "
- "after '.' at %C");
+ "after %<.%> at %C");
goto error;
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 4b4e6ac6947..7edc78ad0cb 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -4061,3 +4061,3 @@ gfc_match_oacc_routine (void)
gfc_error ("Syntax error in !$ACC ROUTINE ( NAME ) at %C, expecting"
- " ')' after NAME");
+ " %<)%> after NAME");
gfc_current_locus = old_loc;
@@ -5350,4 +5350,4 @@ gfc_match_omp_context_selector (gfc_omp_set_selector *oss)
{
- gfc_error ("selector '%s' not allowed for context selector "
- "set '%s' at %C",
+ gfc_error ("selector %qs not allowed for context selector "
+ "set %qs at %C",
selector, oss->trait_set_selector_name);
@@ -5370,3 +5370,3 @@ gfc_match_omp_context_selector (gfc_omp_set_selector *oss)
{
- gfc_error ("selector '%s' does not accept any properties at %C",
+ gfc_error ("selector %qs does not accept any properties at %C",
selector);
@@ -5379,3 +5379,3 @@ gfc_match_omp_context_selector (gfc_omp_set_selector *oss)
{
- gfc_error ("expected '(' at %C");
+ gfc_error ("expected %<(%> at %C");
return MATCH_ERROR;
@@ -5401,3 +5401,3 @@ gfc_match_omp_context_selector (gfc_omp_set_selector *oss)
{
- gfc_error ("expected ')' at %C");
+ gfc_error ("expected %<)%> at %C");
return MATCH_ERROR;
@@ -5514,3 +5514,3 @@ gfc_match_omp_context_selector (gfc_omp_set_selector *oss)
{
- gfc_error ("expected ')' at %C");
+ gfc_error ("expected %<)%> at %C");
return MATCH_ERROR;
@@ -5524,3 +5524,3 @@ gfc_match_omp_context_selector (gfc_omp_set_selector *oss)
{
- gfc_error ("expected '(' at %C");
+ gfc_error ("expected %<(%> at %C");
return MATCH_ERROR;
@@ -5570,4 +5570,4 @@ gfc_match_omp_context_selector_specification (gfc_omp_declare_variant *odv)
{
- gfc_error ("expected 'construct', 'device', 'implementation' or "
- "'user' at %C");
+ gfc_error ("expected %, %, % "
+ "or % at %C");
return MATCH_ERROR;
@@ -5578,3 +5578,3 @@ gfc_match_omp_context_selector_specification (gfc_omp_declare_variant *odv)
{
- gfc_error ("expected '=' at %C");
+ gfc_error ("expected %<=%> at %C");
return MATCH_ERROR;
@@ -5585,3 +5585,3 @@ gfc_match_omp_context_selector_specification (gfc_omp_declare_variant *odv)
{
- gfc_error ("expected '{' at %C");
+ gfc_error ("expected %<{%> at %C");
return MATCH_ERROR;
@@ -5600,3 +5600,3 @@ gfc_match_omp_context_selector_specification (gfc_omp_declare_variant *odv)
{
- gfc_error ("expected '}' at %C");
+ gfc_error ("expected %<}%> at %C");
return MATCH_ERROR;
@@ -5622,3 +5622,3 @@ gfc_match_omp_declare_variant (void)
{
- gfc_error ("expected '(' at %C");
+ gfc_error ("expected %<(%> at %C");
return MATCH_ERROR;
@@ -5670,3 +5670,3 @@ gfc_match_omp_declare_variant (void)
{
- gfc_error ("expected ')' at %C");
+ gfc_error ("expected %<)%> at %C");
return MATCH_ERROR;
@@ -5680,3 +5680,3 @@ gfc_match_omp_declare_variant (void)
{
- gfc_error ("expected 'match' at %C");
+ gfc_error ("expected % at %C");
return MATCH_ERROR;
@@ -5689,3 +5689,3 @@ gfc_match_omp_declare_variant (void)
{
- gfc_error ("expected '(' at %C");
+ gfc_error ("expected %<(%> at %C");
return MATCH_ERROR;
@@ -5698,3 +5698,3 @@ gfc_match_omp_declare_variant (void)
{
- gfc_error ("expected ')' at %C");
+ gfc_error ("expected %<)%> at %C");
return MATCH_ERROR;
@@ -7380,3 +7380,3 @@ resolve_omp_clauses (gfc_code *code,
[PATCH] Fortran: ICE on recursive derived types with allocatable components [PR107872]
Dear all,
I am submitting the attached simple - and obvious - patch on
behalf of Paul. It prevents a resource exhaustion due to an
infinite loop, and has been regtested by multiple contributers, ;-)
at least on x86_64-pc-linux-gnu.
I intend to commit it to mainline within 24 hours, unless
there are further comments.
Thanks,
Harald
From 01254aa2eb766c7584fd047568d7277d4d65d067 Mon Sep 17 00:00:00 2001
From: Paul Thomas
Date: Fri, 9 Dec 2022 22:13:45 +0100
Subject: [PATCH] Fortran: ICE on recursive derived types with allocatable
components [PR107872]
gcc/fortran/ChangeLog:
PR fortran/107872
* resolve.cc (derived_inaccessible): Skip over allocatable components
to prevent an infinite loop.
gcc/testsuite/ChangeLog:
PR fortran/107872
* gfortran.dg/pr107872.f90: New test.
---
gcc/fortran/resolve.cc | 3 +-
gcc/testsuite/gfortran.dg/pr107872.f90 | 40 ++
2 files changed, 42 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr107872.f90
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 75dc4b59105..158bf08ec26 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -7536,7 +7536,8 @@ derived_inaccessible (gfc_symbol *sym)
for (c = sym->components; c; c = c->next)
{
/* Prevent an infinite loop through this function. */
- if (c->ts.type == BT_DERIVED && c->attr.pointer
+ if (c->ts.type == BT_DERIVED
+ && (c->attr.pointer || c->attr.allocatable)
&& sym == c->ts.u.derived)
continue;
diff --git a/gcc/testsuite/gfortran.dg/pr107872.f90 b/gcc/testsuite/gfortran.dg/pr107872.f90
new file mode 100644
index 000..09838479e92
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107872.f90
@@ -0,0 +1,40 @@
+! { dg-do run }
+!
+! Test the fix for PR107872, where an ICE occurred in
+! resolve.cc(derived_inaccessible) because derived types with
+! recursive allocatable components were not catered for.
+!
+module mod1
+ type t
+ integer :: data
+ type(t), allocatable :: next
+ contains
+ procedure, private :: write_t
+ generic :: write(formatted) => write_t
+ end type
+contains
+ recursive subroutine write_t(this, unit, iotype, v_list, iostat, iomsg)
+class(t), intent(in) :: this
+integer, intent(in) :: unit
+character(*), intent(in) :: iotype
+integer, intent(in) :: v_list(:)
+integer, intent(out) :: iostat
+character(*), intent(inout) :: iomsg
+if (ALLOCATED(this%next)) &
+ write (unit, '(dt)') this%next
+write (unit, '(i2)') this%data
+ end subroutine
+end module
+
+ use mod1
+ type(t) :: a
+ character (8) :: buffer
+ a%data = 1
+ allocate (a%next)
+ a%next%data = 2
+ allocate (a%next%next)
+ a%next%next%data = 3
+ write (buffer, '(dt)')a
+ deallocate (a%next)
+ if (trim (buffer) .ne. ' 3 2 1') stop 1
+end
--
2.35.3
Re: Team Collaboration Considerations
Hi Jerry and everybody else, I am with Tobias on this. Between work, gfortran, RSPCA, club and neighbourhood activities I am "channelled" up to the eyeballs. Adding another wouldn't make any great odds but I couldn't pay much more attention to it than many of the others - sorry! At the present, I am spending more time than I really have on finishing the finalization patch(es). Hopefully it will see the light of day very soon. After that, I have to fix the mess that I made of PDTs. Neither of these feature very high on the scale of the user survey that Steve Lionel ran but, at least, we could come close to F2003 compliance. It would help enormously, if somebody would sit down and figure out in detail where the F2008/2018 gaps are. I am about to vote on the F2023 DAS so if anybody has any thoughts on that, I would like to hear them. I hate conditional arguments but the rest looks OK and, I suspect, is relatively easily implemented. One really helpful collaborative activity would be to update the gfortran wiki. For a good long while that, together with the gfortran list, did serve as our collaborative focus. Regards Paul On Fri, 9 Dec 2022 at 19:36, Toon Moene wrote: > On 12/8/22 20:14, Holcomb, Katherine A (kah3f) via Fortran wrote: > > > I was thinking I might try to contribute when I retire, though that may > be in a year or two. But it's been a very long time since I dove into a > large software project and it's intimidating. I do know C (really C++, I > haven't used plain C for a long time). I am one of those "aging" types > but I am familiar at least superficially with newer tools because I must > use them for work, specifically git and Slack (Mattermost seems to be an > open-source Slack alternative) -- we make heavy use of Slack in particular. > > > > Is there some kind of "getting started" guide? > > Thanks, Katherine, for your thoughts on this side of support (i.e., > fixing compiler bugs, and how to get people interested in contributing). > > Based on that, I thought of another approach, namely: interesting > *users* of gfortran to provide us with useful information on their > experiences with it (lest we only look at the depressing list of PRs). > > Would it help if we created a fortran-h...@gcc.gnu.org list (a loose > parallel of gcc-h...@gcc.gnu.org) for *questions* from our user base ? > > I just have to look at the questions I get at work from my colleagues: > > 1. I get this message while compiling XYZ weather forecasting model > (HELP, what does it mean ?). How do I solve it ? Do I need ABC > (mega-corporation chip manufacturing's) fortran compiler ? > > 2. gfortran gives me a "internal compiler error", but this code > compiled perfectly just a year ago (an ICE is never a user's > problem). How can I work around it ? > > 3. Is this (source code provided) code conformant ? gfortran > complains about it, but XYZ compiler just compiles it fine. > > etc. > > This might not result in many new contributors, but it shows to the > broader GCC development community what gfortran is used for, and how > *we* deal with their questions and problems (and, thus, how important > this part of the GNU Compiler *Collection* is). > > Oh, BTW, I retire in nine months, which would give me loads of time to > deal with such a mailing list. > > Kind regards, > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [PATCH] Fortran: ICE on recursive derived types with allocatable components [PR107872]
Hi Harald, Thanks for doing that. My attention is elsewhere gfortran-wise. Good for mainline. Paul On Fri, 9 Dec 2022 at 21:27, Harald Anlauf via Fortran wrote: > Dear all, > > I am submitting the attached simple - and obvious - patch on > behalf of Paul. It prevents a resource exhaustion due to an > infinite loop, and has been regtested by multiple contributers, ;-) > at least on x86_64-pc-linux-gnu. > > I intend to commit it to mainline within 24 hours, unless > there are further comments. > > Thanks, > Harald > > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: Team Collaboration Considerations
On 12/9/22 22:56, Paul Richard Thomas wrote: One really helpful collaborative activity would be to update the gfortran wiki. For a good long while that, together with the gfortran list, did serve as our collaborative focus. Another thing I might have tons of time for beyond 20230827. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
