[Mono-bugs] [Bug 581984] New: Incorrect control flow in Reflection.Emit

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=581984

http://bugzilla.novell.com/show_bug.cgi?id=581984#c0


           Summary: Incorrect control flow in Reflection.Emit
    Classification: Mono
           Product: Mono: Runtime
           Version: 2.6.x
          Platform: PC
        OS/Version: Windows 7
            Status: NEW
          Severity: Major
          Priority: P5 - None
         Component: JIT
        AssignedTo: lupus at novell.com
        ReportedBy: aChrisSmith at gmail.com
         QAContact: mono-bugs at lists.ximian.com
          Found By: Third Party Developer/Partner
           Blocker: ---


Created an attachment (id=343929)
 --> (http://bugzilla.novell.com/attachment.cgi?id=343929)
C# source file to repro the bug

Description of Problem:
Branches are not taken under Mono for certain Reflection.Emit methods in some
situations. This issue falls into the category of silent bad codegen and leads
to incorrect program execution at runtime.

Steps to reproduce the problem:
1. Compile and run the attached C# Source file

Actual Results:
When executing under Mono 2.6.1 prints '0', when executing under CLR pirnts
'1'.

Expected Results:
Mono matches the CLR.


How often does this happen? 

For the repro, every time. It seems to be related to having multiple "returns"
from a method. Mono doesn't like this sequence when generated via F#
Interactive:

    br L0  // or any other test-and-branch to L0:

    ldc.i4 107
    ret

L0:
    ldc.i4 37
    ret

When run, the code always drops through the branch instruction regardless of
input. (This would indicate a problem with JIT and not IL-bytecode generation.)
Mono does seem content if values are stored in temporary locals, e.g.:

br L0  // or any other test-and-branch to L0:

ldc.i4 107
            stloc 0
            br L1
    L0:
      ldc.i4 37
            stloc 0
    L1:
            ldloc 0
            ret

This looks to be related to 'fixing up' code streams; rearrating calls to
CreateType makes the problem go away.

Additional Information:

Please do let me know if there are any workarounds for this other than changing
the order of CreateType invocations. (We have some leway in code gen to work
around this bug, but unfortunately for the F# Interactive case we cannot change
the order of when we call CreateType.)

For a simpler repro, run the latest F# Interactive window and enter the
following text:

let reduce2<'T> (gen: int list) = 
  match gen with 
  | [_; _] -> 1 
  | [_]    -> 0
  | _      -> 3

System.Console.WriteLine("result = {0}", reduce2  [1;2])

FSI on Mono returns from the middle branch '0', while on .NET returns branch
'1'.

-- 
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.