[PATCH] 69759 - document __builtin_alloca and __builtin_alloca_with_align
Tue Feb 16 15:54:00 GMT 2016
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
Joseph S. Myers
More information about the Gcc-patches