On Mon, 2018-11-26 at 22:47 +0100, Andreas Schwab wrote:
> External Email
>
> On Nov 26 2018, Steve Ellcey wrote:
>
> > I looked through the patches for the last couple of weeks to see if
> > I could identify
> > what changed here but I haven't found anything. Maybe it was
> > something in
> >
On Nov 26 2018, Steve Ellcey wrote:
> I looked through the patches for the last couple of weeks to see if I could
> identify
> what changed here but I haven't found anything. Maybe it was something in
> glibc that changed.
Most likely it only worked by accident so far. Last week the first
GLI
I am trying to do a bootstrap build of GCC using a newly built glibc in
a non standard location on my aarch64 platform (thunderx). This was working
up until a week or so ago but now I am running into a problem I haven't seen
before:
build/genautomata /home/sellcey/test-tot/src/gcc/gcc/common.md
Roman Zippel wrote:
> Hi,
>
> On Fri, 22 Jun 2007, Kenneth Zadeck wrote:
>
>
>>> Index: gcc/gcc/reg-stack.c
>>> ===
>>> --- gcc.orig/gcc/reg-stack.c
>>> +++ gcc/gcc/reg-stack.c
>>> @@ -2316,6 +2316,12 @@ subst_stack_regs (rtx insn,
Hi,
On Fri, 22 Jun 2007, Kenneth Zadeck wrote:
> > Index: gcc/gcc/reg-stack.c
> > ===
> > --- gcc.orig/gcc/reg-stack.c
> > +++ gcc/gcc/reg-stack.c
> > @@ -2316,6 +2316,12 @@ subst_stack_regs (rtx insn, stack regsta
> >if (NOTE_P
Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Jun 2007, I wrote:
>
>
>> Index: gcc/df-problems.c
>> ===
>> --- gcc/df-problems.c(revision 125811)
>> +++ gcc/df-problems.c(working copy)
>> @@ -1574,7 +1574,7 @@
>>/* Ca
Paolo Bonzini wrote:
> +
> + /* However a may or must clobber still still needs to
> + kill the reg. */
>
> Add here "so that REG_DEAD notes are later placed appropriately". Ok,
> thanks!
>
> Paolo
so is this an ok to commit with this change?
+
+ /* However a may or must clobber still still needs to
+kill the reg. */
Add here "so that REG_DEAD notes are later placed appropriately". Ok,
thanks!
Paolo
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> @@ -3985,6 +3988,11 @@ df_note_bb_compute (unsigned int bb_inde
> = df_create_unused_note (insn, old_unused_notes,
> def, live, do_not_gen,
> artificial_
Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
>
>
>> If we add the dead note there we are asserting that the value is
>> modified by the caller. however it might not be and someone could write
>> a piece of asm right after the call to use that reg if the person knew
>>
Hi,
On Wed, 20 Jun 2007, I wrote:
> Index: gcc/df-problems.c
> ===
> --- gcc/df-problems.c (revision 125811)
> +++ gcc/df-problems.c (working copy)
> @@ -1574,7 +1574,7 @@
>/* Call-clobbered registers die across exception and cal
Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Jun 2007, Paolo Bonzini wrote:
>
>
>>> This is one of the places where i slavishly copied what flow did. if
>>> you want to change this, go test it on at least 7 platforms and fix all
>>> of the problems that it causes.
>>>
>> I see. Can one of yo
Hi,
On Wed, 20 Jun 2007, Paolo Bonzini wrote:
> > This is one of the places where i slavishly copied what flow did. if
> > you want to change this, go test it on at least 7 platforms and fix all
> > of the problems that it causes.
>
> I see. Can one of you recap how it relates to the m68k probl
Bernd Schmidt wrote:
> Kenneth Zadeck wrote:
>> Paolo Bonzini wrote:
> having the dead note there is asserting to the register allocator
> that
> they are free to use that reg after the calll in any way that it
> wants
> and there is a (small) possibility that is wrong.
IMO
Kenneth Zadeck wrote:
Paolo Bonzini wrote:
having the dead note there is asserting to the register allocator that
they are free to use that reg after the calll in any way that it wants
and there is a (small) possibility that is wrong.
IMO there is nothing wrong with this.
I agree with Roman.
This is one of the places where i slavishly copied what flow did. if
you want to change this, go test it on at least 7 platforms and fix all
of the problems that it causes.
I see. Can one of you recap how it relates to the m68k problem, though? :-)
Paolo
Paolo Bonzini wrote:
>
>>> having the dead note there is asserting to the register allocator that
>>> they are free to use that reg after the calll in any way that it wants
>>> and there is a (small) possibility that is wrong.
>>
>> IMO there is nothing wrong with this.
>
> I agree with Roman. You
Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
>
>
>> If we add the dead note there we are asserting that the value is
>> modified by the caller. however it might not be and someone could write
>> a piece of asm right after the call to use that reg if the person knew
>>
having the dead note there is asserting to the register allocator that
they are free to use that reg after the calll in any way that it wants
and there is a (small) possibility that is wrong.
IMO there is nothing wrong with this.
I agree with Roman. You can always put your call into an asm
Hi,
On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
> If we add the dead note there we are asserting that the value is
> modified by the caller. however it might not be and someone could write
> a piece of asm right after the call to use that reg if the person knew
> that the reg was not modified by t
Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
>
>
>>> I don't understand, wouldn't the consertive approach be that the value
>>> simply doesn't survive?
>>>
>>>
>> No, the conservative is that we do not know anything. it could be
>> destroyed and it could not
Hi,
On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
> > I don't understand, wouldn't the consertive approach be that the value
> > simply doesn't survive?
> >
> No, the conservative is that we do not know anything. it could be
> destroyed and it could not be destroyed.
What is the value of this? I
Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
>
>
>> For certain regs, the subroutine may or may not modify the value. The
>> better information alluded to is information that one might get by doing
>> interprocedural analysis. Without such information you have to as
Hi,
On Wed, 20 Jun 2007, Kenneth Zadeck wrote:
> For certain regs, the subroutine may or may not modify the value. The
> better information alluded to is information that one might get by doing
> interprocedural analysis. Without such information you have to assume
> that the value may or may n
Roman Zippel wrote:
> Hi,
>
> On Tue, 19 Jun 2007, Kenneth Zadeck wrote:
>
>
>
> Another question I have is about DF_REF_MAY_CLOBBER, any function call
> would also clobber the return value and I see defs generated for calls,
> but they are only marked with DF_REF_MAY_CLOBBER and thus the use c
Hi,
On Tue, 19 Jun 2007, Kenneth Zadeck wrote:
> The reason that there is no reg_dead not in the last use (insn 45)
> before the sib_call (insn 46) is that there is no def for r0 in the
> sibcall (insn 46) and r0 is live at the end of the block.
>
> This of course changes the question to not wh
Roman Zippel wrote:
> Hi,
>
> m68k currently doesn't bootstrap, which I think is dataflow related, the
> whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
> the small test below should be enough to demonstrate the problem
> (although it doesn't crash):
>
> int fi1(int);
Hi,
On Tue, 19 Jun 2007, Kenneth Zadeck wrote:
> roman do i need any patches to apply before trying this.
None should be needed, but this one can't hurt:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01247.html
> also what are
> the config options i need?
I use --target=m68k-linux-gnu --enable
Roman Zippel wrote:
> Hi,
>
> m68k currently doesn't bootstrap, which I think is dataflow related, the
> whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
> the small test below should be enough to demonstrate the problem
> (although it doesn't crash):
>
> int fi1(int);
Hi,
m68k currently doesn't bootstrap, which I think is dataflow related, the
whole precompiled file is at http://www.xs4all.nl/~zippel/expmed.i.gz, but
the small test below should be enough to demonstrate the problem
(although it doesn't crash):
int fi1(int);
int fi2(int);
void *fp1(int, void
FX Coudert <[EMAIL PROTECTED]> writes:
> Bootstrapping today's trunk (rev. 125180) on i386-mingw32 (native)
> leads me to the following error at the end of stage3:
>
> > make[3]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/
> > libiberty/testsuite'
> > make[3]: Entering directory `/home
Bootstrapping today's trunk (rev. 125180) on i386-mingw32 (native)
leads me to the following error at the end of stage3:
make[3]: Leaving directory `/home/coudert/ibin/i386-pc-mingw32/
libiberty/testsuite'
make[3]: Entering directory `/home/coudert/ibin/i386-pc-mingw32/
libiberty'
make[3]: *
On May 25, 2005, at 9:38 AM, Andrew Pinski wrote:
Attached is also the .i file for tree-ssa-operands.c
The failure happens in copyprop3 but that is all I can tell, I have no
idea
what is going wrong.
This is blocking me working on the tree combiner.
Could someone look into this?
I noticed
33 matches
Mail list logo
