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

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

[gscfq@t-online.de]

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

            Bug ID: 104848
           Summary: ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gscfq@t-online.de
  Target Milestone: ---

Started with r8 :


$ cat z1.f90
program p
   integer, parameter :: a(2, 0) = 0
   integer, parameter :: b(0) = 1 + minval(a, dim=2)
end


$ cat z2.f90
program p
   integer, parameter :: a(2, 0) = 0
   integer, parameter :: b(1) = 1 + minval(a, dim=2)
end


$ cat z3.f90
program p
   integer, parameter :: a(2, 0) = 0
   integer, parameter :: b(2) = 1 + minval(a, dim=2)
end


$ gfortran-12-20220306 -c z1.f90
*** Error in `.../gcc/x86_64-pc-linux-gnu/12.0.1/f951': double free or
corruption (!prev): 0x0000000002da1030 ***
f951: internal compiler error: Aborted
0xccad7f crash_signal
        ../../gcc/toplev.cc:322
0x6f5cf2 simplify_intrinsic_op
        ../../gcc/fortran/expr.cc:1305
0x6f5cf2 gfc_simplify_expr(gfc_expr*, int)
        ../../gcc/fortran/expr.cc:2279
0x765c59 resolve_operator
        ../../gcc/fortran/resolve.cc:4499
0x761fef gfc_resolve_expr(gfc_expr*)
        ../../gcc/fortran/resolve.cc:7168
0x6f5044 gfc_reduce_init_expr(gfc_expr*)
        ../../gcc/fortran/expr.cc:3161
0x6f7fd0 gfc_match_init_expr(gfc_expr**)
        ../../gcc/fortran/expr.cc:3209
0x6e2354 variable_decl
        ../../gcc/fortran/decl.cc:3004
0x6e2354 gfc_match_data_decl()
        ../../gcc/fortran/decl.cc:6299
0x74cba3 match_word
        ../../gcc/fortran/parse.cc:67
0x74cba3 decode_statement
        ../../gcc/fortran/parse.cc:378
0x74e5ea next_free
        ../../gcc/fortran/parse.cc:1397
0x74e5ea next_statement
        ../../gcc/fortran/parse.cc:1629
0x74fb7b parse_spec
        ../../gcc/fortran/parse.cc:4168
0x752ccc parse_progunit
        ../../gcc/fortran/parse.cc:6192
0x754391 gfc_parse_file()
        ../../gcc/fortran/parse.cc:6737
0x7a1edf gfc_be_parse_file
        ../../gcc/fortran/f95-lang.cc:216

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |anlauf at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-03-09

--- Comment #1 from anlauf at gcc dot gnu.org ---
Interesting.  It might be the arithmetic overflow that is not properly handled.

program p
  integer, parameter :: a(2, 0) = 0
  integer, parameter :: y(*) = minval(a, dim=2)
  print *, y   ! no ICE
  print *, y-1 ! no ICE
  print *, y+1 ! ICE
end

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

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Forgot to add:

  print *, y+1_8 ! no ICE

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

[anlauf at gcc dot gnu.org]

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
Workaround: using -fno-range-check produces an error where appropriate.

Debugging suggests a potential fix for the ICE (needs testing):

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index c9c0ba4cc2e..cfafe10f727 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -1293,7 +1293,7 @@ simplify_intrinsic_op (gfc_expr *p, int type)
       gfc_internal_error ("simplify_intrinsic_op(): Bad operator");
     }

-  if (result == NULL)
+  if (result == NULL || result->expr_type == EXPR_UNKNOWN)
     {
       gfc_free_expr (op1);
       gfc_free_expr (op2);

But that may be just a band-aid.

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

[anlauf at gcc dot gnu.org]

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> But that may be just a band-aid.

Not even that.

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

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

[anlauf at gcc dot 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?

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |14.0

--- Comment #6 from anlauf at gcc dot gnu.org ---
The ICEs are gone at r14-9631, likely by the fixes r14-8902 and r14-9340.

Testcases z1 and z2 are now properly rejected.

The overflow for testcase z3 is not detected.
I think there is a related PR on this.

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=99852

--- Comment #7 from anlauf at gcc dot gnu.org ---
Found pr99852, which reported the missed overflows.

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

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #8 from anlauf at gcc dot gnu.org ---
The remaining issues are covered by pr99852.

*** This bug has been marked as a duplicate of bug 99852 ***