http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #12 from Iain Sandoe 2011-11-12 14:14:46
UTC ---
Author: iains
Date: Sat Nov 12 14:14:43 2011
New Revision: 181316
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181316
Log:
gcc:
PR target/45233
* config/rs6000/rs600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
Iain Sandoe changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #11 from Iain Sandoe 2011-11-12 14:12:31
UTC ---
Author: iains
Date: Sat Nov 12 14:12:26 2011
New Revision: 181315
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181315
Log:
gcc:
PR target/45233
* config/rs6000/rs600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #10 from Dominique d'Humieres
2011-11-11 22:41:36 UTC ---
The patch in comment #8 fixes this pr. I have only been able to regtest gcc and
gfortran without regression. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #9 from Mike Stump 2011-11-09
17:03:21 UTC ---
Ok.
Yeah, combine has a habit of removing a complex thing at one point and
rebuilding at another point, mainly to shorten the lifetime. Mentally, I guess
I was expecting to see code mot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #8 from Iain Sandoe 2011-11-09 10:03:31
UTC ---
well, I was trying to be too complicated - we should just avoid trying to do
the substitution unless we can see the var in the TU. When this is done:
Index: gcc/config/rs6000/rs6000.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #7 from Iain Sandoe 2011-11-07 13:37:16
UTC ---
still not right .. generates wrong code for the first two accesses (missing the
indirect load).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #6 from Richard Guenther 2011-11-07
09:28:17 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
>
> FWIW gcc-4.2.1 (Apple local) fails and clang passes the test (although clang's
> asm at version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #5 from Iain Sandoe 2011-11-07 08:24:54
UTC ---
(In reply to comment #4)
> (In reply to comment #3)
FWIW gcc-4.2.1 (Apple local) fails and clang passes the test (although clang's
asm at version 2.9 is a bit long-winded c.f. GCC's ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #4 from Iain Sandoe 2011-11-06 13:00:18
UTC ---
(In reply to comment #3)
Thanks..
> Well, I guess the testcase is simply invalid for MachO,
well it works for -O0 (and for x86 darwin) ... so let's assume that MachO can
do it ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #3 from Richard Guenther 2011-11-06
12:46:43 UTC ---
Well, I guess the testcase is simply invalid for MachO, or the way MachO
does this UNSPEC stuff is broken (not properly checked during legitimization)
or not properly restoring the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #2 from Iain Sandoe 2011-11-06 12:36:23
UTC ---
Trying to simplify this, the following is enough to trigger the behavior:
extern int w;
void
foo (void)
{
int e2 = w;
__asm__ volatile ("/* %0 */" : : "ro" (e2));
}
==
(1) the co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
13 matches
Mail list logo
