https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276
--- Comment #20 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-12 branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:429a5143d17bd83d4662cd6c7a2c30d065c8f65b commit r12-9423-g429a5143d17bd83d4662cd6c7a2c30d065c8f65b Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Mar 28 10:43:08 2023 +0200 i386: Require just 32-bit alignment for SLOT_FLOATxFDI_387 -m32 -mpreferred-stack-boundary=2 DImode temporaries [PR109276] The following testcase ICEs since r11-2259 because assign_386_stack_local -> assign_stack_local -> ix86_local_alignment now uses 64-bit alignment for DImode temporaries rather than 32-bit as before. Most of the spots in the backend which ask for DImode temporaries are during expansion and those apparently are handled fine with -m32 -mpreferred-stack-boundary=2, we dynamically realign the stack in that case (most of the spots actually don't need that alignment but at least one does), then 2 spots are in STV which I assume also work correctly. But during splitting we can create a DImode slot which doesn't need to be 64-bit alignment (it is nicer for performance though), when we apparently aren't able to detect it for dynamic stack realignment purposes. The following patch just makes the slot 32-bit aligned in that rare case. 2023-03-28 Jakub Jelinek <ja...@redhat.com> PR target/109276 * config/i386/i386.cc (assign_386_stack_local): For DImode with SLOT_FLOATxFDI_387 and -m32 -mpreferred-stack-boundary=2 pass align 32 rather than 0 to assign_stack_local. * gcc.target/i386/pr109276.c: New test. (cherry picked from commit 4b5ef857f5faf09f274c0a95c67faaa80d198124)
