[PATCH] 69759 - document __builtin_alloca and __builtin_alloca_with_align

Martin Sebor msebor@gmail.com
Tue Feb 16 16:45:00 GMT 2016


On 02/16/2016 08:54 AM, Joseph Myers wrote:
> 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.

The DR #445 resolution goes against the intent of the type.  It's
also incompatible with C++.  Unless there's a C++ defect to change
it there too (I haven't found it), the C DR should be revisited to
make sure the languages remain compatible in this area.

> 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.

Malloc is not (need not be) subject to the (original, pre-DR 445)
max_align_t alignment.  What to define max_align_to when there
effectively is maximum alignment is a separate question.

But this discussion is tangential to the proposed documentation
update.  After thinking about the context some more I've decided
that since code that uses __builtin_alloca or even alloca isn't
portable to begin with, mentioning max_align_t won't help it
become any more portable.

Attached is an updated patch with the mention of max_align_t
removed.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-69759.patch
Type: text/x-patch
Size: 4917 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20160216/c9a12a5a/attachment.bin>


More information about the Gcc-patches mailing list