On 04/14/2017 10:24 AM, Richard Sandiford wrote:
Jeff Law writes:
On 04/14/2017 05:22 AM, Richard Sandiford wrote:
Jeff Law writes:
The mips64vr-elf target will fail building newlib, particularly the
mips16 newlib as we emit bogus assembly code.
In
On 04/14/2017 11:01 AM, Jeff Law wrote:
On 04/14/2017 10:24 AM, Richard Sandiford wrote:
I think it only does that if the "containing object" that you're
validating is a MEM. If the object you're validating is an insn
(which it always is for regcprop) then normal constrain_operands
does
On 04/14/2017 10:24 AM, Richard Sandiford wrote:
I think it only does that if the "containing object" that you're
validating is a MEM. If the object you're validating is an insn
(which it always is for regcprop) then normal constrain_operands
does happen.
Hmm, you've of course right!
Jeff Law writes:
> On 04/14/2017 05:22 AM, Richard Sandiford wrote:
>> Jeff Law writes:
>>> The mips64vr-elf target will fail building newlib, particularly the
>>> mips16 newlib as we emit bogus assembly code.
>>>
>>> In particular the compiler will emit
On 04/14/2017 05:22 AM, Richard Sandiford wrote:
Jeff Law writes:
The mips64vr-elf target will fail building newlib, particularly the
mips16 newlib as we emit bogus assembly code.
In particular the compiler will emit something like
lwu $2,0($sp)
That's invalid in mips16
Jeff Law writes:
> The mips64vr-elf target will fail building newlib, particularly the
> mips16 newlib as we emit bogus assembly code.
>
> In particular the compiler will emit something like
>
> lwu $2,0($sp)
>
> That's invalid in mips16 mode AFAICT.
>
> That's emitted by the
The mips64vr-elf target will fail building newlib, particularly the
mips16 newlib as we emit bogus assembly code.
In particular the compiler will emit something like
lwu $2,0($sp)
That's invalid in mips16 mode AFAICT.
That's emitted by the extendsidi pattern. It's a case where the