This is the mail archive of the
mailing list for the GCC project.
Re: Make max_align_t respect _Float128
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, gcc-patches at gcc dot gnu dot org
- Cc: eggert at cs dot ucla dot edu
- Date: Fri, 26 Aug 2016 23:45:35 +0200
- Subject: Re: Make max_align_t respect _Float128
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.firstname.lastname@example.org>
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
In the end, max_align_t is ignored by allocators, and applications
cannot rely on it as a result.