public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Harald Anlauf <anlauf@gmx.de>
To: fortran <fortran@gcc.gnu.org>, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: [PATCH] Fortran: incorrect array bounds when bound intrinsic used in decl [PR108131]
Date: Sat, 17 Dec 2022 22:21:17 +0100	[thread overview]
Message-ID: <trinity-3d8a6fbe-9e01-4e21-960b-3fde6a9d9f51-1671312077244@3c-app-gmx-bap49> (raw)

[-- 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


             reply	other threads:[~2022-12-17 21:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-17 21:21 Harald Anlauf [this message]
2022-12-23 16:14 ` *PING* " Harald Anlauf
2022-12-23 21:12 ` Jerry D

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=trinity-3d8a6fbe-9e01-4e21-960b-3fde6a9d9f51-1671312077244@3c-app-gmx-bap49 \
    --to=anlauf@gmx.de \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).