From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27711 invoked by alias); 7 Jun 2013 22:56:38 -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 27700 invoked by uid 89); 7 Jun 2013 22:56:37 -0000 X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 Received: from arjuna.pair.com (HELO arjuna.pair.com) (209.68.5.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with SMTP; Fri, 07 Jun 2013 22:56:36 +0000 Received: (qmail 31581 invoked by uid 3006); 7 Jun 2013 22:56:34 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Jun 2013 22:56:34 -0000 Date: Fri, 07 Jun 2013 22:56:00 -0000 From: Hans-Peter Nilsson To: Richard Henderson cc: Jakub Jelinek , Richard Biener , Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564) In-Reply-To: <51B245EF.3080602@redhat.com> Message-ID: References: <20130607192540.GH1493@tucnak.redhat.com> <51B245EF.3080602@redhat.com> User-Agent: Alpine 2.02 (BSF 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2013-06/txt/msg00437.txt.bz2 On Fri, 7 Jun 2013, Richard Henderson wrote: > I've had a brief look over the instances of D_A within the tree atm. Most of > them carry the cut-n-paste comment "for the same reasons". These I believe > never intended an ABI change, and were really only interested in optimization. > > But these I think require a good hard look to see if they really intended an > ABI alignment: I'm not sure what is about to change how? > cris compiler options for alignment -- systemwide or local? No, DATA_ALIGNMENT in cris.h is not intended as an ABI indication, but as an optimization when emitting data. (This was the way to do it at the time. Has this changed?) The ABI is as indicated by BIGGEST_ALIGNMENT: 8 (bits; one byte). Nothing is guaranteed (to the data referer) to have a bigger alignment - unless otherwise indicated by attribute-align. (Unfortunately I can't change BIGGEST_ALIGNMENT to indicate that atomic variables require "natural alignment", or actually not to straddle a cache-boundary, as increasing BIGGEST_ALIGNMENT makes GCC change the ABI. But that's a slightly different issue.) > mmix comment mentions GETA instruction Yep, data must be at least 32-bit-aligned so addresses can be formed with a GETA insn. BIGGEST_ALIGNMENT is 64 though and STRICT_ALIGNMENT; natural alignment is required for proper interpretation as the low bits are ignored. brgds, H-P