[PATCH] PR fortran/103607 - [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

[PATCH] PR fortran/103607 - [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

[Harald Anlauf]

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

Dear all,

frontend-passes.c(do_subscript) does a check on array subscripts
which failed for the testcase in the PR where the array spec was
foul: the upper bound finally resolves to a REAL instead of an
INTEGER.  (There is another related testcase by Gerhard).

I haven't figured out yet how to kill or fix the array decl in
that case.  Nevertheless it makes sense to catch situations in
do_subscript where we end up with illegal types of the bounds.
This is trivially done by the attached patch.

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

Thanks,
Harald


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fortran-perform-array-subscript-checks-only-for-vali.patch --]
[-- Type: text/x-patch, Size: 2942 bytes --]

From 4ee6ec6681b76372d10d4e9e82ea037628b8b21b Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Tue, 7 Dec 2021 21:34:31 +0100
Subject: [PATCH] Fortran: perform array subscript checks only for valid
 INTEGER bounds

gcc/fortran/ChangeLog:

	PR fortran/103607
	* frontend-passes.c (do_subscript): Ensure that array bounds are
	of type INTEGER before performing checks on array subscripts.

gcc/testsuite/ChangeLog:

	PR fortran/103607
	* gfortran.dg/pr103607.f90: New test.
---
 gcc/fortran/frontend-passes.c          |  4 ++++
 gcc/testsuite/gfortran.dg/pr103607.f90 | 12 ++++++++++++
 2 files changed, 16 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/pr103607.f90

diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index 4764c834f4f..57b24a11cbe 100644
--- a/gcc/fortran/frontend-passes.c
+++ b/gcc/fortran/frontend-passes.c
@@ -2914,6 +2914,7 @@ do_subscript (gfc_expr **e)
 		    {
 		      if (ar->as->lower[i]
 			  && ar->as->lower[i]->expr_type == EXPR_CONSTANT
+			  && ar->as->lower[i]->ts.type == BT_INTEGER
 			  && mpz_cmp (val, ar->as->lower[i]->value.integer) < 0)
 			gfc_warning (warn, "Array reference at %L out of bounds "
 				     "(%ld < %ld) in loop beginning at %L",
@@ -2923,6 +2924,7 @@ do_subscript (gfc_expr **e)

 		      if (ar->as->upper[i]
 			  && ar->as->upper[i]->expr_type == EXPR_CONSTANT
+			  && ar->as->upper[i]->ts.type == BT_INTEGER
 			  && mpz_cmp (val, ar->as->upper[i]->value.integer) > 0)
 			    gfc_warning (warn, "Array reference at %L out of bounds "
 					 "(%ld > %ld) in loop beginning at %L",
@@ -2938,6 +2940,7 @@ do_subscript (gfc_expr **e)
 		    {
 		      if (ar->as->lower[i]
 			  && ar->as->lower[i]->expr_type == EXPR_CONSTANT
+			  && ar->as->lower[i]->ts.type == BT_INTEGER
 			  && mpz_cmp (val, ar->as->lower[i]->value.integer) < 0)
 			gfc_warning (warn, "Array reference at %L out of bounds "
 				     "(%ld < %ld) in loop beginning at %L",
@@ -2947,6 +2950,7 @@ do_subscript (gfc_expr **e)

 		      if (ar->as->upper[i]
 			  && ar->as->upper[i]->expr_type == EXPR_CONSTANT
+			  && ar->as->upper[i]->ts.type == BT_INTEGER
 			  && mpz_cmp (val, ar->as->upper[i]->value.integer) > 0)
 			gfc_warning (warn, "Array reference at %L out of bounds "
 				     "(%ld > %ld) in loop beginning at %L",
diff --git a/gcc/testsuite/gfortran.dg/pr103607.f90 b/gcc/testsuite/gfortran.dg/pr103607.f90
new file mode 100644
index 00000000000..a6a2c4fdfd0
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103607.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR fortran/103607 - ICE in do_subscript, at fortran/frontend-passes.c:2927
+! Contributed by G.Steinmetz
+
+program p
+  integer :: i, x(abs(2.)) ! { dg-error "must be of INTEGER type" }
+  do i = 1, 2
+     x(i) = 0
+  end do
+end
+
+! { dg-prune-output "must have constant shape" }
--
2.26.2

Re: [PATCH] PR fortran/103607 - [9/10/11/12 Regression] ICE in do_subscript, at fortran/frontend-passes.c:2927

[Mikael Morin]

On 07/12/2021 21:43, Harald Anlauf via Fortran wrote:
> I haven't figured out yet how to kill or fix the array decl in
> that case. 

As long as an error is reported, and the compiler doesn’t crash after 
it, I’m not sure there is something more to fix.

> Nevertheless it makes sense to catch situations in
> do_subscript where we end up with illegal types of the bounds.
> This is trivially done by the attached patch.
>  > Regtested on x86_64-pc-linux-gnu.  OK for mainline/backports?
> 
Yes.