public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Tobias Burnus <tobias@codesourcery.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, fortran <fortran@gcc.gnu.org>
Subject: Re: [Patch] OpenMP/Fortran: Fix loop-iter var privatization with !$OMP LOOP [PR108512]
Date: Tue, 31 Jan 2023 12:20:01 +0100	[thread overview]
Message-ID: <Y9j5YejeoZOGHWQN@tucnak> (raw)
In-Reply-To: <e8e85a77-ce5e-31b5-5b5f-cd9ee1b2ac4a@codesourcery.com>

On Tue, Jan 24, 2023 at 04:24:07PM +0100, Tobias Burnus wrote:
> gcc/fortran/ChangeLog:
> 
> 	PR fortran/108512
> 	* openmp.cc (gfc_resolve_omp_do_blocks): Don't check 'inscan'
> 	restrictions for loop as rejected elsewhere.
> 	(gfc_resolve_do_iterator): Set a source location for added
> 	'private'-clause arguments.
> 	* resolve.cc (gfc_resolve_code): Call gfc_resolve_omp_do_blocks
> 	also for EXEC_OMP_LOOP.
> 
> gcc/testsuite/ChangeLog:
> 
> 	PR fortran/108512
> 	* gfortran.dg/gomp/loop-5.f90: New test.
> 
>  gcc/fortran/openmp.cc                     |  5 +-
>  gcc/fortran/resolve.cc                    |  1 +
>  gcc/testsuite/gfortran.dg/gomp/loop-5.f90 | 84 +++++++++++++++++++++++++++++++
>  3 files changed, 89 insertions(+), 1 deletion(-)
> 
> diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
> index cc1eab90b8c..7673a52249f 100644
> --- a/gcc/fortran/openmp.cc
> +++ b/gcc/fortran/openmp.cc
> @@ -9056,7 +9056,9 @@ gfc_resolve_omp_do_blocks (gfc_code *code, gfc_namespace *ns)
>  	}
>        if (i < omp_current_do_collapse || omp_current_do_collapse <= 0)
>  	omp_current_do_collapse = 1;
> -      if (code->ext.omp_clauses->lists[OMP_LIST_REDUCTION_INSCAN])
> +      if (code->op == EXEC_OMP_LOOP)
> +	;  /* Already rejected in resolve_omp_clauses.  */

I don't understand why is this needed.  Sure, the vast majority of
constructs don't allow reduction(inscan, ...), do we need to list them all?
Is EXEC_OMP_LOOP somehow reusing that list for something else?  What about
EXEC_OMP_*_LOOP?  If not, how does that differ say from EXEC_OMP_DISTRIBUTE
or EXEC_OMP_TASKLOOP and many others?

If it is rejected earlier, then perhaps we should free/clear the list
after we diagnose it if it causes harm later.

> +      else if (code->ext.omp_clauses->lists[OMP_LIST_REDUCTION_INSCAN])
>  	{
>  	  locus *loc
>  	    = &code->ext.omp_clauses->lists[OMP_LIST_REDUCTION_INSCAN]->where;
> @@ -9224,6 +9226,7 @@ gfc_resolve_do_iterator (gfc_code *code, gfc_symbol *sym, bool add_clause)
>  
>        p = gfc_get_omp_namelist ();
>        p->sym = sym;
> +      p->where = omp_current_ctx->code->loc;
>        p->next = omp_clauses->lists[OMP_LIST_PRIVATE];
>        omp_clauses->lists[OMP_LIST_PRIVATE] = p;
>      }

Ok.

> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 94213cd3cd4..bd2a749776d 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -11950,6 +11950,7 @@ gfc_resolve_code (gfc_code *code, gfc_namespace *ns)
>  	    case EXEC_OMP_DISTRIBUTE_SIMD:
>  	    case EXEC_OMP_DO:
>  	    case EXEC_OMP_DO_SIMD:
> +	    case EXEC_OMP_LOOP:
>  	    case EXEC_OMP_SIMD:
>  	    case EXEC_OMP_TARGET_SIMD:
>  	      gfc_resolve_omp_do_blocks (code, ns);

I'm afraid this is needed but insufficient.
I think
            case EXEC_OMP_MASKED_TASKLOOP:
            case EXEC_OMP_MASKED_TASKLOOP_SIMD:
            case EXEC_OMP_MASTER_TASKLOOP:
            case EXEC_OMP_MASTER_TASKLOOP_SIMD:
	    case EXEC_OMP_PARALLEL_LOOP:
	    case EXEC_OMP_TARGET_PARALLEL_LOOP:
	    case EXEC_OMP_TARGET_TEAMS_LOOP:
	    case EXEC_OMP_TARGET_SIMD:
	    case EXEC_OMP_TEAMS_LOOP:
