From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108955 invoked by alias); 11 Oct 2016 20:55:09 -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 108939 invoked by uid 89); 11 Oct 2016 20:55:08 -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=pretending, aligned_alloc 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; Tue, 11 Oct 2016 20:54:58 +0000 Received: from bell.net mtlfep01 184.150.200.30 by mtlfep01.bell.net with ESMTP id <20161011205456.SDTJ31835.mtlfep01.bell.net@mtlspm01.bell.net> for ; Tue, 11 Oct 2016 16:54:56 -0400 Received: from [192.168.0.125] (really [69.156.4.4]) by mtlspm01.bell.net with ESMTP id <20161011205456.SAWZ27845.mtlspm01.bell.net@[192.168.0.125]>; Tue, 11 Oct 2016 16:54:56 -0400 Subject: Re: [PATCH] Implement new hook for max_align_t_align To: Jason Merrill , DJ Delorie References: Cc: Bernd Edlinger , gcc-patches List , Jeff Law From: John David Anglin Message-ID: Date: Tue, 11 Oct 2016 20:55: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.0A020204.57FD51A0.0095,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-SW-Source: 2016-10/txt/msg00783.txt.bz2 On 2016-10-11 4:11 PM, Jason Merrill wrote: > On Tue, Oct 11, 2016 at 2:59 PM, DJ Delorie wrote: >> Jason Merrill writes: >>> 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. >> Should such cases be calling memalign (or posix_memalign) instead of >> malloc? > We're talking about this in the context of C++17 aligned new, which > uses one of those functions (or C aligned_alloc) under the hood. > Currently on PA, allocating one of these types with 'new' in C++14 > mode gives a warning because the compiler doesn't think the allocation > will actually provide the 16-byte alignment that the type wants. This > warning seems to be correct. This patch would silence that warning by > pretending that malloc will provide 16-byte alignment, which is not > actually true. But the check isn't directly about malloc. It's between the alignment for max_align_t and the alignment that the type wants. Joseph indicated that max_align_t should have an alignment as large as the POSIX types (e.g., pthread_mutex_t). So, I think setting it to 16 when pthread_mutex_t wants an alignment of 16 is correct. -- John David Anglin dave.anglin@bell.net