Re: [Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable
Hi Tobias, Thanks. Commit r11-8255-g67378cd63d62bf0c69e966d1d202a1e586550a68. By the way, I did check that there were no problems with pdt_26.f03 reported by valgrind, given the decrease in the malloc count. Cheers Paul On Mon, 19 Apr 2021 at 14:08, Tobias Burnus wrote: > Hi Paul, > > On 19.04.21 14:40, Paul Richard Thomas via Gcc-patches wrote: > > I was just about to announce that I will only do backports and > regressions, > > while I finally attack the fundamental problem with the representation of > > Parameterized Derived Types. Then this PR came up that was such clear low > > hanging fruit that I decided to fix it right away. > > > > Regtests on FC33/x86_64 - OK for mainline? > > LGTM. > > Thanks, > > Tobias > > - > Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank > Thürauf > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable
Hi Paul,
is there a reason why you did not apply the patch to mainline ('master')
but only to GCC 11 ('releases/gcc-11')?
While GCC 11 is okay, I had expected it to be (only) on mainline!
Tobias
On 20.04.21 10:55, Paul Richard Thomas wrote:
Hi Tobias,
Thanks. Commit r11-8255-g67378cd63d62bf0c69e966d1d202a1e586550a68.
By the way, I did check that there were no problems with pdt_26.f03
reported by valgrind, given the decrease in the malloc count.
Cheers
Paul
On Mon, 19 Apr 2021 at 14:08, Tobias Burnus mailto:tob...@codesourcery.com>> wrote:
Hi Paul,
On 19.04.21 14:40, Paul Richard Thomas via Gcc-patches wrote:
> I was just about to announce that I will only do backports and
regressions,
> while I finally attack the fundamental problem with the
representation of
> Parameterized Derived Types. Then this PR came up that was such
clear low
> hanging fruit that I decided to fix it right away.
>
> Regtests on FC33/x86_64 - OK for mainline?
LGTM.
Thanks,
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634
München Registergericht München HRB 106955, Geschäftsführer:
Thomas Heurung, Frank Thürauf
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
Re: [Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable
On Tue, Apr 20, 2021 at 11:58:32AM +0200, Tobias Burnus wrote:
> is there a reason why you did not apply the patch to mainline ('master')
> but only to GCC 11 ('releases/gcc-11')?
>
> While GCC 11 is okay, I had expected it to be (only) on mainline!
r11-8255 is before the branchpoint, so is both in GCC 11 and trunk.
r11-8256 was the last revision on both, followed by r12-0 on trunk
and r11-8257 on releases/gcc-11.
Jakub
Re: [Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable
Answer: Because my 'git pull' somehow got stuck – and showed an old trunk.
Your patch just went in before the merge – thus it was on mainline GCC
11 and is now
on mainline GCC 12 + GCC 11 branch ...
Sorry for the confusion.
Tobias
On 20.04.21 11:58, Tobias Burnus wrote:
Hi Paul,
is there a reason why you did not apply the patch to mainline ('master')
but only to GCC 11 ('releases/gcc-11')?
While GCC 11 is okay, I had expected it to be (only) on mainline!
Tobias
On 20.04.21 10:55, Paul Richard Thomas wrote:
Hi Tobias,
Thanks. Commit r11-8255-g67378cd63d62bf0c69e966d1d202a1e586550a68.
By the way, I did check that there were no problems with pdt_26.f03
reported by valgrind, given the decrease in the malloc count.
Cheers
Paul
On Mon, 19 Apr 2021 at 14:08, Tobias Burnus mailto:tob...@codesourcery.com>> wrote:
Hi Paul,
On 19.04.21 14:40, Paul Richard Thomas via Gcc-patches wrote:
> I was just about to announce that I will only do backports and
regressions,
> while I finally attack the fundamental problem with the
representation of
> Parameterized Derived Types. Then this PR came up that was such
clear low
> hanging fruit that I decided to fix it right away.
>
> Regtests on FC33/x86_64 - OK for mainline?
LGTM.
Thanks,
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634
München Registergericht München HRB 106955, Geschäftsführer:
Thomas Heurung, Frank Thürauf
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
Frank Thürauf
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
Re: [Patch, fortran] PR100110 - Parameterized Derived Types, problems with global variable
Hi Tobias,
That was entirely accidental. I should have been more careful about
checking the timing of the merge. When I last checked the number of P1s
seemed to indicate that there was a while before it would happen.
Apologies to all.
Paul
On Tue, 20 Apr 2021 at 11:07, Tobias Burnus wrote:
> Answer: Because my 'git pull' somehow got stuck – and showed an old trunk.
>
> Your patch just went in before the merge – thus it was on mainline GCC
> 11 and is now
> on mainline GCC 12 + GCC 11 branch ...
>
> Sorry for the confusion.
>
> Tobias
>
> On 20.04.21 11:58, Tobias Burnus wrote:
> > Hi Paul,
> >
> > is there a reason why you did not apply the patch to mainline ('master')
> > but only to GCC 11 ('releases/gcc-11')?
> >
> > While GCC 11 is okay, I had expected it to be (only) on mainline!
> >
> > Tobias
> >
> > On 20.04.21 10:55, Paul Richard Thomas wrote:
> >> Hi Tobias,
> >>
> >> Thanks. Commit r11-8255-g67378cd63d62bf0c69e966d1d202a1e586550a68.
> >>
> >> By the way, I did check that there were no problems with pdt_26.f03
> >> reported by valgrind, given the decrease in the malloc count.
> >>
> >> Cheers
> >>
> >> Paul
> >>
> >>
> >> On Mon, 19 Apr 2021 at 14:08, Tobias Burnus >> > wrote:
> >>
> >> Hi Paul,
> >>
> >> On 19.04.21 14:40, Paul Richard Thomas via Gcc-patches wrote:
> >> > I was just about to announce that I will only do backports and
> >> regressions,
> >> > while I finally attack the fundamental problem with the
> >> representation of
> >> > Parameterized Derived Types. Then this PR came up that was such
> >> clear low
> >> > hanging fruit that I decided to fix it right away.
> >> >
> >> > Regtests on FC33/x86_64 - OK for mainline?
> >>
> >> LGTM.
> >>
> >> Thanks,
> >>
> >> Tobias
> >>
> >> -
> >> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634
> >> München Registergericht München HRB 106955, Geschäftsführer:
> >> Thomas Heurung, Frank Thürauf
> >>
> >>
> >>
> >> --
> >> "If you can't explain it simply, you don't understand it well enough"
> >> - Albert Einstein
> > -
> > Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
> > Frank Thürauf
> -
> Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
> Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
> Thürauf
>
--
"If you can't explain it simply, you don't understand it well enough" -
Albert Einstein
[Patch, fortran] PR84119 - Type parameter inquiry for PDT returns array instead of scalar
Hi All,
This is another PDT warm-up patch before tackling the real beast: PR82649.
As the contributor wrote in the PR, "The F08 standard clearly distinguishes
between type parameter definition statements and component definition
statements. See R425, R431, R435, and in particular see Note 6.7 which says
'It [array%a, for example] is scalar even if designator is an array.' "
gfortran was not making this distinction. The patch realises the fix by
lifting the code used for inquiry part references into a new function and
calling for PDT parameters and inquiry references. The arrayspec lbound is
used for 'start' now, rather than unity. In principle this should remove
the need to suppress bound checking. However, since this would be confusing
for the user to say the least of it, the suppression has been retained.
Bootstraps and regtests on FC33/x86_64. OK for 12- and 11-branches?
Cheers
Paul
Fortran: Make PDT LEN and KIND expressions always scalar [PR84119].
2021-04-20 Paul Thomas
gcc/fortran
PR fortran/84119
* resolve.c (reset_array_ref_to_scalar): New function.
(gfc_resolve_ref): Call it for PDT kind and len expressions.
Code for inquiry refs. moved to new function and replaced by a
call to it.
gcc/testsuite/
PR fortran/84119
* gfortran.dg/pdt_32.f03: New test.
* gfortran.dg/pdt_20.f03: Correct the third test to be against
a scalar instead of an array.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index dd4b26680e0..1571fa9d70c 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -5254,12 +5254,46 @@ gfc_resolve_substring_charlen (gfc_expr *e)
}
+/* Convert an array reference to an array element so that PDT KIND and LEN
+ or inquiry references are always scalar. */
+
+static void
+reset_array_ref_to_scalar (gfc_expr *expr, gfc_ref *array_ref)
+{
+ gfc_expr *unity = gfc_get_int_expr (gfc_default_integer_kind, NULL, 1);
+ int dim;
+
+ array_ref->u.ar.type = AR_ELEMENT;
+ expr->rank = 0;
+ /* Suppress the runtime bounds check. */
+ expr->no_bounds_check = 1;
+ for (dim = 0; dim < array_ref->u.ar.dimen; dim++)
+{
+ array_ref->u.ar.dimen_type[dim] = DIMEN_ELEMENT;
+ if (array_ref->u.ar.start[dim])
+ gfc_free_expr (array_ref->u.ar.start[dim]);
+
+ if (array_ref->u.ar.as && array_ref->u.ar.as->lower[dim])
+ array_ref->u.ar.start[dim]
+ = gfc_copy_expr (array_ref->u.ar.as->lower[dim]);
+ else
+ array_ref->u.ar.start[dim] = gfc_copy_expr (unity);
+
+ if (array_ref->u.ar.end[dim])
+ gfc_free_expr (array_ref->u.ar.end[dim]);
+ if (array_ref->u.ar.stride[dim])
+ gfc_free_expr (array_ref->u.ar.stride[dim]);
+}
+ gfc_free_expr (unity);
+}
+
+
/* Resolve subtype references. */
bool
gfc_resolve_ref (gfc_expr *expr)
{
- int current_part_dimension, n_components, seen_part_dimension, dim;
+ int current_part_dimension, n_components, seen_part_dimension;
gfc_ref *ref, **prev, *array_ref;
bool equal_length;
@@ -5365,6 +5399,14 @@ gfc_resolve_ref (gfc_expr *expr)
}
}
+ /* The F08 standard distinguishes between type parameter definition
+ statements and component definition statements. See R425, R431,
+ R435, and in particular see Note 6.7 which says "It [array%a, for
+ example] is scalar even if designator is an array." */
+ if (array_ref && (ref->u.c.component->attr.pdt_kind
+ || ref->u.c.component->attr.pdt_len))
+ reset_array_ref_to_scalar (expr, array_ref);
+
n_components++;
break;
@@ -5375,27 +5417,7 @@ gfc_resolve_ref (gfc_expr *expr)
/* Implement requirement in note 9.7 of F2018 that the result of the
LEN inquiry be a scalar. */
if (ref->u.i == INQUIRY_LEN && array_ref && expr->ts.deferred)
- {
- array_ref->u.ar.type = AR_ELEMENT;
- expr->rank = 0;
- /* INQUIRY_LEN is not evaluated from the rest of the expr
- but directly from the string length. This means that setting
- the array indices to one does not matter but might trigger
- a runtime bounds error. Suppress the check. */
- expr->no_bounds_check = 1;
- for (dim = 0; dim < array_ref->u.ar.dimen; dim++)
- {
- array_ref->u.ar.dimen_type[dim] = DIMEN_ELEMENT;
- if (array_ref->u.ar.start[dim])
- gfc_free_expr (array_ref->u.ar.start[dim]);
- array_ref->u.ar.start[dim]
- = gfc_get_int_expr (gfc_default_integer_kind, NULL, 1);
- if (array_ref->u.ar.end[dim])
- gfc_free_expr (array_ref->u.ar.end[dim]);
- if (array_ref->u.ar.stride[dim])
- gfc_free_expr (array_ref->u.ar.stride[dim]);
- }
- }
+ reset_array_ref_to_scalar (expr, array_ref);
break;
}
diff --git a/gcc/testsuite/gfortran.dg/pdt_20.f03 b/gcc/testsuite/gfortran.dg/pdt_20.f03
index b712ed59dbb..3aa9b2e086b 100644
--- a/gcc/testsuite/gfortran.dg/pdt_20.f03
+++ b/gcc/testsuite/gfortran.dg/pdt_20.f03
@@ -16,5 +16,5 @@ program p
allocate (t2(3) :: x)! Used to segfault in trans-array.c.
if (x%b .ne. 3) STOP 1
if (x%b .ne. size (x%r, 1)) ST
Re: [Patch][GCC12] Fortran/OpenMP: Add 'omp depobj' and 'depend(mutexinoutset:'
I have now updated the patch – and intent to commit it tomorrow, unless
there are further comments.
On 17.03.21 19:29, Jakub Jelinek wrote:
On Wed, Mar 17, 2021 at 07:19:29PM +0100, Tobias Burnus wrote:
@@ -1831,6 +1852,7 @@ show_omp_node (int level, gfc_code *c)
+case EXEC_OMP_DEPOBJ: name = "DEPBOBJ"; break;
s/DEPBOBJ/DEPOBJ/
+ || omp_clauses->depobj->ts.kind != 2*gfc_index_integer_kind
Formatting (several times), I think we should use 2 * gfc_index_integer_kind
Fixed.
@@ -2545,6 +2545,8 @@ gfc_trans_omp_clauses (stmtblock_t *block,
gfc_omp_clauses *clauses,
+ if (POINTER_TYPE_P (TREE_TYPE (decl)))
+decl = build_fold_indirect_ref (decl);
I'm a little bit worried about this, are you sure it won't affect anything
but depobj?
I have added an 'n->u.depend_op == OMP_DEPEND_DEPOBJ' to be sure.
+ case OMP_DEPEND_MUTEXINOUTSET: k = GOMP_DEPEND_MUTEXINOUTSET; break;
+ case OMP_DEPEND_DEPOBJ: k = GOMP_DEPEND_MUTEXINOUTSET; break;
Can depobj_update be OMP_DEPEND_DEPOBJ ?
'update' can't but 'depend' can – but only in OpenMP 5.1; moved
testcase, fixed check & remove 'case ...DEPOBJ:' line for now.
Otherwise LGTM.
Attached is the full patch.
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
Fortran/OpenMP: Add 'omp depobj' and 'depend(mutexinoutset:'
gcc/fortran/ChangeLog:
* dump-parse-tree.c (show_omp_namelist): Handle depobj + mutexinoutset
in the depend clause.
(show_omp_clauses, show_omp_node, show_code_node): Handle depobj.
* gfortran.h (enum gfc_statement): Add ST_OMP_DEPOBJ.
(enum gfc_omp_depend_op): Add OMP_DEPEND_UNSET,
OMP_DEPEND_MUTEXINOUTSET and OMP_DEPEND_DEPOBJ.
(gfc_omp_clauses): Add destroy, depobj_update and depobj.
(enum gfc_exec_op): Add EXEC_OMP_DEPOBJ
* match.h (gfc_match_omp_depobj): Match 'omp depobj'.
* openmp.c (gfc_match_omp_clauses): Add depobj + mutexinoutset
to depend clause.
(gfc_match_omp_depobj, resolve_omp_clauses, gfc_resolve_omp_directive):
Handle 'omp depobj'.
* parse.c (decode_omp_directive, next_statement, gfc_ascii_statement):
Likewise.
* resolve.c (gfc_resolve_code): Likewise.
* st.c (gfc_free_statement): Likewise.
* trans-openmp.c (gfc_trans_omp_clauses): Handle depobj + mutexinoutset
in the depend clause.
(gfc_trans_omp_depobj, gfc_trans_omp_directive): Handle EXEC_OMP_DEPOBJ.
* trans.c (trans_code): Likewise.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/depobj-1.f90: New test.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/depobj-1.f90: New test.
* gfortran.dg/gomp/depobj-2.f90: New test.
gcc/fortran/dump-parse-tree.c | 33
gcc/fortran/gfortran.h | 12 ++-
gcc/fortran/match.h| 1 +
gcc/fortran/openmp.c | 113 +
gcc/fortran/parse.c| 6 +-
gcc/fortran/resolve.c | 1 +
gcc/fortran/st.c | 1 +
gcc/fortran/trans-openmp.c | 68 +++
gcc/fortran/trans.c| 1 +
gcc/testsuite/gfortran.dg/gomp/depobj-1.f90| 25 ++
gcc/testsuite/gfortran.dg/gomp/depobj-2.f90| 33
libgomp/testsuite/libgomp.fortran/depobj-1.f90 | 113 +
12 files changed, 402 insertions(+), 5 deletions(-)
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index 059d8421bb5..b50265ac742 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -1332,6 +1332,10 @@ show_omp_namelist (int list_type, gfc_omp_namelist *n)
case OMP_DEPEND_IN: fputs ("in:", dumpfile); break;
case OMP_DEPEND_OUT: fputs ("out:", dumpfile); break;
case OMP_DEPEND_INOUT: fputs ("inout:", dumpfile); break;
+ case OMP_DEPEND_DEPOBJ: fputs ("depobj:", dumpfile); break;
+ case OMP_DEPEND_MUTEXINOUTSET:
+ fputs ("mutexinoutset:", dumpfile);
+ break;
case OMP_DEPEND_SINK_FIRST:
fputs ("sink:", dumpfile);
while (1)
@@ -1754,10 +1758,27 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
show_expr (omp_clauses->if_exprs[i]);
fputc (')', dumpfile);
}
+ if (omp_clauses->destroy)
+fputs (" DESTROY", dumpfile);
if (omp_clauses->depend_source)
fputs (" DEPEND(source)", dumpfile);
if (omp_clauses->capture)
fputs (" CAPTURE", dumpfile);
+ if (omp_clauses->depobj_update != OMP_DEPEND_UNSET)
+{
+ const char *deptype;
+ fputs (" UPDATE(", dumpfile);
+ switch (omp_clauses->depobj_update)
+ {
+ case OMP_DEPEND_IN: deptype = "IN"; break;
+ case OMP_DEPEND_OUT: deptype = "OUT"; break;
+ case OMP_DEPEND_INOUT: deptype = "INOUT"; break;
+ case OMP_DEPEND_MUTEXINOUTSET: deptype = "MUTEXINOUTSET"; break;
+ default: gcc_unreachable ();
+ }
+ fputs (deptype, dumpfile
static libgfortran linker warnings
When linking with -static-libgfortran, I get warnings from ld of the form "ld: warning: -z ignore ignored" and "ld: warning: -z record ignored". I can't find those -z options documented anywhere. Why is gfortran adding them?
