Re: [PATCH] Fortran: Fix clause splitting for OMP masked taskloop directive

2022-04-05 Thread Jakub Jelinek via Fortran
On Fri, Mar 25, 2022 at 08:02:04PM -0600, Sandra Loosemore wrote:
> I ran into this bug in the handling of clauses on the combined "masked
> taskloop" OMP directive when I was working on something else.  The fix
> turned out to be a 1-liner.  OK for trunk?
> 
> -Sandra

> commit 17c4fa0bd97c070945004095a06fb7d9e91869e3
> Author: Sandra Loosemore 
> Date:   Wed Mar 23 18:45:25 2022 -0700
> 
> Fortran: Fix clause splitting for OMP masked taskloop directive
> 
> This patch fixes an obvious coding goof that caused all clauses for
> the combined OMP masked taskloop directive to be discarded.
> 
>   gcc/fortran/
>   * trans-openmp.cc (gfc_split_omp_clauses): Fix mask for
>   EXEC_OMP_MASKED_TASKLOOP.
> 
>   gcc/testsuite/
>   * gfortran.dg/gomp/masked-taskloop.f90: New.

Ok, thanks.

> +! { dg-final { scan-tree-dump "omp taskloop collapse\\(2\\) 
> grainsize\\(4\\)" "original" } }

Though perhaps the test should be more flexible and allow both orderings of
the clauses and extra clauses too?  So:
! { dg-final { scan-tree-dump "omp taskloop \[^\n\r]*grainsize\\(4\\)" 
"original" } }
! { dg-final { scan-tree-dump "omp taskloop \[^\n\r]*collapse\\(2\\)" 
"original" } }
?

Jakub



Re: [PATCH] Fortran: Add location info to OpenMP tree nodes

2022-04-05 Thread Jakub Jelinek via Fortran
On Fri, Mar 25, 2022 at 08:03:09PM -0600, Sandra Loosemore wrote:
> I've got another patch forthcoming (stage 1 material) that adds some new
> diagnostics for non-rectangular loops during gimplification of OMP nodes.
> When I was working on that, I discovered that the Fortran front end wasn't
> attaching location information to the tree nodes corresponding to the
> various OMP directives, so the new errors weren't coming out with location
> info either.  I went through trans-openmp.cc and fixed all the places where
> make_node was being called to explicitly set the location.
> 
> I don't have a test case specifically for this change, but my test cases for
> the new diagnostics in the non-rectangular loops patch do exercise it.  Is
> this OK for trunk now, or for stage 1 when we get there?

Ok for GCC 13.

> commit 4c745003d0b39d0e92032b62421df4920753783a
> Author: Sandra Loosemore 
> Date:   Thu Mar 24 21:02:34 2022 -0700
> 
> Fortran: Add location info to OpenMP tree nodes
> 
>gcc/fortran/
>* trans-openmp.cc (gfc_trans_omp_critical): Set location on OMP
>tree node.
>(gfc_trans_omp_do): Likewise.
>(gfc_trans_omp_masked): Likewise.
>(gfc_trans_omp_do_simd): Likewise.
>(gfc_trans_omp_scope): Likewise.
>(gfc_trans_omp_taskgroup): Likewise.
>(gfc_trans_omp_taskwait): Likewise.
>(gfc_trans_omp_distribute): Likewise.
>(gfc_trans_omp_taskloop): Likewise.
>(gfc_trans_omp_master_masked_taskloop): Likewise.

Jakub



[PATCH] PR fortran/104812: generate error for constuct-name clash with symbols

2022-04-05 Thread Mike Kashkarov via Fortran

Greetings,

Propose patch for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104812 to
reject non-conforming code when construct-name clashes with already
defined symbol names, e.g:

 subroutine s1
   logical :: x
   x: if (x) then ! Currently gfortran accepts 'x' as constuct-name
   end if x
 end
 
Steve Kargl poited that (Fortran 2018, 19.4, p 498):

   Identifiers of entities, other than statement or construct entities (19.4),
   in the classes

 (1) named variables, ..., named constructs, ...,

  Within its scope, a local identifier of one class shall not be the
  same as another local identifier of the same class,
  

Regtested on x86_64-pc-linux-gnu, OK for mainline?

Thanks.


>From 7c2749e3963733bf862fc58d3a068b0468a68c7f Mon Sep 17 00:00:00 2001
From: Mike Kashkarov 
Date: Mon, 14 Mar 2022 12:31:23 +0900
Subject: [PATCH] PR fortran/104812: generate error for constuct-name clash with symbols

gcc/fortran/ChangeLog:

	PR fortran/104812
	* match.cc (gfc_match_label): Add new error message if constuct-name
	conflicts with other symbols in scope.

gcc/testsuite/ChangeLog:

	PR fortran/102332
	* gcc/testsuite/gfortran.dg/pr104812.f90: New test.
	* gcc/testsuite/gfortran.dg/pr65045.f90: Update.
---
 gcc/fortran/match.cc   | 17 +
 gcc/testsuite/gfortran.dg/pr104812.f90 | 35 ++
 gcc/testsuite/gfortran.dg/pr65045.f90  | 17 ++---
 3 files changed, 60 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr104812.f90

diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index 8edfe4a3a2d..8226fd4322b 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -576,6 +576,7 @@ cleanup:
 static match
 gfc_match_label (void)
 {
+  gfc_symtree *st;
   char name[GFC_MAX_SYMBOL_LEN + 1];
   match m;
 
@@ -585,6 +586,15 @@ gfc_match_label (void)
   if (m != MATCH_YES)
 return m;
 
+  // Check if we have symbol with matched name in scope.
+  // From 19.3.1:
+  //  Identifiers of entities, other than statement or construct entities (19.4),
+  //  in the classes
+  //(1) named variables, ..., named constructs, ...,
+  // Within its scope, a local identifier of one class shall not be the
+  // same as another local identifier of the same class, ...
+  st = gfc_find_symtree (gfc_current_ns->sym_root, name);
+
   if (gfc_get_symbol (name, NULL, &gfc_new_block))
 {
   gfc_error ("Label name %qs at %C is ambiguous", name);
@@ -597,6 +607,13 @@ gfc_match_label (void)
   return MATCH_ERROR;
 }
 
+  if (st != 0)
+{
+  gfc_error ("Construct label %qs at %C already defined here %L", name,
+ &st->n.sym->declared_at);
+  return MATCH_ERROR;
+}
+
   if (!gfc_add_flavor (&gfc_new_block->attr, FL_LABEL,
 		   gfc_new_block->name, NULL))
 return MATCH_ERROR;
diff --git a/gcc/testsuite/gfortran.dg/pr104812.f90 b/gcc/testsuite/gfortran.dg/pr104812.f90
new file mode 100644
index 000..d103e93a184
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr104812.f90
@@ -0,0 +1,35 @@
+! { dg-do compile }
+
+subroutine s0
+  logical :: x ! { dg-error "Construct label .x. at .1. already defined here .2." }
+  x: block ! { dg-error "Construct label .x. at .1. already defined here .2." }
+  end block x  ! { dg-error "Expecting END SUBROUTINE" }
+end
+
+subroutine s1
+  logical :: x   ! { dg-error "Construct label .x. at .1. already defined here .2." }
+  x: if (.true.) ! { dg-error "Construct label .x. at .1. already defined here .2." }
+  endif x! { dg-error "Expecting END SUBROUTINE" }
+end
+
+subroutine s2
+  logical :: x ! { dg-error "Construct label .x. at .1. already defined here .2." }
+  real :: y! { dg-error "Construct label .y. at .1. already defined here .2." }
+
+  x: block ! { dg-error "Construct label .x. at .1. already defined here .2." }
+  end block x  ! { dg-error "Expecting END SUBROUTINE" }
+
+  y: block ! { dg-error "Construct label .y. at .1. already defined here .2." }
+  end block y  ! { dg-error "Expecting END SUBROUTINE" }
+end
+
+subroutine s3
+  logical :: x   ! { dg-error "Construct label .x. at .1. already defined here .2." }
+  real :: y  ! { dg-error "Construct label .y. at .1. already defined here .2." }
+
+  x: if (.true.) ! { dg-error "Construct label .x. at .1. already defined here .2." }
+  endif x! { dg-error "Expecting END SUBROUTINE" }
+
+  y: if (.true.) ! { dg-error "Construct label .y. at .1. already defined here .2." }
+  endif y! { dg-error "Expecting END SUBROUTINE" }
+end
diff --git a/gcc/testsuite/gfortran.dg/pr65045.f90 b/gcc/testsuite/gfortran.dg/pr65045.f90
index c49652993d7..eba4f5d2882 100644
--- a/gcc/testsuite/gfortran.dg/pr65045.f90
+++ b/gcc/testsuite/gfortran.dg/pr65045.f90
@@ -2,14 +2,13 @@
 !
 ! Contributed by Walt Brainerd  
 !
-real :: i = 9.9
-i:block
- if (i>7.7) then ! { dg-error "is not appropriate for an expression" }
- exit i
-   else  ! { dg-error

Re: [PATCH] PR fortran/105138 - Bogus error when function name does not shadow an intrinsic when RESULT clause is used

2022-04-05 Thread Thomas Koenig via Fortran

Hi Harald,


Steve's analysis (see PR) showed that we confused the case when a
symbol refererred to a recursive procedure which was named the same
as an intrinsic.  The standard allows such recursive references
(see e.g. F2018:19.3.1).

The attached patch is based on Steve's, but handles both functions
and subroutines.  Testcase verified with NAG and Crayftn.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

This bug is a rejects-valid, but could also lead to wrong code,
see e.g. the PR, comment#4.  Would this qualify for a backport
to e.g. the 11-branch?


OK for both.

Thanks for the patch!

Best regards

Thomas