Re: Make max_align_t respect _Float128

[Paul Eggert <eggert at cs dot ucla dot edu>]

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?