Sources Bugzilla – Bug 6527
Malloc alignment insufficient for PowerPC
Last modified: 2013-01-09 21:22:04 UTC
The C standard says that malloc's alignment should be great enough for long
double variables. On PowerPC with 128-bit long double, this is not true. GDB
heap-allocates long double variables, so it is broken; when compiled with
altivec turned on the expression parser will perform misaligned vector loads
thinking they are correctly aligned.
Discussion continues into November:
I'll attach the patch we've been using for six months.
Created attachment 2739 [details]
This patch increases malloc alignment for PowerPC.
It breaks only emacs, which uses malloc_set_state; emacs does not even check
the result of malloc_set_state for failure. Recompiling emacs after updating
glibc is in my opinion acceptable. Nothing else uses malloc_set_state that I
This patch is already in. Closing this as fixed.
This is *not* fixed. The correct alignment is enabled only for !SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_16) - that is, for new ports (x32). No-one has yet done the compatibility work required for new binaries on powerpc32 to get the correct alignment without breaking existing emacs binaries.
I think in fact such a change should be made for 32-bit x86 as well, if we can find a way to do it without breaking existing emacs binaries, because the alignment requirement of _Decimal128 is 16-byte on 32-bit x86, and decimal floating-point is defined in terms of standard types added to the C set.
(32-bit x86 would need a separate MALLOC_ALIGNMENT definition because _Decimal128 isn't a type malloc.c considers when working out the required alignment, and most architectures don't support it.)