Re: [Patch] OpenMP: Handle order(concurrent) clause in gfortran
Hi!
On 2020-07-29T18:30:16+0200, Tobias Burnus wrote:
> Adds 'order(concurrent)'. OpenMP 5.0 also permits it
> for 'loop' but gfortran does not yet support 'loop'.
>
> (That the argument is passed on to the ME can be
> seen by the testcases as the errors are emitted
> by the ME.)
This later got cherry-picked into devel/omp/gcc-10 branch, with FAILing
testcase 'gfortran.dg/gomp/order-4.f90'. I've now pushed "Adjust
'gfortran.dg/gomp/order-4.f90' for og10" to devel/omp/gcc-10 branch in
commit b0e5c3b84ef2c477fe797da59a1aadfbed8445fe, see attached.
Grüße
Thomas
> OpenMP: Handle order(concurrent) clause in gfortran
>
> gcc/fortran/ChangeLog:
>
> * dump-parse-tree.c (show_omp_clauses): Handle order(concurrent).
> * gfortran.h (struct gfc_omp_clauses): Add order_concurrent.
> * openmp.c (enum omp_mask1, OMP_DO_CLAUSES, OMP_SIMD_CLAUSES):
> Add OMP_CLAUSE_ORDER.
> * trans-openmp.c (gfc_trans_omp_clauses, gfc_split_omp_clauses):
> Handle order(concurrent) clause.
>
> gcc/testsuite/ChangeLog:
>
> * gfortran.dg/gomp/order-3.f90: New test.
> * gfortran.dg/gomp/order-4.f90: New test.
>
> gcc/fortran/dump-parse-tree.c | 2 +
> gcc/fortran/gfortran.h | 2 +-
> gcc/fortran/openmp.c | 12 +-
> gcc/fortran/trans-openmp.c | 12 ++
> gcc/testsuite/gfortran.dg/gomp/order-3.f90 | 227
> +
> gcc/testsuite/gfortran.dg/gomp/order-4.f90 | 34 +
> 6 files changed, 286 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
> index 2a02bc871bc..71d0e7d00f5 100644
> --- a/gcc/fortran/dump-parse-tree.c
> +++ b/gcc/fortran/dump-parse-tree.c
> @@ -1552,6 +1552,8 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
> fputs (" SEQ", dumpfile);
>if (omp_clauses->independent)
> fputs (" INDEPENDENT", dumpfile);
> + if (omp_clauses->order_concurrent)
> +fputs (" ORDER(CONCURRENT)", dumpfile);
>if (omp_clauses->ordered)
> {
>if (omp_clauses->orderedc)
> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
> index 20cce5cf39b..48b2ab14fdb 100644
> --- a/gcc/fortran/gfortran.h
> +++ b/gcc/fortran/gfortran.h
> @@ -1365,7 +1365,7 @@ typedef struct gfc_omp_clauses
>bool nowait, ordered, untied, mergeable;
>bool inbranch, notinbranch, defaultmap, nogroup;
>bool sched_simd, sched_monotonic, sched_nonmonotonic;
> - bool simd, threads, depend_source;
> + bool simd, threads, depend_source, order_concurrent;
>enum gfc_omp_cancel_kind cancel;
>enum gfc_omp_proc_bind_kind proc_bind;
>struct gfc_expr *safelen_expr;
> diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
> index 16f39a4e086..ec116206a5c 100644
> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c
> @@ -766,6 +766,7 @@ enum omp_mask1
>OMP_CLAUSE_NUM_THREADS,
>OMP_CLAUSE_SCHEDULE,
>OMP_CLAUSE_DEFAULT,
> + OMP_CLAUSE_ORDER,
>OMP_CLAUSE_ORDERED,
>OMP_CLAUSE_COLLAPSE,
>OMP_CLAUSE_UNTIED,
> @@ -1549,6 +1550,13 @@ gfc_match_omp_clauses (gfc_omp_clauses **cp, const
> omp_mask mask,
> continue;
> break;
> case 'o':
> + if ((mask & OMP_CLAUSE_ORDER)
> + && !c->order_concurrent
> + && gfc_match ("order ( concurrent )") == MATCH_YES)
> + {
> + c->order_concurrent = true;
> + continue;
> + }
> if ((mask & OMP_CLAUSE_ORDERED)
> && !c->ordered
> && gfc_match ("ordered") == MATCH_YES)
> @@ -2575,7 +2583,7 @@ cleanup:
>(omp_mask (OMP_CLAUSE_PRIVATE) | OMP_CLAUSE_FIRSTPRIVATE \
> | OMP_CLAUSE_LASTPRIVATE | OMP_CLAUSE_REDUCTION \
> | OMP_CLAUSE_SCHEDULE | OMP_CLAUSE_ORDERED | OMP_CLAUSE_COLLAPSE \
> - | OMP_CLAUSE_LINEAR)
> + | OMP_CLAUSE_LINEAR | OMP_CLAUSE_ORDER)
> #define OMP_SECTIONS_CLAUSES \
>(omp_mask (OMP_CLAUSE_PRIVATE) | OMP_CLAUSE_FIRSTPRIVATE \
> | OMP_CLAUSE_LASTPRIVATE | OMP_CLAUSE_REDUCTION)
> @@ -2583,7 +2591,7 @@ cleanup:
>(omp_mask (OMP_CLAUSE_PRIVATE) | OMP_CLAUSE_LASTPRIVATE\
> | OMP_CLAUSE_REDUCTION | OMP_CLAUSE_COLLAPSE | OMP_CLAUSE_SAFELEN \
> | OMP_CLAUSE_LINEAR | OMP_CLAUSE_ALIGNED | OMP_CLAUSE_SIMDLEN \
> - | OMP_CLAUSE_IF)
> + | OMP_CLAUSE_IF | OMP_CLAUSE_ORDER)
> #define OMP_TASK_CLAUSES \
>(omp_mask (OMP_CLAUSE_PRIVATE) | OMP_CLAUSE_FIRSTPRIVATE \
> | OMP_CLAUSE_SHARED | OMP_CLAUSE_IF | OMP_CLAUSE_DEFAULT \
> diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
> index f6a39edf121..076efb03831 100644
> --- a/gcc/fortran/trans-openmp.c
> +++ b/gcc/fortran/trans-openmp.c
> @@ -3371,6 +3371,12 @@ gfc_trans_omp_clauses (stmtblock_t *block,
> gfc_omp_clauses *clauses,
>omp_clauses = gfc_trans_add_clause (c, omp_clauses);
> }
>
> + if (clauses->order_concurrent)
> +{
> + c = build_omp_clause (
Re: [PATCH 1/2] openacc: Fix lowering for derived-type mappings through array elements
Hi!
On 2021-02-12T07:46:48-0800, Julian Brown wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90
> @@ -0,0 +1,109 @@
> +[...]
> +!$acc serial present(var3%t2(5)%t1%arr1)
> +var3%t2(5)%t1%arr1(:,:) = 6
> +!$acc end serial
> +[...]
I've pushed "'libgomp.oacc-fortran/derivedtypes-arrays-1.f90' OpenACC
'serial' construct diagnostic for nvptx offloading" to master branch in
commit 8bafce1be11a301c2421483736c634b8bf330e69, and cherry-picked into
devel/omp/gcc-10 branch in commit
c89b23b73edeeb7e3d8cbad278e505c2d6d770c4, see attached.
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
>From 8bafce1be11a301c2421483736c634b8bf330e69 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Thu, 11 Mar 2021 10:52:59 +0100
Subject: [PATCH] 'libgomp.oacc-fortran/derivedtypes-arrays-1.f90' OpenACC
'serial' construct diagnostic for nvptx offloading
Fixup for recent commit d28f3da11d8c0aed9b746689d723022a9b5ec04c "openacc: Fix
lowering for derived-type mappings through array elements". With nvptx
offloading we see the usual:
[...]/libgomp.oacc-fortran/derivedtypes-arrays-1.f90: In function 'MAIN__._omp_fn.0':
[...]/libgomp.oacc-fortran/derivedtypes-arrays-1.f90:90:40: warning: using vector_length (32), ignoring 1
libgomp/
* testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90:
OpenACC 'serial' construct diagnostic for nvptx offloading.
---
libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90 | 1 +
1 file changed, 1 insertion(+)
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90 b/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90
index 644ad1f6b2fc..7bca2df66285 100644
--- a/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90
+++ b/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90
@@ -88,6 +88,7 @@ end do
!$acc data copyin(var3%t2(5)%t1%arr1)
!$acc serial present(var3%t2(5)%t1%arr1)
+! { dg-warning "using vector_length \\(32\\), ignoring 1" "" { target openacc_nvidia_accel_selected } .-1 }
var3%t2(5)%t1%arr1(:,:) = 6
!$acc end serial
--
2.30.2
>From c89b23b73edeeb7e3d8cbad278e505c2d6d770c4 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Thu, 11 Mar 2021 10:52:59 +0100
Subject: [PATCH] 'libgomp.oacc-fortran/derivedtypes-arrays-1.f90' OpenACC
'serial' construct diagnostic for nvptx offloading
Fixup for recent commit d28f3da11d8c0aed9b746689d723022a9b5ec04c "openacc: Fix
lowering for derived-type mappings through array elements". With nvptx
offloading we see the usual:
[...]/libgomp.oacc-fortran/derivedtypes-arrays-1.f90: In function 'MAIN__._omp_fn.0':
[...]/libgomp.oacc-fortran/derivedtypes-arrays-1.f90:90:40: warning: using vector_length (32), ignoring 1
libgomp/
* testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90:
OpenACC 'serial' construct diagnostic for nvptx offloading.
(cherry picked from commit 8bafce1be11a301c2421483736c634b8bf330e69)
---
libgomp/ChangeLog.omp | 3 +++
.../testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90 | 1 +
2 files changed, 4 insertions(+)
diff --git a/libgomp/ChangeLog.omp b/libgomp/ChangeLog.omp
index 19f48dc61202..05788d5c27a2 100644
--- a/libgomp/ChangeLog.omp
+++ b/libgomp/ChangeLog.omp
@@ -1,5 +1,8 @@
2021-03-25 Thomas Schwinge
+ * testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90:
+ OpenACC 'serial' construct diagnostic for nvptx offloading.
+
* plugin/plugin-hsa.c (GOMP_OFFLOAD_supported_features): New
function.
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90 b/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90
index 644ad1f6b2fc..7bca2df66285 100644
--- a/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90
+++ b/libgomp/testsuite/libgomp.oacc-fortran/derivedtypes-arrays-1.f90
@@ -88,6 +88,7 @@ end do
!$acc data copyin(var3%t2(5)%t1%arr1)
!$acc serial present(var3%t2(5)%t1%arr1)
+! { dg-warning "using vector_length \\(32\\), ignoring 1" "" { target openacc_nvidia_accel_selected } .-1 }
var3%t2(5)%t1%arr1(:,:) = 6
!$acc end serial
--
2.30.2
Re: [Patch] Fortran: Fix intrinsic null() handling [PR99651]
Hi Tobias, Please go ahead and commit the patch. I think that your analysis is correct about expr_null and that your patch is the best way to deal with the problem. Best regards Paul On Tue, 23 Mar 2021 at 17:54, Tobias Burnus wrote: > Hi Paul, > > On 23.03.21 18:34, Paul Richard Thomas wrote: > > I took something of a detour in reviewing this patch. Although short, > > understanding it is not straightforward! > > I concur – and as I wrote both in the patch email and in the PR, it is > not straight forward which message is showing with which setting. > > Actually, I think there are many straight-forward ways to fix it > "properly" but they tend to hide some nicer error messages in favour of > a more generic one. Only by taking into account all the diagnostic and > hidden/delayed diagnostic, the patch becomes complex. (-: > > > Your patch works as advertised and regtests OK (with the patch for > > PR93660 on board as well). Is NULL the only case where this can happen? > > I am not sure whether any other code would profit form getting one of > the attributes conditionally assigned in intrinsic.c. > > Otherwise, I think that's the only code which verifies like that it in > such a way whether an intrinsic function was used. I think the reason > that it does so is because 'null' is turned early during parsing into > EXPR_NULL, which is not a function and, hence, bypasses some of the > later checking code in resolve.c. > > > > Just to aid my understanding, I tried: > > diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c > > > > --- a/gcc/fortran/primary.c > > +++ b/gcc/fortran/primary.c > > @@ -3922,6 +3922,9 @@ gfc_match_rvalue (gfc_expr **result) > >if (m == MATCH_NO) > > m = MATCH_YES; > > > > + if (!strcmp (sym->name, "NULL") || !strcmp (sym->name, "null")) > > + sym->attr.intrinsic = 1; > > + > >break; > > > > generic_function: > > > > which also works and regtests OK. (I couldn't remember whether > > sym->name is upper or lower case at this stage.) > > Should be always lowercase, I think. But I am also not sure that your > aid-understanding patch will work correctly with 'external null' or a > use-/host-associated/interface 'null' procedure or some array variable. > Inside intrinsic.c, we are at least sure that we did get an intrinsic > function after having passed all intrinsic checks. > > Tobias > > - > Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank > Thürauf > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[Patch, fortran] PR99602 - [11 regression] runtime error: pointer actual argument not associated
This patch is straightforward but the isolation of the problem was rather
less so. Many thanks to Juergen for testcase reduction.
Regtested on FC33/x86_64 - OK for master?
Paul
Fortran: Fix problem with runtime pointer chack [PR99602].
2021-03-26 Paul Thomas
gcc/fortran/ChangeLog
PR fortran/99602
* trans-expr.c (gfc_conv_procedure_call): Use the _data attrs
for class expressions and detect proc pointer evaluations by
the non-null actual argument list.
gcc/testsuite/ChangeLog
PR fortran/99602
* gfortran.dg/pr99602.f90: New test.
* gfortran.dg/pr99602a.f90: New test.
* gfortran.dg/pr99602b.f90: New test.
! { dg-do compile }
! { dg-options "-fcheck=pointer -fdump-tree-original" }
!
! Test fix of PR99602, where a spurious runtime error was introduced
! by PR99112. This is the testcase in comment #6 of the PR.
! This version of PR99602.f90 turns on the runtime errors by eliminating
! the pointer attribute from the formal arguments in the abstract interface
! and prepare_whizard_m2.
!
! Contributed by Jeurgen Reuter
!
module m
implicit none
private
public :: m_t
type :: m_t
private
end type m_t
end module m
module m2_testbed
use m
implicit none
private
public :: prepare_m2
procedure (prepare_m2_proc), pointer :: prepare_m2 => null ()
abstract interface
subroutine prepare_m2_proc (m2)
import
class(m_t), intent(inout) :: m2
end subroutine prepare_m2_proc
end interface
end module m2_testbed
module a
use m
use m2_testbed, only: prepare_m2
implicit none
private
public :: a_1
contains
subroutine a_1 ()
class(m_t), pointer :: mm
mm => null ()
call prepare_m2 (mm) ! Runtime error triggered here
end subroutine a_1
end module a
module m2
use m
implicit none
private
public :: m2_t
type, extends (m_t) :: m2_t
private
contains
procedure :: read => m2_read
end type m2_t
contains
subroutine m2_read (mm)
class(m2_t), intent(out), target :: mm
end subroutine m2_read
end module m2
program main
use m2_testbed
use a, only: a_1
implicit none
prepare_m2 => prepare_whizard_m2
call a_1 ()
contains
subroutine prepare_whizard_m2 (mm)
use m
use m2
class(m_t), intent(inout) :: mm
select type (mm)
type is (m2_t)
call mm%read ()
end select
end subroutine prepare_whizard_m2
end program main
! { dg-final { scan-tree-dump-times "_gfortran_runtime_error_at" 1 "original" } }
! { dg-final { scan-tree-dump-times "Pointer actual argument" 1 "original" } }
! { dg-do compile }
! { dg-options "-fcheck=pointer -fdump-tree-original" }
!
! Test fix of PR99602, where a spurious runtime error was introduced
! by PR99112. This is the testcase in comment #6 of the PR.
! PR99602a.f90 turns on the runtime errors by eliminating the pointer
! attribute from the formal arguments in the abstract interface and
! prepare_whizard_m2.
!
! Contributed by Jeurgen Reuter
!
module m
implicit none
private
public :: m_t
type :: m_t
private
end type m_t
end module m
module m2_testbed
use m
implicit none
private
public :: prepare_m2
procedure (prepare_m2_proc), pointer :: prepare_m2 => null ()
abstract interface
subroutine prepare_m2_proc (m2)
import
class(m_t), intent(inout), pointer :: m2
end subroutine prepare_m2_proc
end interface
end module m2_testbed
module a
use m
use m2_testbed, only: prepare_m2
implicit none
private
public :: a_1
contains
subroutine a_1 ()
class(m_t), pointer :: mm
mm => null ()
call prepare_m2 (mm) ! Runtime error triggered here
end subroutine a_1
end module a
module m2
use m
implicit none
private
public :: m2_t
type, extends (m_t) :: m2_t
private
contains
procedure :: read => m2_read
end type m2_t
contains
subroutine m2_read (mm)
class(m2_t), intent(out), target :: mm
end subroutine m2_read
end module m2
program main
use m2_testbed
use a, only: a_1
implicit none
prepare_m2 => prepare_whizard_m2
call a_1 ()
contains
subroutine prepare_whizard_m2 (mm)
use m
use m2
class(m_t), intent(inout), pointer :: mm
if (.not. associated (mm)) allocate (m2_t :: mm)
select type (mm)
type is (m2_t)
! call mm%read () ! Since mm is passed to non-pointer, this generates the error code.
end select
end subroutine prepare_whizard_m2
end program main
! { dg-final { scan-tree-dump-times "_gfortran_runtime_error_at" 0 "original" } }
! { dg-final { scan-tree-dump-times "Pointer actual argument" 0 "original" } }
! { dg-do run }
! { dg-options "-fcheck=pointer" }
!
! Test the fix for PR99602 in which the runtime error,
! "Proc-pointer actual argument 'model' is not associated" was triggered
! by the NULL result from model%get_par_data_ptr ("tea ")
!
! Contributed by Juergen Reuter
!
module model_data
type :: model_data_t
type(modelpar_real_t), dimension(:), pointer :: par_real => null ()
contains
procedure
