From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92118 invoked by alias); 12 Oct 2016 13:48:33 -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 91999 invoked by uid 89); 12 Oct 2016 13:48:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=H*RU:209.85.218.45, Hx-spam-relays-external:209.85.218.45, stand, ship X-HELO: mail-oi0-f45.google.com Received: from mail-oi0-f45.google.com (HELO mail-oi0-f45.google.com) (209.85.218.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Oct 2016 13:48:31 +0000 Received: by mail-oi0-f45.google.com with SMTP id t73so61229448oie.1 for ; Wed, 12 Oct 2016 06:48:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=skaRMJy4MEmcVCtKjDVFM3qdoZaWvWw6IHdq1UEOE2Q=; b=liN3zOUxGwO8Fl4NYz13HB0gHb5mqrSvfXEMhHGT5pWsJURa5tTeOl7FPzPVEfVjlp Sa72niJ69em6hxoypLxdXol+9mvt4gMSpbIsL8usHG8BNCjP/5vgaQN8O8NIwZuYT4HR jHSwyzAnSN4N8Njuzg5N/7NPr2diLCIxFcce+TLG0C/ChPvzvqsBHfkqOciwC1OjLWcX 10PlVOQBddDDS+33f+lQ31C4IOTqX45/Xb+4OAdWtemRHhOv/ZMw437HFYDbAx/sVdn1 4zvHCJYCWwA/F9qFHX6aInCNOQq6ol4exXNRNKtcAoAT/ZQ1qanBtI3prGe78qRQW1vF PrdQ== X-Gm-Message-State: AA6/9RmrsRu6tYK1ROUvKElQKsa5/+yPbtvLDqRPy/g8wbCu2wzfkldXfIJfb6rXKNy28Q0ySjjGuvRP8Gtzi9u4 X-Received: by 10.202.192.5 with SMTP id q5mr763906oif.71.1476280109545; Wed, 12 Oct 2016 06:48:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.87.231 with HTTP; Wed, 12 Oct 2016 06:48:08 -0700 (PDT) In-Reply-To: <20161012080208.GK7282@tucnak.redhat.com> 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> From: Jason Merrill Date: Wed, 12 Oct 2016 13:48:00 -0000 Message-ID: Subject: Re: [PATCH] Implement new hook for max_align_t_align To: Jakub Jelinek Cc: Florian Weimer , "Carlos O'Donell" , John David Anglin , Bernd Edlinger , "gcc-patches@gcc.gnu.org" , Jeff Law Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00898.txt.bz2 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. Jason