http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45491
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |jamborm at gcc dot gnu.org
Resolution| |FIXED
--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-11
11:40:47 UTC ---
I can't reproduce this with a cross, but what I can see is that SRA on
hppa does
<bb 2>:
SR.5_29 = MEM[(struct T *)&x];
SR.6_30 = MEM[(struct T *)&x + 4B];
SR.7_31 = MEM[(struct T *)&x + 8B];
MEM[(struct T *)&x.2] = SR.5_29;
MEM[(struct T *)&x.2 + 4B] = SR.6_30;
MEM[(struct T *)&x.2 + 8B] = SR.7_31;
u_11 = fn10 ();
...
D.2056_15 = fn3 (x.2);
while on x86_64 we have
<bb 2>:
xD.2753 = xD.1615;
uD.2755_10 = fn10 ();
...
D.2757_14 = fn3 (xD.2753);
so SRA fails to see that the destination of the x-x copy is used as
aggregate only.
There are a lot of testsuite fails in recent hppa2.0w-hp-hpux11.11 but this
one doesn't prevail.
Thus, fixed.
Martin, CCed you just in case you want to investigate the inefficient-SRA
issue ;)
