From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94179 invoked by alias); 16 Oct 2015 10:50:39 -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 94155 invoked by uid 89); 16 Oct 2015 10:50:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: mx07-00178001.pphosted.com Received: from Unknown (HELO mx07-00178001.pphosted.com) (62.209.51.94) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 16 Oct 2015 10:48:39 +0000 Received: from pps.filterd (m0046037.ppops.net [127.0.0.1]) by m0046037.ppops.net (8.14.5/8.14.5) with SMTP id t9GAlmYi029228; Fri, 16 Oct 2015 12:48:29 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by m0046037.ppops.net with ESMTP id 1xjj1kb6ds-1 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Oct 2015 12:48:29 +0200 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id D703243; Fri, 16 Oct 2015 10:48:05 +0000 (GMT) Received: from Webmail-eu.st.com (safex1hubcas4.st.com [10.75.90.69]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id AA5D910FA; Fri, 16 Oct 2015 10:48:27 +0000 (GMT) Received: from [164.129.122.197] (164.129.122.197) by webmail-eu.st.com (10.75.90.13) with Microsoft SMTP Server (TLS) id 8.3.389.2; Fri, 16 Oct 2015 12:48:27 +0200 Subject: Re: refactoring TARGET_PTRMEMFUNC_VBIT_LOCATION checks To: Bernd Schmidt , "law@redhat.com" References: <560A90F2.5010708@st.com> <560C31CD.7060009@redhat.com> <560CDCD7.9080108@st.com> <560D5B36.2020600@st.com> <5614C412.5080400@st.com> <5614F17B.5060402@redhat.com> <5614F7D0.8010409@st.com> <56155841.6000404@redhat.com> <56155B72.4020807@redhat.com> <56166C36.7040600@st.com> <56166DA5.3030909@redhat.com> <561674C1.8030008@st.com> <56167E09.3010502@redhat.com> <561B91DE.5040909@st.com> <561B973F.90302@redhat.com> <5620AED8.4000805@st.com> <5620C703.1000201@redhat.com> CC: "gcc-patches@gcc.gnu.org" From: Christian Bruel X-No-Archive: yes Message-ID: <5620D5FA.8010904@st.com> Date: Fri, 16 Oct 2015 10:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5620C703.1000201@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-10-16_08:2015-10-15,2015-10-16,1970-01-01 signatures=0 X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01561.txt.bz2 On 10/16/2015 11:44 AM, Bernd Schmidt wrote: > On 10/16/2015 10:01 AM, Christian Bruel wrote: >> - >> - if (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn >> - && DECL_ALIGN (fn) < 2 * BITS_PER_UNIT) >> - DECL_ALIGN (fn) = 2 * BITS_PER_UNIT; >> - >> + DECL_ALIGN (fn) = MINIMUM_METHOD_BOUNDARY; > > This looks like a change in behaviour. You want to use the max of M_M_B > and the current alignment. > > Bernd > I'm not sure. at each point of the macro, we have the current alignment == FUNCTION_BOUNDARY, because we are just returning from the sequence build_lang_decl/make_node so it looks like DECL_ALIGN (fn) = MAX (MINIMUM_METHOD_BOUNDARY, DECL_ALIGN (fn)) would be redundant with just DECL_ALIGN (fn) = MINIMUM_METHOD_BOUNDARY did I miss something ? > > Bernd >