Date: Fri, 9 May 2003 13:46:53 -0700 From: "Bruce A. Mah" <bmah@FreeBSD.org> To: Eric Anholt <anholt@FreeBSD.org> Cc: sparc64@FreeBSD.org Subject: Re: assembler error in XFree86 snapshot Message-ID: <20030509204653.GA11053@intruder.bmah.org> In-Reply-To: <1052347524.1070.10.camel@leguin> References: <20030116072448.GA29468@rot13.obsecurity.org> <20030116201728.GA279@crow.dom2ip.de> <20030408003332.GA60864@rot13.obsecurity.org> <20030507221133.GA678@crow.dom2ip.de> <1052347524.1070.10.camel@leguin>
next in thread | previous in thread | raw e-mail | index | archive | help
--J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable If memory serves me right, Eric Anholt wrote: > 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 immedia= te > > > > here; however, it chooses to output it as an unsigned number and do= es > > > > not sign-extended it from 32 to 64 bit. > > > >=20 > > > > 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 upp= er > > > > 32 bits even if a particular instruction does not use them. > > > >=20 > > > > 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 b= it > > > > more testing. > > >=20 > > > *Ping* > > >=20 > > > Someone needs to take this up with the gcc developers so it can get f= ixed. > >=20 > > 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? > >=20 > > Thanks, > > - Thomas >=20 > Done. Thanks for the patch. Does this patch fix the "gcc sparc64 problems" item on the 5.1 TODO list? (i.e. can I cross it off as completed?) http://www.freebsd.org/releases/5.1R/todo.html Thanks! Bruce. --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE+vBO92MoxcVugUsMRApSCAJ96enmD51T5d0gql7Bb/ar54nZ44ACfbXBV mHm0/56I7frfEqN6aY6pL+4= =FI7O -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030509204653.GA11053>