http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #11 from Iain Sandoe iains at gcc dot gnu.org 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=gccview=revrev=181315
Log:
gcc:
PR target/45233
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #12 from Iain Sandoe iains at gcc dot gnu.org 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=gccview=revrev=181316
Log:
gcc:
PR target/45233
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr
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 #8 from Iain Sandoe iains at gcc dot gnu.org 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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #9 from Mike Stump mikestump at comcast dot net 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #5 from Iain Sandoe iains at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #7 from Iain Sandoe iains at gcc dot gnu.org 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 #2 from Iain Sandoe iains at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
--- Comment #4 from Iain Sandoe iains at gcc dot gnu.org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
13 matches
Mail list logo
