On Wed, Oct 12, 2016 at 03:01:51AM -0400, Carlos O'Donell wrote: > 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 problem with cheating is that gcc will then assume the structure is properly aligned and optimize based on that (optimize away alignment checks etc.). > > > 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. No, you can just drop the aligned attributes for HPUX 32-bit, basically introduce a new ABI. If needed, you could add new symbol versions for pthread_mutex_* etc. (though, if the current code doesn't care about the alignment, perhaps you could get away without bumping that). > 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 If users use posix_memalign/memalign/aligned_alloc or the C++17 aligned new, they should be fine. Jakub