Date: Thu, 8 May 2003 00:11:34 +0200 From: Thomas Moestl <tmoestl@gmx.net> To: Kris Kennaway <kris@obsecurity.org> Cc: sparc64@FreeBSD.ORG Subject: Re: assembler error in XFree86 snapshot Message-ID: <20030507221133.GA678@crow.dom2ip.de> In-Reply-To: <20030408003332.GA60864@rot13.obsecurity.org> References: <20030116072448.GA29468@rot13.obsecurity.org> <20030116201728.GA279@crow.dom2ip.de> <20030408003332.GA60864@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 -- Thomas Moestl <t.moestl@tu-bs.de> http://www.tu-bs.de/~y0015675/ <tmm@FreeBSD.org> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xres.diff" --- lib/XRes/XRes.c.orig Wed Oct 16 02:37:26 2002 +++ lib/XRes/XRes.c Wed May 7 23:44:38 2003 @@ -218,7 +218,13 @@ } #ifdef LONG64 +#ifdef __sparc64__ + /* The first assignment is to work around a bug in gcc/gas on sparc64. */ + *bytes = rep.bytes_overflow; + *bytes = (*bytes * 4294967295) + rep.bytes; +#else *bytes = (rep.bytes_overflow * 4294967295) + rep.bytes; +#endif #else *bytes = rep.bytes_overflow ? 0xffffffff : rep.bytes; #endif --xHFwDpU9dbj6ez1V--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030507221133.GA678>