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
