On 17/02/18 00:04, Steve Ellcey wrote:
> On Thu, 2018-02-15 at 14:01 +, Richard Earnshaw (lists) wrote:
>>
>> Wouldn't it be better to call output_operand_lossage() with a suitable
>> diagnostic message? If the operand isn't in Pmode assembly will
>> (should) fail anyway.
>>
>> R.
>
> How a
On Thu, 2018-02-15 at 14:01 +, Richard Earnshaw (lists) wrote:
>
> Wouldn't it be better to call output_operand_lossage() with a suitable
> diagnostic message? If the operand isn't in Pmode assembly will
> (should) fail anyway.
>
> R.
How about this patch? In addtion to the code change I u
On 05/01/18 22:14, Steve Ellcey wrote:
> This is a fix for PR target/83335. We are asserting in
> aarch64_print_address_internal because we have a non Pmode
> address coming from an asm instruction. My fix is to
> just allow this by checking this_is_asm_operands. This is
> what it was doing bef
This is a fix for PR target/83335. We are asserting in
aarch64_print_address_internal because we have a non Pmode
address coming from an asm instruction. My fix is to
just allow this by checking this_is_asm_operands. This is
what it was doing before the assert was added that caused
the ICE.
Ve