On Wed, Mar 14, 2018 at 8:03 AM, Alexandre Oliva wrote:
> On Mar 12, 2018, "Bin.Cheng" wrote:
>
>> internal compiler error: in aarch64_classify_address, at
>> config/aarch64/aarch64.c:5678
>> 0xfe3c29 aarch64_classify_address
>> /.../build/src/gcc/gcc/config/aarch64/aarch64.c:5677
>> 0xfe8be8
On Mar 12, 2018, "Bin.Cheng" wrote:
> internal compiler error: in aarch64_classify_address, at
> config/aarch64/aarch64.c:5678
> 0xfe3c29 aarch64_classify_address
> /.../build/src/gcc/gcc/config/aarch64/aarch64.c:5677
> 0xfe8be8 aarch64_legitimate_address_hook_p
> /.../build/src/gcc/gcc/c
On Fri, Mar 9, 2018 at 6:45 AM, Alexandre Oliva wrote:
> LRA gets very confused when non-addresses are passed as operands to
> asms with address contraints. Even if other constraints are
> available, and the operand is a perfect fit for them, we'd still
> attempt to process the operand as an addr
On 03/08/2018 11:45 PM, Alexandre Oliva wrote:
> LRA gets very confused when non-addresses are passed as operands to
> asms with address contraints. Even if other constraints are
> available, and the operand is a perfect fit for them, we'd still
> attempt to process the operand as an address, and
On 03/09/2018 01:45 AM, Alexandre Oliva wrote:
LRA gets very confused when non-addresses are passed as operands to
asms with address contraints. Even if other constraints are
available, and the operand is a perfect fit for them, we'd still
attempt to process the operand as an address, and fail
LRA gets very confused when non-addresses are passed as operands to
asms with address contraints. Even if other constraints are
available, and the operand is a perfect fit for them, we'd still
attempt to process the operand as an address, and fail miserably at
that.
Truth is, address constraints
