https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126153
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> --- So it seems to be IPA CP transform going wrong, we do replacing stmt:g_8[g_10.32_1149] = func_22 (_1148, _1130, 35, _1128, l_59); with stmt:g_8[g_10.32_1149] = func_22.constprop (l_59); ... t2.c:3933:70: note: Inlining func_22.constprop/556 to main/177 with frequency 363.71 we then have MEM <char> [(struct S1 *)&l_59 + 13B] = 4; ... p_27 = l_59; ... _1172 = p_27.f3.f7; which SRA decomposes: Created a replacement for p_27 offset: 40, size: 15: p_27$f3$f0D.9115 Created a replacement for p_27 offset: 73, size: 14: p_27$5$f3D.9116 Created a replacement for p_27 offset: 106, size: 3: p_27$f3$f7D.9117 p_27 = l_59; p_27$f3$f0_412 = MEM <struct S0> [(struct S1 *)&l_59 + 5B].f0; p_27$5$f3_405 = MEM <struct S0> [(struct S1 *)&l_59 + 5B].f3; p_27$f3$f7_484 = MEM <struct S0> [(struct S1 *)&l_59 + 5B].f7; ... _1172 = p_27$f3$f7_484; which is where a mismatch must occur (probably with respect to the packedness). PRE sees MEM <char> [(struct S1 *)&l_59 + 13B] = 4; g_11 = 3; p_27$f3$f7_484 = MEM <struct S0> [(struct S1 *)&l_59 + 5B].f7; and Value numbering stmt = p_27$f3$f7_484 = MEM <struct S0> [(struct S1 *)&l_59 + 5B].f7; Setting value number of p_27$f3$f7_484 to 1 (changed) disabling late SRA resolves the segfault (we no longer fall through main), but we still get the checksum mis-calculated. The testcase is quite hard to analyze directly (and offsets to be verified), but there seems to be errors in multiple places. SRA possibly mis-handles the aggregate copy between p_27 and l_59 and IPA-CP possibly has errors on its own (maybe does not handle bit-fields very well?).
