[PATCH] Implement new hook for max_align_t_align

Jason Merrill jason@redhat.com
Tue Oct 11 21:27:00 GMT 2016

On Tue, Oct 11, 2016 at 4:54 PM, John David Anglin <dave.anglin@bell.net> wrote:
> On 2016-10-11 4:11 PM, Jason Merrill wrote:
>> On Tue, Oct 11, 2016 at 2:59 PM, DJ Delorie <dj@redhat.com> wrote:
>>> Jason Merrill <jason@redhat.com> writes:
>>>> If PA malloc doesn't actually provide 16-byte alignment, this change
>>>> seems problematic; it will mean any type that wants 16-byte alignment
>>>> will silently get 8-byte alignment instead.
>>> Should such cases be calling memalign (or posix_memalign) instead of
>>> malloc?
>> We're talking about this in the context of C++17 aligned new, which
>> uses one of those functions (or C aligned_alloc) under the hood.
>> Currently on PA, allocating one of these types with 'new' in C++14
>> mode gives a warning because the compiler doesn't think the allocation
>> will actually provide the 16-byte alignment that the type wants.  This
>> warning seems to be correct.  This patch would silence that warning by
>> pretending that malloc will provide 16-byte alignment, which is not
>> actually true.
> But the check isn't directly about malloc.  It's between the alignment for
> max_align_t and the alignment that the type wants.  Joseph indicated that max_align_t
> should have an alignment as large as the POSIX types (e.g., pthread_mutex_t).  So, I think
> setting it to 16 when pthread_mutex_t wants an alignment of 16 is correct.

The connection to max_align_t is just a GCC implementation detail; the
C++ standard doesn't tie use of aligned new to alignof(max_align_t),
there's a separate macro __STDCPP_DEFAULT_NEW_ALIGNMENT__.  This was
done specifically to allow for the case where malloc for a target
provides more alignment than max_align_t.

But that still doesn't help with this case, where in fact the warning
is correct, you just know it isn't a problem.  So disabling the
warning on PA seems like the way to go.


More information about the Gcc-patches mailing list