From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14361 invoked by alias); 11 Oct 2016 20:04:24 -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 14338 invoked by uid 89); 11 Oct 2016 20:04:24 -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=affecting, nominal X-HELO: torfep01.bell.net Received: from simcoe207srvr.owm.bell.net (HELO torfep01.bell.net) (184.150.200.207) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Oct 2016 20:04:14 +0000 Received: from bell.net torfep01 184.150.200.158 by torfep01.bell.net with ESMTP id <20161011200411.MDGW28435.torfep01.bell.net@torspm01.bell.net> for ; Tue, 11 Oct 2016 16:04:11 -0400 Received: from [192.168.0.125] (really [69.156.4.4]) by torspm01.bell.net with ESMTP id <20161011200411.EJCS1164.torspm01.bell.net@[192.168.0.125]>; Tue, 11 Oct 2016 16:04:11 -0400 Subject: Re: [PATCH] Implement new hook for max_align_t_align To: Jason Merrill References: <305D4697-79B3-4B69-8741-98BFC00A5ECE@bell.net> <856A3FEF-7A0D-43D4-9CBF-23939E7861C4@bell.net> <6C68EDB9-5933-4127-978E-807ABC7F31C7@bell.net> Cc: Bernd Edlinger , "gcc-patches@gcc.gnu.org" , Jeff Law , Carlos O'Donell From: John David Anglin Message-ID: <519be582-d8e5-a6ef-f699-90a21250180b@bell.net> Date: Tue, 11 Oct 2016 20:04: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.0A020202.57FD45BB.0099,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-SW-Source: 2016-10/txt/msg00776.txt.bz2 On 2016-10-11 2:50 PM, Jason Merrill wrote: > /* Alignment, in bits, a C conformant malloc implementation has to > provide. > The HP-UX malloc implementation provides a default alignment of 8 > bytes. > This can be increased with mallopt. The glibc implementation also > provides > 8-byte alignment. Note that this isn't enough for various POSIX > types such > as pthread_mutex_t. However, since we no longer need the 16-byte > alignment > for atomic operations, we ignore the nominal alignment specified > for these > types. The same is true for long double on 64-bit HP-UX. */ > > If PA malloc doesn't actually provide 16-byte alignment, this change > seems problematic; it will mean any type that wants 16-byte alignment > will silently get 8-byte alignment instead. I agree the situation is something of a mess. On linux, we could bump the alignment of malloc to 16-bytes. However, Carlos argued that we don't need to and I think doing so would be detrimental to performance. The 16-byte alignment was used originally because the ldcw instruction used for atomic operations in linux threads needs 16-byte alignment. However, the nptl pthread implementation now uses a kernel helper for atomic operations. It only needs 4-byte alignment. The largest alignment actually needed is for long double (8 bytes). However, we can't change the 16-byte alignment without affecting the layout of various structures. The same is true for long double on HPUX. Originally, it was planned to implement it in hardware and that would have required 16-byte alignment. It was only implemented in software with an 8-byte alignment requirement. Somehow, it ended up with 8 and 16-byte alignment in the HP 32 and 64-bit compilers, respectively. In both cases, malloc has 8-byte alignment. It is possible to increase the "grain" size of HP malloc to 16 bytes. Thus, I don't think the silent reduction to 8-byte alignment matters. Without the change, we are faced with spurious warnings from new. -- John David Anglin dave.anglin@bell.net