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.
