The testing of the committed patch on the PPC-linux has produced no
regressions relatively to the state that was before the bootstrap
break-up. The same holds for the Andrew's version of the patch. 21
testsuite failures on PPC-linux that were introduced together with the
bootstrap problem has disa
Hi,
I've commited the following patch that fixes the obvious problem of
calling emit_insn_1 for INSN_LIST argument. It seems to solve the
problems I can reproduce and it bootstraps x86_64-linux/i686-linux and
Darwin (thanks to andreast). The patch was preaproved by Ian. This is
meant as fast fix
I've bootstrapped OK C/C++/Fortran on PPC. make check-gcc is running now
Thanks,
Vladimir
On 1/1/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> Hi,
> Sorry for possibly causing confusion. I had tested the patch on my ICE
> testcase and bootstrapped for -enable-languages=C, but didn't run the
> fu
> Hi,
> Sorry for possibly causing confusion. I had tested the patch on my ICE
> testcase and bootstrapped for -enable-languages=C, but didn't run the
> full bootstrap. Bootstrapping the latest Andrew's patch on ppc-linux
> and testing it on SPU.
Vladimir,
I bootstrapped/regtested the patch myself
Hi,
Sorry for possibly causing confusion. I had tested the patch on my ICE
testcase and bootstrapped for -enable-languages=C, but didn't run the
full bootstrap. Bootstrapping the latest Andrew's patch on ppc-linux
and testing it on SPU.
Vladimir
On 12/30/06, Jan Hubicka <[EMAIL PROTECTED]> wrote
> On Sunday 31 December 2006 00:59, Jan Hubicka wrote:
> > > Also I should mention, this also fixes a possible bug with libcalls that
> > > are embedded in one another. Before we were just assuming if we have a
> > > REG_RETVAL, then the previous REG_LIBCALL would be the start of the
> > > libcall
On Sunday 31 December 2006 00:59, Jan Hubicka wrote:
> > Also I should mention, this also fixes a possible bug with libcalls that
> > are embedded in one another. Before we were just assuming if we have a
> > REG_RETVAL, then the previous REG_LIBCALL would be the start of the
> > libcall but that
Hi,
I do apologize for the breakage, apparently I tested the only target
that didn't break. Andrew's patch seems to be OK for me (as well as the
patch just omitting copy_insn_1 call in the second branch that should
make situation no worse than before my patch and still save the
quadratic memory con
> > Andrew Pinski <[EMAIL PROTECTED]> writes:
> >
> > > >
> > > > > Hi,
> > > > > thanks for testing. I've bootstrapped/regtested this variant of patch
> > > > > and comitted it as obvious.
> > > >
> > > > Since this is an insn, we should not be copying it as it is just a link
> > > > to that
>
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> > >
> > > > Hi,
> > > > thanks for testing. I've bootstrapped/regtested this variant of patch
> > > > and comitted it as obvious.
> > >
> > > Since this is an insn, we should not be copying it as it is just a link
> > > to that
> > > insn.
> >
Andrew Pinski wrote:
Hi,
thanks for testing. I've bootstrapped/regtested this variant of patch
and comitted it as obvious.
This causes a bootstrap regression on powerpc-darwin while compiling
libgfortran.
And linux-ppc 32-bit.
we call copy_insn_1 with the following RTL:
(gdb) p debug_rtx(
Andrew Pinski <[EMAIL PROTECTED]> writes:
> >
> > > Hi,
> > > thanks for testing. I've bootstrapped/regtested this variant of patch
> > > and comitted it as obvious.
> >
> > Since this is an insn, we should not be copying it as it is just a link to
> > that
> > insn.
> >
> > Attached is a pat
>
> > Hi,
> > thanks for testing. I've bootstrapped/regtested this variant of patch
> > and comitted it as obvious.
>
> Since this is an insn, we should not be copying it as it is just a link to
> that
> insn.
>
> Attached is a patch which fixes the ICE though I have not bootstrapped and
> te
> Hi,
> thanks for testing. I've bootstrapped/regtested this variant of patch
> and comitted it as obvious.
This causes a bootstrap regression on powerpc-darwin while compiling
libgfortran.
we call copy_insn_1 with the following RTL:
(gdb) p debug_rtx(orig)
(insn 858 857 859 106
/Volumes/develo
Hi,
thanks for testing. I've bootstrapped/regtested this variant of patch
and comitted it as obvious.
Honza
2006-12-30 Jan Hubicka <[EMAIL PROTECTED]>
Vladimir Yanovsky <[EMAIL PROTECTED]>
* emit-rt.c (emit_copy_of_insn_after): Fix bug causing exponential
a
Hi,
I've rebuilt again everything from scratch with the changes to
emit_copy_of_insn_after as Jan suggested (see patch below) and the
ICE caused by quadratic accumulation of the counter of scratch
registers is gone!
Thanks,
Vladimir
Index: emit-rtl.c
> Hi, Jan,
> Thanks for fast response!
>
> I've tested the change you proposed and we still failed in the assert
> checking that the number of SCRATCHes being too large (>30) while
> copying the REG_NOTES of the instruction (see below) using just 9
> SCRATCH registers.
Hi,
apparently there seems
Hi, Jan,
Thanks for fast response!
I've tested the change you proposed and we still failed in the assert
checking that the number of SCRATCHes being too large (>30) while
copying the REG_NOTES of the instruction (see below) using just 9
SCRATCH registers.
Thanks,
Vladimir
On 12/18/06, Jan Hubic
> Hello all,
>
> I'm preparing and testing SMS correction/improvements patch and while
> testing it on the SPU with the vectorizer testcases I've got an ICE in
> the "gcc_assert ( MAX_RECOG_OPERANDS - i)" in function copy_insn_1 in
> emit_rtl.c. The call traces back to the loop versionioning call
Hello all,
I'm preparing and testing SMS correction/improvements patch and while
testing it on the SPU with the vectorizer testcases I've got an ICE in
the "gcc_assert ( MAX_RECOG_OPERANDS - i)" in function copy_insn_1 in
emit_rtl.c. The call traces back to the loop versionioning called in
modul
20 matches
Mail list logo
