This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, ARM] Fix PR 43872, incorrectly aligned VLAs
- From: Chung-Lin Tang <cltang at codesourcery dot com>
- To: Ramana Radhakrishnan <ramana dot radhakrishnan at linaro dot org>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Richard Earnshaw <rearnsha at arm dot com>
- Date: Tue, 15 Mar 2011 19:30:45 +0800
- Subject: Re: [PATCH, ARM] Fix PR 43872, incorrectly aligned VLAs
- References: <4D5CF204.4080306@codesourcery.com> <4D7F0A04.90402@linaro.org>
On 2011/3/15 02:41 PM, Ramana Radhakrishnan wrote:
> On 17/02/11 10:01, Chung-Lin Tang wrote:
>> Hi,
>> this PR is a case where we have a leaf function with a zero-size frame,
>> that calls alloca() (here through a C99 VLA).
>>
>> The ARM backend recognizes the leaf-and-no-frame opportunity to save an
>> unneeded stack alignment. But when calling alloca(), the allocated block
>> is of BIGGEST_ALIGNMENT, which is 8-bytes under current AAPCS. Thus a
>> stack align may still be needed to place the alloca() returned block
>> properly.
>>
>> This patch adjusts the early return condition with !cfun->calls_alloca.
>> Tested without regressions on ARM-Linux, okay for trunk?
>
> OK.
Thanks.
>>
>> Also related, the BIGGEST_ALIGNMENT defined for ARM is currently
>> ABI-based; 64-bits for AAPCS targets, and 32 for old ABI. Should this
>> also consider arch-level as well? i.e. anything>= ARMv5TE (with ldrd)
>> should have this set to 64.
>
> I don't think it's that straightforward. The ABI specifies that an 8
> byte quantity must be aligned at 64 bit boundaries and this should be
> independent of architecture revisions. Think about pointers to 64 bit
> quantities passed from !(TARGET_LDRD) to TARGET_LDRD code or indeed
> creating structure layout issues between architecture revisions if you
> change this.
Oh okay, I see. I checked again, originally thought that structure
layout was controlled by other alignment related macros...