This is the mail archive of the
mailing list for the GCC project.
Re: gcc3.1 now sign-extends unsigned integer function arguments
- From: John Baldwin <jhb at FreeBSD dot org>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 17 May 2002 01:39:53 -0400 (EDT)
- Subject: Re: gcc3.1 now sign-extends unsigned integer function arguments
On 17-May-2002 Richard Henderson wrote:
> On Thu, May 16, 2002 at 11:06:50PM -0400, John Baldwin wrote:
>> With gcc 2.95, when a register was passed to this function, the value
>> was zero-extended using the zapnot instruction.
> If so, that was incorrect.
> The Alpha OSF/1 ABI specifies that all 32-bit arguments and return values
> are to be sign-extended in their registers, regardless of the signedness
> of the type involved.
Ok, this sounds good then.
> This is done because manipulating sign-extended values is much more
> efficient on the architecture. Not that gcc always takes advantage...
> However, in this case I don't think that has anything to do with it.
> Your inline assembly is wrong. You passed a 32-bit type to the asm,
> and got a correct 32-bit value. Except that you then use it as a
> 64-bit value. You can expect, in general, for gcc to give you garbage
> in the high-order bits. Why? Because you've not given the compiler
> any reason to think that it matters. Certainly you wouldn't want the
> compiler to extend the value if you were only going to store the
> low N bits.
> So you're going to have to change this to either
> "r" ((long)(int)cmpval)
> "r" ((unsigned long)cmpval)
> as you choose. Naturally, the first is more efficient, since you
> don't have to have the zap in the inline assembly.
Ok, will do. Thanks for the clarification.
John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/