[Mono-devel-list] Bad IL generated for IntPtr -> int32 cast?

[Bernie Solomon]

In working on more 64 bit issues I have discovered some code inside corlib
for some IntPtr casts which I think is wrong. This:

    public static explicit operator int (IntPtr value)
    {
        return (int) value.value;
    }

generates the folowing IL.

    // method line 621
    .method public static  hidebysig  specialname
           default int32 op_Explicit(native int value)  cil managed
    {
        .param [1]
        // Method begins at RVA 0x8015
        // Code size 8 (0x8)
        .maxstack 8
        IL_0000: ldarga.s 0
        IL_0002: ldfld  void* System.IntPtr::value
        IL_0007: ret
    } // end of method IntPtr::default int32 op_Explicit(native int value)

and there is no conv.i4 generated. You will probably get away with this for
a little endian machine even if 64bits but for a big endian 64 bit machine
the conversion actually does something to get the low order 32 bits of the
value. (as necessary when converting the result of Marshal.OffsetOf into an
int.

I think pointer -> int conversions should always generate this IL (which no
doubt JITs can optimize away).

This code is from the 0.25 corlib.dll as in the tarball - I haven't built it
myself - and I haven't looked at mcs to see how to fix it (I assume this was
built using mcs).

Bernie Solomon