This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Make max_align_t respect _Float128


On 08/26/2016 10:54 PM, Joseph Myers wrote:
Such an increase is of course an ABI change, but a reasonably safe
one, in that max_align_t doesn't tend to appear in library interfaces
(rather, it's something to use when writing allocators and similar
code; most matches found on codesearch.debian.net look like copies of
the gnulib stddef.h module rather than anything actually using
max_align_t at all).

The crucial question is whether GCC will start assuming that pointers returned by malloc (or attribute-malloc functions) have such an alignment. That seems impossible.

I'm pretty sure it does not right now because few mallocs have this property (jemalloc, tcmalloc, and until recently glibc's malloc on 32-bit powerpc and MIPS failed this requirement). They only provide 8-byte alignment even though the fundamental alignment is 16. For the dl-minimal malloc in glibc, the glibc consensus was to ignore max_align_t and go with the regular malloc alignment.

Depending on what your malloc looks like, it can be very tempting *not* to provide 16-byte alignment for pointers returned from malloc (8) or strdup ("abc"), and practical evidence, gained with non-glibc malloc on x86_64 (where the fundamental alignment is 16), suggests that this is currently feasible.

In the end, max_align_t is ignored by allocators, and applications cannot rely on it as a result.

Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]