From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19328 invoked by alias); 11 Feb 2003 19:18:41 -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 19310 invoked from network); 11 Feb 2003 19:18:40 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by 172.16.49.205 with SMTP; 11 Feb 2003 19:18:40 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA19908; Tue, 11 Feb 03 14:21:40 EST Date: Tue, 11 Feb 2003 19:18:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10302111921.AA19908@vlsi1.ultra.nyu.edu> To: mstump@apple.com Subject: Re: Altivec + 16 byte alignment Cc: gcc@gcc.gnu.org X-SW-Source: 2003-02/txt/msg00677.txt.bz2 I think the answer is the minimum of MAX_OFILE_ALIGNMENT, STACK_BOUNDARY and BIGGEST_ALIGNMENT, if there are no bugs. If there are bugs, you can't, not without fixing those bugs. Well, then there's another bug. Look at the usage of REGNO_POINTER_ALIGNMENT in combine.c: it assumes that the bits not in that alignment are zero. Then look at all the calls to mark_reg_pointer that just pass TYPE_ALIGN or DECL_ALIGN but nothing performs the minimum above before setting those. But I must say that Biggest alignment that any data type can require on this machine, in bits. still seems in conflict with the current implementation. If a type can *require* that alignment, doesn't that mean that we are going to *give* it that alignment? But how can we if STACK_BOUNDARY is smaller? I think this is a real mess at this point.