From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59006 invoked by alias); 8 Oct 2015 13:51:23 -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 58990 invoked by uid 89); 8 Oct 2015 13:51:22 -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; Thu, 08 Oct 2015 13:51:21 +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 t98DmFuN008774; Thu, 8 Oct 2015 15:51:01 +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 1xd3105ugt-1 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 08 Oct 2015 15:51:01 +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 0030F34; Thu, 8 Oct 2015 13:50:38 +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 819EA5779; Thu, 8 Oct 2015 13:50:58 +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; Thu, 8 Oct 2015 15:50:58 +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> <5614F7D0.8010409@st.com> <56155841.6000404@redhat.com> <56155B72.4020807@redhat.com> <56166C36.7040600@st.com> <56166DA5.3030909@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: <561674C1.8030008@st.com> Date: Thu, 08 Oct 2015 13:51: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: <56166DA5.3030909@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-08_11:2015-10-08,2015-10-08,1970-01-01 signatures=0 X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00836.txt.bz2 On 10/08/2015 03:20 PM, Bernd Schmidt wrote: > On 10/08/2015 03:14 PM, Christian Bruel wrote: > >> Probably at the time of start_decl, because DECL_ALIGN will have the >> boundary given by the global target_flags at that time. But this >> shouldn't be a problem since what matters is the DECL_ALIGN recomputed >> with the definition when there is something to layout. > > I'm not so sure. Don't we take DECL_ALIGN into account when optimizing > things like alignment tests? > > Humm, I don't know what kind of alignment optimization for functions we have based on a declaration only. greping DECL_ALIGN on functions there are some bits in the ipa-icf code that seems to merge code using this information, but I think we have a definition at that point. but honestly, I'm very unfamiliar with this pass. Do you have something else in mind ? > Bernd >