[Bug target/111528] New: aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13

[Bug target/111528] New: aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13

[mpolacek at gcc dot gnu.org]

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

            Bug ID: 111528
           Summary: aarch64: Test gfortran.dg/pr80494.f90 fails with
                    -fstack-protector-strong with gcc-13
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Started with r13-7813-gb96e66fd4ef3e3.

$ ./f951 -quiet -Iinclude /tmp/pr80494.f90 -std=gnu -O2
-fstack-protector-strong
/tmp/pr80494.f90:32:22:

   32 | end subroutine CalcCgr
      |                      ^
Error: unrecognizable insn:
(insn 382 381 189 19 (parallel [
            (set (reg:DF 34 v2 [orig:117 _46 ] [117])
                (mem:DF (plus:DI (reg/f:DI 31 sp)
                        (const_int -8 [0xfffffffffffffff8])) [8 zadj[_142]+0 S8
A64]))
            (set (reg:DF 32 v0 [orig:127 _76 ] [127])
                (mem:DF (plus:DI (reg/f:DI 31 sp)
                        (const_int 0 [0])) [8 zadj[_142]+8 S8 A64]))
        ]) -1
     (nil))
during RTL pass: cprop_hardreg
/tmp/pr80494.f90:32:22: internal compiler error: in extract_insn, at
recog.cc:2791
0x7869e0 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        /home/mpolacek/src/gcc13/gcc/rtl-error.cc:108
0x7869fc _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        /home/mpolacek/src/gcc13/gcc/rtl-error.cc:116
0x78535f extract_insn(rtx_insn*)
        /home/mpolacek/src/gcc13/gcc/recog.cc:2791
0xef3cab extract_constrain_insn(rtx_insn*)
        /home/mpolacek/src/gcc13/gcc/recog.cc:2690
0xef7cf7 copyprop_hardreg_forward_1
        /home/mpolacek/src/gcc13/gcc/regcprop.cc:826
0xef8f34 execute
        /home/mpolacek/src/gcc13/gcc/regcprop.cc:1408

[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Should have been fixed with:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4bb1ae3c13ce4fb72129229de66f5ffbcd45fe4c

[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I see the ICE even with r13-7827-g4bb1ae3c13ce4f in the tree.

[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13 since r13-7813-gb96e66fd4ef3e3

[rsandifo at gcc dot gnu.org]

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

--- Comment #3 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
This was the problem that g:10d59b802a7db9ae908291fb20627c1493cfa26c fixed.  I
wasn't sure it was worth backporting because it only triggers for out-of-bounds
array accesses, or uninitialised Fortran array indices.

[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13 since r13-7813-gb96e66fd4ef3e3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is still ICE on valid code, the code with the out of bounds access or some
other UB might not be ever reachable at runtime, it can even not appear in the
source at all and can be just a result of jump threading on unrelated condition
etc.
So I think we certainly want to backport it.

[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13 since r13-7813-gb96e66fd4ef3e3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Richard Sandiford
<rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:f5e56c5857cc6b704446c3666213468d25f6dcb2

commit r13-7961-gf5e56c5857cc6b704446c3666213468d25f6dcb2
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Wed Oct 18 18:44:57 2023 +0100

    lra: Avoid unfolded plus-0

    While backporting another patch to an earlier release, I hit a
    situation in which lra_eliminate_regs_1 would eliminate an address to:

        (plus (reg:P R) (const_int 0))

    This address compared not-equal to plain:

        (reg:P R)

    which caused an ICE in a later peephole2.  (The ICE showed up in
    gfortran.fortran-torture/compile/pr80464.f90 on the branch but seems
    to be latent on trunk.)

    These unfolded PLUSes shouldn't occur in the insn stream, and later code
    in the same function tried to avoid them.

    gcc/
            PR target/111528
            * lra-eliminations.cc (lra_eliminate_regs_1): Use
simplify_gen_binary
            rather than gen_rtx_PLUS.

    (cherry picked from commit 10d59b802a7db9ae908291fb20627c1493cfa26c)

[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13 since r13-7813-gb96e66fd4ef3e3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Richard Sandiford
<rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:6a527b809f99d3f05df16f792b2de6b32fa0d579

commit r12-9930-g6a527b809f99d3f05df16f792b2de6b32fa0d579
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Thu Oct 19 10:49:19 2023 +0100

    lra: Avoid unfolded plus-0

    While backporting another patch to an earlier release, I hit a
    situation in which lra_eliminate_regs_1 would eliminate an address to:

        (plus (reg:P R) (const_int 0))

    This address compared not-equal to plain:

        (reg:P R)

    which caused an ICE in a later peephole2.  (The ICE showed up in
    gfortran.fortran-torture/compile/pr80464.f90 on the branch but seems
    to be latent on trunk.)

    These unfolded PLUSes shouldn't occur in the insn stream, and later code
    in the same function tried to avoid them.

    gcc/
            PR target/111528
            * lra-eliminations.cc (lra_eliminate_regs_1): Use
simplify_gen_binary
            rather than gen_rtx_PLUS.

    (cherry picked from commit 10d59b802a7db9ae908291fb20627c1493cfa26c)

[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13 since r13-7813-gb96e66fd4ef3e3

[rsandifo at gcc dot gnu.org]

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

Richard Sandiford <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #7 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
Fixed on GCC 12 and 13 branches.  I'm a bit nervous about backporting the fix
to GCC 11 given that the next release will be the last.