[Bug target/77330] __float128 segfaults on 32-bit x86 due to 8-byte malloc alignment
joseph at codesourcery dot com
gcc-bugzilla@gcc.gnu.org
Wed Aug 24 21:24:00 GMT 2016
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330
--- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 24 Aug 2016, bernd.edlinger at hotmail dot de wrote:
> It is only necessary if __float128 is declared a base type.
> But __m512 is no base type, right?
It's clear that __m512 should not be considered a basic type - such types
are a large part of the point of having aligned_alloc and other such
aligned allocation interfaces.
__float128 is now (GCC 7) an alias for _Float128, which is defined by TS
18661-3 to be a basic type (and _Decimal128 met the relevant requirements
long before that).
> Then MALLOC_ABI_ALIGNMENT should be changed to 128 at least for the i386.
I think that would risk breaking applications that do not use any
16-byte-aligned types, without obvious benefits (only those programs that
do use those types are affected by the present issue with malloc providing
insufficient alignment).
MALLOC_ABI_ALIGNMENT is indeed unnecessarily conservative. For glibc
targets it could reflect the actual glibc logic, depending on the glibc
version determined at GCC configure time - except that this might break
things for applications that replace malloc with a version that yields
lower alignment (possibly only for small allocations - if there is a
16-byte-aligned basic type, ISO C requires malloc (1) to return a
16-byte-aligned address, but some replacements may be for contexts where
that is unnecessary), knowing the higher alignment is irrelevant to their
application, so there would need to be some way to address that breakage.
More information about the Gcc-bugs
mailing list