[Bug target/77330] __float128 segfaults on 32-bit x86 due to 8-byte malloc alignment

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.