From owner-freebsd-sparc64@FreeBSD.ORG Wed May 7 15:34:17 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E8AA37B401 for ; Wed, 7 May 2003 15:34:17 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 4FC5443FAF for ; Wed, 7 May 2003 15:34:15 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 9135 invoked by uid 65534); 7 May 2003 22:34:14 -0000 Received: from p508E6C74.dip.t-dialin.net (EHLO galatea.local) (80.142.108.116) by mail.gmx.net (mp007-rz3) with SMTP; 08 May 2003 00:34:14 +0200 Received: from tmm by galatea.local with local (Exim 4.14 #1) id 19DXXQ-0000hm-Jv; Thu, 08 May 2003 00:37:24 +0200 Date: Thu, 8 May 2003 00:37:24 +0200 From: Thomas Moestl To: Kris Kennaway , Eric Anholt , sparc64@FreeBSD.ORG Message-ID: <20030507223724.GA2606@crow.dom2ip.de> Mail-Followup-To: Kris Kennaway , Eric Anholt , sparc64@FreeBSD.ORG References: <20030116072448.GA29468@rot13.obsecurity.org> <20030116201728.GA279@crow.dom2ip.de> <20030408003332.GA60864@rot13.obsecurity.org> <20030507221133.GA678@crow.dom2ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030507221133.GA678@crow.dom2ip.de> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl Subject: Re: assembler error in XFree86 snapshot X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2003 22:34:17 -0000 On Thu, 2003/05/08 at 00:11:34 +0200, Thomas Moestl wrote: > On Mon, 2003/04/07 at 17:33:32 -0700, Kris Kennaway wrote: > > On Thu, Jan 16, 2003 at 09:17:28PM +0100, Thomas Moestl wrote: > > > This is a arguably a gcc bug. All (13-bit) immediate operands are > > > sign-extended, even those to instructions which operate on unsigned > > > values, so umul can handle a range of very small and a range of very > > > large operands. gcc correctly recognizes that it can use an immediate > > > here; however, it chooses to output it as an unsigned number and does > > > not sign-extended it from 32 to 64 bit. > > > > > > All sign extensions for instructions are made to the full 64 bit > > > however (even if umul only happens to use 32 of those), so when the > > > assembler checks whether a value is representable as an immediate, it > > > will check that the 64-bit sign extension of the immediate creates > > > the desired value (in sparc64 mode), i.e. it doesn't ignore the upper > > > 32 bits even if a particular instruction does not use them. > > > > > > One solution is to generate negative literals for immediates if we > > > mean them to be sign-extended (which gcc does already for some other > > > instructions). The attached patch implements this, I'm not sure it > > > uses the best possible way to do this though, and it also needs a bit > > > more testing. > > > > *Ping* > > > > Someone needs to take this up with the gcc developers so it can get fixed. > > Sorry, I didn't have time to get this done for 5.2. 5.1, even. Need sleep. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C