This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 10 Mar 2016 15:40:43 +0000
- Subject: [Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes
- Auto-submitted: auto-generated
- References: <bug-70127-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Martin Jambor from comment #11)
> 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.
I can understand in that case the e#f_17 and e$g_19 assignments in that case
in:
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;
but if you keep the e = a[0]; assignment, I really don't understand the last
two statements. The kept statement already copied them, the extra stores don't
cover the whole structure, so the old one has to be kept anyway, and the stores
don't store anything that isn't already there.