On Tue, Oct 11, 2016 at 4:54 PM, John David Anglin <dave.ang...@bell.net> wrote: > On 2016-10-11 4:11 PM, Jason Merrill wrote: >> >> On Tue, Oct 11, 2016 at 2:59 PM, DJ Delorie <d...@redhat.com> wrote: >>> >>> Jason Merrill <ja...@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. Jason
