gcc3.1 now sign-extends unsigned integer function arguments
John Baldwin
jhb@FreeBSD.org
Thu May 16 22:40:00 GMT 2002
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.
Ok.
> 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)
> or
> "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/
More information about the Gcc-bugs
mailing list