---- Reported by c@tqzh.tk 2006-12-08 23:23:40 MST ----

Description of Problem:
It's aborted when a certain code concerning the pointer is compiled by VC#
 and it executed by mono in linux (x64 edition). 


Steps to reproduce the problem:
1. Compile the following codes by csc (VisualC# 2005). 

// csc.exe /unsafe Test.cs
public class Test {
    public static void Main() {
        unsafe {
            int n;
            int* p = &n;
            *p = 3;
        }
    }
}

2. Execute Test.exe by mono on the Linux of x64 edition.

Actual Results:
Thrown NullReferenceException.

Expected Results:
Anything doesn't happen. 

How often does this happen? 
Every time.

Additional Information:
The highest 32 bits were 0 
when calling ' Console.WriteLine("{0:x16}", (long)p); ' before ' *p = 3; .'

IL was as follows. 

  .method public hidebysig static void  Main() cil managed
  {
    .entrypoint
    .maxstack  2
    .locals init (int32 V_0,
             int32* V_1)
    IL_0000:  nop
    IL_0001:  nop
    IL_0002:  ldloca.s   V_0
    IL_0004:  conv.u
    IL_0005:  stloc.1
    IL_0006:  ldloc.1
    IL_0007:  ldc.i4.3
    IL_0008:  stind.i4
    IL_0009:  nop
    IL_000a:  ret
  }

I think that the cause is conv.u of amd64. 
Please correct it.



---- Additional Comments From robertj@gmx.net 2006-12-17 14:06:24 MST ----

Created an attachment (id=171047)
bug-80190.il




---- Additional Comments From robertj@gmx.net 2006-12-17 14:07:01 MST ----

Created an attachment (id=171048)
mini-amd64.diff




---- Additional Comments From robertj@gmx.net 2006-12-17 14:10:47 MST ----

Since mcs doesn't emit the `conv.u' (is this a bug?), I've attached
the complete IL source of the csc output from this source:

public class Test
{
        public static int Main ()
        {
                unsafe {
                        int n;
                        int* p = &n;
                        *p = 3;
                }
                return 0;
        }
}

It should be suitable as a test case for mono/tests/.




---- Additional Comments From robertj@gmx.net 2006-12-19 10:37:55 MST ----

It looks like CONV.U8 is optimized out somewhere in the runtime,
if a U8 is on the stack. mono_arch_output_basic_block () is cleaning
out the upper dword because it expects something != U8 on the stack.

This expectation is not true for CONV.U, which doesn't seem
to be optimized out => mono_arch_output_basic_block () is
erroneously wiping half of the pointer away.

If this make sense, where is CONV.U8 optimized out?
Maybe we should optimize out CONV.U, too instead of the patch,
which might be not quite correct when something != U8 is on the
stack, because it doesn't clean the upper dword.

Just the 0.02$ of an amateur ;-)




---- Additional Comments From atsushi@ximian.com 2007-02-16 17:33:40 MST ----

Guessing it is for Zoltan.





---- Additional Comments From vargaz@gmail.com 2007-02-22 13:12:18 MST ----

Fixed in SVN.


Imported an attachment (id=171047)
Imported an attachment (id=171048)

Unknown bug field "cf_op_sys_details" encountered while moving bug
   <cf_op_sys_details>maybe all OS of x64 edition</cf_op_sys_details>