[Top][All Lists]
[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