This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]