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. Original posting: http://sourceware.org/ml/libc-alpha/2007-10/msg00087.html Discussion continues into November: http://sourceware.org/ml/libc-alpha/2007-11/msg00000.html http://sourceware.org/ml/libc-alpha/2007-11/msg00007.html I'll attach the patch we've been using for six months.
Created attachment 2739 [details] Alignment patch 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 could locate.
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.)