From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47452 invoked by alias); 12 Oct 2016 14:17:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 47433 invoked by uid 89); 12 Oct 2016 14:17:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 spammy=stand, ship X-HELO: mtlfep01.bell.net Received: from belmont79srvr.owm.bell.net (HELO mtlfep01.bell.net) (184.150.200.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Oct 2016 14:17:11 +0000 Received: from bell.net mtlfep01 184.150.200.30 by mtlfep01.bell.net with ESMTP id <20161012141709.FGUE31835.mtlfep01.bell.net@mtlspm02.bell.net> for ; Wed, 12 Oct 2016 10:17:09 -0400 Received: from [192.168.0.125] (really [69.156.4.4]) by mtlspm02.bell.net with ESMTP id <20161012141709.FYTI29689.mtlspm02.bell.net@[192.168.0.125]>; Wed, 12 Oct 2016 10:17:09 -0400 Subject: Re: [PATCH] Implement new hook for max_align_t_align To: Jason Merrill , Jakub Jelinek References: <305D4697-79B3-4B69-8741-98BFC00A5ECE@bell.net> <856A3FEF-7A0D-43D4-9CBF-23939E7861C4@bell.net> <6C68EDB9-5933-4127-978E-807ABC7F31C7@bell.net> <519be582-d8e5-a6ef-f699-90a21250180b@bell.net> <88e889ee-dec9-5fef-db19-02f4d91d9156@redhat.com> <20161012072540.GJ7282@tucnak.redhat.com> <20161012080208.GK7282@tucnak.redhat.com> Cc: Florian Weimer , Carlos O'Donell , Bernd Edlinger , "gcc-patches@gcc.gnu.org" , Jeff Law From: John David Anglin Message-ID: Date: Wed, 12 Oct 2016 14:17:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Opwv-CommTouchExtSvcRefID: str=0001.0A020205.57FE45E5.013C,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-SW-Source: 2016-10/txt/msg00914.txt.bz2 On 2016-10-12 9:48 AM, Jason Merrill wrote: > On Wed, Oct 12, 2016 at 4: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 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.anglin@bell.net