From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4781 invoked by alias); 9 Jul 2004 19:31:42 -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 4772 invoked from network); 9 Jul 2004 19:31:42 -0000 Received: from unknown (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sourceware.org with SMTP; 9 Jul 2004 19:31:42 -0000 Received: from hiauly1.hia.nrc.ca (hiauly1.hia.nrc.ca [127.0.0.1] (may be forged)) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9) with ESMTP id i69JVeCp023892; Fri, 9 Jul 2004 15:31:41 -0400 (EDT) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.9-20030917/8.12.9/Submit) id i69JVeaY023890; Fri, 9 Jul 2004 15:31:40 -0400 (EDT) Message-Id: <200407091931.i69JVeaY023890@hiauly1.hia.nrc.ca> Subject: Re: [RFT/RFA] gimplify pa va_arg To: gcc-patches@gcc.gnu.org Date: Fri, 09 Jul 2004 20:48:00 -0000 From: "John David Anglin" Cc: paolo.bonzini@polimi.it, rth@redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00995.txt.bz2 > Paolo Bonzini wrote: > > And here is the second. This gives several differences for both PA and > PA64 in the struct case. For PA64, it looks like awful optimization on > part of the current mainline GCC (but HPPA assembly is not my forte). > For PA, the only important change is that the frame grows from 64 to > 128 bytes, but again I cannot figure it out. --------------------- __builtin_va_list list; int f1(void) { return __builtin_va_arg(list, int); } long long f2(void) { return __builtin_va_arg(list, long long); } double f3(void) { return __builtin_va_arg(list, double); } struct S { int x[100]; }; struct S f4(void) { return __builtin_va_arg(list, struct S); } --------------------- The code generated for f4 is wrong. Garbage is used for the first argument in the call to memcpy/memmove (%r26). The same garbage is used for the return in %r28. This doesn't seem to be a result of gimplification. There seems to be some kind of assumption that there is an incoming value in %r28: ;; Function f4 (note 2 0 3 NOTE_INSN_DELETED) (insn 3 2 4 (nil) (set (reg/f:SI 94) (reg:SI 28 %r28)) -1 (nil) (nil)) Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)