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 c/45491] [4.6 Regression] FAIL: gcc.c-torture/compile/pr45085.c


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 ;)


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