[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13 since r13-7813-gb96e66fd4ef3e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111528 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Richard Sandiford --- 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.
[Bug target/111528] aarch64: Test gfortran.dg/pr80494.f90 fails with -fstack-protector-strong with gcc-13 since r13-7813-gb96e66fd4ef3e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111528 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:6a527b809f99d3f05df16f792b2de6b32fa0d579 commit r12-9930-g6a527b809f99d3f05df16f792b2de6b32fa0d579 Author: Richard Sandiford 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111528 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:f5e56c5857cc6b704446c3666213468d25f6dcb2 commit r13-7961-gf5e56c5857cc6b704446c3666213468d25f6dcb2 Author: Richard Sandiford 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111528 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111528 --- Comment #3 from Richard Sandiford --- 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.
