Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=80307 --- shadow/80307 2007-01-15 14:45:39.000000000 -0500 +++ shadow/80307.tmp.24146 2007-01-16 03:21:54.000000000 -0500 @@ -1,12 +1,12 @@ Bug#: 80307 Product: Mono: Runtime Version: 1.2 OS: other OS Details: -Status: NEW +Status: ASSIGNED Resolution: Severity: Unknown Priority: Wishlist Component: JIT AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] @@ -176,6 +176,21 @@ returns the original klass for a byref type, not a 'byref' class, causing the JIT to create variables with the wrong type". I also had big problems with this piece of code when trying to implement type based alias analysis for HSSA. Anyway, I'll investigate more. + +------- Additional Comments From [EMAIL PROTECTED] 2007-01-16 03:21 ------- +As usual, in retrospect it was easy: mono_type_get_underlying_type +"strips" the byref information from the type. +I mean, a "System.Web.Compilation.TagType&" (note the final '&') +becomes a "System.Int32". +This makes so that, on 64 bit systems, mono_allocate_stack_slots_full +puts it in a 4 bytes available slot instead of an 8 bytes one: when +the variable is written it then overwrites (part of) the next slot. + +This is easy to fix, but the question is: is this IMHO broken behavior +of mono_type_get_underlying_type intentional? +I mean, is there code relying on this? +If yes, I'll just fix mono_allocate_stack_slots_full, but I would +prefer fixing mono_type_get_underlying_type instead. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
