JIT: (bug) int.RotateLeft/RotateRight constant folding creates a non-sign-extended TYP_INT constant, so comparisons against it are folded to the wrong result #135814

impRotateHelper folds RotateLeft/RotateRight(const, const) for 32-bit operands via gtNewIconNode(uint32_t, baseType). When the result has bit 31 set, the TYP_INT constant holds +2147483648 instead of -2147483648, so later phases fold comparisons against it incorrectly.

Minimal Repro

using System;
using System.Runtime.CompilerServices;

public class Program
{
    [MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.AggressiveOptimization)]
    static bool Test(int y) => y > int.RotateLeft(1, 31);   // == int.MinValue

    [MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.AggressiveOptimization)]
    static bool TestLt(int y) => y < int.RotateLeft(1, 31);

    public static void Main()
    {
        Console.WriteLine("Test(3) = " + Test(3));
        Console.WriteLine("TestLt(3) = " + TestLt(3));
    }
}

Expected

Test(3) = True
TestLt(3) = False

Actual

Test(3) = False
TestLt(3) = True

Test is compiled to xor eax, eax and TestLt to mov eax, 1.

Regression?

Also reproduces on the 10.0.13 release (Test(3) returns False); not re-verified.

Notes

• impRotateHelper (importercalls.cpp): uint32_t res = ...; return gtNewIconNode(res, baseType); zero-extends res to ssize_t on 64-bit hosts, but assertion prop / VN range reasoning rely on TYP_INT constants being sign-extended.
• Likely fix: gtNewIconNode(static_cast<int32_t>(res), baseType).
• JIT: assertion 'FitsIn<int32_t>(value)' on constant-folded BitOperations.RotateRight(0xFFFFFFFFu, k) with multiple uses #129099 is the same root cause reported as a Checked-only assert (FitsIn<int32_t>(value)); this repro shows it also miscompiles on Release.