C#'是'类型检查struct - 奇怪的.NET 4.0 x86优化行为

Question

更新:我已向Microsoft Connect 提交了错误报告,请投票支持!

更新2: Microsoft已将错误报告标记为已修复

微软于18/08/2010 17:25发表

此错误将在运行时的未来版本中修复.我担心现在判断它是在服务包还是下一个主要版本中还为时过早.

自从升级到VS2010后,我的'is'关键字出现了一些非常奇怪的行为.

下面的程序(test.cs)在调试模式下编译时(对于x86)输出True,在编译时使用优化(对于x86)时输出False.编译x64或AnyCPU中的所有组合可得到预期结果True.

.NET 3.5下的所有编译组合都给出了预期的结果True.

我正在使用下面的批处理文件(runtest.bat)来编译和测试代码,使用编译器.NET框架的各种组合.

• 有谁在.NET 4.0下看到过这类问题？
• 运行runtests.bat时,其他人是否在计算机上看到与我相同的行为？

• @ $ @#$？

• 有没有解决这个问题？

test.cs中

using System;

public class Program
{
    public static bool IsGuid(object item)
    {
        return item is Guid;
    } 

    public static void Main()
    {
        Console.Write(IsGuid(Guid.NewGuid()));
    }
}

runtest.bat

@echo off

rem Usage:
rem   runtest         -- runs with csc.exe x86 .NET 4.0
rem   runtest 64      -- runs with csc.exe x64 .NET 4.0
rem   runtest v3.5    -- runs with csc.exe x86 .NET 3.5
rem   runtest v3.5 64 -- runs with csc.exe x64 .NET 3.5

set version=v4.0.30319
set platform=Framework

for %%a in (%*) do (
  if "%%a" == "64" (set platform=Framework64)
  if "%%a" == "v3.5" (set version=v3.5)
)

echo Compiler: %platform%\%version%\csc.exe
set csc="C:\Windows\Microsoft.NET\%platform%\%version%\csc.exe"

set make=%csc% /nologo /nowarn:1607 test.cs
rem CS1607: Referenced assembly targets a different processor
rem This happens if you compile for x64 using csc32, or x86 using csc64

%make% /platform:x86
test.exe
echo  =^> x86

%make% /platform:x86 /optimize
test.exe
echo  =^> x86 (Optimized)

%make% /platform:x86 /debug
test.exe
echo  =^> x86 (Debug)

%make% /platform:x86 /debug /optimize
test.exe
echo  =^> x86 (Debug + Optimized)

%make% /platform:x64
test.exe
echo  =^> x64

%make% /platform:x64 /optimize
test.exe
echo  =^> x64 (Optimized)

%make% /platform:x64 /debug
test.exe
echo  =^> x64 (Debug)

%make% /platform:x64 /debug /optimize
test.exe
echo  =^> x64 (Debug + Optimized)

%make% /platform:AnyCPU
test.exe
echo  =^> AnyCPU

%make% /platform:AnyCPU /optimize
test.exe
echo  =^> AnyCPU (Optimized)

%make% /platform:AnyCPU /debug
test.exe
echo  =^> AnyCPU (Debug)

%make% /platform:AnyCPU /debug /optimize
test.exe
echo  =^> AnyCPU (Debug + Optimized)

检测结果

运行runtest.bat时,我在Win7 x64安装上得到以下结果.

> runtest 32 v4.0
Compiler: Framework\v4.0.30319\csc.exe
False => x86
False => x86 (Optimized)
True => x86 (Debug)
False => x86 (Debug + Optimized)
True => x64
True => x64 (Optimized)
True => x64 (Debug)
True => x64 (Debug + Optimized)
True => AnyCPU
True => AnyCPU (Optimized)
True => AnyCPU (Debug)
True => AnyCPU (Debug + Optimized)

