[PATCH] 69759 - document __builtin_alloca and __builtin_alloca_with_align

[Joseph Myers]

On Tue, 16 Feb 2016, Martin Sebor wrote:

> Max_align_t need not impact efficiency.  In C, the malloc alignment
> also need not have an impact on the type since aligned_alloc returns
> storage that is (or can be) more strictly aligned.

As per the DR#445 resolution, malloc must return memory "whose alignment 
is the greatest fundamental alignment".  It's obviously necessary for 
malloc to return memory sufficiently aligned for any object that can be 
declared within the standard without using over-aligned types.

As per DR#075, this applies even to malloc (1).  If max_align_t is 
64-byte-aligned, malloc (1) must return 64-byte-aligned memory.

As a practical matter of ABI compatibility, standard typedefs such as 
max_align_t should not depend on options for e.g. vector ISA extensions 
that might affect what alignments are useful (and if a change is needed, 
it should be a one-off change, only increasing the alignment and not 
depending on such ISA options).  They should also avoid depending on 
details of implementation limits (e.g. if GCC supports 2^63 byte alignment 
for ELF in future, that shouldn't need to change max_align_t).

> the other storage durations.  So for example on a C implementation
> like Linux with GLIBC, while conforming, to define max_align_t to
> _Alignof(long double) is redunant and less than useful.  Programs
> can trivially query the alignment of basic types.  What they cannot
> do (but may need to do) is query the greatest supported alignment in
> all contexts/storage durations.

If you disregard malloc, that is effectively unbounded (2^28 bytes at 
least), with current GCC on ELF targets.  This is not a useful thing to 
query, and not useful for malloc to be required to return memory aligned 
to.

-- 
Joseph S. Myers
joseph@codesourcery.com