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.
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.
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.
--
John David Anglin dave.ang...@bell.net
