https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118055
--- Comment #2 from Hans-Peter Nilsson <hp at gcc dot gnu.org> --- (In reply to Hongtao Liu from comment #1) > I explained in the thread. > https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671289.html > > ------------- > BTW arm ci reported 2 regressed testcase so I added > * gcc.dg/tree-ssa/pr83403-1.c: Add --param max-completely-peeled-insns=300 > for arm*-*-*. > * gcc.dg/tree-ssa/pr83403-2.c: Ditto. > > For 32-bit arm, there're more stmts in the innermost loop, > and removal of the reduction prevents completely unrolling for them. > For aarch64, it looks fine. Thanks for the quick reply. I found the post after entering the bug. Still, that's not an explanation of why it happens for these targets and not for others. Is it perhaps that the test is brittle; mostly target-specific despite being at the tree-level and that instead the scan-test should be a specific known-matching target list? > So the fix for cris-elf/m68k could be similar as arm. While I know the "fix" works for cris-elf, I'd prefer to put a meaningful effective target than accumulating a list of random targets.
