dotgnu-libjit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Dotgnu-libjit] [Patch] Type conversion bug


From: ktreichel
Subject: Re: [Dotgnu-libjit] [Patch] Type conversion bug
Date: Thu, 14 Oct 2010 08:41:19 +0200 (CEST)

>2010/10/13 Klaus Treichel <address@hidden>:
>> Hi Michele,
>>
>[...]
>> This is not a bug.
>> In libjit we follow the C conversion standard.
>> So the sign extension or zero extension depends on the source type for a
>> widening conversion.
>> A signed 32bit is always sign extended to 64bit even if the target type
>> is unsigned.
>
>Mmmh... I'm sorry, but I do not agree.
>
>I have an int32 with value 0xffffffff that has to be converted to a uint64.
>
>According to C99 standard
>(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf), paragraph
>"6.3.1.3 Signed and unsigned integers", page 55, the conversion is the
>following:
>"[...]if the new type is unsigned, the value is converted by
>repeatedly adding or
>subtracting one more than the maximum value that can be represented in
>the new type
>until the value is in the range of the new type."
>
>Therefore, the new type is uint64. The maximum number that can be
>represented in that type is 0xffffffffffffffff. I add 1 to that value
>and obtain 0x10000000000000000, that is "one more than the maximum
>value that can be represented in the new type".
>Now, I add this -arithmetically, as specified by note 49 in the
>standard- to the value to be converted and I obtain:
>
>0x10000000000000000 + 0xffffffff = 0x100000000ffffffff.
>
>Therefore, I discard the leading "1" (that is the carry bit) and I
>obtain 0x00000000ffffffff, that is what I expect: the conversion to
>64-bit WITHOUT sign extension, as opposed to what you suggest (sign
>extension depending on the source type).
>
>Did I miss something? Or is my reasoning correct? 

The new sign extended value is in the range of the new type.
But it's not the same value.

My C  testcase gives a different result (gcc 4.4)
Converting 0x8000000 to an unsigned long integer (on X86_64) yields 
0xffffffff80000000

See 
http://www.eggheadcafe.com/software/aspnet/36123200/integral-promotion--sign-extension-and-unsigned-char.aspx

That might give you a hint.

Cheers,
Klaus
___________________________________________________________
GRATIS! Movie-FLAT mit über 300 Videos. 
Jetzt freischalten unter http://movieflat.web.de



reply via email to

[Prev in Thread] Current Thread [Next in Thread]