I reduced an miscompile for aarch64 inside _Unwind_RaiseException and I noticed the same issue can be reproduced on powerpc64-linux-gnu and powerpc-linux-gnu. Reduced testcase: ``` __attribute__((noipa,noinline)) int f(int *a, long offset, void *handler) { if (*a == 5) return 5; __builtin_eh_return (offset, handler); } int main() { int t = 5; if (f(&t, 0, 0) != 5) __builtin_abort(); } ``` This produces a load (of r4) in the epilogue part for the `return 5` path (which is reduced from the end of stack path inside _Unwind_RaiseException). ``` bne $r13,$r12,.L2 addi.w $r4,$r0,5 # 0x5 or $r8,$r0,$r0 .L4: ld.d $r1,$r3,40 .cfi_remember_state .cfi_restore 1 ld.d $r5,$r3,24 .cfi_restore 5 ld.d $r4,$r3,32 .cfi_restore 4 ld.d $r6,$r3,16 .cfi_restore 6 ld.d $r7,$r3,8 .cfi_restore 7 addi.d $r3,$r3,48 .cfi_def_cfa_offset 0 add.d $r3,$r3,$r8 jr $r1 ```
Hmm, AFAIK this should be already fixed with r14-6440? I cannot reproduce it with r14-9823 but maybe it has regressed again in the recent weeks.
(In reply to Xi Ruoyao from comment #1) > Hmm, AFAIK this should be already fixed with r14-6440? > > I cannot reproduce it with r14-9823 but maybe it has regressed again in the > recent weeks. Oh I only tested gcc 13.2.0. If it is fixed you can close it.
(In reply to Andrew Pinski from comment #2) > (In reply to Xi Ruoyao from comment #1) > > Hmm, AFAIK this should be already fixed with r14-6440? > > > > I cannot reproduce it with r14-9823 but maybe it has regressed again in the > > recent weeks. > > Oh I only tested gcc 13.2.0. If it is fixed you can close it. Hmm it looks like we need a backport to releases/gcc-13 (and 12?) I thought the bug was introduced by my shrink-wrap change (r14-545) so I didn't proposed a backport. But it seems I was wrong and the bug exists even before r14-545.
Also it looks like I messed up comment #0 and forgot to change powerpc to longarch64 :). That is what I get for trying to split this all out.
(In reply to Xi Ruoyao from comment #3) > (In reply to Andrew Pinski from comment #2) > > (In reply to Xi Ruoyao from comment #1) > > > Hmm, AFAIK this should be already fixed with r14-6440? > > > > > > I cannot reproduce it with r14-9823 but maybe it has regressed again in the > > > recent weeks. > > > > Oh I only tested gcc 13.2.0. If it is fixed you can close it. > > Hmm it looks like we need a backport to releases/gcc-13 (and 12?) I have backpointed r14-6440 to gcc-13 and gcc-12 and am testing > > I thought the bug was introduced by my shrink-wrap change (r14-545) so I > didn't proposed a backport. But it seems I was wrong and the bug exists > even before r14-545.
The releases/gcc-12 branch has been updated by LuluCheng <chenglulu@gcc.gnu.org>: https://gcc.gnu.org/g:bb78099d2624b52c781ed6e5d85e43d54c3cda1a commit r12-10403-gbb78099d2624b52c781ed6e5d85e43d54c3cda1a Author: Yang Yujie <yangyujie@loongson.cn> Date: Fri Dec 8 18:01:18 2023 +0800 LoongArch: Fix eh_return epilogue for normal returns. On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved and restored in the function prologue and epilogue if the given function calls __builtin_eh_return. This causes the return value to be overwritten on normal return paths and breaks a rare case of libgcc's _Unwind_RaiseException. gcc/ChangeLog: PR target/114848 * config/loongarch/loongarch.cc: Do not restore the saved eh_return data registers ($r4-$r7) for a normal return of a function that calls __builtin_eh_return elsewhere. * config/loongarch/loongarch-protos.h: Same. * config/loongarch/loongarch.md: Same. gcc/testsuite/ChangeLog: * gcc.target/loongarch/eh_return-normal-return.c: New test. (cherry picked from commit 4b421728289e6f1caa0dfaa953a11698ab95d37d)
The releases/gcc-13 branch has been updated by LuluCheng <chenglulu@gcc.gnu.org>: https://gcc.gnu.org/g:88f22217521564e1a956e14ac55456caa160e055 commit r13-8661-g88f22217521564e1a956e14ac55456caa160e055 Author: Yang Yujie <yangyujie@loongson.cn> Date: Fri Dec 8 18:01:18 2023 +0800 LoongArch: Fix eh_return epilogue for normal returns. On LoongArch, the regitsters $r4 - $r7 (EH_RETURN_DATA_REGNO) will be saved and restored in the function prologue and epilogue if the given function calls __builtin_eh_return. This causes the return value to be overwritten on normal return paths and breaks a rare case of libgcc's _Unwind_RaiseException. gcc/ChangeLog: PR target/114848 * config/loongarch/loongarch.cc: Do not restore the saved eh_return data registers ($r4-$r7) for a normal return of a function that calls __builtin_eh_return elsewhere. * config/loongarch/loongarch-protos.h: Same. * config/loongarch/loongarch.md: Same. gcc/testsuite/ChangeLog: * gcc.target/loongarch/eh_return-normal-return.c: New test. (cherry picked from commit 4b421728289e6f1caa0dfaa953a11698ab95d37d)
Fixed for 12 and 13.