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.
>>

Reply via email to