On Tue, Oct 15, 2013 at 10:18 AM, Richard Sandiford
wrote:
> Ian Lance Taylor writes:
>> On Tue, Oct 15, 2013 at 2:18 AM, Richard Biener
>> wrote:
>>>
>>> Ok for the tailcall parts and the testcase - I'd prefer someone else to
>>> ack the libgcc change. CCing maintainer.
>>
>> The libgcc patch
Ian Lance Taylor writes:
> On Tue, Oct 15, 2013 at 2:18 AM, Richard Biener
> wrote:
>>
>> Ok for the tailcall parts and the testcase - I'd prefer someone else to
>> ack the libgcc change. CCing maintainer.
>
> The libgcc patch is missing the updates to the comments. This code is
> confusing eno
On Tue, Oct 15, 2013 at 2:18 AM, Richard Biener
wrote:
>
> Ok for the tailcall parts and the testcase - I'd prefer someone else to
> ack the libgcc change. CCing maintainer.
The libgcc patch is missing the updates to the comments. This code is
confusing enough as it is, having incorrect comment
On Tue, Oct 15, 2013 at 9:59 AM, Richard Sandiford
wrote:
> Richard Biener writes:
Honza? For tailr this boils down to symtab_semantically_equivalent_p ().
I suppose we don't want to change that but eventually special case
builtins in tailr, thus
Index: gcc/tree-tailcall
Richard Biener writes:
>>> Honza? For tailr this boils down to symtab_semantically_equivalent_p ().
>>> I suppose we don't want to change that but eventually special case
>>> builtins in tailr, thus
>>>
>>> Index: gcc/tree-tailcall.c
>>> ===
On Fri, Oct 11, 2013 at 3:27 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Fri, Oct 11, 2013 at 12:48 PM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Fri, Oct 11, 2013 at 11:43 AM, Richard Sandiford
wrote:
> Jakub Jelinek writes:
>> On Fri, Oct 11
Richard Biener writes:
> On Fri, Oct 11, 2013 at 12:48 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Fri, Oct 11, 2013 at 11:43 AM, Richard Sandiford
>>> wrote:
Jakub Jelinek writes:
> On Fri, Oct 11, 2013 at 10:17:41AM +0200, Richard Biener wrote:
>> asm(".alias
Jakub Jelinek writes:
> On Fri, Oct 11, 2013 at 10:17:41AM +0200, Richard Biener wrote:
>> asm(".alias __sync_synchronize sync_synchronize");
>
> It is .set, but not everywhere.
> /* The MIPS assembler has different syntax for .set. We set it to
>.dummy to trap any errors. */
> #undef SET_ASM
On Fri, Oct 11, 2013 at 12:48 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Fri, Oct 11, 2013 at 11:43 AM, Richard Sandiford
>> wrote:
>>> Jakub Jelinek writes:
On Fri, Oct 11, 2013 at 10:17:41AM +0200, Richard Biener wrote:
> asm(".alias __sync_synchronize sync_synchroni
Richard Biener writes:
> On Fri, Oct 11, 2013 at 11:43 AM, Richard Sandiford
> wrote:
>> Jakub Jelinek writes:
>>> On Fri, Oct 11, 2013 at 10:17:41AM +0200, Richard Biener wrote:
asm(".alias __sync_synchronize sync_synchronize");
>>>
>>> It is .set, but not everywhere.
>>> /* The MIPS assem
On Fri, Oct 11, 2013 at 12:16:03PM +0200, Richard Biener wrote:
> For the __sync functions it's unfortunate that the library function has
> the same 'name' as the builtin and the builtin doesn't have an alternate
> spelling. So - can't we just add __builtin__sync_... spellings and use
>
> __sync_
On Fri, Oct 11, 2013 at 11:43 AM, Richard Sandiford
wrote:
> Jakub Jelinek writes:
>> On Fri, Oct 11, 2013 at 10:17:41AM +0200, Richard Biener wrote:
>>> asm(".alias __sync_synchronize sync_synchronize");
>>
>> It is .set, but not everywhere.
>> /* The MIPS assembler has different syntax for .set
Jakub Jelinek writes:
> On Fri, Oct 11, 2013 at 10:17:41AM +0200, Richard Biener wrote:
>> asm(".alias __sync_synchronize sync_synchronize");
>
> It is .set, but not everywhere.
> /* The MIPS assembler has different syntax for .set. We set it to
>.dummy to trap any errors. */
> #undef SET_ASM
On Fri, Oct 11, 2013 at 10:17:41AM +0200, Richard Biener wrote:
> asm(".alias __sync_synchronize sync_synchronize");
It is .set, but not everywhere.
/* The MIPS assembler has different syntax for .set. We set it to
.dummy to trap any errors. */
#undef SET_ASM_OP
#define SET_ASM_OP "\t.dummy\t"
On Fri, Oct 11, 2013 at 9:29 AM, Richard Sandiford
wrote:
> This is a follow-up to:
>
> http://gcc.gnu.org/ml/gcc/2013-10/msg00075.html
>
> The outcome on IRC was that __asm ought to behave like aliases eventually,
> so we should abandom the renaming-in-C thing. One way would be to code
> the f
15 matches
Mail list logo