On 08/26/2016 01: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;
It should be fine, though I would like to mention a thin-ice area. Emacs
uses max_align_t to infer whether malloc returns a pointer that is a
multiple of 8, with macros like this:
// in src/lisp.h:
#define GCALIGNMENT 8
// in src/alloc.c:
#define MALLOC_IS_GC_ALIGNED (__alignof__ (max_align_t) % GCALIGNMENT
== 0)
If __alignof__ (max_align_t) is greater than malloc alignment, the
assumption behind the above code is wrong, i.e., MALLOC_IS_GC_ALIGNED
might return 1 even though the correct value is 0. As it happens, Emacs
will work on x86 since GCALIGNMENT is 8; but if GCALIGNMENT were
increased to 16 the definition of MALLOC_IS_GC_ALIGNED would become
incorrect with the proposed GCC patch.
(I think glibc malloc alignment should also increase to 16-byte on
32-bit x86 so it works for allocating objects of these types, which is
now straightforward given the fix made for 32-bit powerpc.)
Yes. I hope the above note helps explain why malloc alignment should be
at least max_align_t.
OK to commit?
For what it's worth, it looks good to me.
[in your followup email]
Well, the patch could use __SIZEOF_FLOAT128__ just as well as __i386__
(the effect would be an extra union member
s/union/struct/. Though I've always wondered why it is a struct and not
a union. Maybe change it to union while we're doing an ABI change anyway?
