public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] Fortran: error recovery on associate with bad selector [PR107577]
@ 2022-11-22 21:53 Harald Anlauf
  2022-11-24 18:58 ` Thomas Koenig
  0 siblings, 1 reply; 2+ messages in thread
From: Harald Anlauf @ 2022-11-22 21:53 UTC (permalink / raw)
  To: fortran, gcc-patches, kargl

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pr107577.diff --]
[-- Type: text/x-patch, Size: 1903 bytes --]

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] Fortran: error recovery on associate with bad selector [PR107577]
  2022-11-22 21:53 [PATCH] Fortran: error recovery on associate with bad selector [PR107577] Harald Anlauf
@ 2022-11-24 18:58 ` Thomas Koenig
  0 siblings, 0 replies; 2+ messages in thread
From: Thomas Koenig @ 2022-11-24 18:58 UTC (permalink / raw)
  To: Harald Anlauf, fortran, gcc-patches, kargl

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-11-24 18:58 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-22 21:53 [PATCH] Fortran: error recovery on associate with bad selector [PR107577] Harald Anlauf
2022-11-24 18:58 ` Thomas Koenig

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).