From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Henderson To: Cort Dougan Cc: gas2@sourceware.cygnus.com Subject: Re: ppc instructions in gas Date: Thu, 06 May 1999 18:43:00 -0000 Message-id: <19990506184343.C13363@cygnus.com> References: <19990505145806.H9469@cygnus.com> <19990505165232.A8594@attis.cs.nmt.edu> <19990506150724.A10994@cygnus.com> <19990506161159.A27229@attis.cs.nmt.edu> <19990506153554.B10994@cygnus.com> <19990506171639.A26711@attis.cs.nmt.edu> <19990506165624.A24549@cygnus.com> <19990506180806.A5113@attis.cs.nmt.edu> <19990506174929.A13363@cygnus.com> <19990506185754.A12025@attis.cs.nmt.edu> <19990506185754.A12025@attis.cs.nmt.edu> X-SW-Source: 1999/msg00099.html On Thu, May 06, 1999 at 06:57:54PM -0600, Cort Dougan wrote: > } We should fix gcc then. That should not be hard at all. > > Ok. Patch gcc to emit correct code and modify the asm we have in the > kernel? Know of any cute gas methods of converting 0xffff and its ilk to a > signed value? Pardon? "gas methods"? > } I'm not real comfortable just changing it. Who knows what sort > } of code is out there. I wouldn't be adverse to reducing the > } error to a warning in 32-bit mode though. > > I'd prefer to actually do the right thing in my asm and if gcc did the same > that would all the better. So the check in binutils to allow unsigned > values is probably a workaround for gcc? No, the check to allow unsigned values is a workaround for (to pick a name out of the hat) NorTel's hand-written assembly code. So I'm on the right page, "lis" is the only instruction this is an issue for? What about the old "liu" insn? "U" presumably stood for "upper" not "unsigned"? r~