Hi Nathan,
> lm32 has a gdb simulator available, so it should be fairly easy to write
> a board file for it if one doesn't already exist.
>
> Unfortunately, building lm32-elf is broken in several different ways
> right now.
What problems do you have building lm32-elf? If you let me know, I can t
Paolo Bonzini schrieb:
> On 10/26/2010 07:42 PM, Georg Lay wrote:
>> I set a break at the end of df_simulate_one_insn_backwards.
>> CURRENT = *(live->current->bits)
>> FIRST = *(live->first->bits)
>
> Or call debug_bitmap (). :)
>
>> reg 26 (Stackpointer) and reg 27 (return address) do not matt
Hello
I am at the GCC Summit.
If some GCC Makefile maintainer could meet me to discuss face to face how
and where concretely should the gengtype program be installed I would be
grateful.
As you know, I am pushing patches to make gengtype really usable from
plugins, and that means persisting its
On 27/10/2010 07:47, Joakim Tjernlund wrote:
> Alan Modra wrote on 2010/10/27 04:01:50:
>> On Wed, Oct 27, 2010 at 12:53:00AM +0100, Dave Korn wrote:
>>> On 26/10/2010 23:37, Joakim Tjernlund wrote:
>>>
Everything went dead quiet the minute I stated to send patches, what did
I do wrong?
On 10/27/2010 12:54 PM, Georg Lay wrote:
reg 26 (Stackpointer) and reg 27 (return address) do not matter here.
The result ist
insn 10 (CALL) CURRENT = FIRST = 0xc008010 = {...,4,15}
Ok, this looks like a bug somewhere (either in DF or in your backend).
hmmm. How could the backend introduce
Paolo Bonzini schrieb:
> On 10/27/2010 12:54 PM, Georg Lay wrote:
reg 26 (Stackpointer) and reg 27 (return address) do not matter here.
The result ist
insn 10 (CALL) CURRENT = FIRST = 0xc008010 = {...,4,15}
>>>
>>> Ok, this looks like a bug somewhere (either in DF or in your b
On 10/27/2010 04:30 PM, Georg Lay wrote:
The first time it occurs in "exit block uses" is in pro/epilogue:
peep2.c.193r.split2:;; exit block uses 2 [d2] 26 [SP] 27 [a11]
peep2.c.195r.pro_and_epilogue:;; exit block uses2 [d2] 15 [d15] 26 [SP]
27 [a11]
peep2.c.196r.dse2:;; exit
Hi Jon,
Le mardi 26 octobre 2010 à 13:07 +0100, Jon Beniston a écrit :
> What problems do you have building lm32-elf? If you let me know, I can try
> to look in to them.
If you have access to a lm32 toolchain, can you test if
gcc.c-torture/execute/built-in-setjmp.c passes at different optimizatio
On Tue, Oct 26, 2010 at 01:07:26PM +0100, Jon Beniston wrote:
> > lm32 has a gdb simulator available, so it should be fairly easy to write
> > a board file for it if one doesn't already exist.
> >
> > Unfortunately, building lm32-elf is broken in several different ways
> > right now.
>
> What pro
Hi Jeff,
On 26 October 2010 16:22, Jeff Law wrote:
> There is currently no pass which does "un-cse"; however, using insn
> splitting and operand costing and suitable insn constraints/predicates you
> can usually arrange to avoid expensive constants in places where it makes
> sense.
The thing is
Sorry for having to bail out without saying goodbye to anyone or
participate in the GCC Steering Committee panel; I got word from my
attorney that the affidavit that he needed did not get properly
transferred this morning. After repeated attempts I gave up on the
hotel fax service (Les Suite
On 10/27/10 12:15, Frederic Riss wrote:
Hi Jeff,
On 26 October 2010 16:22, Jeff Law wrote:
There is currently no pass which does "un-cse"; however, using insn
splitting and operand costing and suitable insn constraints/predicates you
can usually arrange to avoid expensive constants in places
On 27 October 2010 21:21, Jeff Law wrote:
> On 10/27/10 12:15, Frederic Riss wrote:
>> On 26 October 2010 16:22, Jeff Law wrote:
>>
>> The thing is the cprop pass doesn't look at insn costs while doing its
>> job AFAICS. I'm interested to see how insn splitting can help with
>> this if you don't
13 matches
Mail list logo
