This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/58065] New: ARM MALLOC_ABI_ALIGNMENT is wrong
- From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 02 Aug 2013 22:35:23 +0000
- Subject: [Bug target/58065] New: ARM MALLOC_ABI_ALIGNMENT is wrong
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58065
Bug ID: 58065
Summary: ARM MALLOC_ABI_ALIGNMENT is wrong
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target: arm*-*-*
the ARM target architecture does not define the MALLOC_ABI_ALIGNMENT,
therefore the default is used as BITS_PER_WORD, 32 in this case.
This produces sometimes suboptimal code, because the front-end
assumes that the function malloc() returns only word-aligned pointers,
which is likely wrong. I have not found any specific requirements
on the malloc alignment in the AAPCS document at
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf
but I believe that the intention is to align everything including stack
pointers to 8 bytes.
Therefore I would suggest the attached patch which defines
MALLOC_ABI_ALIGNMENT as BIGGEST_ALIGNMENT, which is 64 bits.
As a proof that this has indeed some subtle influence on the generated code
I attach a test case. The function foo is called by bar, and bar uses
malloc to allocate the memory, with compiler options "-O3 -g0 -mfpu=neon
-mfloat-abi=softfp" the function foo is inlined into bar,
but the inlined version does not use vstr instructions any more, because
the front-end does assume that malloc returns 4 byte aligned memory.
If that was really true, foo must fail, if it is called without inlining.
Therefore this code is just clumsy and less optimal than it could be.