From owner-freebsd-sparc64@FreeBSD.ORG Wed May 7 15:39:18 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 DE9A937B401 for ; Wed, 7 May 2003 15:39:18 -0700 (PDT) Received: from lewis.lclark.edu (sunfire.lclark.edu [149.175.1.5]) by mx1.FreeBSD.org (Postfix) with SMTP id 3958343FAF for ; Wed, 7 May 2003 15:39:18 -0700 (PDT) (envelope-from anholt@FreeBSD.org) Received: from [149.175.30.191] ([149.175.30.191]) by lewis.lclark.edu (SAVSMTP 3.0.1.45) with SMTP id M2003050715383813978 ; Wed, 07 May 2003 15:38:38 -0700 From: Eric Anholt To: Thomas Moestl In-Reply-To: <20030507221133.GA678@crow.dom2ip.de> References: <20030116072448.GA29468@rot13.obsecurity.org> <20030116201728.GA279@crow.dom2ip.de> <20030408003332.GA60864@rot13.obsecurity.org> <20030507221133.GA678@crow.dom2ip.de> Content-Type: text/plain Organization: Message-Id: <1052347524.1070.10.camel@leguin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 May 2003 15:45:25 -0700 Content-Transfer-Encoding: 7bit cc: sparc64@FreeBSD.org cc: Kris Kennaway 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:39:19 -0000 On Wed, 2003-05-07 at 15:11, 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. The attached patch > should work around the bug however; Eric, could you please add it to > XFree86-4-libraries, until the problem is resolved in gcc or gas, so > that there can be a package for the release? > > Thanks, > - Thomas Done. Thanks for the patch. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org