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

cvs-commit at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed Jun 15 15:09:17 GMT 2022


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

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

https://gcc.gnu.org/g:8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3

commit r13-1110-g8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3
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.cc (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.


More information about the Gcc-bugs mailing list