[Bug fortran/106987] New: [10/11/12/13 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

[Bug fortran/106987] New: [10/11/12/13 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

[gscfq@t-online.de]

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

            Bug ID: 106987
           Summary: [10/11/12/13 Regression] ICE in simplify_intrinsic_op,
                    at fortran/expr.cc:1305
           Product: gcc
           Version: 13.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 r6 :


$ cat z1.f90
program p
!  integer, parameter :: a(1) = 31
   integer, parameter :: b(1) = 32
   integer, parameter :: c(1) = 33
!  print *, 2**a
   print *, 2**b
   print *, 2**c
end


$ gfortran-13-20220918 -c z1.f90
z1.f90:6:13:

    6 |    print *, 2**b
      |             1
Error: Arithmetic overflow at (1)
*** Error in `.../lib/gcc/x86_64-pc-linux-gnu/13.0.0/f951': free(): invalid
pointer: 0x0000000004260358 ***
f951: internal compiler error: Aborted
0xf3a72f crash_signal
        ../../gcc/toplev.cc:314
0x7f9af2 simplify_intrinsic_op
        ../../gcc/fortran/expr.cc:1305
0x7f9af2 gfc_simplify_expr(gfc_expr*, int)
        ../../gcc/fortran/expr.cc:2281
0x86ac39 resolve_operator
        ../../gcc/fortran/resolve.cc:4511
0x866fcf gfc_resolve_expr(gfc_expr*)
        ../../gcc/fortran/resolve.cc:7187
0x86f8bc gfc_resolve_expr(gfc_expr*)
        ../../gcc/fortran/resolve.cc:7161
0x86f8bc gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.cc:11974
0x86e34f gfc_resolve_blocks(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.cc:10972
0x86e6a8 gfc_resolve_code(gfc_code*, gfc_namespace*)
        ../../gcc/fortran/resolve.cc:11964
0x871457 resolve_codes
        ../../gcc/fortran/resolve.cc:17617
0x87151e gfc_resolve(gfc_namespace*)
        ../../gcc/fortran/resolve.cc:17652
0x8592e4 resolve_all_program_units
        ../../gcc/fortran/parse.cc:6606
0x8592e4 gfc_parse_file()
        ../../gcc/fortran/parse.cc:6862
0x8a7ccf gfc_be_parse_file
        ../../gcc/fortran/f95-lang.cc:229

[Bug fortran/106987] [10/11/12/13 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

[gscfq@t-online.de]

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

--- Comment #1 from G. Steinmetz <gscfq@t-online.de> ---

Compiles with scalars :

$ cat z2.f90
program p
!  integer, parameter :: a = 31
   integer, parameter :: b = 32
   integer, parameter :: c = 33
!  print *, 2**a
   print *, 2**b
   print *, 2**c
end

[Bug fortran/106987] [10/11/12/13 Regression] 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=106987

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-09-20
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |ice-on-invalid-code

--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed.

We are not really good at recovering from arithmetic errors.

[Bug fortran/106987] [10/11/12/13 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
   Target Milestone|---                         |10.5

[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.

[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:93e1d4d24ed014387da97e2ce11556d68fe98e66

commit r14-9340-g93e1d4d24ed014387da97e2ce11556d68fe98e66
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Tue Mar 5 21:54:26 2024 +0100

    Fortran: error recovery while simplifying expressions [PR103707,PR106987]

    When an exception is encountered during simplification of arithmetic
    expressions, the result may depend on whether range-checking is active
    (-frange-check) or not.  However, the code path in the front-end should
    stay the same for "soft" errors for which the exception is triggered by the
    check, while "hard" errors should always terminate the simplification, so
    that error recovery is independent of the flag.  Separation of arithmetic
    error codes into "hard" and "soft" errors shall be done consistently via
    is_hard_arith_error().

            PR fortran/103707
            PR fortran/106987

    gcc/fortran/ChangeLog:

            * arith.cc (is_hard_arith_error): New helper function to determine
            whether an arithmetic error is "hard" or not.
            (check_result): Use it.
            (gfc_arith_divide): Set "Division by zero" only for regular
            numerators of real and complex divisions.
            (reduce_unary): Use is_hard_arith_error to determine whether a hard
            or (recoverable) soft error was encountered.  Terminate immediately
            on hard error, otherwise remember code of first soft error.
            (reduce_binary_ac): Likewise.
            (reduce_binary_ca): Likewise.
            (reduce_binary_aa): Likewise.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/pr99350.f90:
            * gfortran.dg/arithmetic_overflow_3.f90: New test.

[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |anlauf at gcc dot gnu.org

--- Comment #5 from Paul Thomas <pault at gcc dot gnu.org> ---
Hi Harald,

I am pinning this one on you since it needs backporting to 13-branch, at least.
It also keeps the audit trail clean.

Cheers

Paul

[Bug fortran/106987] [11/12/13/14 Regression] 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=106987

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #5)
> Hi Harald,
> 
> I am pinning this one on you since it needs backporting to 13-branch, at
> least. It also keeps the audit trail clean.

Hi Paul,

this one is at the top of my backport list.

It depends on backporting r14-8902 (mine), and has weak conflict if
r14-1629 (yours) is not backported, as testcase gfortran.dg/pr99350.f90
was introduced in that commit.

I could amend backporting the fix for the current PR as well as r14-8902
to 13-branch by removing the changes to pr99350.f90 from the backport.
That is likely the most simple solution, as backporting r14-1629 might
introduce regressions.

Nevertheless, the current fixes can only be backported to 13-branch,
as some of the infrastructure changes for better error recovery after
arithmetic errors and when array ctors are involved are to risky to
backport to 12-branch.

What do you think?

[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

[paul.richard.thomas at gmail dot com]

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

--- Comment #7 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Hi Harald,

I will have a stab at backporting r14-1629 later this afternoon and will
let you know what happens. I am just rebuilding after applying the fix for
pr112407 (yes, I did add -std=f2008 :-) ).

I don't think that there is any point in going back to 12-branch at this
point in the release cycle.

Cheers

Paul




On Mon, 1 Apr 2024 at 21:42, anlauf at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987
>
> anlauf at gcc dot gnu.org changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>              Status|NEW                         |ASSIGNED
>
> --- Comment #6 from anlauf at gcc dot gnu.org ---
> (In reply to Paul Thomas from comment #5)
> > Hi Harald,
> >
> > I am pinning this one on you since it needs backporting to 13-branch, at
> > least. It also keeps the audit trail clean.
>
> Hi Paul,
>
> this one is at the top of my backport list.
>
> It depends on backporting r14-8902 (mine), and has weak conflict if
> r14-1629 (yours) is not backported, as testcase gfortran.dg/pr99350.f90
> was introduced in that commit.
>
> I could amend backporting the fix for the current PR as well as r14-8902
> to 13-branch by removing the changes to pr99350.f90 from the backport.
> That is likely the most simple solution, as backporting r14-1629 might
> introduce regressions.
>
> Nevertheless, the current fixes can only be backported to 13-branch,
> as some of the infrastructure changes for better error recovery after
> arithmetic errors and when array ctors are involved are to risky to
> backport to 12-branch.
>
> What do you think?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

[paul.richard.thomas at gmail dot com]

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

--- Comment #8 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Hi Harald,

After a lot of messing around, I managed to backport the patch; essentially
by hand. However, two of the  testcases ICEd in trans-array.cc and so there
were obviously dependences that I had missed.

I will not be backporting r14-1629, if for no other reason than it is not a
regression but also because the amount of work that would be involved
doesn't warrant it. It's a pity that I didn't keep 13-branch up to speed
with mainline on the associate fixes but we will just have to live with it
now.

Regards

Paul


On Tue, 2 Apr 2024 at 14:32, Paul Richard Thomas <
paul.richard.thomas@gmail.com> wrote:

> Hi Harald,
>
> I will have a stab at backporting r14-1629 later this afternoon and will
> let you know what happens. I am just rebuilding after applying the fix for
> pr112407 (yes, I did add -std=f2008 :-) ).
>
> I don't think that there is any point in going back to 12-branch at this
> point in the release cycle.
>
> Cheers
>
> Paul
>
>
>
>
> On Mon, 1 Apr 2024 at 21:42, anlauf at gcc dot gnu.org <
> gcc-bugzilla@gcc.gnu.org> wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106987
>>
>> anlauf at gcc dot gnu.org changed:
>>
>>            What    |Removed                     |Added
>>
>> ----------------------------------------------------------------------------
>>              Status|NEW                         |ASSIGNED
>>
>> --- Comment #6 from anlauf at gcc dot gnu.org ---
>> (In reply to Paul Thomas from comment #5)
>> > Hi Harald,
>> >
>> > I am pinning this one on you since it needs backporting to 13-branch, at
>> > least. It also keeps the audit trail clean.
>>
>> Hi Paul,
>>
>> this one is at the top of my backport list.
>>
>> It depends on backporting r14-8902 (mine), and has weak conflict if
>> r14-1629 (yours) is not backported, as testcase gfortran.dg/pr99350.f90
>> was introduced in that commit.
>>
>> I could amend backporting the fix for the current PR as well as r14-8902
>> to 13-branch by removing the changes to pr99350.f90 from the backport.
>> That is likely the most simple solution, as backporting r14-1629 might
>> introduce regressions.
>>
>> Nevertheless, the current fixes can only be backported to 13-branch,
>> as some of the infrastructure changes for better error recovery after
>> arithmetic errors and when array ctors are involved are to risky to
>> backport to 12-branch.
>>
>> What do you think?
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for the bug.
>
>

[Bug fortran/106987] [11/12/13/14 Regression] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:2808797fc4da7cc455803e2b69368b52db857b4c

commit r13-8559-g2808797fc4da7cc455803e2b69368b52db857b4c
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Tue Mar 5 21:54:26 2024 +0100

    Fortran: error recovery while simplifying expressions [PR103707,PR106987]

    When an exception is encountered during simplification of arithmetic
    expressions, the result may depend on whether range-checking is active
    (-frange-check) or not.  However, the code path in the front-end should
    stay the same for "soft" errors for which the exception is triggered by the
    check, while "hard" errors should always terminate the simplification, so
    that error recovery is independent of the flag.  Separation of arithmetic
    error codes into "hard" and "soft" errors shall be done consistently via
    is_hard_arith_error().

            PR fortran/103707
            PR fortran/106987

    gcc/fortran/ChangeLog:

            * arith.cc (is_hard_arith_error): New helper function to determine
            whether an arithmetic error is "hard" or not.
            (check_result): Use it.
            (gfc_arith_divide): Set "Division by zero" only for regular
            numerators of real and complex divisions.
            (reduce_unary): Use is_hard_arith_error to determine whether a hard
            or (recoverable) soft error was encountered.  Terminate immediately
            on hard error, otherwise remember code of first soft error.
            (reduce_binary_ac): Likewise.
            (reduce_binary_ca): Likewise.
            (reduce_binary_aa): Likewise.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/arithmetic_overflow_3.f90: New test.

    (cherry picked from commit 93e1d4d24ed014387da97e2ce11556d68fe98e66)

[Bug fortran/106987] [11/12/13/14 Regression] 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=106987

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
   Target Milestone|11.5                        |13.3
         Resolution|---                         |FIXED

--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to paul.richard.thomas@gmail.com from comment #8)
> Hi Harald,
> 
> After a lot of messing around, I managed to backport the patch; essentially
> by hand. However, two of the  testcases ICEd in trans-array.cc and so there
> were obviously dependences that I had missed.
> 
> I will not be backporting r14-1629, if for no other reason than it is not a
> regression but also because the amount of work that would be involved
> doesn't warrant it. It's a pity that I didn't keep 13-branch up to speed
> with mainline on the associate fixes but we will just have to live with it
> now.

Hi Paul,

no problem, I manually removed the conflict and pushed after regtesting.
Thanks for trying!

As I said before, I will close this one as fixed with target milestone 13.3,
as it does not make sense to try to backport all needed dependencies to 12,
and this one is an ICE-on-invalid.

@Gerhard: thanks for the report!