http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916
--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2013-01-09 20:57:13 UTC --- On Wed, 9 Jan 2013, pinskia at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55916 > > --- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2013-01-09 > 16:09:25 UTC --- > > As __float128 is outside of the scope of C/C++, this is not a bug on the C > > library side. > > It might be outside the scope of C/C++ but doesn't C99 allow some > implementation defined types? C99 has no concept of types with extended alignment requirements. I've commented before on how __int128 needs to be thought of as a "sui generis extended type" not "extended integer type" because while it has some of the properties of an integer type, it's wider than intmax_t which forms part of the C library ABI so isn't that easy to change to make 128 bits. I suppose in fact such a sui generis extended type also isn't strictly an object type (just acts like one) in order to follow the "suitably aligned so that it may be assigned to a pointer to any type of object and then used to access such an object or an array of such objects in the space allocated" in C99. For C11 the wording is different - "suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and then used to access such an object or an array of such objects in the space allocated". Fundamental alignments are defined in 6.2.8#2 "A fundamental alignment is represented by an alignment less than or equal to the greatest alignment supported by the implementation in all contexts, which is equal to _Alignof (max_align_t).". Extended alignments are defined in the following paragraph (but over-aligned types aren't actually possible within the C11 syntax because the syntax for structure and union elements omits to include the possibility of _Alignas specifications). The meaning of "supported by the implementation in all contexts" isn't exactly clear. One might guess that it includes at least static objects, stack objects and malloc. Nothing actually seems to say what alignments are required to be supported by the implementation in all contexts. 6.2.8#4 says "Valid alignments include only those values returned by an _Alignof expression for fundamental types, plus an additional implementation-defined set of values, which may be empty.", but (a) "Valid" may not mean "supported in all contexts" and (b) as noted recently on comp.std.c, the C standard has no definition of "fundamental type", although it does define "basic type". The DFP specification, at least, defines DFP types in a way that would make them basic types (by text that would be inserted in the C standard to describe DFP), which certainly suggests that malloc should return memory suitably aligned for them. I imagine that when the IEEE 754-2008 bindings reach the point of defining _Float128, the same will apply there. I'm sure 32-bit powerpc glibc users will be glad if x86 people work out how to increase malloc alignment to 16-byte without breaking existing emacs binaries, since it's a longstanding problem <http://sourceware.org/bugzilla/show_bug.cgi?id=6527> that malloc there returns memory insufficiently aligned for long double.
