https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123447
--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Pengfei Li <[email protected]>: https://gcc.gnu.org/g:7b29e31e693953a306b2bd0db7b2975ceed7e44c commit r16-7109-g7b29e31e693953a306b2bd0db7b2975ceed7e44c Author: Pengfei Li <[email protected]> Date: Mon Jan 26 16:09:42 2026 +0000 expand: Increase stack slot alignment for STRICT_ALIGNMENT targets [PR123447] PR123447 reports an ICE on AArch64 with "-O2 -mstrict-align" in subreg lowering while decomposing the following multiword store RTL: (insn 12 11 13 2 (set (mem/c:XI (plus:DI (reg/f:DI 64 sfp) (const_int -96 [0xffffffffffffffa0])) [0 S64 A8]) (reg:XI 103)) "a.c":14:6 4861 {*aarch64_movxi} This RTL originates from expanding the following GIMPLE statement: _1 = BIT_FIELD_REF <{ 9, -64497, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, 256, 0>; The operand is a constant _Decimal64 vector with BLKmode, so expand has to materialize it in memory. Current get_object_alignment() returns a 1-byte guaranteed alignment for this VECTOR_CST, as indicated by A8 in the RTL dump above. However, with "-mstrict-align" enabled, later subreg lowering pass expects at least 64-bit alignment when it constructs a new RTX to decompose the store into pieces. Because the original alignment is too small, simplify_gen_subreg() returns NULL_RTX and an assertion is hit. This patch increases the stack slot alignment for STRICT_ALIGNMENT targets, when the operand is forced into memory. The increased alignment is capped by MAX_SUPPORTED_STACK_ALIGNMENT so it won't be too large. Bootstrapped and tested on aarch64-linux-gnu and x86_64-linux-gnu. gcc/ChangeLog: PR middle-end/123447 * expr.cc (expand_expr_real_1): Increase stack slot alignment for STRICT_ALIGNMENT targets. gcc/testsuite/ChangeLog: PR middle-end/123447 * gcc.dg/pr123447.c: New test.
