[PATCH] Fortran: incorrect array bounds when bound intrinsic used in decl [PR108131]

[PATCH] Fortran: incorrect array bounds when bound intrinsic used in decl [PR108131]

[Harald Anlauf]

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

Dear all,

the previous fix for pr103505 introduced a regression that could lead
to wrong array bounds when LBOUND/UBOUND were used in the array spec
of a declaration.  The reason was that we tried to simplify too early
the array element spec, which appears to have interfered with the
subtle semantics of the bound intrinsics.

The solution is to undo the fix for pr103505.  It turns out that
there are other code changes in place that were put in place to
fix related ICEs, and which handle that one, too, and only lead
to a change of the emitted error diagnostics.

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

As this is a 10/11/12/13 regression, I would like to backport
as seems fit.

Thanks,
Harald


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

From 531be0753352ec30c4b1e24591ec3e0c33cd4409 Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Sat, 17 Dec 2022 22:04:32 +0100
Subject: [PATCH] Fortran: incorrect array bounds when bound intrinsic used in
 decl [PR108131]

gcc/fortran/ChangeLog:

	PR fortran/108131
	* array.cc (match_array_element_spec): Avoid too early simplification
	of matched array element specs that can lead to a misinterpretation
	when used as array bounds in array declarations.

gcc/testsuite/ChangeLog:

	PR fortran/108131
	* gfortran.dg/pr103505.f90: Adjust expected patterns.
	* gfortran.dg/pr108131.f90: New test.
---
 gcc/fortran/array.cc                   |  4 ----
 gcc/testsuite/gfortran.dg/pr103505.f90 |  8 +++++---
 gcc/testsuite/gfortran.dg/pr108131.f90 | 25 +++++++++++++++++++++++++
 3 files changed, 30 insertions(+), 7 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr108131.f90

diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index 10d9e0c5354..7457c03e6cd 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -512,8 +512,6 @@ match_array_element_spec (gfc_array_spec *as)
   if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
     return AS_UNKNOWN;

-  gfc_try_simplify_expr (*upper, 0);
-
   if (((*upper)->expr_type == EXPR_CONSTANT
 	&& (*upper)->ts.type != BT_INTEGER) ||
       ((*upper)->expr_type == EXPR_FUNCTION
@@ -546,8 +544,6 @@ match_array_element_spec (gfc_array_spec *as)
   if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
     return AS_UNKNOWN;

-  gfc_try_simplify_expr (*upper, 0);
-
   if (((*upper)->expr_type == EXPR_CONSTANT
 	&& (*upper)->ts.type != BT_INTEGER) ||
       ((*upper)->expr_type == EXPR_FUNCTION
diff --git a/gcc/testsuite/gfortran.dg/pr103505.f90 b/gcc/testsuite/gfortran.dg/pr103505.f90
index 522e53efcb2..01308019b2c 100644
--- a/gcc/testsuite/gfortran.dg/pr103505.f90
+++ b/gcc/testsuite/gfortran.dg/pr103505.f90
@@ -3,7 +3,9 @@
 ! Testcase by G.Steinmetz

 program p
-  integer, parameter :: a((2.))   = [4,8] ! { dg-error "scalar INTEGER" }
-  integer, parameter :: z(1:(2.)) = [4,8] ! { dg-error "scalar INTEGER" }
-  print *, a(1:1)                         ! { dg-error "Syntax error" }
+  integer, parameter :: a((2.))   = [4,8] ! { dg-error "INTEGER type" }
+  integer, parameter :: z(1:(2.)) = [4,8] ! { dg-error "INTEGER type" }
+  print *, a(1:1)
 end
+
+! { dg-prune-output "Parameter array" }
diff --git a/gcc/testsuite/gfortran.dg/pr108131.f90 b/gcc/testsuite/gfortran.dg/pr108131.f90
new file mode 100644
index 00000000000..4a3c467f73a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr108131.f90
@@ -0,0 +1,25 @@
+! { dg-do run }
+! { dg-additional-options "-fdump-tree-original" }
+! PR fortran/108131
+!
+! Incorrect array bounds when bound intrinsic used in declaration
+
+program test
+  implicit none
+  integer, parameter :: mg(7:10)                 = 0
+  integer, parameter :: u =   ubound(mg, dim=1)
+  integer, parameter :: cx(-1:ubound(mg, dim=1)) = 1
+  integer, parameter :: dx(lbound(mg, dim=1):ubound(mg, dim=1)) = 2
+
+  write(*,*) ubound(mg, dim=1)
+  write(*,*) ubound(cx, dim=1)
+  if (u /= 10) stop 1
+  if (ubound(mg, dim=1) /= 10) stop 2
+  if (ubound(cx, dim=1) /= 10) stop 3
+  if (ubound(dx, dim=1) /= 10) stop 4
+  if (lbound(mg, dim=1) /=  7) stop 5
+  if (lbound(cx, dim=1) /= -1) stop 6
+  if (lbound(dx, dim=1) /=  7) stop 7
+end program test
+
+! { dg-final { scan-tree-dump-not "_gfortran_stop_numeric" "original" } }
--
2.35.3

*PING* [PATCH] Fortran: incorrect array bounds when bound intrinsic used in decl [PR108131]

[Harald Anlauf]

Am 17.12.22 um 22:21 schrieb Harald Anlauf via Gcc-patches:
> Dear all,
>
> the previous fix for pr103505 introduced a regression that could lead
> to wrong array bounds when LBOUND/UBOUND were used in the array spec
> of a declaration.  The reason was that we tried to simplify too early
> the array element spec, which appears to have interfered with the
> subtle semantics of the bound intrinsics.
>
> The solution is to undo the fix for pr103505.  It turns out that
> there are other code changes in place that were put in place to
> fix related ICEs, and which handle that one, too, and only lead
> to a change of the emitted error diagnostics.
>
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?
>
> As this is a 10/11/12/13 regression, I would like to backport
> as seems fit.
>
> Thanks,
> Harald
>

Re: [PATCH] Fortran: incorrect array bounds when bound intrinsic used in decl [PR108131]

[Jerry D]

On 12/17/22 1:21 PM, Harald Anlauf via Fortran wrote:
> Dear all,
> 
> the previous fix for pr103505 introduced a regression that could lead
> to wrong array bounds when LBOUND/UBOUND were used in the array spec
> of a declaration.  The reason was that we tried to simplify too early
> the array element spec, which appears to have interfered with the
> subtle semantics of the bound intrinsics.
> 
> The solution is to undo the fix for pr103505.  It turns out that
> there are other code changes in place that were put in place to
> fix related ICEs, and which handle that one, too, and only lead
> to a change of the emitted error diagnostics.
> 
> Regtested on x86_64-pc-linux-gnu.  OK for mainline?


Yes, OK for mainline.

My thought is that this is the kind of bug that can go unseen with 
incorrect array bounds so is a good candidate to backport.  At least 12, 
10 and 11 if you have time and it is applicable.
> 
> As this is a 10/11/12/13 regression, I would like to backport
> as seems fit.
> 
> Thanks,
> Harald
>