type inference in optimized netcore2.1 code differs from all other targets

[gpomykala]

Platform: Windows / Linux

runtime: dotnet 2.1.403

code optimization enabled

The code:

    [Test]
    public void BugRepro()
    {
      byte[] valueBytes = new byte[] { 0x7f, 0xff };

      byte firstByte = valueBytes[0];
      byte secondByte = valueBytes[1];

      // (firstByte << 8) should be inferred as int as in other targets and as without optimization
      ushort guilty = (ushort)((firstByte << 8) | secondByte);

      guilty.Should().Be(32767);
    }

Actual outcome:
guilty == 255

Most likely (firstByte << 8) is inferred as byte with compile time optimization enabled, and guilty is evalueated as (0 | 0xff)

It works as expected without code optimization in netcore2.1. All other targets: net462, mono, netcore2.0 produce expected result

This is a jitter bug and doesn't repro with .NET Core 3.0.

[gpomykala]

Hello,
Thanks for a quick reply. I appreciate that it's already fixed in netcore30. It seems like the only affected target is netcore2.1 - the same code was confirmed to work fine on .net up to 4.6.2, mono 4/5 an netcore2.0.
Can it be fixed as part of netcore2.1 service release?
Cheers,
Greg

[karelz]

@0xd4d do you know which bug it is?
cc @jkotas @RussKeldorph

[jkotas]

@AndyAyersMS Does it ring a bell?

[AndyAyersMS]

Seems like it could be dotnet/coreclr#18238 dotnet/coreclr#18235.

[karelz]

@AndyAyersMS what is our position on backporting it to 2.1 servicing? Do we need more upvotes / impact clarification?

[AndyAyersMS]

I need to confirm this and look at what we did for a fix.

The bar for 2.1 is pretty high. So yes, it would be helpful to know more about the impact of this issue.

[AndyAyersMS]

The actual issue was dotnet/coreclr#18235.

I've verified that porting the fix for this (from dotnet/coreclr#18627) resolves this issue.

[AndyAyersMS]

Also reported as dotnet/coreclr#20439.

@gpomykala can you say more about the impact this bug has on your usage of Core 2.1?

[gpomykala]

@AndyAyersMS The impact is that the language fundamentals that are taken for granted suddenly return unexpected results. There are workarounds once the impacted user figures out what is happening, but it may go unnoticed in a so-so tested system (why would someone test the correctness of CLR?).
My app had been patched with a workaround therefore it is not a blocker for me anymore - if that was your question.

Best regards,
Greg

[AndyAyersMS]

@gpomykala thanks.

[karelz]

Duplicate of https://github.com/dotnet/coreclr/issues/18235