Fortran: incorrect array bounds when bound intrinsic used in decl [PR108131]
Checks
Commit Message
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
Comments
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
>
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
>
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
@@ -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
@@ -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" }
new file mode 100644
@@ -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