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.
Created attachment 30598 [details] test case
Created attachment 30599 [details] compiler output without this patch
Created attachment 30600 [details] correct compiler output with patch
Created attachment 30601 [details] Proposed patch
malloc() [glibc implementation] default alignment is sizeof(long double) or 2 * sizeof(size_t) if I remember correctly, which is 8 bytes for ARMv7. I think, based on C and C++ standard you have to make sure that alignment is good for whatever primitive type, which means alignment size being the size of the biggest primitive type (long double). Reference bug ticket(9 years old): http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795 Quote from C standard (identical or similar exist in C++): The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated).
(In reply to Bernd Edlinger from comment #4) > Created attachment 30601 [details] > Proposed patch If you want to propose a patch please post to the mailing list. Ramana
Patch was posted here: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00350.html
Fixed by http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00197.html
Author: clyon Date: Thu Sep 5 12:27:56 2013 New Revision: 202276 URL: http://gcc.gnu.org/viewcvs?rev=202276&root=gcc&view=rev Log: 2013-09-05 Christophe Lyon <christophe.lyon@linaro.org> Backport from trunk r201589. 2013-08-08 Bernd Edlinger <bernd.edlinger@hotmail.de> PR target/58065 * config/arm/arm.h (MALLOC_ABI_ALIGNMENT): Define. Modified: branches/linaro/gcc-4_8-branch/ (props changed) branches/linaro/gcc-4_8-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_8-branch/gcc/config/arm/arm.h Propchange: branches/linaro/gcc-4_8-branch/ ('svn:mergeinfo' modified)