The attached patch defines MALLOC_ABI_ALIGNMENT so that it now reflects the
alignment
provided by malloc on hpux and linux.
I also adjusted the comment for BIGGEST_ALIGNMENT so that the define is more
understandable.
Tested on hppa2.0w-hp-hpux11.11, hppa64-hp-hpux11.11 and hppa-unknown-linux-gnu.
Committed to trunk.
Dave
--
John David Anglin dave.ang...@bell.net
2016-10-09 John David Anglin <dang...@gcc.gnu.org>
* config/pa/pa.h (BIGGEST_ALIGNMENT): Adjust comment.
(MALLOC_ABI_ALIGNMENT): Define.
Index: config/pa/pa.h
===================================================================
--- config/pa/pa.h (revision 240688)
+++ config/pa/pa.h (working copy)
@@ -292,9 +292,21 @@
/* A bit-field declared as `int' forces `int' alignment for the struct. */
#define PCC_BITFIELD_TYPE_MATTERS 1
-/* No data type wants to be aligned rounder than this. */
+/* No data type wants to be aligned rounder than this. The long double
+ type has 16-byte alignment on the 64-bit target even though it was never
+ implemented in hardware. The software implementation only needs 8-byte
+ alignment. This is to match the HP compilers. */
#define BIGGEST_ALIGNMENT (2 * BITS_PER_WORD)
+/* 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. */
+#define MALLOC_ABI_ALIGNMENT (64)
+
/* Get around hp-ux assembler bug, and make strcpy of constants fast. */
#define CONSTANT_ALIGNMENT(EXP, ALIGN) \
(TREE_CODE (EXP) == STRING_CST \
