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

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77330

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 23 Aug 2016, mikulas at artax dot karlin.mff.cuni.cz wrote:

> And if you add a new type __float256 with 32-byte alignment - does it mean that
> glibc suddenly starts being buggy, because it couldn't anticipate what types
> with what alignment will be added in the future? In this situation, GCC broke
> it by adding new types, glibc didn't.

If you add a new basic type, that requires cooperation between the 
compiler and the library; "implementation" in standard terms includes 
both.

If you add a new type that is not a basic type, such as a vector type, 
users need to use aligned_alloc etc. when allocating memory for it.

If you consider __float128 a basic type, the change for this issue must be 
made in libc.  If you don't, the program in this report is buggy because 
it uses malloc for a type with an extended alignment requirement.  In 
neither case is there a GCC bug (except that max_align_t should be updated 
if __float128 is a basic type).

The ABI for __float128 and _Decimal128, including alignment, is now long 
established and would not be appropriate to change (changing max_align_t 
would be rather safer).

> GCC works on wide range of systems, not only on glibc - how are you going to
> patch malloc alignment in all those libc's that GCC supports?

GCC works best as part of the GNU system, with glibc.  If the library 
doesn't support the new types, that may limit the GCC support.

Note that glibc support for _Float128 on powerpc64le is planned, and once 
it's there it will be easy to add all the library functions on x86 and 
x86_64 as well.