From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id EE80E3858D3C; Wed, 19 Oct 2022 19:18:17 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EE80E3858D3C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1666207097;
	bh=gWYLsNyRatLbOCHAtcFzq9Mk4wid7oi4m3GfhNMnPQs=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=noq9ZktTSjBARVg0MBMDXmPVx6sZ3enfn6jtlUrk22K4UDZPuiAHohIsRTmJW2ieF
	 OQ7COW4rn5EzT4d/e+/d5vqEnZs9JSmtSmBkiWj3nHnnz9PtRvi4Ab7Fwvs8kcyHZi
	 D9ck/tfGhzZaAxmUncCGPg2ov6RQsFKP2ybuonKo=
From: "anlauf at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/104848] ICE in simplify_intrinsic_op, at
 fortran/expr.cc:1305
Date: Wed, 19 Oct 2022 19:18:17 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: anlauf at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-104848-4-eDKfmOvd85@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-104848-4@http.gcc.gnu.org/bugzilla/>
References: <bug-104848-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104848

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> The following example shows that bad overflow handling is a regression th=
at
> was likely introduced in 6.x:
>=20
> program p
>   integer, parameter :: b(0) =3D 1 + [ huge(1) ]
> end

Another potential fix for this is:

diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index fc9224ebc5c..67ef10d4bf7 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -1710,8 +1720,8 @@ eval_intrinsic (gfc_intrinsic_op op,
   if (rc !=3D ARITH_OK)
     {
       gfc_error (gfc_arith_error (rc), &op1->where);
-      if (rc =3D=3D ARITH_OVERFLOW)
-       goto done;
+      // if (rc =3D=3D ARITH_OVERFLOW)
+      //       goto done;

       if (rc =3D=3D ARITH_DIV0 && op2->ts.type =3D=3D BT_INTEGER)
        gfc_seen_div0 =3D true;

While this fixes the testcases in this PR, this regresses on the following:

gfortran.dg/pr84734.f90 (from r8-7226, which added the above commented code=
),

gfortran.dg/integer_exponentiation_6.F90 (from r5-7381)

The latter is a weird testcase, which changed behavior and prints different
values (0 for gfortran <=3D 8, 4611686018427387904 for gfortran >=3D 9).

(Other compilers print either 0 oder produce an error, so the current
behavior is sort of at odds with the others.)

Do we have a concept for how to handle integer and real overflow depending =
on
the flag -f(no-)range-check?=