https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127
--- Comment #11 from Martin Jambor <jamborm at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #3) > Looking at the tree dumps, I see weirdo behavior in early SRA (CCing > Martin), where it changes: > e.f = 1; > e.g = 1; > a[0] = c; > e = a[0]; > d = e; > e ={v} {CLOBBER}; > into: > e$f_4 = 1; > e$g_18 = 1; > a[0] = c; > e = a[0]; > e$f_17 = MEM[(struct S[1] *)&a]; > e$g_19 = MEM[(struct S[1] *)&a].g; > MEM[(struct S *)&e] = e$f_17; > e.g = e$g_19; > d = e; > e ={v} {CLOBBER}; > (the weird thing is that e = a[0] assignment remains, and then it is done > once again for each element). > Well, e has size 64 bits and the replacements created for it have 32 and 2 bits respectively and so in the simple SRA reprezentation of things, there are 30 bits that are not covered by the replacements and because the copy statement e = a[0] stores 64 bits, it thinks there are so called "unscalarized data." When that happens, SRA does not remove original aggregate assignments. While it seems that it should be trivial to tell SRA that it is just a padding, it is not, because SRA (with the exception of total scalarization) does not look at the type of aggregates but builds up a map of stored data from load and store statements in the function instead, which works much better in presence of unions, VIEW_CONVERT_EXPRs and MEM_REFs (that is also the reason why total scalarization is quite a bit of an alien concept that does not fit into the scheme very well). In the absence of unions, VIEW_CONVERT_EXPRs or MEM_REFs, it should still be reasonably doable though.