[Bug rtl-optimization/118873] -favoid-store-forwarding makes a mess out of a STLF fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118873 --- Comment #2 from Konstantinos Eleftheriou --- We have submitted a fix for this (https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684671.html).

[Bug rtl-optimization/119884] [16 Regression] ICE: in emit_move_insn, at expr.cc:4636 with -O2 -fno-dse -favoid-store-forwarding since r16-15

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119884 --- Comment #2 from Konstantinos Eleftheriou --- We have submitted a fix https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681886.html

[Bug rtl-optimization/119160] wrong code with -O2 -finstrument-functions-once -favoid-store-forwarding -fnon-call-exceptions -fschedule-insns -mgeneral-regs-only

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119160 --- Comment #5 from Konstantinos Eleftheriou --- We have submitted a solution for this (https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679572.html).

[Bug testsuite/116860] Move optimization from match.pd into tree-ssa-reassoc (optimize_range_tests) where it can be more effective

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116860 --- Comment #11 from Konstantinos Eleftheriou --- We have sent a solution for this (https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677190.html).

[Bug rtl-optimization/117712] [15 regression] ICE when building x265: internal compiler error: in expand_fix, at optabs.cc:5936 since r15-2890

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117712 --- Comment #17 from Konstantinos Eleftheriou --- I've started bootstrapping and testing this on arm32 when it was posted, but ran into some unrelated bootstrapping issues. The whole testing cycle is quite slow because I'm using a QEMU environme

[Bug rtl-optimization/117712] [15 regression] ICE when building x265: internal compiler error: in expand_fix, at optabs.cc:5936 since r15-2890

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117712 --- Comment #9 from Konstantinos Eleftheriou --- It's okay, I was thinking of how we could fix this in the middle-end, but I haven't come up with something yet, as I'm working on other issues in parallel.

[Bug rtl-optimization/118873] -favoid-store-forwarding makes a mess out of a STLF fail

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118873 --- Comment #1 from Konstantinos Eleftheriou --- These subregs are generated from `store_bit_field`. We could fix this by updating `store_bit_field` or avoid calling it in those cases and handle this in-place. Actually, we're rejecting cases wit

[Bug testsuite/116860] Move optimization from match.pd into tree-ssa-reassoc (optimize_range_tests) where it can be more effective

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116860 --- Comment #10 from Konstantinos Eleftheriou --- We are currently working on a solution for this in reassoc.

[Bug middle-end/116845] gcc.dg/pr109393.c test fails on ilp32 targets (and maybe others)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116845 --- Comment #11 from Konstantinos Eleftheriou --- I have sent a patch that excludes the test from ilp32 targets, until implementing a solution for this (https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675060.html).

[Bug middle-end/116845] gcc.dg/pr109393.c test fails on ilp32 targets (and maybe others)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116845 --- Comment #9 from Konstantinos Eleftheriou --- This is optimized in x86 using -m32 during "combine", the problem is that the test cases check for the optimization in GIMPLE. But, this isn't the case for AArch64 using ILP32, which isn't optimiz

[Bug middle-end/116845] gcc.dg/pr109393.c test fails on ilp32 targets (and maybe others)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116845 --- Comment #8 from Konstantinos Eleftheriou --- I implemented Andrew's suggested solution and sent it to the lists (https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672368.html).

[Bug target/117835] wrong code with -O -favoid-store-forwarding -mno-push-args --param=store-forwarding-max-distance=0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117835 --- Comment #2 from Konstantinos Eleftheriou --- Submitted a solution for this to the lists: https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671800.html This also fixes bug 117872.

[Bug target/117835] wrong code with -O -favoid-store-forwarding -mno-push-args --param=store-forwarding-max-distance=0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117835 --- Comment #1 from Konstantinos Eleftheriou --- I have reproduced this and I'm working on finding the cause.

[Bug rtl-optimization/117816] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2837: flow control insn inside a basic block with -O -favoid-store-forwarding -fnon-call-exceptions -fno-forward-propagate -fins

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117816 --- Comment #2 from Konstantinos Eleftheriou --- Submitted my proposed fix to the lists: https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670921.html

[Bug rtl-optimization/117816] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2837: flow control insn inside a basic block with -O -favoid-store-forwarding -fnon-call-exceptions -fno-forward-propagate -fins

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117816 --- Comment #1 from Konstantinos Eleftheriou --- The cause of this is that we are not handling the case that we have a REG_EH_REGION note on an instruction in the store-load sequence. Thus, we are inserting instructions after it, leading to it n

[Bug tree-optimization/116352] [15 regression] ICE when building opencv-4.9.0 (error: definition in block 208 does not dominate use in block 188) since r15-2820-gab18785840d7b8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116352 --- Comment #12 from Konstantinos Eleftheriou --- How can I reproduce this on aarch64? I tried using the code in comment 3, using `-O3 -fno-vect-cost-model` with SVE disabled as Andrew mentioned and GCC on commit 7a970bd03f1d8eed7703db8a8db3c753