On 4/16/20 5:21 PM, Segher Boessenkool wrote:
>> +#undef TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P
>> +#define TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P
>> rs6000_cannot_substitute_mem_equiv_p
>
> This line gets too long, you could split it in two?
Done.
>> +/* { dg-do compile { target { powerpc*-*-lin
Hi!
On Thu, Apr 16, 2020 at 08:21:07AM -0500, Peter Bergner wrote:
> The ICE in PR93974 is caused by a bug in decompose address not being able to
> handle Altivec addresses the use AND: to strip off the bottom address bits.
> Rather than modify lra-constraints.c or rtlanal.c to solve this generic
On 4/16/20 8:21 AM, Peter Bergner wrote:
> This passed bootstrap and regression testing on powerpc64le-linux with no
> regressions. Ok for mainline?
This also just passed bootstrap and regtesting on (BE) powerpc64-linux
running the testsuite in both 32-bit and 64-bit modes, with no regressions.
On Thu, 2020-04-16 at 08:21 -0500, Peter Bergner via Gcc-patches wrote:
> The ICE in PR93974 is caused by a bug in decompose address not being
> able to
> handle Altivec addresses the use AND: to strip off the bottom address
> bits.
> Rather than modify lra-constraints.c or rtlanal.c to solve this
The ICE in PR93974 is caused by a bug in decompose address not being able to
handle Altivec addresses the use AND: to strip off the bottom address bits.
Rather than modify lra-constraints.c or rtlanal.c to solve this generic
problem this late in the release cycle, I have decided to fix this in targ
