[PATCH] Implement new hook for max_align_t_align

[Carlos O'Donell]

On 10/11/2016 04:04 PM, John David Anglin wrote:
> On 2016-10-11 2:50 PM, Jason Merrill wrote:
>> /* Alignment, in bits, a C conformant malloc implementation has to
>> provide.
>>     The HP-UX malloc implementation provides a default alignment of 8
>> bytes.
>>     This can be increased with mallopt.  The glibc implementation also
>> provides
>>     8-byte alignment.  Note that this isn't enough for various POSIX
>> types such
>>     as pthread_mutex_t.  However, since we no longer need the 16-byte
>> alignment
>>     for atomic operations, we ignore the nominal alignment specified
>> for these
>>     types.  The same is true for long double on 64-bit HP-UX.  */
>>
>> 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.
> 
> I agree the situation is something of a mess.  On linux, we could bump the alignment
> of malloc to 16-bytes.  However, Carlos argued that we don't need to and I think doing
> so would be detrimental to performance.

Correct, we do not need a 16-byte alignment at runtime.

> The 16-byte alignment was used originally because the ldcw instruction used for atomic
> operations in linux threads needs 16-byte alignment.  However, the nptl pthread
> implementation now uses a kernel helper for atomic operations.  It only needs
> 4-byte alignment.  The largest alignment actually needed is for long double (8 bytes).
> However, we can't change the 16-byte alignment without affecting the layout of various
> structures.

Correct, the structure padding needs to continue to be there to match the original ABI.

> The same is true for long double on HPUX.  Originally, it was planned to implement it
> in hardware and that would have required 16-byte alignment.  It was only implemented
> in software with an 8-byte alignment requirement.  Somehow, it ended up with 8 and
> 16-byte alignment in the HP 32 and 64-bit compilers, respectively. In both cases, malloc
> has 8-byte alignment.  It is possible to increase the "grain" size of HP malloc to 16 bytes.
> 
> Thus, I don't think the silent reduction to 8-byte alignment matters.  Without the change,
> we are faced with spurious warnings from new.

I suggested disabling the warnings.
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01445.html

Which is what Jason suggests here:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00786.html

Though Florian Weimer suggests just bumping malloc to return 16-byte aligned objects and
raising max_align_t, since conceptually that's simple (but will impact performance):
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01446.html

I think the case where a user specifically requests a larger aligment is still always
bound to fail if they exceed malloc's aligment. So removing the warning just leaves
hppa where it is today. No warning. Working with existing malloc alignment. But unable
to warn users of legitimate cases where this might matter?

I still suggest disabling the warning.

-- 
Cheers,
Carlos.