From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22405 invoked by alias); 5 Dec 2002 02:14:07 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 22398 invoked from network); 5 Dec 2002 02:14:06 -0000 Received: from unknown (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sources.redhat.com with SMTP; 5 Dec 2002 02:14:06 -0000 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 gB52E4ot001401; Wed, 4 Dec 2002 21:14:05 -0500 (EST) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) id gB52E3LH001400; Wed, 4 Dec 2002 21:14:03 -0500 (EST) Message-Id: <200212050214.gB52E3LH001400@hiauly1.hia.nrc.ca> Subject: Re: HP-UX PA long double alignment change To: dave@hiauly1.hia.nrc.ca (John David Anglin) Date: Wed, 04 Dec 2002 18:14:00 -0000 From: "John David Anglin" Cc: rth@redhat.com, sje@cup.hp.com, gcc-patches@gcc.gnu.org In-Reply-To: from "John David Anglin" at Dec 4, 2002 06:40:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00308.txt.bz2 > So if I understand correctly, you are suggesting that we drop > BIGGEST_ALIGNMENT back to 64 and increase STACK_BOUNDARY to 128. > I think then the STARTING_FRAME_OFFSET would have to increase > to 16. Otherwise, we never have a zero frame size. This will > add two more unused slots in the stack frame which I don't much > like. In the discussion that led to the original change, Richard wrote: > On Fri, Jan 18, 2002 at 06:35:40PM -0800, Aldy Hernandez wrote: > > this patch introduces a new macro STARTING_FRAME_PHASE (documented). > > There is no need for a new macro. The frame pointer _must_ be > aligned, as we assert here: > > emit-rtl.c:4719: REGNO_POINTER_ALIGN (FRAME_POINTER_REGNUM) = STACK_BOUNDARY; > > therefore it must always be the case that > > sb = STACK_BOUNDARY / BITS_PER_UNIT; > off = STARTING_FRAME_OFFSET % sb; > > STARTING_FRAME_PHASE == (off ? sb - off : 0) In diagnosing why we never had a zero frame size on hppa64, I found that when STARTING_FRAME_PHASE % sb is non zero you can never get a frame size of zero. This seems like a bug as it wastes stack space if you increase STARTING_FRAME_OFFSET so that off==0. dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605)