From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-73873-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 28950 invoked by alias); 11 May 2003 14:49:23 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 28943 invoked from network); 11 May 2003 14:49:22 -0000
Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213)
  by sources.redhat.com with SMTP; 11 May 2003 14:49:22 -0000
Received: by vlsi1.ultra.nyu.edu (4.1/1.34)
	id AA27189; Sun, 11 May 03 10:54:05 EDT
Date: Sun, 11 May 2003 14:49:00 -0000
From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
Message-Id: <10305111454.AA27189@vlsi1.ultra.nyu.edu>
To: dj@redhat.com
Subject: Re: alignment: store_one_arg vs emit_push_insn
Cc: gcc@gcc.gnu.org
X-SW-Source: 2003-05/txt/msg01045.txt.bz2

    > I don't follow.  emit_push_insn barely uses it *at all*.

    But the one place it *does* use it is here:

    	  move_by_pieces (NULL, xinner, INTVAL (size) - used, align);
    
    In the failing case, align is 16 and xinner is 8-bit aligned.

I thought you were talking about it using PARM_BOUNDARY.

In this case the bug seems to be that xinner isn't properly aligned.