This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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)
> 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 <>  <><
"Power Users Use the Power to Serve!"  -

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]