From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2405 invoked by alias); 12 Oct 2016 07:52:10 -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 2394 invoked by uid 89); 12 Oct 2016 07:52:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=fairly, sk:attachm, Hx-languages-length:1557, ship X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Oct 2016 07:52:08 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 61E097F6A4; Wed, 12 Oct 2016 07:52:07 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-116-87.ams2.redhat.com [10.36.116.87]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9C7q4np000530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2016 03:52:05 -0400 Subject: Re: [PATCH] Implement new hook for max_align_t_align To: Jakub Jelinek , "Carlos O'Donell" 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> Cc: John David Anglin , Jason Merrill , Bernd Edlinger , "gcc-patches@gcc.gnu.org" , Jeff Law From: Florian Weimer Message-ID: Date: Wed, 12 Oct 2016 07:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161012072540.GJ7282@tucnak.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00813.txt.bz2 On 10/12/2016 09:25 AM, Jakub Jelinek wrote: > No, you can just drop the aligned attributes for HPUX 32-bit, basically > introduce a new ABI. If needed, you could add new symbol versions for > pthread_mutex_* etc. (though, if the current code doesn't care about the > alignment, perhaps you could get away without bumping that). This is not something which can be solved with symbol versioning. It is fairly common to embed mutexes into other objects, like this: struct client { pthread_mutex_t lock; struct client *next; size_t attachment_count; }; The layout above is fine with the alignment change, but if the programmer writes this instead: struct client { struct client *next; pthread_mutex_t lock; size_t attachment_count; }; 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. 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 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. Thanks, Florian