Hello gcc maintainers:
I'm Qinwei from Sunnorth. I volunteer to be a Score gcc maintainer and
I'm eager to do more contributions to gcc. Previously i maintained
Score gdb, binutils and glibc rtld for Sunnorth. Could i do that? If i
could, what should i do?
--
Best regards,
Qinwei
On Wed, Mar 2, 2011 at 2:07 PM, Qin wei wrote:
> Hello gcc maintainers:
>
> I'm Qinwei from Sunnorth. I volunteer to be a Score gcc maintainer and
> I'm eager to do more contributions to gcc. Previously i maintained
> Score gdb, binutils and glibc rtld for Sunnorth. Could i do that? If i
> could,
>
> SCORE lacks somebody monitoring the GCC development trunk making
> sure that 1) it builds, 2) it works (*)
>
> Richard.
>
> (*) perform testsuite runs, monitor and address regressions and regularly
> post testresults to gcc-testresults
>
Hi Richard,
We are doing this thing now, you will see
t
On 02/03/2011 07:56, Liu wrote:
> The wrong code is :
> L9284: ATTRIBUTE_UNUSED_LABEL
> x3 = XEXP (x2, {);
> if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (13)])
> goto L9285;
> goto ret0;
>
> L9285: ATTRIBUTE_UNUSED_LABEL
> x3 = XEXP (x2, |);
> if (x3 == const_int_rtx[MAX_SAVED_C
On Wed, Mar 2, 2011 at 8:07 AM, Qin wei wrote:
> Hello gcc maintainers:
>
> I'm Qinwei from Sunnorth. I volunteer to be a Score gcc maintainer and
> I'm eager to do more contributions to gcc. Previously i maintained
> Score gdb, binutils and glibc rtld for Sunnorth. Could i do that? If i
> could,
Dave Korn writes:
> On 02/03/2011 07:56, Liu wrote:
>
>> The wrong code is :
>> L9284: ATTRIBUTE_UNUSED_LABEL
>> x3 = XEXP (x2, {);
>> if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (13)])
>> goto L9285;
>> goto ret0;
>
> Well, that's coming from here:
>
> else
> printf ("
On Wed, Mar 02, 2011 at 07:14:53AM -0800, Ian Lance Taylor wrote:
> This patch should at least cause genrecog to crash for you rather than
> generating bogus output. I've verified that this patch bootstraps on
> x86_64 and makes no difference in the generated insn-recog.c. Can you
> see whether t
Question, how is the uid for a type calculated? What are the
contributing factors?
Can I count on the uid for a type in a header to be the same across all
compilation units that use that header?
Cheers,
Kyle
On Wed, Mar 02, 2011 at 07:16:19AM +0100, Ralf Wildenhues wrote:
> Hello Dave,
>
> * Dave Korn wrote on Wed, Mar 02, 2011 at 06:28:15AM CET:
> > http://mad-scientist.net/make/autodep.html
> >
> > although note that where that recommends using "-include" (under
> > "Avoiding ``No rule to make
Hi,
On Wed, 2 Mar 2011, Kyle Girard wrote:
> Question, how is the uid for a type calculated? What are the
> contributing factors?
It's simply a counter incremented each time a type node is created (see
next_type_uid), hence ...
> Can I count on the uid for a type in a header to be the same acr
Nathan Froyd writes:
> On Wed, Mar 02, 2011 at 07:14:53AM -0800, Ian Lance Taylor wrote:
>> This patch should at least cause genrecog to crash for you rather than
>> generating bogus output. I've verified that this patch bootstraps on
>> x86_64 and makes no difference in the generated insn-recog
> It's simply a counter incremented each time a type node is created (see
> next_type_uid), hence ...
>
Thanks the info.
> > Can I count on the uid for a type in a header to be the same across all
> > compilation units that use that header?
>
> ... no.
>
Is there anyway in gcc to get a uni
We are trying to add some flags to GCC_FOR_TARGET so that when
check-gcc runs, it includes a few extra sysroot and -isystem options.
To do this, we've modified the definition in gcc/Makefile.in to add
these extra options:
-GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./
-B$(build_tooldir)/bin/ -i
Kyle Girard writes:
> Is there anyway in gcc to get a unique id for a type that would be the
> same across compilation units? Or would I have to come up with my own
> encoding somehow?
I don't know of anything like that in gcc today. The first thing you
need to do is define when two types are
Diego Novillo writes:
> We are trying to add some flags to GCC_FOR_TARGET so that when
> check-gcc runs, it includes a few extra sysroot and -isystem options.
> To do this, we've modified the definition in gcc/Makefile.in to add
> these extra options:
>
> -GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./x
* Jack Howarth wrote on Wed, Mar 02, 2011 at 06:08:22PM CET:
> On Wed, Mar 02, 2011 at 07:16:19AM +0100, Ralf Wildenhues wrote:
> > Jack, the actual issue you're seeing might well be the result of some
> > missing dependency. With parallel build failures, it is most important
> > to see output fro
On 02/26/2011 08:20 AM, DJ Delorie wrote:
> Is this expected behavior? Do I need to do some magic in my epilogue
> to further "fix" the stack pointer?
Well, you can begin by honoring frame_pointer_needed properly.
I can't see how m32c works with any function that uses alloca.
You seem to be rely
On 03/03/2011 01:14 AM, Ian Lance Taylor wrote:
> This patch should at least cause genrecog to crash for you rather than
> generating bogus output. I've verified that this patch bootstraps on
> x86_64 and makes no difference in the generated insn-recog.c. Can you
> see whether this gives you a cr
So... gcc assumes the register push/pops happen before the frame
pointer is initialized? So the epilog always restores $sp from $fp
before restoring registers?
That would make the m32c port much less efficient, since it has the
exitd opcode which restores $sp, releases the frame, and returns, al
On 03/03/2011 09:55 AM, DJ Delorie wrote:
> So... gcc assumes the register push/pops happen before the frame
> pointer is initialized? So the epilog always restores $sp from $fp
> before restoring registers?
Ah, I see you're one of the rare ! EXIT_IGNORE_STACK targets.
There does seem to be an o
> which never needs the pair of spill insns. Something to consider...
Does gcc provide a flag that says "your $sp will be unspecified at the
end of this function" that's valid during reload and for prologue and
epilogue generation? I could push $pc onto the stack just after
setting $fp, so it's
On 03/03/2011 11:49 AM, DJ Delorie wrote:
>> which never needs the pair of spill insns. Something to consider...
>
> Does gcc provide a flag that says "your $sp will be unspecified at the
> end of this function" that's valid during reload and for prologue and
> epilogue generation? I could push
Doh, I suppose what I want is $sp, no, $fp, but that's where I'm
storing it, so I suppose I could just set $sp from $fp+const, yes?
It's an extra "restore sp from fp" but only when the frame size is
variable.
On 03/03/2011 12:04 PM, DJ Delorie wrote:
> Doh, I suppose what I want is $sp, no, $fp, but that's where I'm
> storing it, so I suppose I could just set $sp from $fp+const, yes?
Yes. That's what I was trying to describe with that mova sequence.
> It's an extra "restore sp from fp" but only when
On Wed, Mar 2, 2011 at 11:14 PM, Ian Lance Taylor wrote:
> Dave Korn writes:
>
>> On 02/03/2011 07:56, Liu wrote:
>>
>>> The wrong code is :
>>> L9284: ATTRIBUTE_UNUSED_LABEL
>>> x3 = XEXP (x2, {);
>>> if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (13)])
>>> goto L9285;
>>> goto ret0;
Liu writes:
>> It's a bit odd to have more than 26 elements. Do you have any
>> incredibly large define_insn patterns?
>>
> Yes, I have some 80 lines define_insn patterns, are they incredibly large?
An 80 line pattern is incredibly large, yes. The size of the overall
define_insn doesn't matter
On Thu, Mar 3, 2011 at 11:09 AM, Ian Lance Taylor wrote:
> Liu writes:
>
>>> It's a bit odd to have more than 26 elements. Do you have any
>>> incredibly large define_insn patterns?
>>>
>> Yes, I have some 80 lines define_insn patterns, are they incredibly large?
>
> An 80 line pattern is incred
27 matches
Mail list logo
