http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #28 from davem at gcc dot gnu.org 2012-11-07 08:42:17 UTC ---
Author: davem
Date: Wed Nov 7 08:42:09 2012
New Revision: 193283
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193283
Log:
Revert sparc U constraint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
davem at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #24 from davem at gcc dot gnu.org 2012-11-06 18:07:46 UTC ---
On several occasions, in both public and private emails, I have in fact
expressed my displeasure with how the configure system and the sparc backend
treat things
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #25 from davem at gcc dot gnu.org 2012-11-06 22:32:40 UTC ---
Just an update. I know what the exact problem is. Actually it's a combination
of things.
Because of the way that IRA maintains it's hard reg sets, it can end up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #26 from davem at gcc dot gnu.org 2012-11-07 07:11:44 UTC ---
Ok, it seems it is not possible to expression the even integer register
condition using register classes. Therefore I will revert the U constraint
removal.
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #27 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-07
07:37:05 UTC ---
Longer term we do need a fix for this. It is very clear that IRA is
allocating
odd registers at times for DImode pseudos on 32-bit, and the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||davem at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2012-11-05
13:14:22 UTC ---
I'm now trying a bootstrap with r192871, r192824, and r192757 reverted, as
those were the only recent SPARC-specific changes I could find.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2012-11-05
14:12:09 UTC ---
(In reply to comment #0)
= 0x00575f94 _ZL27emit_note_insn_var_locationPPvS_+1604: ldd [ %i0 +
%g1 ], %o1
The destination register field is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #5 from davem at gcc dot gnu.org 2012-11-05 18:22:17 UTC ---
I'm really surprised to see the integer ldd/std patterns matching in a 64-bit
build.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #6 from davem at gcc dot gnu.org 2012-11-05 18:24:11 UTC ---
Oh I see, you're forcing v8 in the configure line.
It's so much easier to sparc32 bash before running configure so that the
build/host/target ends up being correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2012-11-05
19:13:30 UTC ---
(In reply to comment #2)
I'm now trying a bootstrap with r192871, r192824, and r192757 reverted, as
those were the only recent SPARC-specific changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #8 from davem at gcc dot gnu.org 2012-11-05 19:16:14 UTC ---
Thanks for tracking this down, I'll fix or revert.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #9 from davem at gcc dot gnu.org 2012-11-05 21:38:40 UTC ---
I'm having a hard time reproducing this, I've tried 32-bit
bootstraps with several variations of your listed configure
command line.
But meanwhile I want some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-05
21:41:09 UTC ---
I guess best would be if you could attach your var-tracking.ii and the exact
cc1plus command line used to compile it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-05
21:47:17 UTC ---
I'm having a hard time reproducing this, I've tried 32-bit
bootstraps with several variations of your listed configure
command line.
I can
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #12 from davem at gcc dot gnu.org 2012-11-05 21:50:38 UTC ---
That configuration doesn't make any sense.
It's going to pass -m64 down into the libgcc2 build, then
the internal --with-cpu=v8 setting is going to override
all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-05
21:55:13 UTC ---
Created attachment 28621
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28621
Preprocessed file
/home/ebotcazou/build/./prev-gcc/cc1plus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #14 from davem at gcc dot gnu.org 2012-11-05 22:04:10 UTC ---
The bug does not trigger using that var-tracking test file using a properly
configures 32-bit compiler, I just checked.
This sparc64+--with-cpu=v8 is not a legal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #15 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-05
22:08:00 UTC ---
That configuration doesn't make any sense.
It's going to pass -m64 down into the libgcc2 build, then
the internal --with-cpu=v8 setting is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-05
22:19:38 UTC ---
The bug does not trigger using that var-tracking test file using a properly
configures 32-bit compiler, I just checked.
Configure a regular
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #17 from davem at gcc dot gnu.org 2012-11-05 22:21:32 UTC ---
If sparc+--with-cpu=v8 and sparc64+--with-cpu=v8 were equal then my build
would trigger the problem too :-)
I'll look more deeply into this, thanks Eric.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #18 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-05
22:31:13 UTC ---
If sparc+--with-cpu=v8 and sparc64+--with-cpu=v8 were equal then my build
would trigger the problem too :-)
Yep, you might want to configure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #19 from davem at gcc dot gnu.org 2012-11-06 01:43:40 UTC ---
I always use --enable-targets=all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #20 from davem at gcc dot gnu.org 2012-11-06 01:44:09 UTC ---
Eric, I checked, and that is not how Debian builds their gcc.
They build with sparc-unknown-linux as the triplet.
So they configure their compiler correctly, and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #21 from davem at gcc dot gnu.org 2012-11-06 01:49:28 UTC ---
And now I remember more about this. They did that utterly stupid
sparc64+--with-cpu=v8 thing exactly because --enable-targets=all didn't exist
for sparc way back
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #22 from davem at gcc dot gnu.org 2012-11-06 04:15:21 UTC ---
Ok IRA is where the allocation of %o1 for DImode is performed.
I'll try to figure out why it isn't consulting HARD_REGNO_MODE_OK
to validate this choice.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55211
--- Comment #23 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-06
07:49:43 UTC ---
Eric, I checked, and that is not how Debian builds their gcc.
They build with sparc-unknown-linux as the triplet.
So they configure their
30 matches
Mail list logo
