[PATCH] Implement new hook for max_align_t_align

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

On 2016-10-12 12:14 PM, Jeff Law wrote:
> On 10/12/2016 02:02 AM, Jakub Jelinek 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 
>>> 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.
> If the issue is strictly limited to 32 bit hpux, then do we really 
> care?  Can we just deprecate that platform and thus make the issue go 
> away?
> It's really hard to make an argument to do anything other than 
> deprecate that platform.  Given John's ongoing involvement it's much 
> harder to deprecate 64bit linux (and consequently 64bit hpux).

I believe that deprecating the 32-bit HP-UX platform makes sense. There 
is no HP involvement in hppa,
  ia64 or alpha open source that I am aware of, so deprecating gcc 
platforms with HP systems is reasonable.

My primary focus is open source and one less platform will free some 
time. We still need 64bit hpux for
64bit linux development.


John David Anglin  dave.anglin@bell.net

More information about the Gcc-patches mailing list