https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93270
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- And pasting from my ml analysis: So clearly something is wrong: <component_ref 0x7ffff695d240 type <real_type 0x7ffff682d3f0 long double sizes-gimplified XF size <integer_cst 0x7ffff680dd20 constant 128> unit-size <integer_cst 0x7ffff680dd38 constant 16> align:128 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type 0x7ffff682d3f0 precision:80 pointer_to_this <pointer_type 0x7ffff682d930>> and thus GET_MODE_SIZE (XFmode) == 16. The target cannot possibly just store 12 bytes here, it lies. Why's XFmode not 12 bytes but with 8/16 byte alignment? Does the ABI say sizeof(long double) is 16? That said, a mode-has-padding or whatever should be reflected in TYPE_SIZE & friends as well, inconsistencies there just make things worse. Now they're at least consistently wrong.