From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99544 invoked by alias); 4 Jan 2017 10:53:49 -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 99487 invoked by uid 89); 4 Jan 2017 10:53:48 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=krebbel, Krebbel, krebbel@linux.vnet.ibm.com, U*krebbel X-HELO: mail-ua0-f178.google.com Received: from mail-ua0-f178.google.com (HELO mail-ua0-f178.google.com) (209.85.217.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Jan 2017 10:53:47 +0000 Received: by mail-ua0-f178.google.com with SMTP id 88so341300450uaq.3 for ; Wed, 04 Jan 2017 02:53:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ELcgq1BljqpC6AyFkAoiheg9qhx3KVnhfMeQiKup5Oc=; b=HpnuA6PJaIUNrJO20Pf8OYTwctYXcbPdb/WC3m0+Nz97Kq+XafVWS288+1GDzKv9db k1igmTc9TTbAfv32JOqN6Vvn1INx7zSbWtEcztGzKncrIyGcuY0/hiwpAZ0PQERnci5G 6voEJzGSLnwoOu6PWWBKR1lrGJJbTk0l0KvB7RyxcIGRChBZC8we7pAq2KWGIyFsEnZf tt+fET2LRgyQMEg7drBlOLxoHIOS/NhMm03eUIuNFfJBWYFHbZmSbjrwVZWCRyvRIupV PT/njRO4uM37EEUlJknboylKTEbmhw08wHI58mkFwlMHW0EMwLnALLeZ5NrJdCs8rUEX fb9Q== X-Gm-Message-State: AIkVDXJerAMm8wKgkcRYndqF4Bsd2MdAz6SFyiB5gS++ljpD4V308QHPJQbusdFQdqnlD110Ff/VBYDk66Gg4A== X-Received: by 10.176.86.28 with SMTP id y28mr39784027uaa.88.1483527225215; Wed, 04 Jan 2017 02:53:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.72.8 with HTTP; Wed, 4 Jan 2017 02:53:44 -0800 (PST) In-Reply-To: <461fe6c7-9d40-feec-fb7b-d7a52e739c3f@linux.vnet.ibm.com> References: <20161216202922.14425-1-krebbel@linux.vnet.ibm.com> <461fe6c7-9d40-feec-fb7b-d7a52e739c3f@linux.vnet.ibm.com> From: Richard Biener Date: Wed, 04 Jan 2017 10:53:00 -0000 Message-ID: Subject: Re: [PATCH] varasm: Propagate litpool decl alignment to generated RTX. To: Andreas Krebbel Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00174.txt.bz2 On Thu, Dec 22, 2016 at 1:58 PM, Andreas Krebbel wrote: > On 12/20/2016 11:38 AM, Richard Biener wrote: >> On Fri, Dec 16, 2016 at 9:29 PM, Andreas Krebbel >> wrote: >>> When pushing a value into the literal pool the resulting decl might >>> get a higher alignment than the original expression depending on how a >>> target defines CONSTANT_ALIGNMENT. Generating an RTX for the constant >>> pool access we currently use the alignment from the original >>> expression. Changed with the attached patch. >> >> And it might be even smaller alignment... or do we not allow that? > I did assume that this is not supposed to happen. Adding an assertion triggering in that case > survived bootstrap and testsuite. s390x only. It basically boils down to whether align_variable and > set_mem_attributes/get_object_alignment come to different conclusions about the alignment starting > at either the var decl or the original expression. > > ... >>> Bootstrapped and regtested on x86_64 and s390x. >>> >>> No regressions. >>> >>> Ok? >> >> Ok. >> >> Richard. > > Ok for GCC 6 branch as well? Yes. Richard. > -Andreas- > >