[AArch64] Fix predicate and constraint mismatch in logical atomic operations

[Christophe Lyon]

On 15 June 2015 at 14:16, Christophe Lyon <christophe.lyon@linaro.org> wrote:
> On 8 May 2015 at 12:42, Richard Biener <richard.guenther@gmail.com> wrote:
>> On Tue, Nov 4, 2014 at 11:44 AM, Marcus Shawcroft
>> <marcus.shawcroft@gmail.com> wrote:
>>> On 25 September 2014 04:45, Michael Collison
>>> <michael.collison@linaro.org> wrote:
>>>> On certain patterns in atomics.md the constraint 'n' is used in combination
>>>> with the predicate atomic_op_operand. The constraint is too general and
>>>> allows constants that are disallowed by the predicate. This causes an ICE In
>>>> final_scan_insn when the insn cannot be split because the constraint and
>>>> predicate do not match.
>>>>
>>>> Tested on aarch64-none-elf, aarch64-linux-gnu. Additionally the originally
>>>> reporter of the bug, (doko@ubuntu.com), applied the patch and successfully
>>>> bootstrapped and tested with no regressions.
>>>>
>>>> 2014-09-23  Michael Collison <michael.collison@linaro.org>
>>>>
>>>>     * config/aarch64/iterators.md (lconst_atomic): New mode attribute to
>>>>     support constraints for CONST_INT in atomic operations.
>>>>     * config/aarch64/atomics.md
>>>>     (atomic_<atomic_optab><mode>): Use lconst_atomic constraint.
>>>>     (atomic_nand<mode>): Likewise.
>>>>     (atomic_fetch_<atomic_optab><mode>): Likewise.
>>>>     (atomic_fetch_nand<mode>): Likewise.
>>>>     (atomic_<atomic_optab>_fetch<mode>): Likewise.
>>>>     (atomic_nand_fetch<mode>): Likewise.
>>>
>>> OK Thanks.  /Marcus
>>
>> Can you please backport this to all release branches as well?
>>
>
> Hi Richard,
>
> I have tested this backport against 4.8 and 4.9 branches.
> I applies cleanly in both cases, shows no regression and fixes the ICE.
>
> I'm afraid it's too late for committing into the 4.8 branch?
>
> Sorry for the delay in handling this.
>
> Christophe.
>

For the record, I have committed this backport as r224503. in the 4.9-branch.

I will commit it in the 4.8-branch when Richard confirms it's OK.


>> Thanks,
>> Richard.