Fortran: error recovery on associate with bad selector [PR107577]

Message ID trinity-dbdce3d4-1d85-4628-b9ea-d4935aaa02df-1669153996745@3c-app-gmx-bap12
State Accepted
Headers
Series Fortran: error recovery on associate with bad selector [PR107577] |

Checks

Context Check Description
snail/gcc-patch-check success Github commit url

Commit Message

Harald Anlauf Nov. 22, 2022, 9:53 p.m. UTC
  Dear all,

please find attached an obvious patch by Steve for a technical
regression that resulted from improvements in error recovery
of bad uses of associate.

Regtested on x86_64-pc-linux-gnu.

Will commit soon unless there are comments.

As a sidenote: the testcase shows that we resolve the associate
names quite often, likely more often than necessary, resulting
in many error messages produced for the same line of code.  In
the present case, each use of the bad name produces two errors,
one where it is used, and one at the associate statement.
That is probably not helpful for the user.

Thanks,
Harald
  

Comments

Thomas Koenig Nov. 24, 2022, 6:58 p.m. UTC | #1
Hi Harald,

> please find attached an obvious patch by Steve for a technical
> regression that resulted from improvements in error recovery
> of bad uses of associate.
> 
> Regtested on x86_64-pc-linux-gnu.
> 
> Will commit soon unless there are comments.

Obvious enough, I think.  Thanks!

> As a sidenote: the testcase shows that we resolve the associate
> names quite often, likely more often than necessary, resulting
> in many error messages produced for the same line of code.  In
> the present case, each use of the bad name produces two errors,
> one where it is used, and one at the associate statement.
> That is probably not helpful for the user.

We have an "error" flag in gfc_expr, which we use infrequently to
avoid repetitions of errors.  If an error has already been issued
for an expression, then we could set this.  We would have to be careful
about resetting the error on matching though, so it is probably better
to only use it during resolution.

Best regards

	Thomas
  

Patch

From 9ff8d2ec56d139b54e2f66f747142687a38d2106 Mon Sep 17 00:00:00 2001
From: Steve Kargl <kargl@gcc.gnu.org>
Date: Tue, 22 Nov 2022 22:31:51 +0100
Subject: [PATCH] Fortran: error recovery on associate with bad selector
 [PR107577]

gcc/fortran/ChangeLog:

	PR fortran/107577
	* resolve.cc (find_array_spec): Choose appropriate locus either of
	bad array reference or of non-array entity in error message.

gcc/testsuite/ChangeLog:

	PR fortran/107577
	* gfortran.dg/pr107577.f90: New test.
---
 gcc/fortran/resolve.cc                 |  3 ++-
 gcc/testsuite/gfortran.dg/pr107577.f90 | 13 +++++++++++++
 2 files changed, 15 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr107577.f90

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 24e5aa03556..3396c6ce4a7 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5005,8 +5005,9 @@  find_array_spec (gfc_expr *e)
       case REF_ARRAY:
 	if (as == NULL)
 	  {
+	    locus loc = ref->u.ar.where.lb ? ref->u.ar.where : e->where;
 	    gfc_error ("Invalid array reference of a non-array entity at %L",
-		       &ref->u.ar.where);
+		       &loc);
 	    return false;
 	  }

diff --git a/gcc/testsuite/gfortran.dg/pr107577.f90 b/gcc/testsuite/gfortran.dg/pr107577.f90
new file mode 100644
index 00000000000..94e6620a0ee
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107577.f90
@@ -0,0 +1,13 @@ 
+! { dg-do compile }
+! PR fortran/107577 - ICE in find_array_spec
+! Contributed by G.Steinmetz
+
+program p
+  implicit none
+  associate (y => f(4))            ! { dg-error "has no IMPLICIT type" }
+    if (lbound (y, 1) /= 1) stop 1 ! { dg-error "Invalid array reference" }
+    if (y(1) /= 1) stop 2          ! { dg-error "Invalid array reference" }
+  end associate
+end
+
+! { dg-error "has no type" " " { target *-*-* } 7 }
--
2.35.3