On 10/08/14 10:04, Richard Sandiford wrote:
Rainer Orth writes:
Hi Richard,
Does this work for you? I tested it on x86_64-linux-gnu but obviously
that's not particularly useful for SEQUENCEs.
the patch is fine, as tested on both sparc-sun-solaris2.11 and (for good
measure) i386-pc-solaris2
Rainer Orth writes:
> Hi Richard,
>
>> Does this work for you? I tested it on x86_64-linux-gnu but obviously
>> that's not particularly useful for SEQUENCEs.
>
> the patch is fine, as tested on both sparc-sun-solaris2.11 and (for good
> measure) i386-pc-solaris2.11.
OK, great.
To recap, the ide
Hi Richard,
> Does this work for you? I tested it on x86_64-linux-gnu but obviously
> that's not particularly useful for SEQUENCEs.
the patch is fine, as tested on both sparc-sun-solaris2.11 and (for good
measure) i386-pc-solaris2.11.
Thanks.
Rainer
--
Richard Sandiford writes:
> Rainer Orth writes:
>> Hi Richard,
>>> Rainer Orth writes:
Hi Richard,
>> It seems the new get_some_local_dynamic_name implementation in
>> function.c lost the non-NULL check the sparc.c version had. I'm
>> currently testing the following patch:
Rainer Orth writes:
> Hi Richard,
>> Rainer Orth writes:
>>> Hi Richard,
> It seems the new get_some_local_dynamic_name implementation in
> function.c lost the non-NULL check the sparc.c version had. I'm
> currently testing the following patch:
Could you do a:
c
Hi Richard,
> Rainer Orth writes:
>> Hi Richard,
It seems the new get_some_local_dynamic_name implementation in
function.c lost the non-NULL check the sparc.c version had. I'm
currently testing the following patch:
>>>
>>> Could you do a:
>>>
>>> call debug_rtx (...)
>>>
>>> on
Rainer Orth writes:
> Hi Richard,
>>> It seems the new get_some_local_dynamic_name implementation in
>>> function.c lost the non-NULL check the sparc.c version had. I'm
>>> currently testing the following patch:
>>
>> Could you do a:
>>
>> call debug_rtx (...)
>>
>> on the insn that contains a
Hi Richard,
>> It seems the new get_some_local_dynamic_name implementation in
>> function.c lost the non-NULL check the sparc.c version had. I'm
>> currently testing the following patch:
>
> Could you do a:
>
> call debug_rtx (...)
>
> on the insn that contains a null pointer? Normally insn pa
Rainer Orth writes:
> Hi Richard,
>> Several targets define a function like i386's get_some_local_dynamic_name.
>> The function looks through the current output function and returns the first
>> (arbitrary) local-dynamic symbol that it finds. The result can be used in
>> a call to __tls_get_addr,
Hi Richard,
> Several targets define a function like i386's get_some_local_dynamic_name.
> The function looks through the current output function and returns the first
> (arbitrary) local-dynamic symbol that it finds. The result can be used in
> a call to __tls_get_addr, since all local-dynamic s
Gerald Pfeifer writes:
> On Thu, 4 Sep 2014, Richard Sandiford wrote:
>> Is this stage 1 libgcc or a later libgcc? Seems unlikely if stage 1.
>
> Stage 1. I kicked off a non-parallel build, which just failed as
> follows:
>
> /scratch2/tmp/gerald/OBJ-0904-1719/./gcc/xgcc
> -B/scratch2/tmp/gerald
On Thu, 4 Sep 2014, Richard Sandiford wrote:
> Is this stage 1 libgcc or a later libgcc? Seems unlikely if stage 1.
Stage 1. I kicked off a non-parallel build, which just failed as
follows:
/scratch2/tmp/gerald/OBJ-0904-1719/./gcc/xgcc
-B/scratch2/tmp/gerald/OBJ-0904-1719/./gcc/
-B/home/geral
Gerald Pfeifer writes:
> On Tue, 2 Sep 2014, Richard Sandiford wrote:
>> Also, i386 was robust against uses of %& in inline asm. The patch
>> makes sure the other ports are too. Using %& in inline asm would
>> often be a mistake, but it should at least trigger a proper error
>> rather than an IC
On Tue, 2 Sep 2014, Richard Sandiford wrote:
> Also, i386 was robust against uses of %& in inline asm. The patch
> makes sure the other ports are too. Using %& in inline asm would
> often be a mistake, but it should at least trigger a proper error
> rather than an ICE.
>
> Tested on x86_64-linux
On 09/02/14 12:36, Richard Sandiford wrote:
Several targets define a function like i386's get_some_local_dynamic_name.
The function looks through the current output function and returns the first
(arbitrary) local-dynamic symbol that it finds. The result can be used in
a call to __tls_get_addr,
On Tue, Sep 2, 2014 at 8:36 PM, Richard Sandiford
wrote:
> Several targets define a function like i386's get_some_local_dynamic_name.
> The function looks through the current output function and returns the first
> (arbitrary) local-dynamic symbol that it finds. The result can be used in
> a call
Several targets define a function like i386's get_some_local_dynamic_name.
The function looks through the current output function and returns the first
(arbitrary) local-dynamic symbol that it finds. The result can be used in
a call to __tls_get_addr, since all local-dynamic symbols have the same
17 matches
Mail list logo
