On 2016-10-12 9:48 AM, Jason Merrill wrote:
On Wed, Oct 12, 2016 at 4:02 AM, Jakub Jelinek <ja...@redhat.com> wrote:
On Wed, Oct 12, 2016 at 09:52:04AM +0200, Florian Weimer wrote:
dropping the alignment means that the padding before the lock member
vanishes. Consequently, we have just created a silent ABI change in
application code, which is a big no-no.
Sure, it would be an ABI change, but how many users would it affect?
Since this is PA-RISC, which is essentially dead (neither HPE nor Debian
ship it anymore), I stand by my suggestion to bump the fundamental alignment
Or just drop support for a dead arch?
instead. Sure, it is a bit inefficient, but this will only affect PA-RISC
users. It does not even cause work for PA-RISC porters. Conversely, if we
work on this to come up with a different fix, many more people will be
affected (because they don't get all the nice things we could work on
instead), and we may need to maintain a special GCC kludge for the
alternative solution, impacting GCC developers in particular.
But sure, bumping malloc alignment is probably easiest. And people who want
performance have better options than to stay on 32-bit PA-RISC anyway.
Or we could do nothing and tell people to ignore the harmless warning.
The warning is an issue because of -Werror. However, it appears easy to
suppress it in the PA
backend. I have a patch that I'm testing.
We are discussing offline regarding the glibc issue. It easy to bump
the alignment of malloc
but I take Jakub's point and maybe we should break the ABI. Debian
unstable churns
quickly, and I think we would be better off being consistent with the
current max_align_t
and 8-byte aligned malloc.
Dave
--
John David Anglin dave.ang...@bell.net
