[Mono-bugs] [Bug 381559] trivially simple reproduction of Invalid IL code bug ( anonymous methods + string concat)

[bugzilla_noreply at novell.com]

https://bugzilla.novell.com/show_bug.cgi?id=381559

User zorander at gmail.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=381559#c2





--- Comment #2 from Brian Luczkiewicz <zorander at gmail.com>  2008-04-18 19:25:22 MST ---
There are actually two problems here..

  IL_0019:  ldloc.0
  IL_001a:  dup
  IL_001b:  ldc.i4.5
  IL_001c:  newarr     [mscorlib]System.Object
  IL_0021:  dup
  IL_0022:  ldc.i4.0
****************
missing object load here!
****************
  IL_0023:  ldfld      string Fail/'<>c__CompilerGenerated0'::'<1:a>'

In addition to the 'missing object load here', there is an "extra" reference to
the closure state sitting on the stack from the dup at IL_001a that never gets
used (just adding ldloc causes a different IL failure on the ret from the
method as a result of this). 

This only gets generated when Variable.HasInstance is true (which seems only
true for generated closure variables when prepare_for_load is true in
EmitAssign). The purpose of prepare_for_load is to protect against
double-evaluation of the lhs of the assignment, but double-evaluation is not
harmful for closure state since they are simple locals references and have no
side effects.

The dup breaks the auto-generation of arrays for StringConcat nodes when #
nodes > 3 (due to matching the params object[] overload of String.Concat). It
does no harm when the next operation is a ldfld (e.g. for the simple
String.Concat cases where no array is generated).

This solution is probably not totally ideal since it always does ldloc twice on
the closure state object in compound assignments even when dup could have been
used with no troubles.


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