Ping...
On 2/12/19 1:32 PM, Bernd Edlinger wrote: > Hi! > > I'd like to ping for this patch: > https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00248.html > > Thanks > Bernd. > > > On 2/5/19 4:07 PM, Bernd Edlinger wrote: >> Hi, >> >> due to the AAPCS parameter passing of 8-byte aligned structures, which >> happen to >> be 8-byte aligned or only 4-byte aligned in the test case, ldrd instructions >> are generated that may access 4-byte aligned stack slots, which will trap on >> ARMv5 and >> ARMv6 according to the following document: >> >> >> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473m/dom1361290002364.html >> says: >> >> "In ARMv5TE, or in ARMv6 when SCTLR.U is 0, LDRD and STRD doubleword data >> transfers must be >> eight-byte aligned. Use ALIGN 8 before memory allocation directives such as >> DCQ if the data >> is to be accessed using LDRD or STRD. This is not required in ARMv6 when >> SCTLR.U is 1, or in >> ARMv7, because in these versions, doubleword data transfers can be >> word-aligned." >> >> >> The reason why the ldrd instruction is generated seems to be a missing >> alignment check in the >> function output_move_double. But when that is fixed, it turns out that if >> the parameter happens >> to be 8-byte aligned by chance, they still have MEM_ALIGN = 4, which >> prevents the ldrd completely. >> >> The reason for that is in function.c (assign_parm_find_stack_rtl), where >> values that happen to be >> aligned to STACK_BOUNDARY, are only aligned to PARM_BOUNDARY. >> >> >> Bootstrapped and reg-tested on x86_64-pc-linux-gnu and arm-linux-gnueabihf >> with all languages. >> Is it OK for trunk? >> >> >> Thanks >> Bernd. >>