[Mono-devel-list] incorrect code generated by mcs

Paolo Molaro lupus at ximian.com
Wed Nov 5 13:01:39 EST 2003

On 11/05/03 Bernie Solomon wrote:
> I think Laurent is right: from the spec on stloc
> The stloc indx instruction pops the top value off the evalution stack and
> moves it into local variable number indx (see Partition I_alink_partitionI),
> where local variables are numbered 0 onwards. The type of value must match
> the type of the local variable as specified in the current method's locals
> signature.
> Actually I recall seeing something a little similar where both csc & mcs
> generated a 'dup' to effectively get from a int32 to a nati with no
> conversion. I can't recall the input code at the moment. Though there is a
> bit of a hack in the interpreter to try and manage this. When I get time
> I'll try and work out the offending code.

Well, you should remember that the people that wrote the CLR are the
same that made sizeof(long) == sizeof(int) on 64 bit architectures:-)
So they are used to think sizeof(int) == sizeof(void*), too, even in
the sample code they post on blogs or mailing lists.
The standard is ambiguous with the wording: since the eval stack only
holds a subset of the primitive types, there is no way the type of the
value can always match the type of the local (think storing true/false
to a bool: the value is a int32).
So, my take is that the table about implicit conversions in argument
passing in the standard also applies to stloc/stfld and the like
(and yes, allowing the implicit cast from native int to int is
unfortunate, since native ints represent pointers).
If you write a little test in ilasm (c# won't let you) you'll also note
that PEVerify doesn't complain about that case, but does complain
if you put a long in an int (their jit in full trust mode will also
happily run the code). What this means, basically, is that there is
already code out there (and compilers) that likely depend on the
behaviour and we'll have to support that (note that the cost of this
support is basically null, since we need to verify the types anyway).


lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better

More information about the Mono-devel-list mailing list