> runtest 64 v4.0
Compiler: Framework64\v4.0.30319\csc.exe
False => x86
False => x86 (Optimized)
True => x86 (Debug)
False => x86 (Debug + Optimized)
True => x64
True => x64 (Optimized)
True => x64 (Debug)
True => x64 (Debug + Optimized)
True => AnyCPU
True => AnyCPU (Optimized)
True => AnyCPU (Debug)
True => AnyCPU (Debug + Optimized)

> runtest 32 v3.5
Compiler: Framework\v3.5\csc.exe
True => x86
True => x86 (Optimized)
True => x86 (Debug)
True => x86 (Debug + Optimized)
True => x64
True => x64 (Optimized)
True => x64 (Debug)
True => x64 (Debug + Optimized)
True => AnyCPU
True => AnyCPU (Optimized)
True => AnyCPU (Debug)
True => AnyCPU (Debug + Optimized)

> runtest 64 v3.5
Compiler: Framework64\v3.5\csc.exe
True => x86
True => x86 (Optimized)
True => x86 (Debug)
True => x86 (Debug + Optimized)
True => x64
True => x64 (Optimized)
True => x64 (Debug)
True => x64 (Debug + Optimized)
True => AnyCPU
True => AnyCPU (Optimized)
True => AnyCPU (Debug)
True => AnyCPU (Debug + Optimized)

TL;博士

Answer 1

我编写了一个类似的例子,它以同样的方式失败:

using System;
using System.Runtime.CompilerServices;

public class Program {
  static void Main() {
    Console.Write(Verify(Test.Create()));
    Console.ReadLine();
  }
  //[MethodImpl(MethodImplOptions.NoInlining)]
  static bool Verify(IDisposable item) {
    return item is Test;
  }
  struct Test : IDisposable {
    public void Dispose() { }
    public static Test Create() { return new Test(); }
  }
}

这是一个JIT优化器错误.不能完全把手指放在上面,它会大大优化代码.但它让我觉得它在优化拳击转换时会遇到麻烦.坦率地说,相当严重的bug.

这个bug已经修复,我再也无法重复了.我当前的clrjit.dll版本是2011年5月17日的4.0.30319.237.我无法确切地知道更新修复了什么.我在2011年8月5日获得了一个安全更新,它将clrjit.dll更新为版本235,日期为4月12日,这将是最早的.

Answer 2

要回答上一个问题,可以将MethodImpl带有选项的属性添加MethodImplOptions.NoInlining到IsGuid方法中,以解决问题.

我刚刚在.NET 4.0上对x86的Debug和Release配置进行了简单的测试,这似乎解决了这个问题.我还没有运行你的runtests.bat.

如果尚未提交问题,您还应该在Connect中提交问题并将其与您的问题相关联.

Answer 3

除了一些 nops 之外，反射器指出唯一的区别在于 IsGuid 方法：

调试：

.method public hidebysig static bool IsGuid(object item) cil managed
{
    .maxstack 2
    .locals init (
        [0] bool CS$1$0000)
    L_0000: nop 
    L_0001: ldarg.0 
    L_0002: isinst [mscorlib]System.Guid
    L_0007: ldnull 
    L_0008: cgt.un 
    L_000a: stloc.0 
    L_000b: br.s L_000d
    L_000d: ldloc.0 
    L_000e: ret 
}

发布：

.method public hidebysig static bool IsGuid(object item) cil managed
{
    .maxstack 8
    L_0000: ldarg.0 
    L_0001: isinst [mscorlib]System.Guid
    L_0006: ldnull 
    L_0007: cgt.un 
    L_0009: ret 
}

我不够流利地解释这些差异，但这是社区维基的答案，所以也许其他人可以启发我们？

更改方法以使其通用可以解决此问题（可能的错误？）

public static bool IsGuid<T>(T item)
{
    return item is Guid;
}

与强制将其放入局部变量一样（但必须在方法中使用它以防止优化启动）：

public static bool IsGuid(object item)
{
    bool a = item is Guid;
    a.ToString();
    return a;
}