[Bug fortran/104848] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

["anlauf at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- 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 that
> was likely introduced in 6.x:
> 
> program p
>   integer, parameter :: b(0) = 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 != ARITH_OK)
     {
       gfc_error (gfc_arith_error (rc), &op1->where);
-      if (rc == ARITH_OVERFLOW)
-       goto done;
+      // if (rc == ARITH_OVERFLOW)
+      //       goto done;

       if (rc == ARITH_DIV0 && op2->ts.type == BT_INTEGER)
        gfc_seen_div0 = 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 <= 8, 4611686018427387904 for gfortran >= 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?