Richard Sandiford wrote:
Returning to this old thread...
Richard Sandiford writes:
Tejas Belagod writes:
When I relaxed CANNOT_CHANGE_MODE_CLASS to undefined for AArch64,
gcc.c-torture/execute/copysign1.c generates incorrect code because LRA cannot
seem to handle subregs like
(subreg:DI (
Returning to this old thread...
Richard Sandiford writes:
> Tejas Belagod writes:
>> When I relaxed CANNOT_CHANGE_MODE_CLASS to undefined for AArch64,
>> gcc.c-torture/execute/copysign1.c generates incorrect code because LRA
>> cannot
>> seem to handle subregs like
>>
>> (subreg:DI (reg:TF
"H.J. Lu" writes:
> How about this patch
>
> http://gcc.gnu.org/git/?p=gcc.git;a=patch;h=23023006b946e06b6fd93786585f2f8cd4837956
>
> I tested it on Linux/x86-64 without any regressions.
I don't think we should key this off vectorness. It's a question of
whether the class contains a register for
On Sat, Jan 11, 2014 at 2:12 AM, Richard Sandiford
wrote:
> Tejas Belagod writes:
>> When I relaxed CANNOT_CHANGE_MODE_CLASS to undefined for AArch64,
>> gcc.c-torture/execute/copysign1.c generates incorrect code because LRA cannot
>> seem to handle subregs like
>>
>> (subreg:DI (reg:TF hard_re
Tejas Belagod writes:
> When I relaxed CANNOT_CHANGE_MODE_CLASS to undefined for AArch64,
> gcc.c-torture/execute/copysign1.c generates incorrect code because LRA cannot
> seem to handle subregs like
>
> (subreg:DI (reg:TF hard_reg) 8)
>
> on hard registers where the subreg byte offset is unal
Hi,
When I relaxed CANNOT_CHANGE_MODE_CLASS to undefined for AArch64,
gcc.c-torture/execute/copysign1.c generates incorrect code because LRA cannot
seem to handle subregs like
(subreg:DI (reg:TF hard_reg) 8)
on hard registers where the subreg byte offset is unaligned to a hard register
bou
