> I wasn't ever able to get comfortable with the change in behavior that
> Bernd E's patch introduced. Namely that X no longer meant "anything",
> which is how it's been documented for eons.
Understood. I have applied my patchlet then, with the other, more serious LRA
patch I posted yesterday,
On 12/07/2016 04:21 PM, Eric Botcazou wrote:
Presumably the MEM isn't a valid memory address, but it's allowed
through due to the use of an "X" constraint?
Yes (that was supposed to be more or less clear given the description :-).
ISTM that LRA has to be prepared to handle an arbitrary RTX, s
> Presumably the MEM isn't a valid memory address, but it's allowed
> through due to the use of an "X" constraint?
Yes (that was supposed to be more or less clear given the description :-).
> ISTM that LRA has to be prepared to handle an arbitrary RTX, so punting
> seems appropriate.
My opinion
On 12/06/2016 05:28 AM, Eric Botcazou wrote:
Hi,
the compiler ICEs for SPARC 64-bit with LRA on the asm-subreg-1.c test:
volatile unsigned short _const_32 [4] = {1,2,3,4};
void
evas_common_convert_yuv_420p_601_rgba()
{
__asm__ __volatile__ ("" : : "X" (*_const_32));
}
The issue is that combi
On 12/07/16 10:44, Richard Sandiford wrote:
> Bernd Edlinger writes:
>> Hi Eric,
>>
>> what you got there, looks more or less exactly like what I tried
>> to fix with that patch a few months ago, but unfortunately
>> we were unable to get a consensus on that approach:
>>
>> [PATCH] Fix asm X const
Bernd Edlinger writes:
> Hi Eric,
>
> what you got there, looks more or less exactly like what I tried
> to fix with that patch a few months ago, but unfortunately
> we were unable to get a consensus on that approach:
>
> [PATCH] Fix asm X constraint (PR inline-asm/59155)
> https://gcc.gnu.org/ml/
On Dec 6, 2016, at 8:59 AM, Eric Botcazou wrote:
>
>> what you got there, looks more or less exactly like what I tried
>> to fix with that patch a few months ago, but unfortunately
>> we were unable to get a consensus on that approach:
>
> It's indeed the same underlying issue, but restricted to
> what you got there, looks more or less exactly like what I tried
> to fix with that patch a few months ago, but unfortunately
> we were unable to get a consensus on that approach:
It's indeed the same underlying issue, but restricted to a specific case where
reload and other passes do the right
Hi Eric,
what you got there, looks more or less exactly like what I tried
to fix with that patch a few months ago, but unfortunately
we were unable to get a consensus on that approach:
[PATCH] Fix asm X constraint (PR inline-asm/59155)
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01649.html
Be
Hi,
the compiler ICEs for SPARC 64-bit with LRA on the asm-subreg-1.c test:
volatile unsigned short _const_32 [4] = {1,2,3,4};
void
evas_common_convert_yuv_420p_601_rgba()
{
__asm__ __volatile__ ("" : : "X" (*_const_32));
}
The issue is that combine merges back the 3 instructions necessary to
10 matches
Mail list logo
