From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11905 invoked by alias); 27 Jul 2007 18:28:08 -0000 Received: (qmail 11896 invoked by uid 22791); 27 Jul 2007 18:28:07 -0000 X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jul 2007 18:28:05 +0000 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 4AA7612295; Fri, 27 Jul 2007 20:28:02 +0200 (CEST) Date: Fri, 27 Jul 2007 19:28:00 -0000 From: Richard Guenther To: Andrew Haley Cc: Paolo Bonzini , gcc-patches@gcc.gnu.org, Andreas Tobler Subject: Re: [PATCH] Fix PR32843, testsuite bug wrt sign/zero-extension of return values In-Reply-To: <18090.13124.426368.235300@zebedee.pink> Message-ID: References: <46A8AAF0.1090603@gnu.org> <18088.44823.174959.708412@zebedee.pink> <18088.45169.206955.401393@zebedee.pink> <18090.13124.426368.235300@zebedee.pink> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-07/txt/msg02005.txt.bz2 On Fri, 27 Jul 2007, Andrew Haley wrote: > Andrew Haley writes: > > OK, I've looked and every libffi target except x86 has explicit code > to do sign extend retvals. I presume that such code isn't present for > x86 because hitherto $eax has always been properly sign extended for > the return type. > > So, are we *absolutely* sure that gcc hasn't broken the ABI? I can > certainly imagine some cases where a change like this one (gcc no > longer sign extends retvals) would break code in interesting ways. Well, if every other libffi target has explicit sign extension code then the change (which is to generic code!) if it breaks the ABI shows that the x86 target machinery is lacking code to do sign extend retvals. Of course I'd like to see what other language frontends to for returning signed/unsigned quantities of QImode or HImode on x86. For example Fortran does zero extension in 4.2.1 (well, really the backend is - the frontend simply returns HImode, like mainline now does for C as well after the change): foo_: pushl %ebp movl %esp, %ebp movl 8(%ebp), %eax movzwl (%eax), %eax popl %ebp ret function foo(bar) integer*2 foo,bar foo = bar end if backends other than x86 still sign-extend for QImode returns in C the it is the x86 backend that needs to be fixed if we decide that it makes a difference that we need to care about. Richard.