[PATCH] Implement new hook for max_align_t_align

John David Anglin dave.anglin@bell.net
Wed Oct 12 14:17:00 GMT 2016

On 2016-10-12 9:48 AM, Jason Merrill wrote:
> On Wed, Oct 12, 2016 at 4:02 AM, Jakub Jelinek <jakub@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.


John David Anglin  dave.anglin@bell.net

More information about the Gcc-patches mailing list