From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99449 invoked by alias); 7 Oct 2015 10:45:51 -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 99438 invoked by uid 89); 7 Oct 2015 10:45:50 -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,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mx07-00178001.pphosted.com Received: from mx08-00178001.pphosted.com (HELO mx07-00178001.pphosted.com) (91.207.212.93) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 07 Oct 2015 10:45:44 +0000 Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx08-00178001.pphosted.com (8.14.5/8.14.5) with SMTP id t97Aj2sc015199; Wed, 7 Oct 2015 12:45:39 +0200 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx08-00178001.pphosted.com with ESMTP id 1xca19dm7x-1 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 07 Oct 2015 12:45:39 +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 99C9031; Wed, 7 Oct 2015 10:45:17 +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 866D827F4; Wed, 7 Oct 2015 10:45:37 +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; Wed, 7 Oct 2015 12:45:37 +0200 Subject: Re: [PATCH ARM]: PR67745: Fix function alignment after __attribute__ 2/2 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> CC: "gcc-patches@gcc.gnu.org" , "Ramana.Radhakrishnan@arm.com" , "kyrylo.tkachov@arm.com" , "richard.earnshaw@arm.com" From: Christian Bruel X-No-Archive: yes Message-ID: <5614F7D0.8010409@st.com> Date: Wed, 07 Oct 2015 10:45: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: <5614F17B.5060402@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-07_04:2015-10-06,2015-10-07,1970-01-01 signatures=0 X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00696.txt.bz2 On 10/07/2015 12:18 PM, Bernd Schmidt wrote: > On 10/07/2015 09:04 AM, Christian Bruel wrote: >> + /* Similarly, relayout function's alignment if not forced. */ >> + if (!DECL_USER_ALIGN (fndecl) >> + && (TREE_CODE (fntype) != METHOD_TYPE >> + || TARGET_PTRMEMFUNC_VBIT_LOCATION != ptrmemfunc_vbit_in_pfn)) >> + DECL_ALIGN (fndecl) = FUNCTION_BOUNDARY; >> } > > That's a very odd-looking condition. Why the vbit location test? This is for member functions to make sure that the lsb address is reserved for the virtual function bit. see cp/decl.c: /* If pointers to member functions use the least significant bit to indicate whether a function is virtual, ensure a pointer to this function will have that bit clear. */ if (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn && TREE_CODE (type) == METHOD_TYPE && DECL_ALIGN (decl) < 2 * BITS_PER_UNIT) DECL_ALIGN (decl) = 2 * BITS_PER_UNIT; This happens for instance on i386 that aligns member functions on 2 bytes, bigger than the one byte required boundary. So we cannot re-layout bellow that.