On 2016-04-24, at 11:17 PM, NIIBE Yutaka wrote: > On 04/25/2016 04:48 AM, John David Anglin wrote: >> On 2016-04-24, at 12:57 PM, John David Anglin wrote: >> >>> It looks like this was introduced by the following change: >>> >>> diff --git >>> a/debian/patches/0006-fix-Solaris-and-HPPA-this-is-a-collection-of-upstrea.patch >>> >>> b/debian/patches/0006-fix-Solaris-and-HPPA-this-is-a-collection-of-upstrea.patch >>> new file mode 100644 >>> index 0000000..54ae9a1 >>> --- /dev/null >>> +++ >>> b/debian/patches/0006-fix-Solaris-and-HPPA-this-is-a-collection-of-upstrea.patch >> >> Reverting this change fixes bug. My sense is the alignment of the lock >> object cannot be reduced from >> 16 to 8 bytes without breaking packages. > > My fix for 757060 was wrong. > > I considered that the object size were 8-byte, but it is *16*-byte. > My intention was incorporating the patch for HPPA, but I did it > wrongly. I wanted to remove the GCC feature for alignment. Are there > any C object of quadword (128-bit) for HPPA arch?
Long double has 16-byte alignment on hppa-hpux but 8-byte alignment on other hppa targets. At one time, HP thought they would add quadword long double hardware support in hardware but it never happened. There are no other C objects with 16-byte alignment on hppa, so one is stuck using the gcc attribute on non hpux hppa targets. On hppa-linux, I believe it would be possible to now use the default size for this object. I think the 16-byte alignment stems from the original pthread implementation that used a 16-byte lock. However, it didn't need 16-byte alignment. The ldcw instruction requires 16-byte alignment in PA 1.X. This is the only operation on hppa that needs 16-byte alignment. The lock was changed to int with nptl. However, it looks like a new library version would be needed to make this change so existing code doesn't break. The atomic support in glibc and gcc for linux now use a kernel helper to avoid the deadlock problems that can occur in userspace. Dave -- John David Anglin dave.ang...@bell.net
