From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25401 invoked by alias); 12 Feb 2003 16:21:59 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 25394 invoked from network); 12 Feb 2003 16:21:58 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by 172.16.49.205 with SMTP; 12 Feb 2003 16:21:58 -0000 Received: from hiauly1.hia.nrc.ca ([132.246.100.193]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18izcM-0005PL-00 for gcc@gcc.gnu.org; Wed, 12 Feb 2003 11:20:14 -0500 Received: from hiauly1.hia.nrc.ca (localhost [127.0.0.1]) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id h1CGIoot004890; Wed, 12 Feb 2003 11:18:51 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) id h1CGInoH004889; Wed, 12 Feb 2003 11:18:49 -0500 (EST) Message-Id: <200302121618.h1CGInoH004889@hiauly1.hia.nrc.ca> Subject: Re: Altivec + 16 byte alignment To: fjh@cs.mu.oz.au (Fergus Henderson) Date: Wed, 12 Feb 2003 16:39:00 -0000 From: "John David Anglin" Cc: mstump@apple.com, gcc@gcc.gnu.org, gianni@scaramanga.co.uk, kenner@vlsi1.ultra.nyu.edu In-Reply-To: <20030212165348.A14176@hg.cs.mu.OZ.AU> from "Fergus Henderson" at Feb 12, 2003 04:53:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00813.txt.bz2 > Please let us agree that this is just a bug, regardless of the CPU's > requirements. The alignment declaration might be used by the programmer > to ensure that the lower bits are available for use as tag bits. > > For example, the following program should result in either success > or a compile error (if the requested alignment is not supported). > But IMHO it should not result in an assertion failure. > > #include > #define ALIGN 32 > int main() { > char c __attribute__((aligned(ALIGN))); > assert ((((unsigned long) &c) & (ALIGN - 1)) == 0); > return 0; > } You have my vote on the matter. If we go back to Franz's original reply to my post regarding the rs6000 port, he said "BIGGEST_ALIGNMENT is 128, but STACK_BOUNDARY is 64 unless you give -mabi=altivec (in 3.2+)." If you look at assign_stack_temp_for_type and assign_stack_local_1, you will see that BLKmode objects are aligned to BIGGEST_ALIGNMENT. Thus, without -mabi=altivec, you would randomly get an assertion failure, depending on the stack alignment, if you checked the alignment of structs with code similar to that above. In other words, you aren't getting the alignment of BLKmode stack locals that you have specified in the backend. Possibly, this doesn't matter, but it seems inconsistent and I think would lead to problems if the compiler checked alignment requests as suggested above. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605)