| Message ID | 4C488CE9.1080504@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
On Thu, Jul 22, 2010 at 08:24:41PM +0200, Bernd Schmidt wrote: > On 07/22/2010 08:00 PM, Nathan Froyd wrote: > > http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02056.html > > > > causes ICEs with powerpc-eabispe when compiling -msoft-float's libgcc: > > > > ../../.././gcc/dp-bit.c: In function '_fpadd_parts': > > ../../.././gcc/dp-bit.c:731:1: internal compiler error: in check_allocation, at ira.c:1629 > > Please submit a full bug report, > > with preprocessed source if appropriate. > > See <http://gcc.gnu.org/bugs.html> for instructions. > > > > I am way out of my depth debugging this code; I tried loading everything > > into gdb to provide a little more useful information, but of course the > > compilation succeeds when cc1 is being run under gdb. :( > > At least this seems at first glance only to be a bug in the > verification. Can you test the attached patch? Yeah, that seems to work much better. Thanks! -Nathan
>> At least this seems at first glance only to be a bug in the >> verification. Can you test the attached patch? > > Yeah, that seems to work much better. Thanks! Nathan tested a bit more, and I bootstrapped & tested on {i686,x86_64}-linux. Committed. Bernd
On Thu, Jul 22, 2010 at 3:33 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: >>> At least this seems at first glance only to be a bug in the >>> verification. Can you test the attached patch? >> >> Yeah, that seems to work much better. Thanks! > > Nathan tested a bit more, and I bootstrapped & tested on > {i686,x86_64}-linux. Committed. > This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45061
On Sat, Jul 24, 2010 at 6:22 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Thu, Jul 22, 2010 at 3:33 PM, Bernd Schmidt <bernds@codesourcery.com> wrote: >>>> At least this seems at first glance only to be a bug in the >>>> verification. Can you test the attached patch? >>> >>> Yeah, that seems to work much better. Thanks! >> >> Nathan tested a bit more, and I bootstrapped & tested on >> {i686,x86_64}-linux. Committed. >> > > This caused: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45061 > This also caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477
Index: ira.c =================================================================== --- ira.c (revision 162421) +++ ira.c (working copy) @@ -1624,11 +1624,14 @@ check_allocation (void) || (hard_regno = ALLOCNO_HARD_REGNO (a)) < 0) continue; nregs = hard_regno_nregs[hard_regno][ALLOCNO_MODE (a)]; - if (n > 1) - { - gcc_assert (n == nregs); - nregs = 1; - } + if (nregs == 1) + /* We allocated a single hard register. */ + n = 1; + else if (n > 1) + /* We allocated multiple hard registers, and we will test + conflicts in a granularity of single hard regs. */ + nregs = 1; + for (i = 0; i < n; i++) { ira_object_t obj = ALLOCNO_OBJECT (a, i); @@ -1648,7 +1651,13 @@ check_allocation (void) int conflict_hard_regno = ALLOCNO_HARD_REGNO (conflict_a); if (conflict_hard_regno < 0) continue; - if (ALLOCNO_NUM_OBJECTS (conflict_a) > 1) + + conflict_nregs + = (hard_regno_nregs + [conflict_hard_regno][ALLOCNO_MODE (conflict_a)]); + + if (ALLOCNO_NUM_OBJECTS (conflict_a) > 1 + && conflict_nregs == ALLOCNO_NUM_OBJECTS (conflict_a)) { if (WORDS_BIG_ENDIAN) conflict_hard_regno += (ALLOCNO_NUM_OBJECTS (conflict_a) @@ -1657,10 +1666,6 @@ check_allocation (void) conflict_hard_regno += OBJECT_SUBWORD (conflict_obj); conflict_nregs = 1; } - else - conflict_nregs - = (hard_regno_nregs - [conflict_hard_regno][ALLOCNO_MODE (conflict_a)]); if ((conflict_hard_regno <= this_regno && this_regno < conflict_hard_regno + conflict_nregs)