On 10/12/2016 10:17 AM, John David Anglin wrote:
> 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.

I am against breaking the ABI.

I would rather see us bump malloc alignment up to 16-bytes.

The last time I changed this alignment it _immediately_ broken libstdc++ 
because it's using exactly the kind of embedded pthread_mutext_t we're talking 

So in that case the debian builds in unstable broke right away, and I had to 
the change. We'd have to BinNMU a bunch of things to get this working again.

Again I think our two options are, in my order of preference:

- Disable the warning via a PA backend change.
- Bump malloc alignment.

I am sensitive to the first change being something that carries with it extra
maintenance burden, so I'm happy to see the second solution chosen if that's 
everyone wants (Florian's suggestion).


Reply via email to