public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Julian Brown <julian@codesourcery.com>
To: <gcc-patches@gcc.gnu.org>
Cc: <fortran@gcc.gnu.org>, <jakub@redhat.com>, <tobias@codesourcery.com>
Subject: [PATCH 13/14] OpenACC: Allow implicit uses of assumed-size arrays in offload regions
Date: Mon, 19 Jun 2023 21:17:37 +0000	[thread overview]
Message-ID: <2cc6dd851955f96cf0e11c419b5105a5c0be6940.1687201316.git.julian@codesourcery.com> (raw)
In-Reply-To: <cover.1687201315.git.julian@codesourcery.com>

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  <julian@codesourcery.com>

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 00000000000..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 00000000000..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 how this works.  The "enter data"
+! and "exit data" operations expand to a pair of mapping nodes for OpenACC,
+! GOMP_MAP_{TO/FROM} and GOMP_MAP_POINTER.  The former maps the array data,
+! and the latter creates a separate mapping on the target for the pointer
+! itself with a bias so it represents the "zeroth" element.
+
+!$acc enter data copyin(arr(2:8))
+
+! ...then this implicit mapping creates a zero-length array section
+! (GOMP_MAP_ZERO_LEN_ARRAY_SECTION) followed by another GOMP_MAP_POINTER for
+! 'arr'.  But now that pointer is already "present" on the target, so is not
+! overwritten.
+
+!$acc serial
+! This access is then done via the on-target pointer.
+arr(5) = 5
+!$acc end serial
+
+!$acc exit data copyout(arr(2:8))
+
+end subroutine subr
+end program p
-- 
2.31.1


  parent reply	other threads:[~2023-06-19 21:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-19 21:17 [PATCH 00/14] [og13] OpenMP/OpenACC: map clause and OMP gimplify rework Julian Brown
2023-06-19 21:17 ` [PATCH 01/14] Revert "Assumed-size arrays with non-lexical data mappings" Julian Brown
2023-06-19 21:17 ` [PATCH 02/14] Revert "Fix references declared in lexically-enclosing OpenACC data region" Julian Brown
2023-06-19 21:17 ` [PATCH 03/14] Revert "Fix implicit mapping for array slices on lexically-enclosing data constructs (PR70828)" Julian Brown
2023-06-19 21:17 ` [PATCH 04/14] Revert "openmp: Handle C/C++ array reference base-pointers in array sections" Julian Brown
2023-06-19 21:17 ` [PATCH 05/14] OpenMP/OpenACC: Reindent TO/FROM/_CACHE_ stanza in {c_}finish_omp_clause Julian Brown
2023-06-19 21:17 ` [PATCH 06/14] OpenMP/OpenACC: Rework clause expansion and nested struct handling Julian Brown
2023-06-19 21:17 ` [PATCH 07/14] OpenMP: implicitly map base pointer for array-section pointer components Julian Brown
2023-06-19 21:17 ` [PATCH 08/14] OpenMP: Pointers and member mappings Julian Brown
2023-06-19 21:17 ` [PATCH 09/14] OpenMP/OpenACC: Unordered/non-constant component offset runtime diagnostic Julian Brown
2023-06-19 21:17 ` [PATCH 10/14] OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc Julian Brown
2023-06-19 21:17 ` [PATCH 11/14] OpenACC: Reimplement "inheritance" for lexically-nested offload regions Julian Brown
2023-06-19 21:17 ` [PATCH 12/14] OpenACC: "declare create" fixes wrt. "allocatable" variables Julian Brown
2023-06-19 21:17 ` Julian Brown [this message]
2023-06-19 21:17 ` [PATCH 14/14] OpenACC: Improve implicit mapping for non-lexically nested offload regions Julian Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2cc6dd851955f96cf0e11c419b5105a5c0be6940.1687201316.git.julian@codesourcery.com \
    --to=julian@codesourcery.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=tobias@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).