This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] 69759 - document __builtin_alloca and __builtin_alloca_with_align
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Martin Sebor <msebor at gmail dot com>
- Cc: Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 16 Feb 2016 17:16:56 +0000
- Subject: Re: [PATCH] 69759 - document __builtin_alloca and __builtin_alloca_with_align
- Authentication-results: sourceware.org; auth=none
- References: <56BF8976 dot 3080907 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1602152315580 dot 14423 at digraph dot polyomino dot org dot uk> <56C2951E dot 1040304 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1602161339100 dot 26462 at digraph dot polyomino dot org dot uk> <56C3439F dot 8010401 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1602161546280 dot 5386 at digraph dot polyomino dot org dot uk> <56C35216 dot 8030007 at gmail dot com>
On Tue, 16 Feb 2016, Martin Sebor wrote:
> 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
I see no reason to suppose that, given the extensive discussion of the
issues in WG14.
max_align_t is of use as-is in writing allocators and allocator-like code
(cf how glibc uses it). Something that represents the possibility of
aligning things to anything up to the entire address space would not be
useful.
> also incompatible with C++. Unless there's a C++ defect to change
Presumably the C++ liaison people considered compatibility as part of the
WG14 discussions. In any case, I see no sign that (beyond the
"fundamental type" terminology issue) the wording in C++ is any better
thought out than the pre-DR#445 C wording.
> > 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
C90 and C99 compatibility requires malloc to return memory suitably
aligned for all types definable within C90 and C99, and it would be very
confusing to say in C11 that certain header typedefs are within such a
rule but others (such as max_align_t) aren't because they are new in C11
(a rule saying that all standard header types can be stored in memory
returned by malloc is much better for the C11 user).
--
Joseph S. Myers
joseph@codesourcery.com