runtime: Wrong integer promotion in release
For .NET core 2.1, the following program outputs 1023 in debug, but 255 in release.
using System;
class C0
{
public sbyte F;
}
public class Program
{
public static void Main()
{
C0 var0 = new C0 { F = -1 };
ulong var1 = (ulong)(1000 | (byte)var0.F);
Console.WriteLine(var1);
}
}
This issue repros on .NET framework 4.6.1 as well with 64-bit JIT (it does not repro with 32-bit JIT). The compiler used is csc.exe 2.8.3.62923 (7aafab56).
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 20 (20 by maintainers)
Commits related to this issue
- Fix value numbering when selecting a constant When applying selectors, constants were special-cased to not require any type casts. However this is wrong if a narrowing needs to be performed. Fix #18... — committed to jakobbotsch/coreclr by jakobbotsch 6 years ago
- Fix value numbering when selecting a constant When applying selectors, constants were special-cased to not require any type casts. However this is wrong if a narrowing needs to be performed. Fix #18... — committed to jakobbotsch/coreclr by jakobbotsch 6 years ago
- Fix value numbering when selecting a constant (#18627) When applying selectors, constants were special-cased to not require any type casts. However this is wrong if a narrowing needs to be performed... — committed to dotnet/coreclr by jakobbotsch 6 years ago
- Port fix value numbering when selecting a constant to release/2.1 Master PR #18627 When applying selectors, constants were special-cased to not require any type casts. However this is wrong if a nar... — committed to AndyAyersMS/coreclr by AndyAyersMS 6 years ago
- Port fix value numbering when selecting a constant to release/2.2 Master PR #18627 When applying selectors, constants were special-cased to not require any type casts. However this is wrong if a nar... — committed to AndyAyersMS/coreclr by AndyAyersMS 6 years ago
- Port fix value numbering when selecting a constant to release/2.1 Master PR #18627 When applying selectors, constants were special-cased to not require any type casts. However this is wrong if a nar... — committed to dotnet/coreclr by AndyAyersMS 6 years ago
I opened dotnet/coreclr#18238.
As a project for a university course we wrote a fuzzer that generates C# programs, https://github.com/jakobbotsch/Fuzzlyn. It generates a program, then compares the results of all static and local variables when running in debug and release mode. I have many more examples, but we have no automatic reducer yet, so I have been reducing them to minimal repros by hand. I am not too familiar with the JIT internals, so it is a little hard for me to know which problems are new and which aren’t.
EDIT: It is of course heavily inspired by Csmith, which I’m sure you’re familiar with.
I spent the weekend writing an automatic reducer and running it on all our examples. The programs can be seen here. I have looked through most of them and I believe they are all instances of the bugs I have already reported. though it’s hard for me to tell for sure. Once these issues are fixed I will rerun and filter away the non-interesting programs.
Yep, it’s the same incorrect value numbering of indirs.
var2[0]andvar1[0]have the same value number (even if one produces 0xffff and the other 0xffffffff) and CSE replacesvar1[0]with the value produced earlier byvar2[0].And incorrect value numbering aside, CSE is dubious anyway. It doesn’t make sense to introduce a new temporary variable to hold the result of
var2[0]when this is actually a constant. And even if it’s not a constant it would make more sense to re-use whatever value was used to initializevar1[0]so that the temporary has a shorter life.@mikedn
OverflowExceptionderives fromArithmeticException, so ifOverflowExceptionis thrown, both specs should be satisfied.@jakobbotsch Very good work - does it test all possible syntax variations or just a subset of C#/IL?