[Bug target/105981] [10/11/12 regression] Wrong code from gen_cpymem_ldrd_strd() with -mbig-endian

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105981

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Richard Earnshaw
<rearnsha@gcc.gnu.org>:

https://gcc.gnu.org/g:2a9c9ed732d6a7f4565a286bdeb953f08fbe8fb9

commit r11-10074-g2a9c9ed732d6a7f4565a286bdeb953f08fbe8fb9
Author: Richard Earnshaw <rearnsha@arm.com>
Date:   Wed Jun 15 16:07:20 2022 +0100

    arm: big-endian issue in gen_cpymem_ldrd_strd [PR105981]

    The code in gen_cpymem_ldrd_strd has been incorrect for big-endian
    since r230663.  The problem is that we use gen_lowpart, etc. to split
    the 64-bit quantity, but fail to account for the fact that these
    routines are really dealing with 64-bit /values/ and in big-endian the
    ordering of the sub-registers changes.

    To fix this, I've renamed the conceptually misnamed low_reg and hi_reg
    as first_reg and second_reg, and then used different logic for
    big-endian targets to initialize these values.  This makes the logic
    clearer than trying to think about high bits and low bits.

    gcc/ChangeLog:

            PR target/105981
            * config/arm/arm.c (gen_cpymem_ldrd_strd): Rename low_reg and
hi_reg
            to first_reg and second_reg respectively.  Initialize them
correctly
            when generating big-endian code.

    (cherry picked from commit 8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3)