should be in the list above (of course alphabetically sorted in between the
others)
	      gfc_resolve_omp_parallel_blocks (code, ns);
(the non-parallel-workshare one).
Went through the c-family/c-omp.cc list in comment above splitting
function and checked all appropriate constructs there...

> diff --git a/gcc/testsuite/gfortran.dg/gomp/loop-5.f90 b/gcc/testsuite/gfortran.dg/gomp/loop-5.f90
> new file mode 100644
> index 00000000000..1948e782653
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/gomp/loop-5.f90
> @@ -0,0 +1,84 @@
> +! { dg-additional-options "-fdump-tree-original" }
> +!
> +! PR fortran/108512
> +
> +! The problem was that the context wasn't reset for the 'LOOP'
> +! such that the clauses of the loops weren't seen when adding
> +! PRIVATE clauses.
> +!
> +! In the following, only the loop variable of the non-OpenMP loop
> +! in 'subroutine four' should get a front-end addded PRIVATE clause
> +
> +implicit none
> +integer :: x, a(10), b(10), n
> +    n = 10
> +    a = -42
> +    b = [(2*x, x=1,10)]
> +
> +! { dg-final { scan-tree-dump-times "#pragma omp target map\\(tofrom:a\\) map\\(tofrom:b\\) map\\(tofrom:x\\)\[\r\n\]" 1 "original" } }
> +! { dg-final { scan-tree-dump-times "#pragma omp parallel\[\r\n\]" 2 "original" } }
> +!  ^- shows up twice; checked only here.
> +! { dg-final { scan-tree-dump-times "#pragma omp loop lastprivate\\(x\\)\[\r\n\]" 1 "original" } }
> +
> +    !$omp target parallel map(tofrom: a, b, x)
> +    !$omp loop lastprivate(x)
> +    DO x = 1, n
> +      a(x) = a(x) + b(x)
> +    END DO
> +    !$omp end loop
> +    !$omp end target parallel
> +    if (x /= 11) error stop
> +    if (any (a /= [(2*x - 42, x=1,10)])) error stop
> +    call two()
> +    call three()
> +    call four()
> +end
> +
> +subroutine two
> +  implicit none
> +  integer :: ii, mm, arr(10)
> +  mm = 10
> +  arr = 0
> +
> +! { dg-final { scan-tree-dump-times "#pragma omp target map\\(tofrom:arr\\) map\\(tofrom:ii\\)\[\r\n\]" 1 "original" } }
> +! { dg-final { scan-tree-dump-times "#pragma omp parallel shared\\(ii\\)\[\r\n\]" 1 "original" } }
> +! { dg-final { scan-tree-dump-times "#pragma omp loop lastprivate\\(ii\\)\[\r\n\]" 1 "original" } }
> +
> +  !$omp target parallel loop map(tofrom: arr) lastprivate(ii)
> +    DO ii = 1, mm
> +      arr(ii) = arr(ii) + ii
> +    END DO
> +end
> +
> +subroutine three
> +  implicit none
> +  integer :: kk, zz, var(10)
> +  zz = 10
> +  var = 0
> +
> +! { dg-final { scan-tree-dump-times "#pragma omp target map\\(tofrom:var\\)\[\r\n\]" 1 "original" } }
> +! "#pragma omp parallel\[\r\n\]" - shows up twice, dump checked above
> +! { dg-final { scan-tree-dump-times "#pragma omp loop\[\r\n\]" 1 "original" } }
> +
> +  !$omp target parallel loop map(tofrom: var)
> +    DO kk = 1, zz
> +      var(kk) = var(kk) + kk
> +    END DO
> +end
> +
> +subroutine four
> +  implicit none
> +  integer :: jj, qq, dist(10)
> +  qq = 10
> +  dist = 0
> +
> +! { dg-final { scan-tree-dump-times "#pragma omp target map\\(tofrom:dist\\)\[\r\n\]" 1 "original" } }
> +! { dg-final { scan-tree-dump-times "#pragma omp parallel private\\(jj\\)\[\r\n\]" 1 "original" } }
> +
> +  !$omp target parallel map(tofrom: dist)
> +    ! *no* '!$omp do/loop/simd'
> +    DO jj = 1, qq
> +      dist(qq) = dist(qq) + qq
> +    END DO
> +  !$omp end target parallel
> +end


	Jakub


  reply	other threads:[~2023-01-31 11:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-24 15:24 Tobias Burnus
2023-01-31 11:20 ` Jakub Jelinek [this message]
2023-02-10 11:52   ` [Patch][v2] " Tobias Burnus
2023-02-15 10:07     ` Jakub Jelinek

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=Y9j5YejeoZOGHWQN@tucnak \
    --to=jakub@redhat.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --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).