assumed size
Hi all, I am working paper for the following syntax extension int a[10]; int (*a)[*] = &a; This would not be a wide pointer, it will just initialize the size of the type from the initializer. This would also work for VM type. So the result is a conventional pointer to an arrays and either a regular or a variably modified type. I am not so sure how to best integrate it. Maybe we could just say the type becomes the composite type. Martin
[PATCH 13/14] OpenACC: Allow implicit uses of assumed-size arrays in offload regions
This patch reimplements the functionality of the previously-reverted
patch "Assumed-size arrays with non-lexical data mappings". The purpose
is to support implicit uses of assumed-size arrays for Fortran when those
arrays have already been mapped on the target some other way (e.g. by
"acc enter data").
This relates to upstream OpenACC issue 489 (not yet resolved).
2023-06-16 Julian Brown
gcc/fortran/
* trans-openmp.cc (gfc_omp_finish_clause): Treat implicitly-mapped
assumed-size arrays as zero-sized for OpenACC, rather than an error.
gcc/testsuite/
* gfortran.dg/goacc/assumed-size.f90: Don't expect error.
libgomp/
* testsuite/libgomp.oacc-fortran/nonlexical-assumed-size-1.f90: New
test.
* testsuite/libgomp.oacc-fortran/nonlexical-assumed-size-2.f90: New
test.
---
gcc/fortran/trans-openmp.cc | 16 ++--
.../gfortran.dg/goacc/assumed-size.f90 | 4 +-
.../nonlexical-assumed-size-1.f90 | 28 +++++
.../nonlexical-assumed-size-2.f90 | 40 +++
4 files changed, 82 insertions(+), 6 deletions(-)
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/nonlexical-assumed-size-1.f90
create mode 100644
libgomp/testsuite/libgomp.oacc-fortran/nonlexical-assumed-size-2.f90
diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index 819d79cda28..230cebf250b 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -1587,6 +1587,7 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p, bool
openacc)
return;
tree decl = OMP_CLAUSE_DECL (c);
+ bool assumed_size = false;
/* Assumed-size arrays can't be mapped implicitly, they have to be
mapped explicitly using array sections. */
@@ -1597,9 +1598,14 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p, bool
openacc)
GFC_TYPE_ARRAY_RANK (TREE_TYPE (decl)) - 1)
== NULL)
{
- error_at (OMP_CLAUSE_LOCATION (c),
- "implicit mapping of assumed size array %qD", decl);
- return;
+ if (openacc)
+ assumed_size = true;
+ else
+ {
+ error_at (OMP_CLAUSE_LOCATION (c),
+ "implicit mapping of assumed size array %qD", decl);
+ return;
+ }
}
if (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FORCE_DEVICEPTR)
@@ -1654,7 +1660,9 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p, bool
openacc)
else
{
OMP_CLAUSE_DECL (c) = decl;
- OMP_CLAUSE_SIZE (c) = NULL_TREE;
+ OMP_CLAUSE_SIZE (c) = assumed_size ? size_zero_node : NULL_TREE;
+ if (assumed_size)
+ OMP_CLAUSE_MAP_MAYBE_ZERO_LENGTH_ARRAY_SECTION (c) = 1;
}
if (TREE_CODE (TREE_TYPE (orig_decl)) == REFERENCE_TYPE
&& (GFC_DECL_GET_SCALAR_POINTER (orig_decl)
diff --git a/gcc/testsuite/gfortran.dg/goacc/assumed-size.f90
b/gcc/testsuite/gfortran.dg/goacc/assumed-size.f90
index 4fced2e70c9..12f44c4743a 100644
--- a/gcc/testsuite/gfortran.dg/goacc/assumed-size.f90
+++ b/gcc/testsuite/gfortran.dg/goacc/assumed-size.f90
@@ -4,7 +4,8 @@
! exit data, respectively.
! This does not appear to be supported by the OpenACC standard as of version
-! 3.0. Check for an appropriate error message.
+! 3.0. There is however real-world code that relies on this working, so we
+! make an attempt to support it.
program test
implicit none
@@ -26,7 +27,6 @@ subroutine dtest (a, n)
!$acc enter data copyin(a(1:n))
!$acc parallel loop
-! { dg-error {implicit mapping of assumed size array 'a'} "" { target *-*-* }
.-1 }
do i = 1, n
a(i) = i
end do
diff --git
a/libgomp/testsuite/libgomp.oacc-fortran/nonlexical-assumed-size-1.f90
b/libgomp/testsuite/libgomp.oacc-fortran/nonlexical-assumed-size-1.f90
new file mode 100644
index 000..4b61e1cee9b
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/nonlexical-assumed-size-1.f90
@@ -0,0 +1,28 @@
+! { dg-do run }
+
+program p
+implicit none
+integer :: myarr(10)
+
+myarr = 0
+
+call subr(myarr)
+
+if (myarr(5).ne.5) stop 1
+
+contains
+
+subroutine subr(arr)
+implicit none
+integer :: arr(*)
+
+!$acc enter data copyin(arr(1:10))
+
+!$acc serial
+arr(5) = 5
+!$acc end serial
+
+!$acc exit data copyout(arr(1:10))
+
+end subroutine subr
+end program p
diff --git
a/libgomp/testsuite/libgomp.oacc-fortran/nonlexical-assumed-size-2.f90
b/libgomp/testsuite/libgomp.oacc-fortran/nonlexical-assumed-size-2.f90
new file mode 100644
index 000..daf7089915f
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-fortran/nonlexical-assumed-size-2.f90
@@ -0,0 +1,40 @@
+! { dg-do run }
+
+program p
+implicit none
+integer :: myarr(10)
+
+myarr = 0
+
+call subr(myarr)
+
+if (myarr(5).ne.5) stop 1
+
+contains
+
+subroutine subr(arr)
+implicit none
+integer :: arr(*)
+
+! At first glance, it might not be obvious ho
[PATCH 01/14] Revert "Assumed-size arrays with non-lexical data mappings"
This reverts commit 72733f6e6f6ec1bb9884fea8bfbebd3de03d9374.
2023-06-16 Julian Brown
gcc/
Revert:
* gimplify.cc (gimplify_adjust_omp_clauses_1): Raise error for
assumed-size arrays in map clauses for Fortran/OpenMP.
* omp-low.cc (lower_omp_target): Set the size of assumed-size Fortran
arrays to one to allow use of data already mapped on the offload device.
gcc/fortran/
Revert:
* trans-openmp.cc (gfc_omp_finish_clause): Change clauses mapping
assumed-size arrays to use the GOMP_MAP_FORCE_PRESENT map type.
---
gcc/fortran/trans-openmp.cc | 22 +-
gcc/gimplify.cc | 14 --
gcc/omp-low.cc | 5 -
3 files changed, 9 insertions(+), 32 deletions(-)
diff --git a/gcc/fortran/trans-openmp.cc b/gcc/fortran/trans-openmp.cc
index e8f3b24e5f8..e55c8292d05 100644
--- a/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -1588,18 +1588,10 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p, bool
openacc)
tree decl = OMP_CLAUSE_DECL (c);
/* Assumed-size arrays can't be mapped implicitly, they have to be mapped
- explicitly using array sections. For OpenACC this restriction is lifted
- if the array has already been mapped:
-
- - Using a lexically-enclosing data region: in that case we see the
- GOMP_MAP_FORCE_PRESENT mapping kind here.
-
- - Using a non-lexical data mapping ("acc enter data").
-
- In the latter case we change the mapping type to GOMP_MAP_FORCE_PRESENT.
- This raises an error for OpenMP in the caller
- (gimplify.c:gimplify_adjust_omp_clauses_1). OpenACC will raise a runtime
- error if the implicitly-referenced assumed-size array is not mapped. */
+ explicitly using array sections. An exception is if the array is
+ mapped explicitly in an enclosing data construct for OpenACC, in which
+ case we see GOMP_MAP_FORCE_PRESENT here and do not need to raise an
+ error. */
if (OMP_CLAUSE_MAP_KIND (c) != GOMP_MAP_FORCE_PRESENT
&& TREE_CODE (decl) == PARM_DECL
&& GFC_ARRAY_TYPE_P (TREE_TYPE (decl))
@@ -1607,7 +1599,11 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p, bool
openacc)
&& GFC_TYPE_ARRAY_UBOUND (TREE_TYPE (decl),
GFC_TYPE_ARRAY_RANK (TREE_TYPE (decl)) - 1)
== NULL)
-OMP_CLAUSE_SET_MAP_KIND (c, GOMP_MAP_FORCE_PRESENT);
+{
+ error_at (OMP_CLAUSE_LOCATION (c),
+ "implicit mapping of assumed size array %qD", decl);
+ return;
+}
if (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FORCE_DEVICEPTR)
return;
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 09c596f026e..3729b986801 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -12828,26 +12828,12 @@ gimplify_adjust_omp_clauses_1 (splay_tree_node n,
void *data)
*list_p = clause;
struct gimplify_omp_ctx *ctx = gimplify_omp_ctxp;
gimplify_omp_ctxp = ctx->outer_context;
- gomp_map_kind kind = (code == OMP_CLAUSE_MAP) ? OMP_CLAUSE_MAP_KIND (clause)
- : (gomp_map_kind) GOMP_MAP_LAST;
/* Don't call omp_finish_clause on implicitly added OMP_CLAUSE_PRIVATE
in simd. Those are only added for the local vars inside of simd body
and they don't need to be e.g. default constructible. */
if (code != OMP_CLAUSE_PRIVATE || ctx->region_type != ORT_SIMD)
lang_hooks.decls.omp_finish_clause (clause, pre_p,
(ctx->region_type & ORT_ACC) != 0);
- /* Allow OpenACC to have implicit assumed-size arrays via FORCE_PRESENT,
- which should work as long as the array has previously been mapped
- explicitly on the target (e.g. by "enter data"). Raise an error for
- OpenMP. */
- if (lang_GNU_Fortran ()
- && code == OMP_CLAUSE_MAP
- && (ctx->region_type & ORT_ACC) == 0
- && kind == GOMP_MAP_TOFROM
- && OMP_CLAUSE_MAP_KIND (clause) == GOMP_MAP_FORCE_PRESENT)
-error_at (OMP_CLAUSE_LOCATION (clause),
- "implicit mapping of assumed size array %qD",
- OMP_CLAUSE_DECL (clause));
if (gimplify_omp_ctxp)
for (; clause != chain; clause = OMP_CLAUSE_CHAIN (clause))
if (OMP_CLAUSE_CODE (clause) == OMP_CLAUSE_MAP
diff --git a/gcc/omp-low.cc b/gcc/omp-low.cc
index 3424eba2217..59143d8efe5 100644
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -14353,11 +14353,6 @@ lower_omp_target (gimple_stmt_iterator *gsi_p,
omp_context *ctx)
s = OMP_CLAUSE_SIZE (c);
if (s == NULL_TREE)
s = TYPE_SIZE_UNIT (TREE_TYPE (ovar));
- /* Fortran assumed-size arrays have zero size because the type is
- incomplete. Set the size to one to allow the runtime to remap
- any existing data that is already p
Re: [PATCH] Fortran: rank checking with explicit-/assumed-size arrays and CLASS [PR58331]
Hi Tobias, Am 15.03.23 um 10:10 schrieb Tobias Burnus: Hi Harald, On 14.03.23 20:38, Harald Anlauf wrote: The testcase covers only non-coarray cases, as playing with coarray variants hit pre-exisiting issues in gfortran that are very likely unrelated to the interface checks. I concur (but would not rule out additional interface issues). More testing seems to mostly uncover issues later on in trans*.cc, e.g. when passing type to class. I'll open a PR on this as a followup. I consider this rather as post 13-release stuff. In any case, the coarray issue can be fixed separately. And I think post-GCC-13 makes sense. Good. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks – LGTM! + formal_as = formal->ts.type == BT_CLASS ? CLASS_DATA (formal)->as + : formal->as; + (Jakub remarks for such code that some editor (emacs?), he does not use, mis--auto-indent such a code - and proposes to add a parentheses around the right-hand side of the assignment.) Ah, adding parentheses helps! I've reformatted this block accordingly. Pushed as: https://gcc.gnu.org/g:901edd99b44976b3c2b13a7d525d9e315540186a * * * I also wonder whether we need some run-time testcase. The interface check now works and I also tend to write dg-do-compile testcases, but given what can go wrong with all the array descriptor, class etc handling, we may want to ensure it works at run time. – Thoughts? If you comment out the lines with dg-error, the code compiles and seems to run fine here. I've even found cases where passing array sections works correctly here and with current Intel it does not ;-) I'd prefer to postpone more elaborate run-time tests until we have more non-ICEing related code. Thanks, Harald (That's independent of the patch it and could be done as follow up, if it deemed reasonable. The included testcase is surely compile-only as it has dg-error checks.) 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
Re: [PATCH] Fortran: rank checking with explicit-/assumed-size arrays and CLASS [PR58331]
Hi Harald, On 14.03.23 20:38, Harald Anlauf wrote: The testcase covers only non-coarray cases, as playing with coarray variants hit pre-exisiting issues in gfortran that are very likely unrelated to the interface checks. I concur (but would not rule out additional interface issues). I consider this rather as post 13-release stuff. In any case, the coarray issue can be fixed separately. And I think post-GCC-13 makes sense. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks – LGTM! + formal_as = formal->ts.type == BT_CLASS ? CLASS_DATA (formal)->as + : formal->as; + (Jakub remarks for such code that some editor (emacs?), he does not use, mis--auto-indent such a code - and proposes to add a parentheses around the right-hand side of the assignment.) * * * I also wonder whether we need some run-time testcase. The interface check now works and I also tend to write dg-do-compile testcases, but given what can go wrong with all the array descriptor, class etc handling, we may want to ensure it works at run time. – Thoughts? (That's independent of the patch it and could be done as follow up, if it deemed reasonable. The included testcase is surely compile-only as it has dg-error checks.) 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
[PATCH] Fortran: rank checking with explicit-/assumed-size arrays and CLASS [PR58331]
Dear all,
the attached patch, which is based on a draft by Tobias, fixes
an old rejects-valid issue with rank checking for CLASS arrays
by using the proper array spec of CLASS variables.
The testcase covers only non-coarray cases, as playing with
coarray variants hit pre-exisiting issues in gfortran that
are very likely unrelated to the interface checks. I consider
this rather as post 13-release stuff.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 4453686ae4e70c14a0898c6687db912fa84ece9f Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 14 Mar 2023 20:23:06 +0100
Subject: [PATCH] Fortran: rank checking with explicit-/assumed-size arrays and
CLASS [PR58331]
gcc/fortran/ChangeLog:
PR fortran/58331
* interface.cc (compare_parameter): Adjust check of array dummy
arguments to handle the case of CLASS variables.
gcc/testsuite/ChangeLog:
PR fortran/58331
* gfortran.dg/class_dummy_10.f90: New test.
Co-authored-by: Tobias Burnus
---
gcc/fortran/interface.cc | 27 +++---
gcc/testsuite/gfortran.dg/class_dummy_10.f90 | 56
2 files changed, 76 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/class_dummy_10.f90
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index dafe41753b7..1d0f8bb5915 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -2349,6 +2349,7 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
char err[200];
gfc_component *ppc;
bool codimension = false;
+ gfc_array_spec *formal_as;
/* If the formal arg has type BT_VOID, it's to one of the iso_c_binding
procs c_f_pointer or c_f_procpointer, and we need to accept most
@@ -2540,6 +2541,9 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
return false;
}
+ formal_as = formal->ts.type == BT_CLASS ? CLASS_DATA (formal)->as
+ : formal->as;
+
if (codimension && formal->attr.allocatable)
{
gfc_ref *last = NULL;
@@ -2650,10 +2654,10 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
if (symbol_rank (formal) == actual->rank || symbol_rank (formal) == -1)
return true;
- rank_check = where != NULL && !is_elemental && formal->as
- && (formal->as->type == AS_ASSUMED_SHAPE
- || formal->as->type == AS_DEFERRED)
- && actual->expr_type != EXPR_NULL;
+ rank_check = where != NULL && !is_elemental && formal_as
+&& (formal_as->type == AS_ASSUMED_SHAPE
+ || formal_as->type == AS_DEFERRED)
+&& actual->expr_type != EXPR_NULL;
/* Skip rank checks for NO_ARG_CHECK. */
if (formal->attr.ext_attr & (1 << EXT_ATTR_NO_ARG_CHECK))
@@ -2662,14 +2666,20 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
/* Scalar & coindexed, see: F2008, Section 12.5.2.4. */
if (rank_check || ranks_must_agree
|| (formal->attr.pointer && actual->expr_type != EXPR_NULL)
- || (actual->rank != 0 && !(is_elemental || formal->attr.dimension))
+ || (actual->rank != 0
+ && !(is_elemental || formal->attr.dimension
+ || (formal->ts.type == BT_CLASS
+ && CLASS_DATA (formal)->attr.dimension)))
|| (actual->rank == 0
&& ((formal->ts.type == BT_CLASS
&& CLASS_DATA (formal)->as->type == AS_ASSUMED_SHAPE)
|| (formal->ts.type != BT_CLASS
&& formal->as->type == AS_ASSUMED_SHAPE))
&& actual->expr_type != EXPR_NULL)
- || (actual->rank == 0 && formal->attr.dimension
+ || (actual->rank == 0
+ && (formal->attr.dimension
+ || (formal->ts.type == BT_CLASS
+ && CLASS_DATA (formal)->attr.dimension))
&& gfc_is_coindexed (actual))
/* Assumed-rank actual argument; F2018 C838. */
|| actual->rank == -1)
@@ -2690,7 +2700,10 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
}
return false;
}
- else if (actual->rank != 0 && (is_elemental || formal->attr.dimension))
+ else if (actual->rank != 0
+ && (is_elemental || formal->attr.dimension
+ || (formal->ts.type == BT_CLASS
+ && CLASS_DATA (formal)->attr.dimension)))
return true;
/* At this point, we are considering a scalar passed to an array. This
diff --git a/gcc/testsuite/gfortran.dg/class_dummy_10.f90 b/gcc/testsuite/gfortran.dg/class_dummy_10.f90
new file mode 100644
index 000..cee5d4d82b2
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_dummy_10.f90
@@ -0,0 +1,56 @@
+! { dg-do compile }
+! PR fortran/58331 - rank checking for CLASS dummy arguments
+
+module mymod
+ implicit none
+contains
+ subroutine mysub(a, n)
+integer, intent(in) :: n
+class(*), intent(in) :: a(n)
Re: [PATCH, committed] Fortran: error recovery on invalid assumed size reference [PR104554]
On Wed, Feb 15, 2023 at 10:28:00PM +0100, Harald Anlauf via Fortran wrote: > Dear all, > > I've committed the attached obvious and trivial patch for a NULL > pointer dereference on behalf of Steve and after regtesting on > x86_64-pc-linux-gnu as r13-6066-ga418129273725fd02e881e6fb5e0877287a1356c > Thanks Harald! -- Steve
[PATCH, committed] Fortran: error recovery on invalid assumed size reference [PR104554]
Dear all,
I've committed the attached obvious and trivial patch for a NULL
pointer dereference on behalf of Steve and after regtesting on
x86_64-pc-linux-gnu as r13-6066-ga418129273725fd02e881e6fb5e0877287a1356c
Thanks,
Harald
From a418129273725fd02e881e6fb5e0877287a1356c Mon Sep 17 00:00:00 2001
From: Steve Kargl
Date: Wed, 15 Feb 2023 22:20:22 +0100
Subject: [PATCH] Fortran: error recovery on invalid assumed size reference
[PR104554]
gcc/fortran/ChangeLog:
PR fortran/104554
* resolve.cc (check_assumed_size_reference): Avoid NULL pointer
dereference.
gcc/testsuite/ChangeLog:
PR fortran/104554
* gfortran.dg/pr104554.f90: New test.
---
gcc/fortran/resolve.cc | 8 +---
gcc/testsuite/gfortran.dg/pr104554.f90 | 11 +++
2 files changed, 16 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr104554.f90
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 96c34065691..fb0745927ac 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -1670,9 +1670,11 @@ check_assumed_size_reference (gfc_symbol *sym, gfc_expr *e)
/* FIXME: The comparison "e->ref->u.ar.type == AR_FULL" is wrong.
What should it be? */
- if (e->ref && (e->ref->u.ar.end[e->ref->u.ar.as->rank - 1] == NULL)
- && (e->ref->u.ar.as->type == AS_ASSUMED_SIZE)
- && (e->ref->u.ar.type == AR_FULL))
+ if (e->ref
+ && e->ref->u.ar.as
+ && (e->ref->u.ar.end[e->ref->u.ar.as->rank - 1] == NULL)
+ && (e->ref->u.ar.as->type == AS_ASSUMED_SIZE)
+ && (e->ref->u.ar.type == AR_FULL))
{
gfc_error ("The upper bound in the last dimension must "
"appear in the reference to the assumed size "
diff --git a/gcc/testsuite/gfortran.dg/pr104554.f90 b/gcc/testsuite/gfortran.dg/pr104554.f90
new file mode 100644
index 000..099f219c85d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr104554.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR fortran/104554 - ICE in check_assumed_size_reference
+! Contributed by G.Steinmetz
+
+program p
+ type t
+ integer :: a
+ end type
+ class(t) :: x(*) ! { dg-error "Assumed size array" }
+ x%a = 3
+end
--
2.35.3
Re: [PATCH] Fortran: improve checking of assumed size array spec [PR102180]
On Mon, Dec 12, 2022 at 08:49:50PM +0100, Harald Anlauf via Fortran wrote:
>
> Committed as r13-4623-gcf5327b89ab610.
>
To be clear, I have no problems with this commit.
But, just a FYI, there is gfc_peek_ascii_char(),
which allows you to look at the next character
without having to keep track of the locus.
> +{
> + locus old_loc = gfc_current_locus;
> + if (gfc_match_char ('*') == MATCH_YES)
gfc_gobble_whitespace (); /* Can't remember if matching up to this
eats whitespace. */
if (gfc_peek_ascii_char () == '*')
> + {
> + /* F2018:R821: "assumed-implied-spec is [ lower-bound : ] *". */
> + gfc_error ("A lower bound must precede colon in "
> + "assumed-size array specification at %L", &old_loc);
> + return AS_UNKNOWN;
> + }
> + else
> + {
gfc_current_locus = old_loc; /* Is this needed? */
> + return AS_DEFERRED;
> + }
> +}
--
Steve
Re: [PATCH] Fortran: improve checking of assumed size array spec [PR102180]
Hi Steve,
Am 12.12.22 um 00:52 schrieb Steve Kargl via Gcc-patches:
On Sun, Dec 11, 2022 at 11:33:43PM +0100, Harald Anlauf via Fortran wrote:
Dear all,
the attached patch improves checking of array specs in two ways:
- bad assumed size array spec
- a bad first array element spec may already trigger an error,
leading to a more consistent behavior
Regtested on x86_64-pc-linux-gnu. OK for mainline?
OK with minor nit.
+ /* F2018:R821: "assumed-implied-spec is [ lower-bound : ] *". */
+ if (gfc_match (" : * ") == MATCH_YES)
+{
+ gfc_error ("A lower bound must precede colon in "
+"assumed size array specification at %C");
"assumed size" should likely be "assumed-size"
good point, I've fixed that.
I was a bit unhappy with the previously submitted patch,
as it tried to match ':' twice and gave an unfortunate locus
in the error message. I now chose to combine the adjacent
matches and to remember a more suitable locus for use with
the emitted error, see attached updated patch.
Committed as r13-4623-gcf5327b89ab610.
Thanks,
Harald
+ return AS_UNKNOWN;
+}
+
From cf5327b89ab610649c5faab78ea7907bb74b103c Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 11 Dec 2022 23:24:03 +0100
Subject: [PATCH] Fortran: improve checking of assumed-size array spec
[PR102180]
gcc/fortran/ChangeLog:
PR fortran/102180
* array.cc (match_array_element_spec): Add check for bad
assumed-implied-spec.
(gfc_match_array_spec): Reorder logic so that the first bad array
element spec may trigger an error.
gcc/testsuite/ChangeLog:
PR fortran/102180
* gfortran.dg/pr102180.f90: New test.
---
gcc/fortran/array.cc | 19 ---
gcc/testsuite/gfortran.dg/pr102180.f90 | 19 +++
2 files changed, 35 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr102180.f90
diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index bbdb5b392fc..10d9e0c5354 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -489,7 +489,20 @@ match_array_element_spec (gfc_array_spec *as)
}
if (gfc_match_char (':') == MATCH_YES)
-return AS_DEFERRED;
+{
+ locus old_loc = gfc_current_locus;
+ if (gfc_match_char ('*') == MATCH_YES)
+ {
+ /* F2018:R821: "assumed-implied-spec is [ lower-bound : ] *". */
+ gfc_error ("A lower bound must precede colon in "
+ "assumed-size array specification at %L", &old_loc);
+ return AS_UNKNOWN;
+ }
+ else
+ {
+ return AS_DEFERRED;
+ }
+}
m = gfc_match_expr (upper);
if (m == MATCH_NO)
@@ -591,6 +604,8 @@ gfc_match_array_spec (gfc_array_spec **asp, bool match_dim, bool match_codim)
{
as->rank++;
current_type = match_array_element_spec (as);
+ if (current_type == AS_UNKNOWN)
+ goto cleanup;
/* Note that current_type == AS_ASSUMED_SIZE for both assumed-size
and implied-shape specifications. If the rank is at least 2, we can
@@ -600,8 +615,6 @@ gfc_match_array_spec (gfc_array_spec **asp, bool match_dim, bool match_codim)
if (as->rank == 1)
{
- if (current_type == AS_UNKNOWN)
- goto cleanup;
as->type = current_type;
}
else
diff --git a/gcc/testsuite/gfortran.dg/pr102180.f90 b/gcc/testsuite/gfortran.dg/pr102180.f90
new file mode 100644
index 000..cbf3e7299e7
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr102180.f90
@@ -0,0 +1,19 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib" }
+! PR fortran/102180 - Improve checking of assumed size array spec
+
+subroutine s(x,y)
+ real :: x(0:*) ! legal
+ real :: y[0:*] ! legal
+end
+
+subroutine t(x,y)
+ real :: x(:*) ! { dg-error "A lower bound must precede colon" }
+ real :: y[:*] ! { dg-error "A lower bound must precede colon" }
+end
+
+subroutine u(x,y,z)
+ real :: x(2,*)
+ real :: y(2,2:*)
+ real :: z(2,:*) ! { dg-error "A lower bound must precede colon" }
+end
--
2.35.3
Re: [PATCH] Fortran: improve checking of assumed size array spec [PR102180]
On Sun, Dec 11, 2022 at 11:33:43PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> the attached patch improves checking of array specs in two ways:
> - bad assumed size array spec
> - a bad first array element spec may already trigger an error,
> leading to a more consistent behavior
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
OK with minor nit.
> + /* F2018:R821: "assumed-implied-spec is [ lower-bound : ] *". */
> + if (gfc_match (" : * ") == MATCH_YES)
> +{
> + gfc_error ("A lower bound must precede colon in "
> + "assumed size array specification at %C");
"assumed size" should likely be "assumed-size"
> + return AS_UNKNOWN;
> +}
> +
--
Steve
[PATCH] Fortran: improve checking of assumed size array spec [PR102180]
Dear all,
the attached patch improves checking of array specs in two ways:
- bad assumed size array spec
- a bad first array element spec may already trigger an error,
leading to a more consistent behavior
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 06c1d0a96544640c7b1485fe977337ef1572ac91 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 11 Dec 2022 23:24:03 +0100
Subject: [PATCH] Fortran: improve checking of assumed size array spec
[PR102180]
gcc/fortran/ChangeLog:
PR fortran/102180
* array.cc (match_array_element_spec): Add check for bad
assumed-implied-spec.
(gfc_match_array_spec): Reorder logic so that a first bad array
element spec may trigger an error.
gcc/testsuite/ChangeLog:
PR fortran/102180
* gfortran.dg/pr102180.f90: New test.
---
gcc/fortran/array.cc | 12 ++--
gcc/testsuite/gfortran.dg/pr102180.f90 | 19 +++
2 files changed, 29 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr102180.f90
diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index bbdb5b392fc..9c1d55fa8cc 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -488,6 +488,14 @@ match_array_element_spec (gfc_array_spec *as)
return AS_ASSUMED_SIZE;
}
+ /* F2018:R821: "assumed-implied-spec is [ lower-bound : ] *". */
+ if (gfc_match (" : * ") == MATCH_YES)
+{
+ gfc_error ("A lower bound must precede colon in "
+ "assumed size array specification at %C");
+ return AS_UNKNOWN;
+}
+
if (gfc_match_char (':') == MATCH_YES)
return AS_DEFERRED;
@@ -591,6 +599,8 @@ gfc_match_array_spec (gfc_array_spec **asp, bool match_dim, bool match_codim)
{
as->rank++;
current_type = match_array_element_spec (as);
+ if (current_type == AS_UNKNOWN)
+ goto cleanup;
/* Note that current_type == AS_ASSUMED_SIZE for both assumed-size
and implied-shape specifications. If the rank is at least 2, we can
@@ -600,8 +610,6 @@ gfc_match_array_spec (gfc_array_spec **asp, bool match_dim, bool match_codim)
if (as->rank == 1)
{
- if (current_type == AS_UNKNOWN)
- goto cleanup;
as->type = current_type;
}
else
diff --git a/gcc/testsuite/gfortran.dg/pr102180.f90 b/gcc/testsuite/gfortran.dg/pr102180.f90
new file mode 100644
index 000..cbf3e7299e7
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr102180.f90
@@ -0,0 +1,19 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib" }
+! PR fortran/102180 - Improve checking of assumed size array spec
+
+subroutine s(x,y)
+ real :: x(0:*) ! legal
+ real :: y[0:*] ! legal
+end
+
+subroutine t(x,y)
+ real :: x(:*) ! { dg-error "A lower bound must precede colon" }
+ real :: y[:*] ! { dg-error "A lower bound must precede colon" }
+end
+
+subroutine u(x,y,z)
+ real :: x(2,*)
+ real :: y(2,2:*)
+ real :: z(2,:*) ! { dg-error "A lower bound must precede colon" }
+end
--
2.35.3
Re: [Patch] OpenMP/Fortran: Permit assumed-size arrays in uniform clause
On Fri, Jul 29, 2022 at 11:47:54AM +0200, Tobias Burnus wrote: > Testcase wise, the run-time testcase libgomp.fortran/examples-4/simd-2.f90 > checks essentially the same, except that it uses an array-descriptor array > (assumed shape) while this testcase uses an assumed-size array. > > I decided for an extra compile-time only testcase, but it could be also be > moved to libgomp as run-time test or the other test could be extended to > also test assumed-size arrays. > > The OpenMP examples document contains two testcases which now pass, > but are reject without this patch: > - SIMD/sources/SIMD.2.f90 (for OpenMP 4.0) > - SIMD/sources/linear_modifier.3.f90 (for OpenMP 5.2) > > OK for mainline? Ok, thanks. Jakub
[Patch] OpenMP/Fortran: Permit assumed-size arrays in uniform clause
Testcase wise, the run-time testcase libgomp.fortran/examples-4/simd-2.f90
checks essentially the same, except that it uses an array-descriptor array
(assumed shape) while this testcase uses an assumed-size array.
I decided for an extra compile-time only testcase, but it could be also be
moved to libgomp as run-time test or the other test could be extended to
also test assumed-size arrays.
The OpenMP examples document contains two testcases which now pass,
but are reject without this patch:
- SIMD/sources/SIMD.2.f90 (for OpenMP 4.0)
- SIMD/sources/linear_modifier.3.f90 (for OpenMP 5.2)
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
OpenMP/Fortran: Permit assumed-size arrays in uniform clause
gcc/fortran/ChangeLog:
* openmp.cc (resolve_omp_clauses): Permit assumed-size arrays
in uniform clause.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/declare-simd-3.f90: New test.
gcc/fortran/openmp.cc | 3 ++-
gcc/testsuite/gfortran.dg/gomp/declare-simd-3.f90 | 30 +++
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index df9cdf43eb7..a7eb6c3e8f4 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -7386,7 +7386,8 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses *omp_clauses,
|| code->op == EXEC_OACC_PARALLEL
|| code->op == EXEC_OACC_SERIAL))
check_array_not_assumed (n->sym, n->where, name);
- else if (n->sym->as && n->sym->as->type == AS_ASSUMED_SIZE)
+ else if (list != OMP_LIST_UNIFORM
+ && n->sym->as && n->sym->as->type == AS_ASSUMED_SIZE)
gfc_error ("Assumed size array %qs in %s clause at %L",
n->sym->name, name, &n->where);
if (n->sym->attr.in_namelist && !is_reduction)
diff --git a/gcc/testsuite/gfortran.dg/gomp/declare-simd-3.f90 b/gcc/testsuite/gfortran.dg/gomp/declare-simd-3.f90
new file mode 100644
index 000..b94587ef35a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/declare-simd-3.f90
@@ -0,0 +1,30 @@
+! { dg-do compile }
+
+module m
+ implicit none (type, external)
+contains
+ real function add(x, y, j) result(res)
+!$omp declare simd(add) uniform(x, y) linear(j : 1) simdlen(4)
+integer, value :: j
+real, intent(in) :: x(*), y(*)
+res = x(j) + y(j)
+ end function
+end module m
+
+program main
+ use m
+ implicit none (type, external)
+ real, allocatable :: A(:), B(:), C(:)
+ integer :: i, N
+ N = 128
+ A = [(3*i, i = 1, N)]
+ B = [(7*i, i = 1, N)]
+ allocate (C(N))
+
+ !$omp simd
+ do i = 1, N
+C(i) = add(A, B, i)
+ end do
+
+ if (any (C /= [(10*i, i = 1, N)])) error stop
+end program main
Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]
Hi Tobias, let me first reach for my brown bag... > Otherwise, the quote from F2018 of my previous email applies: > > F2018:16.9.109 LBOUND has for "case(i)", i.e. with a 'dim' > argument the following. The case without 'dim' just iterates > through case (i) for each dim. Thus: > > "If DIM is present, > ARRAY is a whole array, > and either ARRAY is an assumed-size array of rank DIM > or dimension DIM of ARRAY has nonzero extent, > the result has a value equal to the lower bound for subscript DIM of ARRAY. > Otherwise, if DIM is present, the result value is 1." It was probably too late, and I could no longer distinguish "assumed-size" from "assumed-rank", and likely some more... > Here, we assume dim=2 is present [either directly or via case(ii)], > ARRAY is a whole array but it neither is of assumed size nor has nonzero > extent. > Hence, the "otherwise" applies and the result is 1 - as gfortran has > and ifort has in the caller. ... which lead to my complete confusion and loss of focus. Of course you are right. Sorry for that. Will now put that bag on... Harald
Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]
Hi!
On 2021-09-27T14:07:53+0200, Tobias Burnus wrote:
> now committed r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0
> Conclusion: Reviews are very helpful :-)
Ha! :-) (... and I wasn't even involed here!) ;-P
As testing showed here:
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/assumed_rank_22_aux.c
> @@ -0,0 +1,68 @@
> +/* Called by assumed_rank_22.f90. */
> + if (num == 0)
> +assert (x->dim[2].extent == -1);
> + else if (num == 20)
> +assert (x->dim[2].extent == 1);
> + else if (num == 40)
> +{
> + /* FIXME: - dg-output = 'c_assumed ... OK' checked in .f90 file. */
> + /* assert (x->dim[2].extent == 0); */
> + if (x->dim[2].extent == 0)
> + __builtin_printf ("c_assumed - 40 - OK\n");
> + else
> + __builtin_printf ("ERROR: c_assumed num=%d: "
> + "x->dim[2].extent = %d != 0\n",
> + num, x->dim[2].extent);
> +}
> + else if (num == 60)
> +assert (x->dim[2].extent == 2);
> + else if (num == 80)
> +assert (x->dim[2].extent == 2);
> + else if (num == 100)
> +{
> + /* FIXME: - dg-output = 'c_assumed ... OK' checked in .f90 file. */
> + /* assert (x->dim[2].extent == 0); */
> + if (x->dim[2].extent == 0)
> + __builtin_printf ("c_assumed - 100 - OK\n");
> + else
> + __builtin_printf ("ERROR: c_assumed num=%d: "
> + "x->dim[2].extent = %d != 0\n",
> + num, x->dim[2].extent);
> +}
> + else
> +assert (0);
... the 'ERROR:' prefixes printed do confuse DejaGnu... As obvious,
pushed to master branch commit 95540a6d1d7b29cdd3ed06fbcb07465804504cfd
"'gfortran.dg/assumed_rank_22_aux.c' messages printed vs. DejaGnu", see
attached.
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 95540a6d1d7b29cdd3ed06fbcb07465804504cfd Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Tue, 28 Sep 2021 09:02:56 +0200
Subject: [PATCH] 'gfortran.dg/assumed_rank_22_aux.c' messages printed vs.
DejaGnu
Print lower-case 'error: [...]' instead of upper-case 'ERROR: [...]', to not
confuse the DejaGnu log processing harness into thinking these are DejaGnu
harness ERRORs:
Running /scratch/tschwing/build2-trusty-cs/gcc/build/submit-big/source-gcc/gcc/testsuite/gfortran.dg/dg.exp ...
+ERROR: c_assumed num=100: x->dim[2].extent = -1 != 0
+ERROR: c_assumed num=100: x->dim[2].extent = -1 != 0
+ERROR: c_assumed num=100: x->dim[2].extent = -1 != 0
+ERROR: c_assumed num=100: x->dim[2].extent = -1 != 0
+ERROR: c_assumed num=100: x->dim[2].extent = -1 != 0
+ERROR: c_assumed num=100: x->dim[2].extent = -1 != 0
[...]
Fix-up for recent commit 00f6de9c69119594f7dad3bd525937c94c8200d0
"Fortran: Fix assumed-size to assumed-rank passing [PR94070]".
gcc/testsuite/
* gfortran.dg/assumed_rank_22_aux.c: Adjust messages printed.
---
gcc/testsuite/gfortran.dg/assumed_rank_22_aux.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/assumed_rank_22_aux.c b/gcc/testsuite/gfortran.dg/assumed_rank_22_aux.c
index 2fbf83d649a..e5fe02135e9 100644
--- a/gcc/testsuite/gfortran.dg/assumed_rank_22_aux.c
+++ b/gcc/testsuite/gfortran.dg/assumed_rank_22_aux.c
@@ -29,7 +29,7 @@ c_assumed (CFI_cdesc_t *x, int num)
if (x->dim[2].extent == 0)
__builtin_printf ("c_assumed - 40 - OK\n");
else
- __builtin_printf ("ERROR: c_assumed num=%d: "
+ __builtin_printf ("error: c_assumed num=%d: "
"x->dim[2].extent = %d != 0\n",
num, x->dim[2].extent);
}
@@ -44,7 +44,7 @@ c_assumed (CFI_cdesc_t *x, int num)
if (x->dim[2].extent == 0)
__builtin_printf ("c_assumed - 100 - OK\n");
else
- __builtin_printf ("ERROR: c_assumed num=%d: "
+ __builtin_printf ("error: c_assumed num=%d: "
"x->dim[2].extent = %d != 0\n",
num, x->dim[2].extent);
}
--
2.33.0
Re: [committed] libgomp.oacc-fortran/privatized-ref-2.f90: Fix dg-note (was: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070])
Hi!
On 2021-09-27T14:38:56+0200, Tobias Burnus wrote:
> On 27.09.21 14:07, Tobias Burnus wrote:
>> now committed r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0
>
> I accidentally changed dg-note to dg-message when updating the expected
> output, as the dump has changed. (Copying seemingly the sorry line
> instead of the dg-note lines as template.)
Strange. ;-P
> Changed back to dg-note & committed as
> r12-3898-gda1f6391b7c255e4e2eea983832120eff4f7d3df.
As shown by offloading testing, a bit more is necessary here; I've
pushed to master branch commit a43ae03a053faad871e6f48099d21e64b8e316cf
'Further test case adjustment re "Fortran: Fix assumed-size to
assumed-rank passing"', see attached.
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 a43ae03a053faad871e6f48099d21e64b8e316cf Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Tue, 28 Sep 2021 08:05:28 +0200
Subject: [PATCH] Further test case adjustment re "Fortran: Fix assumed-size to
assumed-rank passing"
Fix-up for recent commit 00f6de9c69119594f7dad3bd525937c94c8200d0
"Fortran: Fix assumed-size to assumed-rank passing [PR94070]",
and commit da1f6391b7c255e4e2eea983832120eff4f7d3df
"libgomp.oacc-fortran/privatized-ref-2.f90: Fix dg-note".
Due to use of '#if !ACC_MEM_SHARED' conditionals in
'libgomp.oacc-fortran/if-1.f90', 'target { ! openacc_host_selected }'
needs some special care (ignoring the pre-existing mismatch of
'ACC_MEM_SHARED' vs. 'openacc_host_selected').
As seen with GCN offloading, we need to revert to another bit of the
original code in 'libgomp.oacc-fortran/privatized-ref-2.f90'.
libgomp/
* testsuite/libgomp.oacc-fortran/if-1.f90: Adjust.
* testsuite/libgomp.oacc-fortran/privatized-ref-2.f90: Likewise.
---
libgomp/testsuite/libgomp.oacc-fortran/if-1.f90 | 6 ++
libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90 | 3 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/if-1.f90 b/libgomp/testsuite/libgomp.oacc-fortran/if-1.f90
index 3089d6a0c43..9eadfcf9738 100644
--- a/libgomp/testsuite/libgomp.oacc-fortran/if-1.f90
+++ b/libgomp/testsuite/libgomp.oacc-fortran/if-1.f90
@@ -394,6 +394,7 @@ program main
!$acc data copyin (a(1:N)) copyout (b(1:N)) if (0 == 1)
! { dg-note {variable 'D\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target { ! openacc_host_selected } } .-1 }
+ ! { dg-note {variable 'parm\.[0-9]+' declared in block is candidate for adjusting OpenACC privatization level} "" { target { ! openacc_host_selected } } .-2 }
#if !ACC_MEM_SHARED
if (acc_is_present (a) .eqv. .TRUE.) STOP 21
@@ -408,6 +409,7 @@ program main
!$acc data copyin (a(1:N)) if (1 == 1)
! { dg-note {variable 'D\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } .-1 }
! { dg-note {variable 'parm\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } .-2 }
+ ! { dg-note {variable 'parm\.[0-9]+' declared in block is candidate for adjusting OpenACC privatization level} "" { target { ! openacc_host_selected } } .-3 }
#if !ACC_MEM_SHARED
if (acc_is_present (a) .eqv. .FALSE.) STOP 23
@@ -416,6 +418,7 @@ program main
!$acc data copyout (b(1:N)) if (0 == 1)
! { dg-note {variable 'D\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } .-1 }
! { dg-note {variable 'parm\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } .-2 }
+! { dg-note {variable 'parm\.[0-9]+' declared in block is candidate for adjusting OpenACC privatization level} "" { target { ! openacc_host_selected } } .-3 }
#if !ACC_MEM_SHARED
if (acc_is_present (b) .eqv. .TRUE.) STOP 24
#endif
@@ -864,6 +867,7 @@ program main
!$acc data copyin (a(1:N)) copyout (b(1:N)) if (0 == 1)
! { dg-note {variable 'D\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target { ! openacc_host_selected } } .-1 }
+ ! { dg-note {variable 'parm\.[0-9]+' declared in block is candidate for adjusting OpenACC privatization level} "" { target { ! openacc_host_select
Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]
Hi Harald, hi all, On 27.09.21 21:34, Harald Anlauf via Gcc-patches wrote: [...] here is what I played with: program p implicit none integer, pointer :: x(:,:) allocate (x(-3:3,4:0)) print *, "lbound =", lbound (x) call sub (x) contains subroutine sub (y) integer, pointer :: y(..) print *, "lbound =", lbound (y) print *, "ubound =", ubound (y) end subroutine sub end (Slightly shortened) This prints: lbound = -3 1 lbound = -3 1 ubound = 3 0 For some reason Intel prints different lbound lbound = -3 1 lbound = -3 4 ubound = 3 3 First, that should be rather unrelated to my patch as here the dummy argument is a pointer (could be also allocatable), where the argument is passed through "as is". For the latter reason, the expectation is that, both in the caller and callee, the result is the same - which ifort's result isn't. Otherwise, the quote from F2018 of my previous email applies: F2018:16.9.109 LBOUND has for "case(i)", i.e. with a 'dim' argument the following. The case without 'dim' just iterates through case (i) for each dim. Thus: "If DIM is present, ARRAY is a whole array, and either ARRAY is an assumed-size array of rank DIM or dimension DIM of ARRAY has nonzero extent, the result has a value equal to the lower bound for subscript DIM of ARRAY. Otherwise, if DIM is present, the result value is 1." Here, we assume dim=2 is present [either directly or via case(ii)], ARRAY is a whole array but it neither is of assumed size nor has nonzero extent. Hence, the "otherwise" applies and the result is 1 - as gfortran has and ifort has in the caller. The ubound then follows – there is a long list of conditions which are all not fulfilled (you could check to confirm this) and remaining is then only: "Otherwise, if DIM is present, the result has a value equal to the number of elements in dimension DIM of ARRAY." And following your quote, there are zero elements in dim=2 of your array. → ubound(…, dim=2) == 0. So for the first dimension everything is fine, but for the second dim, which has extent zero, my question is: what should the lbound be? 1 or 4? 1 With BIND(C) applied to f and g, ubound remains the same but lbound is now 0 instead of 1. I haven't check the BIND(C) complications. There aren't real complications, except that with the C descriptor, there is no lbound/ubound anymore but the descr->dim[i].lower_bound + ...[i].extent are directly referenced. For GCC, the difference is that GCC uses lbound + ubound and CFI uses lbound + extent. (The other difference is the use of stride in number of elements vs. sm/stride multipler in number of bytes.) The CFI array descriptor is IMHO more sensible than the GFC descriptor, but for legacy reasons, we still carry it along. For "common" Fortran code, I looked at 9.7.1.2(1): ... It is the word "determine" in first sentence that made me stumble. I think the Fortran standard does often not really tell what the bounds are but just what lbound/ubound/size/shape produce. That's perfectly fine – and permits different implementations in the background. (For C interop, they had to specify, for obvious reasons, what's in the descriptor itself.) Cheers, 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
Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]
Hi Thomas,
Am 27.09.21 um 14:07 schrieb Tobias Burnus:
While playing I stumbled over the fact that when allocating an array
with a dimension that has extent 0, e.g. 4:-5, the lbound gets reset
to 1 and ubound set to 0.
I am not sure, whether I fully understand what you wrote. For:
integer, allocatable :: a(:)
allocate(a(4:-5))
print *, size(a), size(a, dim=1), shape(a) ! should print the '0 0 0'
print *, lbound(a, dim=1) ! should print '1'
print *, ubound(a, dim=1) ! should print '0'
where the last line is due to F2018, 16.9.196, which has:
'Otherwise, if DIM is present, the result has a value equal to the
number of elements in dimension DIM of ARRAY.'
And lbound(a,dim=1) == 1 due to the "otherwise" case of F2018:16.9.109
LBOUND:
"Case (i): If DIM is present, ARRAY is a whole array, and either
ARRAY is an assumed-size array of rank DIM or dimension DIM of
ARRAY has nonzero extent, the result has a value equal to the
lower bound for subscript DIM of ARRAY. Otherwise, if DIM is
present, the result value is 1."
And when doing
call f(a)
call g(a)
with 'subroutine f(x); integer :: x(:)'
and 'subroutine g(y); integer :: y(..)'
Here, ubound == 0 due to the reason above and lbound is set to
the declared lower bound, which is for 'x' the default ("1") but
could also be 5 with "x(5:)" and for 'y' it cannot be specified.
For 'x', see last sentence of F2018:8.5.8.3. For 'y', I did not
find the exact location but it follows alongsize.
it appears that I managed to kill the related essential part of
my comment (fat fingers?). So here is what I played with:
program p
implicit none
! integer, allocatable :: x(:,:)
integer, pointer :: x(:,:)
allocate (x(-3:3,4:0))
print *, "lbound =", lbound (x)
call sub (x)
contains
subroutine sub (y)
! integer, allocatable :: y(..)
integer, pointer :: y(..)
print *, "size =", size (y)
print *, "shape =", shape (y)
print *, "lbound =", lbound (y)
print *, "ubound =", ubound (y)
end subroutine sub
end
Array x is deferred shape, as is the dummy y.
This prints:
lbound = -3 1
size = 0
shape = 7 0
lbound = -3 1
ubound = 3 0
For some reason Intel prints different lbound for main/sub,
meaning that it is broken, but here it goes:
lbound = -3 1
size = 0
shape = 7 0
lbound = -3 4
ubound = 3 3
So for the first dimension everything is fine, but for the
second dim, which has extent zero, my question is: what should
the lbound be? 1 or 4?
With BIND(C) applied to f and g, ubound remains the same but
lbound is now 0 instead of 1.
I haven't check the BIND(C) complications.
For "common" Fortran code, I looked at 9.7.1.2(1):
"When an ALLOCATE statement is executed for an array for which
allocate-shape-spec-list is specified, the values of the lower bound
and upper bound expressions determine the bounds of the array.
Subsequent redefinition or undefinition of any entities in the bound
expressions do not affect the array bounds. If the lower bound is
omitted, the default value is 1. If the upper bound is less than the
lower bound, the extent in that dimension is zero and the array has
zero size."
It is the word "determine" in first sentence that made me stumble.
I am not saying that it is wrong to handle extent zero the way it
is done - using lower bound 1 and upper bound 0 - as the extent is
correct. *If* that is the case, then I would consider gfortran having
a consistent quality of implementation, but not Intel...
Has the standard has changed in this respect?
I doubt it, but only looked at F2018 and not at older standards.
PS: I saw that we recently had a couple of double reviews. I think it is
useful if multiple persons look at patches, but hope that we do not
start requiring two reviews for each patch ;-)
That would certainly have a very adversary affect and terribly increase
the spam^WPING rate...
Harald
[committed] libgomp.oacc-fortran/privatized-ref-2.f90: Fix dg-note (was: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070])
On 27.09.21 14:07, Tobias Burnus wrote:
now committed r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0
I accidentally changed dg-note to dg-message when updating the expected
output, as the dump has changed. (Copying seemingly the sorry line
instead of the dg-note lines as template.)
Changed back to dg-note & committed as
r12-3898-gda1f6391b7c255e4e2eea983832120eff4f7d3df.
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
commit da1f6391b7c255e4e2eea983832120eff4f7d3df
Author: Tobias Burnus
Date: Mon Sep 27 14:33:39 2021 +0200
libgomp.oacc-fortran/privatized-ref-2.f90: Fix dg-note
In my last commit, r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0,
which inlined array-size code, I had to update the expected output. However,
in doing so, I accidentally (copy'n'paste) changed dg-note into dg-message.
libgomp/
* testsuite/libgomp.oacc-fortran/privatized-ref-2.f90: Change
dg-message back to dg-note.
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90 b/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90
index 2ff60226109..588f528b2d5 100644
--- a/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90
+++ b/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90
@@ -75,9 +75,9 @@ contains
! { dg-note {variable 'A\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: static} "" { target *-*-* } l_compute$c_compute }
array = [(-2*i, i = 1, size(array))]
!$acc loop gang private(array) ! { dg-line l_loop[incr c_loop] }
-! { dg-message {variable 'i' in 'private' clause isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } l_loop$c_loop }
-! { dg-message {variable 'array\.[0-9]+' in 'private' clause is candidate for adjusting OpenACC privatization level} "" { target *-*-* } l_loop$c_loop }
-! { dg-message {variable 'array\.[0-9]+' ought to be adjusted for OpenACC privatization level: 'gang'} "" { target *-*-* } l_loop$c_loop }
+! { dg-note {variable 'i' in 'private' clause isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } l_loop$c_loop }
+! { dg-note {variable 'array\.[0-9]+' in 'private' clause is candidate for adjusting OpenACC privatization level} "" { target *-*-* } l_loop$c_loop }
+! { dg-note {variable 'array\.[0-9]+' ought to be adjusted for OpenACC privatization level: 'gang'} "" { target *-*-* } l_loop$c_loop }
! { dg-message {sorry, unimplemented: target cannot support alloca} PR65181 { target openacc_nvidia_accel_selected } l_loop$c_loop }
Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]
Hi Thomas, hi Harald, hi all,
now committed r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0
with the following changes:
* Removed now unused gfor_fndecl_size0/gfor_fndecl_size1 (trans{-decl.c,.h})
* Add a scan-dump-not check for those.
See below for some comments.
On 24.09.21 22:38, Thomas Koenig wrote:
OK for mainline?
As promised on IRC, here's the review.
Thanks for the quick review :-)
Maybe you can add a test case which shows that the call to the size
intrinsic really does not happen.
OK with that.
I think you mean to the (_gfortran_)size0/size1 function libgfortran.
Unsurprisingly, the intrinsic itself _is_ still used and the simplify.c +
trans-instrinsic.c's functions are called. However, the libgfortran
functions size0/size1 shouldn't be callable – given that I deleted
the function decl in the front end. I have nonetheless added some
-fdump-tree checks that size0 and size1 do not appear.
Hmm, looking at my patch again – I think I did intent to remove
the decl – but did not actually do it.
In this patch, I have now actually done what I intended and wrote
above: I removed the gfor_fndecl_size0/gfor_fndecl_size1 also from
trans.h (declared) and trans-decl.c (global var, init with fn decl).
size_optional_dim_1.f90 was the only testcase that used size1 before
the patch (it also used size0). Thus, I added the dump check to it
and to the new assumed_rank_22.f90, which has 7 size0 calls with an
unpatched compiler.
Thus: Thanks for asking for the dump check as it showed that I did
forget to remove something ... :-)
Conclusion: Reviews are very helpful :-)
* * *
As the following email by Harald did not show up at the gcc-patches mailing
list:
you can find it at
https://gcc.gnu.org/pipermail/fortran/2021-September/056578.html
In my email, it shows up with "To: fortran@" and "CC: gcc-patches@", thus,
I have no idea why it did not arrive at the mailing-list archive :-(
On 24.09.21 23:12, Harald Anlauf via Fortran wrote:
I played around with your patch and was unable to break it.
Good. That means we can now hand it over to Gerald ;-)
Are you tracking the xfailed parts?
For my newly added xfail, it is fixed by the posted CFI<->GFC
descriptor patch, which I am currently updating (for several reasons).
Otherwise, I lost a bit track of the various TS29113, C-interop,
class(*), type(*), dimension(..) etc. PRs. I think they do cover
most of it. – Besides that CFI/GFC descriptor patch, some additional
patches are still in Sandra's and my pipeline.
And once the CFI/GFC descriptor patch is in, I think it makes sense
to check a bunch of PRs to see whether they are now fixed or something
still needs to be done. Likewise for José's patches. I think they
will be partially superseded by the patches committed, submitted or
soon to be submitted – but I am sure not all issues are fixed.
While playing I stumbled over the fact that when allocating an array
with a dimension that has extent 0, e.g. 4:-5, the lbound gets reset
to 1 and ubound set to 0.
I am not sure, whether I fully understand what you wrote. For:
integer, allocatable :: a(:)
allocate(a(4:-5))
print *, size(a), size(a, dim=1), shape(a) ! should print the '0 0 0'
print *, lbound(a, dim=1) ! should print '1'
print *, ubound(a, dim=1) ! should print '0'
where the last line is due to F2018, 16.9.196, which has:
'Otherwise, if DIM is present, the result has a value equal to the
number of elements in dimension DIM of ARRAY.'
And lbound(a,dim=1) == 1 due to the "otherwise" case of F2018:16.9.109 LBOUND:
"Case (i): If DIM is present, ARRAY is a whole array, and either
ARRAY is an assumed-size array of rank DIM or dimension DIM of
ARRAY has nonzero extent, the result has a value equal to the
lower bound for subscript DIM of ARRAY. Otherwise, if DIM is
present, the result value is 1."
And when doing
call f(a)
call g(a)
with 'subroutine f(x); integer :: x(:)'
and 'subroutine g(y); integer :: y(..)'
Here, ubound == 0 due to the reason above and lbound is set to
the declared lower bound, which is for 'x' the default ("1") but
could also be 5 with "x(5:)" and for 'y' it cannot be specified.
For 'x', see last sentence of F2018:8.5.8.3. For 'y', I did not
find the exact location but it follows alongsize.
With BIND(C) applied to f and g, ubound remains the same but
lbound is now 0 instead of 1.
Has the standard has changed in this respect?
I doubt it, but only looked at F2018 and not at older standards.
I am probably not the best person to review the trans-* parts, but
I did not spot anything I could point at, and the dump-tree looked
reasonable. Therefore OK from my side.
Thanks for the work!
Thanks also for your review.
Thanks,
Tobias
PS: I saw that we recently had a couple of double reviews. I think it is
useful if
Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]
Hi Tobias, OK for mainline? As promised on IRC, here's the review. Maybe you can add a test case which shows that the call to the size intrinsic really does not happen. OK with that. Thanks for the patch! Best regards Thomas
[Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]
This patch requires the previously mentioned simple-loop-gen patch, which also still needs to be reviewed: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579576.html For the xfailed part of the new testcase, the updated array descriptor is needed, but I think leaving it as xfailed for now - and reviewing this patch first makes more sense. size(a,dim=i) of an array is simply: a.dim[i].ubound - a.dim[i].lbound + 1 except that the result is always >= 0, i.e. a(5:-10) has size 0. Assumed-size arrays like as(5, -3:*) can be passed to assumed-rank arrays – but, obviously, the upper bound is unknown. Without BIND(C), the standard is quiet how those get transported but: ubound(as,dim=2) == size(as,dim=2) == -1 However, for ..., allocatable :: c(:,:) allocate (c(5,-4:-1)) the size(c,dim=2) is surely 4 and not -1. Thus, when passing it to a subroutine foo(x) ..., allocatable :: x(..) it should also come out as size(x, dim=2) == 4. To make the distinction, the allocatable/pointer attribute of the dummy can be used – as an assumed-size array cannot be allocatable. That's what is used in trans-intrinsic.c/trans-array.c – and the main reason I started to generate inline code for the array size. (Given that it permits optimizations and is a trivial code, I also think that it makes sense in general.) But even when doing so, it still did not work properly as when calling call foo(d) the bounds where not always reset such that the caller could still receive ubound(d,dim=last_dim) == -1 - in the case it just happened to be -1, be it for a zero-sized array or because the lbounds just happend to be -1 or smaller. That's taken care of in trans-expr.c. 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: Fix assumed-size to assumed-rank passing [PR94070] This code inlines the size0 and size1 libgfortran calls, the former is still used by libgfortan itself (and by old code). Besides permitting more optimizations, it also permits to handle assumed-rank dummies better: If the dummy argument is a nonpointer/nonallocatable, an assumed-size actual arg is repesented by having ubound == -1 for the last dimension. However, for allocatable/pointers, this value can also exist. Hence, the dummy arg attr has to be honored. For that reason, when calling an assumed-rank procedure with nonpointer, nonallocatable dummy arguments, the bounds have to be updated to avoid the case ubound == -1 for the last dimension. PR fortran/94070 gcc/fortran/ChangeLog: * trans-array.c (gfc_tree_array_size): New function to find size inline (whole array or one dimension). (array_parameter_size): Use it, take stmt_block as arg. (gfc_conv_array_parameter): Update call. * trans-array.h (gfc_tree_array_size): Add prototype. * trans-expr.c (gfc_conv_procedure_call): Update bounds of pointer/allocatable actual args to nonallocatable/nonpointer dummies to be one based. * trans-intrinsic.c (gfc_conv_intrinsic_shape): Fix case for assumed rank with allocatable/pointer dummy. (gfc_conv_intrinsic_size): Update to use inline function. libgfortran/ChangeLog: * intrinsics/size.c (size0, size1): Comment that now not used by newer compiler code. libgomp/ChangeLog: * testsuite/libgomp.oacc-fortran/privatized-ref-2.f90: Update expected dg-note output. gcc/testsuite/ChangeLog: * gfortran.dg/c-interop/cf-out-descriptor-6.f90: Remove xfail. * gfortran.dg/c-interop/size.f90: Remove xfail. * gfortran.dg/intrinsic_size_3.f90: * gfortran.dg/transpose_optimization_2.f90: * gfortran.dg/assumed_rank_22.f90: New test. * gfortran.dg/assumed_rank_22_aux.c: New test. gcc/fortran/trans-array.c | 165 gcc/fortran/trans-array.h | 2 + gcc/fortran/trans-expr.c | 43 +- gcc/fortran/trans-intrinsic.c | 119 ++- gcc/testsuite/gfortran.dg/assumed_rank_22.f90 | 167 + gcc/testsuite/gfortran.dg/assumed_rank_22_aux.c| 68 + .../gfortran.dg/c-interop/cf-out-descriptor-6.f90 | 2 +- gcc/testsuite/gfortran.dg/c-interop/size.f90 | 2 +- gcc/testsuite/gfortran.dg/intrinsic_size_3.f90 | 2 +- .../gfortran.dg/transpose_optimization_2.f90 | 2 +- libgfortran/intrinsics/size.c | 4 + .../libgomp.oacc-fortran/privatized-ref-2.f90 | 13 +- 12 files changed, 476 insertions(+), 113 deletions(-) diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c index 0d013defdbb..b8061f37772 100644 --- a/gcc/fortran/trans-array.c +++ b/gcc/fortran/trans-array.c @@ -7901,31 +7901,143 @@ gfc_conv_expr_descriptor (gfc_se *se, gfc_expr *expr) gfc_cleanu
Re: [Patch] Fortran/OpenMP: Fix use_device_{ptr,addr} with assumed-size array [PR98858]
On Thu, Mar 11, 2021 at 02:44:38PM +0100, Tobias Burnus wrote:
> Fortran/OpenMP: Fix use_device_{ptr,addr} with assumed-size array [PR98858]
>
> gcc/ChangeLog:
>
> PR fortran/98858
> * gimplify.c (omp_add_variable): Handle NULL_TREE as size
> occuring for assumed-size arrays in use_device_{ptr,addr}.
>
> libgomp/ChangeLog:
>
> PR fortran/98858
> * testsuite/libgomp.fortran/use_device_ptr-3.f90: New test.
Ok, thanks.
Jakub
[Patch] Fortran/OpenMP: Fix use_device_{ptr,addr} with assumed-size array [PR98858]
The ICE occurs because the 't' == NULL for assumed-size arrays.
For them, the size is not known – but as this should only occur
for use_device_{addr,ptr}, the size is not needed.
OK for mainline?
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: Fix use_device_{ptr,addr} with assumed-size array [PR98858]
gcc/ChangeLog:
PR fortran/98858
* gimplify.c (omp_add_variable): Handle NULL_TREE as size
occuring for assumed-size arrays in use_device_{ptr,addr}.
libgomp/ChangeLog:
PR fortran/98858
* testsuite/libgomp.fortran/use_device_ptr-3.f90: New test.
gcc/gimplify.c | 2 +-
.../testsuite/libgomp.fortran/use_device_ptr-3.f90 | 91 ++
2 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index caf25ccdd5c..6da66985ad6 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -7078,7 +7078,7 @@ omp_add_variable (struct gimplify_omp_ctx *ctx, tree decl, unsigned int flags)
if ((flags & GOVD_SHARED) == 0)
{
t = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (decl)));
- if (DECL_P (t))
+ if (t && DECL_P (t))
omp_notice_variable (ctx, t, true);
}
}
diff --git a/libgomp/testsuite/libgomp.fortran/use_device_ptr-3.f90 b/libgomp/testsuite/libgomp.fortran/use_device_ptr-3.f90
new file mode 100644
index 000..f2b33cd5e89
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/use_device_ptr-3.f90
@@ -0,0 +1,91 @@
+! PR fortran/98858
+!
+! Assumed-size array with use_device_ptr()
+!
+program test_use_device_ptr
+ use iso_c_binding, only: c_ptr, c_loc, c_f_pointer
+ implicit none
+ double precision :: alpha
+ integer, parameter :: lda = 10
+ integer, allocatable :: mat(:, :)
+ integer :: i, j
+
+ allocate(mat(lda, lda))
+ do i = 1, lda
+do j = 1, lda
+ mat(j,i) = i*100 + j
+end do
+ end do
+
+ !$omp target enter data map(to:mat)
+ call dgemm(lda, mat)
+ !$omp target exit data map(from:mat)
+
+ do i = 1, lda
+do j = 1, lda
+ if (mat(j,i) /= -(i*100 + j)) stop 1
+end do
+ end do
+
+ !$omp target enter data map(to:mat)
+ call dgemm2(lda, mat)
+ !$omp target exit data map(from:mat)
+
+ do i = 1, lda
+do j = 1, lda
+ if (mat(j,i) /= (i*100 + j)) stop 1
+end do
+ end do
+
+ contains
+
+subroutine dgemm(lda, a)
+ implicit none
+ integer :: lda
+ integer, target:: a(lda,*) ! need target attribute to use c_loc
+ !$omp target data use_device_ptr(a)
+call negate_it(c_loc(a), lda)
+ !$omp end target data
+end subroutine
+
+subroutine dgemm2(lda, a)
+ implicit none
+ integer :: lda
+ integer, target:: a(lda,*) ! need target attribute to use c_loc
+ !$omp target data use_device_addr(a)
+call negate_it(c_loc(a), lda)
+ !$omp end target data
+end subroutine
+
+subroutine negate_it(a, n)
+ type(c_ptr), value :: a
+ integer, value :: n
+ integer, pointer :: array(:,:)
+
+ ! detour due to OpenMP 5.0 oddness
+ call c_f_pointer(a, array, [n,n])
+ call do_offload(array, n)
+end
+
+subroutine do_offload(aptr, n)
+ integer, target :: aptr(:,:)
+ integer, value :: n
+ !$omp target is_device_ptr(aptr)
+ call negate_it_tgt(aptr, n)
+ !$omp end target
+end subroutine do_offload
+
+subroutine negate_it_tgt(array, n)
+ !$omp declare target
+ integer, value :: n
+ integer :: array(n,n)
+ integer :: i, j
+ !$omp parallel do collapse(2)
+ do i = 1, n
+ do j = 1, n
+ array(j,i) = - array(j,i)
+ end do
+ end do
+ !$omp end parallel do
+ end subroutine
+end program
Re: [Patch, fortran] PR fortran/95352 - ICE on select rank with assumed-size selector and lbound intrinsic
Hi Jose, Proposed patch to PR95352 - ICE on select rank with assumed-size selector and lbound intrinsic. Patch tested only on x86_64-pc-linux-gnu. Add check for NULL pointer before trying to access structure member, patch by Steve Kargl. this is OK, but you'll have to adjust your ChangeLog. I'll only write this once for your series of patches (I think you just broke the record for most patches per day :-) Regarding the ChangeLog, for this and for your other patches: Before this is accepted by the scripts, you will need to massage the git commit log into a form for that the scripts will accept. You can run your commit through "git gcc-verify" to check if you have previously run contrib/gcc-git-customization.sh (which I recommend). Read https://gcc.gnu.org/codingconventions.html#ChangeLogs to find the gory details. Running contrib/mklog.py will prepare a template for the ChangeLog. Thanks a lot for taking up this patch! Best regards Thomas
Re: [Patch, fortran] PR fortran/94110 - Passing an assumed-size to an assumed-shape argument should be rejected
Hi Jose, Proposed patch to PR94110 - Passing an assumed-size to an assumed-shape argument should be rejected. OK for master. Thanks a lot for the patch! Best regards Thomas
[Patch, fortran] PR fortran/95352 - ICE on select rank with assumed-size selector and lbound intrinsic
Hi all!
Proposed patch to PR95352 - ICE on select rank with assumed-size
selector and lbound intrinsic.
Patch tested only on x86_64-pc-linux-gnu.
Add check for NULL pointer before trying to access structure member,
patch by Steve Kargl.
Thank you very much.
Best regards,
José Rui
2020-8-21 Steve Kargl
PR fortran/95352
* simplify.c (simplify_bound_dim): Add check for NULL pointer before
trying to access structure member.
2020-8-21 José Rui Faustino de Sousa
PR fortran/95352
* PR95352.f90: New test.
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 074b50c..a1153dd 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4080,7 +4080,7 @@ simplify_bound_dim (gfc_expr *array, gfc_expr *kind, int d, int upper,
|| (coarray && d == as->rank + as->corank
&& (!upper || flag_coarray == GFC_FCOARRAY_SINGLE)))
{
- if (as->lower[d-1]->expr_type == EXPR_CONSTANT)
+ if (as->lower[d-1] && as->lower[d-1]->expr_type == EXPR_CONSTANT)
{
gfc_free_expr (result);
return gfc_copy_expr (as->lower[d-1]);
diff --git a/gcc/testsuite/gfortran.dg/PR95352.f90 b/gcc/testsuite/gfortran.dg/PR95352.f90
new file mode 100644
index 000..20c8167
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR95352.f90
@@ -0,0 +1,27 @@
+! { dg-do compile }
+!
+! Test the fix for PR95352
+!
+
+module ice6_m
+
+ implicit none
+
+contains
+
+ function ice6_s(a) result(ierr)
+integer, intent(in) :: a(..)
+
+integer :: ierr
+
+integer :: lb
+
+select rank(a)
+rank(*)
+ lb = lbound(a, dim=1)
+ if(lbound(a, dim=1)/=lb) ierr = -1
+end select
+return
+ end function ice6_s
+
+end module ice6_m
[Patch, fortran] PR fortran/94110 - Passing an assumed-size to an assumed-shape argument should be rejected
Hi all!
Proposed patch to PR94110 - Passing an assumed-size to an assumed-shape
argument should be rejected.
Patch tested only on x86_64-pc-linux-gnu.
Add code to also check for deferred-shape and assumed-rank pointer
(allocatable arguments are checked elsewhere) dummy arguments being
passed an assumed-size array formal argument when raising an error.
Thank you very much.
Best regards,
José Rui
2020-8-20 José Rui Faustino de Sousa
PR fortran/94110
* interface.c (gfc_compare_actual_formal): Add code to also raise the
actual argument cannot be an assumed-size array error when the dummy
arguments are deferred-shape or assumed-rank pointer.
2020-8-20 José Rui Faustino de Sousa
PR fortran/94110
* PR94110.f90: New test.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 7985fc7..020cdd7 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -3303,7 +3303,10 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
return false;
}
- if (f->sym->as && f->sym->as->type == AS_ASSUMED_SHAPE
+ if (f->sym->as
+ && (f->sym->as->type == AS_ASSUMED_SHAPE
+ || f->sym->as->type == AS_DEFERRED
+ || (f->sym->as->type == AS_ASSUMED_RANK && f->sym->attr.pointer))
&& a->expr->expr_type == EXPR_VARIABLE
&& a->expr->symtree->n.sym->as
&& a->expr->symtree->n.sym->as->type == AS_ASSUMED_SIZE
diff --git a/gcc/testsuite/gfortran.dg/PR94110.f90 b/gcc/testsuite/gfortran.dg/PR94110.f90
new file mode 100644
index 000..9ec70ec
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR94110.f90
@@ -0,0 +1,88 @@
+! { dg-do compile }
+!
+! Test the fix for PR94110
+!
+
+program asa_p
+
+ implicit none
+
+ integer, parameter :: n = 7
+
+ integer :: p(n)
+ integer :: s
+
+ p = 1
+ s = sumf_as(p)
+ if (s/=n) stop 1
+ s = sumf_ar(p)
+ if (s/=n) stop 2
+ stop
+
+contains
+
+ function sumf_as(a) result(s)
+integer, target, intent(in) :: a(*)
+
+integer :: s
+
+s = sum_as(a) ! { dg-error "Actual argument for .a. cannot be an assumed-size array" }
+s = sum_p_ds(a) ! { dg-error "Actual argument for .a. cannot be an assumed-size array" }
+s = sum_p_ar(a) ! { dg-error "Actual argument for .a. cannot be an assumed-size array" }
+return
+ end function sumf_as
+
+ function sumf_ar(a) result(s)
+integer, target, intent(in) :: a(..)
+
+integer :: s
+
+select rank(a)
+rank(*)
+ s = sum_as(a) ! { dg-error "Actual argument for .a. cannot be an assumed-size array" }
+ s = sum_p_ds(a) ! { dg-error "Actual argument for .a. cannot be an assumed-size array" }
+ s = sum_p_ar(a) ! { dg-error "Actual argument for .a. cannot be an assumed-size array" }
+rank default
+ stop 3
+end select
+return
+ end function sumf_ar
+
+ function sum_as(a) result(s)
+integer, intent(in) :: a(:)
+
+integer :: s
+
+s = sum(a)
+return
+ end function sum_as
+
+ function sum_p_ds(a) result(s)
+integer, pointer, intent(in) :: a(:)
+
+integer :: s
+
+s = -1
+if(associated(a))&
+ s = sum(a)
+return
+ end function sum_p_ds
+
+ function sum_p_ar(a) result(s)
+integer, pointer, intent(in) :: a(..)
+
+integer :: s
+
+s = -1
+select rank(a)
+rank(1)
+ if(associated(a))&
+s = sum(a)
+rank default
+ stop 4
+end select
+return
+ end function sum_p_ar
+
+end program asa_p
+
Re: [Patch, fortran] PR fortran/94022 - Array slices of assumed-size arrays
Hi Jose, Proposed patch to Bug 94022 - Array slices of assumed-size arrays. Patch tested only on x86_64-pc-linux-gnu. Reviewed, regression-tested and commited as r11-1228-g6a07010b774cb5a0b1790b857e69d3d8534eebd2 . Thanks for the patch! Regards Thomas
[Patch, fortran] PR fortran/94022 - Array slices of assumed-size arrays
Hi All!
Proposed patch to Bug 94022 - Array slices of assumed-size arrays.
Patch tested only on x86_64-pc-linux-gnu.
Make sure that when passing array sections of assumed-size arrays to
procedures expecting an assumed-rank array the upper bound of the last
dimension of the array section does not get improperly reset to -1 to
mark it has an assumed size array.
Best regards,
José Rui
2020-6-3 José Rui Faustino de Sousa
PR fortran/94022
* trans-expr.c (gfc_conv_procedure_call): In the case of assumed-size
arrays ensure that the reference is to a full array.
2020-6-3 José Rui Faustino de Sousa
PR fortran/94022
* PR94022.f90: New test.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 33fc061..2e221b5 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6243,6 +6243,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
|| gfc_expr_attr (e).allocatable)
set_dtype_for_unallocated (&parmse, e);
else if (e->expr_type == EXPR_VARIABLE
+ && e->ref
+ && e->ref->u.ar.type == AR_FULL
&& e->symtree->n.sym->attr.dummy
&& e->symtree->n.sym->as
&& e->symtree->n.sym->as->type == AS_ASSUMED_SIZE)
diff --git a/gcc/testsuite/gfortran.dg/PR94022.f90
b/gcc/testsuite/gfortran.dg/PR94022.f90
new file mode 100644
index 000..63b7d90
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR94022.f90
@@ -0,0 +1,132 @@
+! { dg-do run }
+!
+! Test the fix for PR94022
+!
+
+function isasa_f(a) result(s)
+ implicit none
+
+ integer, intent(in) :: a(..)
+
+ logical :: s
+
+ select rank(a)
+ rank(*)
+s = .true.
+ rank default
+s = .false.
+ end select
+ return
+end function isasa_f
+
+function isasa_c(a) result(s) bind(c)
+ use, intrinsic :: iso_c_binding, only: c_int, c_bool
+
+ implicit none
+
+ integer(kind=c_int), intent(in) :: a(..)
+
+ logical(kind=c_bool) :: s
+
+ select rank(a)
+ rank(*)
+s = .true.
+ rank default
+s = .false.
+ end select
+ return
+end function isasa_c
+
+program isasa_p
+
+ implicit none
+
+ interface
+function isasa_f(a) result(s)
+ implicit none
+ integer, intent(in) :: a(..)
+ logical :: s
+end function isasa_f
+function isasa_c(a) result(s) bind(c)
+ use, intrinsic :: iso_c_binding, only: c_int, c_bool
+ implicit none
+ integer(kind=c_int), intent(in) :: a(..)
+ logical(kind=c_bool):: s
+end function isasa_c
+ end interface
+
+ integer, parameter :: sz = 7
+ integer, parameter :: lb = 3
+ integer, parameter :: ub = 9
+ integer, parameter :: ex = ub-lb+1
+
+ integer :: arr(sz,lb:ub)
+
+ arr = 1
+ if (asaf_a(arr, lb+1, ub-1)) stop 1
+ if (asaf_p(arr, lb+1, ub-1)) stop 2
+ if (asaf_a(arr, 2, ex-1))stop 3
+ if (asaf_p(arr, 2, ex-1))stop 4
+ if (asac_a(arr, lb+1, ub-1)) stop 5
+ if (asac_p(arr, lb+1, ub-1)) stop 6
+ if (asac_a(arr, 2, ex-1))stop 7
+ if (asac_p(arr, 2, ex-1))stop 8
+
+ stop
+
+contains
+
+ function asaf_a(a, lb, ub) result(s)
+integer, intent(in) :: lb
+integer, target, intent(in) :: a(sz,lb:*)
+integer, intent(in) :: ub
+
+logical :: s
+
+s = isasa_f(a(:,lb:ub))
+return
+ end function asaf_a
+
+ function asaf_p(a, lb, ub) result(s)
+integer, intent(in) :: lb
+integer, target, intent(in) :: a(sz,lb:*)
+integer, intent(in) :: ub
+
+logical :: s
+
+integer, pointer :: p(:,:)
+
+p => a(:,lb:ub)
+s = isasa_f(p)
+return
+ end function asaf_p
+
+ function asac_a(a, lb, ub) result(s)
+integer, intent(in) :: lb
+integer, target, intent(in) :: a(sz,lb:*)
+integer, intent(in) :: ub
+
+logical :: s
+
+s = logical(isasa_c(a(:,lb:ub)))
+return
+ end function asac_a
+
+ function asac_p(a, lb, ub) result(s)
+integer, intent(in) :: lb
+integer, target, intent(in) :: a(sz,lb:*)
+integer, intent(in) :: ub
+
+logical :: s
+
+integer, pointer :: p(:,:)
+
+p => a(:,lb:ub)
+s = logical(isasa_c(p))
+return
+ end function asac_p
+
+end program isasa_p
+
+
+
Re: [Patch v2, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified
Hi Jose, On 21/04/20 16:38, Thomas Koenig wrote: Do you have commit privileges? It not, I can commit it for you. No i do not. I would be grateful if you could. Done, as https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=808a6eadda1a353ce3a70556feac128580491b24 . Thanks a lot for the patch! Regards Thomas
Re: [Patch v2, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified
Hi Thomas, On 21/04/20 16:38, Thomas Koenig wrote: Do you have commit privileges? It not, I can commit it for you. No i do not. I would be grateful if you could. Best regards, José Rui
Re: [Patch v2, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified
Hi Jose, Proposed patch to Bug 90350 - ubound ICE on assumed size array even though explicit bound is specified Patch tested only on x86_64-pc-linux-gnu. Best regards, José Rui Looks good. Do you have commit privileges? It not, I can commit it for you. Regards Thomas
[Patch v2, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified
Hi again!
Proposed patch to Bug 90350 - ubound ICE on assumed size array even
though explicit bound is specified
Patch tested only on x86_64-pc-linux-gnu.
Best regards,
José Rui
2020-4-19 José Rui Faustino de Sousa
PR fortran/90350
* simplify.c (simplify_bound): In the case of assumed-size arrays check
if the reference is to a full array.
2020-4-19 José Rui Faustino de Sousa
PR fortran/90350
* PR90350.f90: New test.
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index c7a4f77..eb8b2af 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4157,6 +4157,7 @@ simplify_bound (gfc_expr *array, gfc_expr *dim, gfc_expr
*kind, int upper)
{
gfc_ref *ref;
gfc_array_spec *as;
+ ar_type type = AR_UNKNOWN;
int d;
if (array->ts.type == BT_CLASS)
@@ -4180,6 +4181,7 @@ simplify_bound (gfc_expr *array, gfc_expr *dim, gfc_expr
*kind, int upper)
switch (ref->type)
{
case REF_ARRAY:
+ type = ref->u.ar.type;
switch (ref->u.ar.type)
{
case AR_ELEMENT:
@@ -4233,7 +4235,7 @@ simplify_bound (gfc_expr *array, gfc_expr *dim, gfc_expr
*kind, int upper)
int k;
/* UBOUND(ARRAY) is not valid for an assumed-size array. */
- if (upper && as && as->type == AS_ASSUMED_SIZE)
+ if (upper && type == AR_FULL && as && as->type == AS_ASSUMED_SIZE)
{
/* An error message will be emitted in
check_assumed_size_reference (resolve.c). */
diff --git a/gcc/testsuite/gfortran.dg/PR90350.f90
b/gcc/testsuite/gfortran.dg/PR90350.f90
new file mode 100644
index 000..2e2cf10
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR90350.f90
@@ -0,0 +1,19 @@
+! { dg-do compile }
+!
+! Test the fix for PR90350
+!
+! Contributed by
+!
+
+program artificial
+implicit none
+integer :: arr(-10:10)
+ call asub(arr,size(arr))
+end program artificial
+subroutine asub(arr,n)
+integer,intent(in) :: arr(*)
+integer,intent(in) :: n
+ write(*,*)'UPPER=',ubound(arr(:n))
+ write(*,*)'LOWER=',lbound(arr(:n))
+ write(*,*)'SIZE=',size(arr(:n))
+end subroutine asub
Re: [Patch, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified
Am 19.04.20 um 20:03 schrieb José Rui Faustino de Sousa via Fortran: Hi Thomas! > ? In other words, maybe a check on the upper bound > of the last dimension would be better? > You mean enforcing: C928 (R921) The second subscript shall not be omitted from a subscript-triplet in the last dimension of an assumed-size array. right? If I have correctly understood the way things are done this is a more general test which is already done at resolve.c around line 4690. I just checked that it works, so I think this is fine. It looks like assumed_size_refs_4.f90 already checks for that, so that is fine. Other than that, a couple of points: The style you used for your patch, + if (upper + && type == AR_FULL + && as + && as->type == AS_ASSUMED_SIZE) doesn't conform to the GNU style guidelines. This should go on one line (as long as it fits). Also, I could not apply your patch via copy & paste from the text of the e-mail. Could you send patches as an attachment in the future? Due do some unfortunate limitations of the current mailing list software, it is probably best if you send it as a *.txt file. So, OK for trunk with the cosmetic corrections above. Thanks a lot for the patch, and welcome aboard! > A question: Do you have a copyright assignment yet? > Yes, I have already done that. Excellent. Best regards Thomas
Re: [Patch, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified
Hi Thomas! > ? In other words, maybe a check on the upper bound > of the last dimension would be better? > You mean enforcing: C928 (R921) The second subscript shall not be omitted from a subscript-triplet in the last dimension of an assumed-size array. right? If I have correctly understood the way things are done this is a more general test which is already done at resolve.c around line 4690. One could just duplicate the test to be extra safe. > A question: Do you have a copyright assignment yet? > Yes, I have already done that. Best regards, José Rui
Re: [Patch, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified
Hi Jose, first, thanks for coming on board! A question: Do you have a copyright assignment yet? This patch is probably short enough that it can be accepted without it, but if you're planning to contribute more (which I certainly hope) then it would make sense to do this. Regarding your patch, I have one question: What will happen with the test case program artificial implicit none integer :: arr(-10:10) call asub(arr,size(arr)) end program artificial subroutine asub(arr,n) integer,intent(in) :: arr(*) integer,intent(in) :: n write(*,*)'UPPER=',ubound(arr(3:)) write(*,*)'LOWER=',lbound(arr(3:)) write(*,*)'SIZE=',size(arr(3:)) end subroutine asub ? In other words, maybe a check on the upper bound of the last dimension would be better? Regards Thomas
[Patch, fortran] PR fortran/90350 - ubound ICE on assumed size array even though explicit bound is specified
Hi all!
Proposed patch to Bug 90350 - ubound ICE on assumed size array even
though explicit bound is specified
Patch tested only on x86_64-pc-linux-gnu.
Bumped into the same problem.
Probably a better fix would be to add an extra step to the reference
chain reflecting that array-section are explicit-shape arrays not
whatever that was sectioned. But, although this pattern of problem shows
up in the code in other places, it may be more trouble than it is worth...
Thank you very much.
Best regards,
José Rui
2020-4-19 José Rui Faustino de Sousa
PR fortran/90350
* simplify.c (simplify_bound): In the case of assumed-size arrays check
if the reference is to a full array.
2020-4-19 José Rui Faustino de Sousa
PR fortran/90350
* PR90350.f90: New test.
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index d5703e3..4818368 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4157,6 +4157,7 @@ simplify_bound (gfc_expr *array, gfc_expr *dim,
gfc_expr *kind, int upper)
{
gfc_ref *ref;
gfc_array_spec *as;
+ ar_type type = AR_UNKNOWN;
int d;
if (array->ts.type == BT_CLASS)
@@ -4180,6 +4181,7 @@ simplify_bound (gfc_expr *array, gfc_expr *dim,
gfc_expr *kind, int upper)
switch (ref->type)
{
case REF_ARRAY:
+ type = ref->u.ar.type;
switch (ref->u.ar.type)
{
case AR_ELEMENT:
@@ -4233,7 +4235,10 @@ simplify_bound (gfc_expr *array, gfc_expr *dim,
gfc_expr *kind, int upper)
int k;
/* UBOUND(ARRAY) is not valid for an assumed-size array. */
- if (upper && as && as->type == AS_ASSUMED_SIZE)
+ if (upper
+ && type == AR_FULL
+ && as
+ && as->type == AS_ASSUMED_SIZE)
{
/* An error message will be emitted in
check_assumed_size_reference (resolve.c). */
diff --git a/gcc/testsuite/gfortran.dg/PR90350.f90
b/gcc/testsuite/gfortran.dg/PR90350.f90
new file mode 100644
index 000..2e2cf10
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR90350.f90
@@ -0,0 +1,19 @@
+! { dg-do compile }
+!
+! Test the fix for PR90350
+!
+! Contributed by
+!
+
+program artificial
+implicit none
+integer :: arr(-10:10)
+ call asub(arr,size(arr))
+end program artificial
+subroutine asub(arr,n)
+integer,intent(in) :: arr(*)
+integer,intent(in) :: n
+ write(*,*)'UPPER=',ubound(arr(:n))
+ write(*,*)'LOWER=',lbound(arr(:n))
+ write(*,*)'SIZE=',size(arr(:n))
+end subroutine asub
[og9] OpenACC assumed-size arrays with non-lexical data mappings
Hi,
This patch provides support for implicit mapping of assumed-sized
arrays for OpenACC, in cases where those arrays have previously been
mapped using non-lexical data mappings (e.g. "#pragma acc enter data").
Previously posted here:
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02090.html
and then revised:
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00069.html
It's not clear if this is required behaviour for OpenACC, but at least
one test program we are using relies on the semantics introduced by this
patch.
Tested with offloading to nvptx. I will apply to the
openacc-gcc-9-branch shortly.
Julian
ChangeLog
2019-07-10 Cesar Philippidis
Thomas Schwinge
Julian Brown
gcc/
* gimplify.c (gimplify_adjust_omp_clauses_1): Raise error for
assumed-size arrays in map clauses for Fortran/OpenMP.
* omp-low.c (lower_omp_target): Set the size of assumed-size
Fortran arrays to one to allow use of data already mapped on
the offload device.
gcc/fortran/
* trans-openmp.c (gfc_omp_finish_clause): Change clauses mapping
assumed-size arrays to use the GOMP_MAP_FORCE_PRESENT map type.
>From 2c5a7e445ebadc920730c732279732d2f9b40598 Mon Sep 17 00:00:00 2001
From: Julian Brown
Date: Thu, 4 Jul 2019 18:14:41 -0700
Subject: [PATCH 2/3] Assumed-size arrays with non-lexical data mappings
gcc/fortran/
* trans-openmp.c (gfc_omp_finish_clause): Change clauses mapping
assumed-size arrays to use the GOMP_MAP_FORCE_PRESENT map type.
* gimplify.c (gimplify_adjust_omp_clauses_1): Raise error for
assumed-size arrays in map clauses for Fortran/OpenMP.
* omp-low.c (lower_omp_target): Set the size of assumed-size Fortran
arrays to one to allow use of data already mapped on the offload device.
---
gcc/fortran/ChangeLog.openacc | 9 +
gcc/fortran/trans-openmp.c| 22 +-
gcc/gimplify.c| 14 ++
gcc/omp-low.c | 5 +
4 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/gcc/fortran/ChangeLog.openacc b/gcc/fortran/ChangeLog.openacc
index c44a5ebdb3b..beba7d94ad2 100644
--- a/gcc/fortran/ChangeLog.openacc
+++ b/gcc/fortran/ChangeLog.openacc
@@ -1,3 +1,12 @@
+2019-07-10 Julian Brown
+
+ * trans-openmp.c (gfc_omp_finish_clause): Change clauses mapping
+ assumed-size arrays to use the GOMP_MAP_FORCE_PRESENT map type.
+ * gimplify.c (gimplify_adjust_omp_clauses_1): Raise error for
+ assumed-size arrays in map clauses for Fortran/OpenMP.
+ * omp-low.c (lower_omp_target): Set the size of assumed-size Fortran
+ arrays to one to allow use of data already mapped on the offload device.
+
2019-07-10 Julian Brown
* openmp.c (resolve_oacc_data_clauses): Allow polymorphic allocatable
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index d5ae0b717df..db009130c85 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -1137,10 +1137,18 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p)
tree decl = OMP_CLAUSE_DECL (c);
/* Assumed-size arrays can't be mapped implicitly, they have to be mapped
- explicitly using array sections. An exception is if the array is
- mapped explicitly in an enclosing data construct for OpenACC, in which
- case we see GOMP_MAP_FORCE_PRESENT here and do not need to raise an
- error. */
+ explicitly using array sections. For OpenACC this restriction is lifted
+ if the array has already been mapped:
+
+ - Using a lexically-enclosing data region: in that case we see the
+ GOMP_MAP_FORCE_PRESENT mapping kind here.
+
+ - Using a non-lexical data mapping ("acc enter data").
+
+ In the latter case we change the mapping type to GOMP_MAP_FORCE_PRESENT.
+ This raises an error for OpenMP in our the caller
+ (gimplify.c:gimplify_adjust_omp_clauses_1). OpenACC will raise a runtime
+ error if the assumed-size array is not mapped. */
if (OMP_CLAUSE_MAP_KIND (c) != GOMP_MAP_FORCE_PRESENT
&& TREE_CODE (decl) == PARM_DECL
&& GFC_ARRAY_TYPE_P (TREE_TYPE (decl))
@@ -1148,11 +1156,7 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p)
&& GFC_TYPE_ARRAY_UBOUND (TREE_TYPE (decl),
GFC_TYPE_ARRAY_RANK (TREE_TYPE (decl)) - 1)
== NULL)
-{
- error_at (OMP_CLAUSE_LOCATION (c),
- "implicit mapping of assumed size array %qD", decl);
- return;
-}
+OMP_CLAUSE_SET_MAP_KIND (c, GOMP_MAP_FORCE_PRESENT);
tree c2 = NULL_TREE, c3 = NULL_TREE, c4 = NULL_TREE;
if (OMP_CLAUSE_MAP_KIND (c) == GOMP_MAP_FORCE_DEVICEPTR)
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 60e04ff8353..58142c9eb90 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -10088,7 +10088,21 @@ gimplify_adjust_omp_clauses_1 (splay_tree_node n, void *data)
*list_p = clause;
struct gimplify_omp_ctx *ctx = gimplify_omp_ctxp;
gimplify_omp_ctxp =
[patch, fortran, committed] Set rank and lower bound for assumed size arguments
Hello world,
in the absence of a test case for PR 90539, I'm taking a shotgun
approach: Fix something that appears strange in the debug logs
and see if this more or less accidentally fixes the problem.
If not, at least there is one fewer point to look at.
I have committed the attached patch as obvious and simple,
r271630.
Regards
Thomas
2019-05-26 Thomas Koenig
PR fortran/90539
* trans-types.c (get_formal_from_actual_arglist): Set rank
and lower bound for assumed size arguments.
Index: trans-types.c
===
--- trans-types.c (Revision 271376)
+++ trans-types.c (Arbeitskopie)
@@ -3010,6 +3010,10 @@ get_formal_from_actual_arglist (gfc_symbol *sym, g
{
s->attr.dimension = 1;
s->as = gfc_get_array_spec ();
+ s->as->rank = 1;
+ s->as->lower[0] = gfc_get_int_expr (gfc_index_integer_kind,
+ &a->expr->where, 1);
+ s->as->upper[0] = NULL;
s->as->type = AS_ASSUMED_SIZE;
}
}
Re: *ping* [patch, fortran] Fix handling of assumed-size arrays in inline matmul
On 02/17/2018 06:22 AM, Thomas Koenig wrote: Am 12.02.2018 um 11:46 schrieb Thomas Koenig: Hello world, the attached patch fixes a regression where a rejects-valid would be issued. OK for the affected branches, trunk and gcc-7? PING ** (5.D0/7.D0) ? Yes, OK Jerry
*ping* [patch, fortran] Fix handling of assumed-size arrays in inline matmul
Am 12.02.2018 um 11:46 schrieb Thomas Koenig: Hello world, the attached patch fixes a regression where a rejects-valid would be issued. OK for the affected branches, trunk and gcc-7? PING ** (5.D0/7.D0) ?
[patch, fortran] Fix handling of assumed-size arrays in inline matmul
Hello world,
the attached patch fixes a regression where a rejects-valid would
be issued.
OK for the affected branches, trunk and gcc-7?
Regards
Thomas
2018-02-12 Thomas Koenig
PR fortran/84270
* frontend-passes (scalarized_expr): If the expression
is an assumed size array, leave in the last reference
and pass AR_SECTION instead of AR_FULL to gfc_resolve
in order to avoid an error.
2018-02-12 Thomas Koenig
PR fortran/84270
* gfortran.dg/inline_matmul_22.f90: New test.
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 257347)
+++ frontend-passes.c (Arbeitskopie)
@@ -3567,11 +3567,27 @@ scalarized_expr (gfc_expr *e_in, gfc_expr **index,
is the lbound of a full ref. */
int j;
gfc_array_ref *ar;
+ int to;
ar = &ref->u.ar;
- ar->type = AR_FULL;
- for (j = 0; j < ar->dimen; j++)
+
+ /* For assumed size, we need to keep around the final
+ reference in order not to get an error on resolution
+ below, and we cannot use AR_FULL. */
+
+ if (ar->as->type == AS_ASSUMED_SIZE)
{
+ ar->type = AR_SECTION;
+ to = ar->dimen - 1;
+ }
+ else
+ {
+ to = ar->dimen;
+ ar->type = AR_FULL;
+ }
+
+ for (j = 0; j < to; j++)
+ {
gfc_free_expr (ar->start[j]);
ar->start[j] = NULL;
gfc_free_expr (ar->end[j]);
! { dg-do compile }
! { dg-additional-options "-ffrontend-optimize" }
! PR 84270 - this used to be rejected.
! Test case by Michael Weinert
module fp_precision
integer, parameter :: fp = selected_real_kind(13)
end module fp_precision
subroutine lhcal(nrot,orth,ngpts,vgauss,vr_0)
use fp_precision ! floating point precision
implicit none
!--->rotation matrices and rotations (input)
integer, intent(in) :: nrot
! real(kind=fp),intent(in) :: orth(3,3,nrot) ! fine at all -O
real(kind=fp),intent(in) :: orth(3,3,*)
!--->gaussian integration points
integer, intent(in) :: ngpts
real(kind=fp),intent(in) :: vgauss(3,*)
!--->output results
real(kind=fp),intent(out) :: vr_0(3)
real(kind=fp) :: v(3),vr(3)
integer :: n,nn
vr_0 = 0
do nn=1,ngpts
v(:) = vgauss(:,nn)
!--->apply rotations
do n=2,nrot
vr = matmul( orth(:,:,n), v )
vr_0 = vr_0 + vr
enddo
enddo
return
end subroutine lhcal
Re: [gomp4] fix an ICE involving assumed-size arrays
Hi!
On Tue, 30 Aug 2016 14:55:06 -0700, Cesar Philippidis
wrote:
> Usually a data clause would would have OMP_CLAUSE_SIZE set, but not all
> do. In the latter case, lower_omp_target falls back to using size of the
> type of the variable specified in the data clause. However, in the case
> of assumed-size arrays, the size of the type may be NULL because its
> undefined. My fix for this solution is to set the size to one byte if
> the size of the type is NULL. This solution at least allows the runtime
> the opportunity to remap any data already present on the accelerator.
> However, if the data isn't present on the accelerator, this will likely
> result in some sort of segmentation fault on the accelerator.
>
> The OpenACC spec is not clear how the compiler should handle
> assumed-sized arrays when the user does not provide an explicit data
> clause with a proper subarray. It was tempting to make such implicit
> variables errors, but arguably that would affect usability. Perhaps I
> should a warning for implicitly used assumed-sizes arrays?
(I don't know a lot about Fortran assumed-size arrays, but I agree that a
user might expect code to work, like that in the example you added.)
> I've applied this patch to gomp-4_0-branch. It looks like OpenMP has a
> similar problem.
... which Jakub for <https://gcc.gnu.org/PR78866> fixed in trunk r243860,
<http://mid.mail-archive.com/20161221161950.GY21933@tucnak> by
"disallow[ing] explicit or implicit OpenMP mapping of assumed-size
arrays". So when merging these two changes, I had to apply the following
additional patch, which will need to get resolved some way or another:
--- gcc/fortran/trans-openmp.c
+++ gcc/fortran/trans-openmp.c
@@ -1048,6 +1048,11 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p)
tree decl = OMP_CLAUSE_DECL (c);
+ /* This conflicts with the OpenACC changes done to support assumed-size
+ arrays that are implicitly mapped after enter data directive (see
+ libgomp.oacc-fortran/assumed-size.f90) -- doesn't the same apply to
+ OpenMP, too? */
+#if 0
/* Assumed-size arrays can't be mapped implicitly, they have to be
mapped explicitly using array sections. */
if (TREE_CODE (decl) == PARM_DECL
@@ -1061,6 +1066,7 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p)
"implicit mapping of assumed size array %qD", decl);
return;
}
+#endif
tree c2 = NULL_TREE, c3 = NULL_TREE, c4 = NULL_TREE;
if (POINTER_TYPE_P (TREE_TYPE (decl)))
--- gcc/testsuite/gfortran.dg/gomp/pr78866-2.f90
+++ gcc/testsuite/gfortran.dg/gomp/pr78866-2.f90
@@ -3,7 +3,8 @@
subroutine pr78866(x)
integer :: x(*)
-!$omp target ! { dg-error "implicit mapping of assumed size array" }
+! Regarding the XFAIL, see gcc/fortran/trans-openmp.c:gfc_omp_finish_clause.
+!$omp target ! { dg-error "implicit mapping of assumed size array"
"" { xfail *-*-* } }
x(1) = 1
!$omp end target
end
For reference, here are Cesar's gomp-4_0-branch r239874 changes:
> --- a/gcc/omp-low.c
> +++ b/gcc/omp-low.c
> @@ -16534,6 +16534,12 @@ lower_omp_target (gimple_stmt_iterator *gsi_p,
> omp_context *ctx)
> s = OMP_CLAUSE_SIZE (c);
> if (s == NULL_TREE)
> s = TYPE_SIZE_UNIT (TREE_TYPE (ovar));
> + /* Fortran assumed-size arrays have zero size because the
> +type is incomplete. Set the size to one to allow the
> +runtime to remap any existing data that is already
> +present on the accelerator. */
> + if (s == NULL_TREE)
> + s = integer_one_node;
> s = fold_convert (size_type_node, s);
> purpose = size_int (map_idx++);
> CONSTRUCTOR_APPEND_ELT (vsize, purpose, s);
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-fortran/assumed-size.f90
> @@ -0,0 +1,31 @@
> +! Test if implicitly determined data clauses work with an
> +! assumed-sized array variable. Note that the array variable, 'a',
> +! has been explicitly copied in and out via acc enter data and acc
> +! exit data, respectively.
(Should add a "dg-do run" directive here?)
> +
> +program test
> + implicit none
> +
> + integer, parameter :: n = 100
> + integer a(n), i
> +
> + call dtest (a, n)
> +
> + do i = 1, n
> + if (a(i) /= i) call abort
> + end do
> +end program test
> +
> +subroutine dtest (a, n)
> + integer i, n
> + integer a(*)
> +
> + !$acc enter data copyin(a(1:n))
> +
> + !$acc parallel loop
> + do i = 1, n
> + a(i) = i
> + end do
> +
> + !$acc exit data copyout(a(1:n))
> +end subroutine dtest
Grüße
Thomas
[committed] Disallow explicit or implicit OpenMP mapping of assumed-size arrays (PR fortran/78866)
Hi!
At least in my reading of the standard OpenMP 4.[05] does not disallow
explicit or implicit mapping of assumed-size arrays, but it is IMNSHO a
defect in the standard, it is something that can't be really supported
because the compiler does not know the size of the assumed size array.
What works and is supported is explicit mapping of array section with
the upper bound specificied, then you give it the size through the array
section. ifort also rejects it. I've raised an OpenMP ticket for this.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk,
queued for 6.4.
2016-12-21 Jakub Jelinek
PR fortran/78866
* openmp.c (resolve_omp_clauses): Diagnose assumed size arrays in
OpenMP map, to and from clauses.
* trans-openmp.c: Include diagnostic-core.h, temporarily redefining
GCC_DIAG_STYLE to __gcc_tdiag__.
(gfc_omp_finish_clause): Diagnose implicitly mapped assumed size
arrays.
* gfortran.dg/gomp/map-1.f90: Add expected error.
* gfortran.dg/gomp/pr78866-1.f90: New test.
* gfortran.dg/gomp/pr78866-2.f90: New test.
--- gcc/fortran/openmp.c.jj 2016-11-10 12:34:12.0 +0100
+++ gcc/fortran/openmp.c2016-12-21 10:36:25.535619047 +0100
@@ -4382,6 +4382,11 @@ resolve_omp_clauses (gfc_code *code, gfc
else
resolve_oacc_data_clauses (n->sym, n->where, name);
}
+ else if (list != OMP_CLAUSE_DEPEND
+&& n->sym->as
+&& n->sym->as->type == AS_ASSUMED_SIZE)
+ gfc_error ("Assumed size array %qs in %s clause at %L",
+n->sym->name, name, &n->where);
if (list == OMP_LIST_MAP && !openacc)
switch (code->op)
{
--- gcc/fortran/trans-openmp.c.jj 2016-12-15 10:26:19.0 +0100
+++ gcc/fortran/trans-openmp.c 2016-12-21 13:11:34.131670305 +0100
@@ -38,6 +38,11 @@ along with GCC; see the file COPYING3.
#include "gomp-constants.h"
#include "omp-general.h"
#include "omp-low.h"
+#undef GCC_DIAG_STYLE
+#define GCC_DIAG_STYLE __gcc_tdiag__
+#include "diagnostic-core.h"
+#undef GCC_DIAG_STYLE
+#define GCC_DIAG_STYLE __gcc_gfc__
int ompws_flags;
@@ -1039,6 +1044,21 @@ gfc_omp_finish_clause (tree c, gimple_se
return;
tree decl = OMP_CLAUSE_DECL (c);
+
+ /* Assumed-size arrays can't be mapped implicitly, they have to be
+ mapped explicitly using array sections. */
+ if (TREE_CODE (decl) == PARM_DECL
+ && GFC_ARRAY_TYPE_P (TREE_TYPE (decl))
+ && GFC_TYPE_ARRAY_AKIND (TREE_TYPE (decl)) == GFC_ARRAY_UNKNOWN
+ && GFC_TYPE_ARRAY_UBOUND (TREE_TYPE (decl),
+ GFC_TYPE_ARRAY_RANK (TREE_TYPE (decl)) - 1)
+== NULL)
+{
+ error_at (OMP_CLAUSE_LOCATION (c),
+ "implicit mapping of assumed size array %qD", decl);
+ return;
+}
+
tree c2 = NULL_TREE, c3 = NULL_TREE, c4 = NULL_TREE;
if (POINTER_TYPE_P (TREE_TYPE (decl)))
{
--- gcc/testsuite/gfortran.dg/gomp/map-1.f90.jj 2015-01-15 23:39:06.0
+0100
+++ gcc/testsuite/gfortran.dg/gomp/map-1.f902016-12-21 13:29:03.333952262
+0100
@@ -70,7 +70,7 @@ subroutine test(aas)
! { dg-error "Rightmost upper bound of assumed size array section not
specified" "" { target *-*-* } 68 }
! { dg-error "'aas' in MAP clause at \\\(1\\\) is not a proper array
section" "" { target *-*-* } 68 }
- !$omp target map(aas) ! { dg-error "The upper bound in the last dimension
must appear" "" { xfail *-*-* } }
+ !$omp target map(aas) ! { dg-error "Assumed size array" }
!$omp end target
!$omp target map(aas(5:7))
--- gcc/testsuite/gfortran.dg/gomp/pr78866-1.f90.jj 2016-12-21
11:16:06.202498432 +0100
+++ gcc/testsuite/gfortran.dg/gomp/pr78866-1.f902016-12-21
11:12:14.0 +0100
@@ -0,0 +1,19 @@
+! PR fortran/78866
+! { dg-do compile }
+
+subroutine pr78866(x)
+ integer :: x(*)
+!$omp target map(x)! { dg-error "Assumed size array" }
+ x(1) = 1
+!$omp end target
+!$omp target data map(tofrom: x) ! { dg-error "Assumed size array" }
+!$omp target update to(x) ! { dg-error "Assumed size array" }
+!$omp target update from(x)! { dg-error "Assumed size array" }
+!$omp end target data
+!$omp target map(x(:23)) ! { dg-bogus "Assumed size array" }
+ x(1) = 1
+!$omp end target
+!$omp target map(x(:)) ! { dg-error "upper bound of assumed
size array section" }
+ x(1) = 1 ! { dg-error "not a proper array
section" "
[gomp4] fix an ICE involving assumed-size arrays
Usually a data clause would would have OMP_CLAUSE_SIZE set, but not all do. In the latter case, lower_omp_target falls back to using size of the type of the variable specified in the data clause. However, in the case of assumed-size arrays, the size of the type may be NULL because its undefined. My fix for this solution is to set the size to one byte if the size of the type is NULL. This solution at least allows the runtime the opportunity to remap any data already present on the accelerator. However, if the data isn't present on the accelerator, this will likely result in some sort of segmentation fault on the accelerator. The OpenACC spec is not clear how the compiler should handle assumed-sized arrays when the user does not provide an explicit data clause with a proper subarray. It was tempting to make such implicit variables errors, but arguably that would affect usability. Perhaps I should a warning for implicitly used assumed-sizes arrays? I've applied this patch to gomp-4_0-branch. It looks like OpenMP has a similar problem. Cesar 2016-08-30 Cesar Philippidis gcc/ * omp-low.c (lower_omp_target): Handle NULL-sized types for assumed-sized arrays. libgomp/ * testsuite/libgomp.oacc-fortran/assumed-size.f90: New test. diff --git a/gcc/omp-low.c b/gcc/omp-low.c index b314523..0faf6c3 100644 --- a/gcc/omp-low.c +++ b/gcc/omp-low.c @@ -16534,6 +16534,12 @@ lower_omp_target (gimple_stmt_iterator *gsi_p, omp_context *ctx) s = OMP_CLAUSE_SIZE (c); if (s == NULL_TREE) s = TYPE_SIZE_UNIT (TREE_TYPE (ovar)); + /* Fortran assumed-size arrays have zero size because the + type is incomplete. Set the size to one to allow the + runtime to remap any existing data that is already + present on the accelerator. */ + if (s == NULL_TREE) + s = integer_one_node; s = fold_convert (size_type_node, s); purpose = size_int (map_idx++); CONSTRUCTOR_APPEND_ELT (vsize, purpose, s); diff --git a/libgomp/testsuite/libgomp.oacc-fortran/assumed-size.f90 b/libgomp/testsuite/libgomp.oacc-fortran/assumed-size.f90 new file mode 100644 index 000..79de675 --- /dev/null +++ b/libgomp/testsuite/libgomp.oacc-fortran/assumed-size.f90 @@ -0,0 +1,31 @@ +! Test if implicitly determined data clauses work with an +! assumed-sized array variable. Note that the array variable, 'a', +! has been explicitly copied in and out via acc enter data and acc +! exit data, respectively. + +program test + implicit none + + integer, parameter :: n = 100 + integer a(n), i + + call dtest (a, n) + + do i = 1, n + if (a(i) /= i) call abort + end do +end program test + +subroutine dtest (a, n) + integer i, n + integer a(*) + + !$acc enter data copyin(a(1:n)) + + !$acc parallel loop + do i = 1, n + a(i) = i + end do + + !$acc exit data copyout(a(1:n)) +end subroutine dtest
[Patch, Fortran, committed] PR 54189: ICE (segfault) with invalid assumed-size dummy
Hi all, I have just committed as obvious a small ICE-on-invalid fix: http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=199445 Cheers, Janus
