C＃'is'类型检查结构 - 奇.NET 4.0 x86优化行为 [英] C# 'is' type check on struct - odd .NET 4.0 x86 optimization behavior

问题描述

更新：我提交了错误报告，请投票！

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

Update 2: Microsoft have marked the bug report as fixed

/ 08/2010 at 17:25

这个错误会在未来版本的
中修复。我是
恐怕现在太早了，如果
将在服务包或下一个
主要版本。

This bug will be fixed in a future version of the runtime. I'm afraid it's too early to tell if that will be in a service pack or the next major release.

自从升级到VS2010以来，我通过'is'关键字得到了一些很奇怪的行为。

Since upgrading to VS2010 I'm getting some very strange behavior with the 'is' keyword.

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

The program below (test.cs) outputs True when compiled in debug mode (for x86) and False when compiled with optimizations on (for x86). Compiling all combinations in x64 or AnyCPU gives the expected result, True.

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

All combinations of compiling under .NET 3.5 give the expected result, True.

我使用下面的批处理文件（runtest.bat）使用编译器.NET框架的各种组合来编译和测试代码。

I'm using the batch file below (runtest.bat) to compile and test the code using various combinations of compiler .NET framework.

• 有没有人在.NET 4.0下看到这些问题？


• 运行runtests.bat时，其他人在他们的电脑上看到的行为是否与我一样？



• @ $ @＃$ ??



• 是否有解决方法？

• Has anyone else seen these kind of problems under .NET 4.0?
• Does everyone else see the same behavior as me on their computer when running runtests.bat?

• @$@#$??

• Is there a fix for this?

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

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安装上得到以下结果。

Test Results

When running the runtest.bat I get the following results on my Win7 x64 install.

> 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; dr

推荐答案

我做了一个类似的例子，失败了同样的方式：

I worked up a similar example that fails the same way:

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，坦率地说。

It is a JIT optimizer bug. Can't quite put the finger on it, it optimizes the code heavily. But it looks to me like it gets in trouble when it optimizes the boxing conversion away. Pretty serious bug, frankly.

这个错误已修复，我当前版本的clrjit.dll是4.0.30319.237日期为2011年5月17日。我不知道什么更新修复它。我在2011年8月5日获得了一个安全更新，将clrjit.dll更新为版本235，日期为4月12日，这将是最早的。

This bug has been fixed, I can no longer repro it. My current version of clrjit.dll is 4.0.30319.237 dated May 17th 2011. I can't tell exactly what update repaired it. I got a security update on Aug 5th 2011 that updated clrjit.dll to revision 235 with a date of Apr 12, that would be the earliest.

这篇关于C＃'is'类型检查结构 - 奇.NET 4.0 x86优化行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！