JIT: don't keep a stale range when assertion tightening yields an empty range

[EgorBo]

RangeCheck::MergeEdgeAssertionsWorker tightens *pRange with each incoming assertion. When tightening yielded an empty range it returned early and left the previously tightened range in place -- a range the assertions had just contradicted. That is only safe if the assertion set truly holds (then the block is unreachable), but ComputeRangeForLocalDef merges the use block's bbAssertionIn into the range of a definition in another block, and that set can be self-contradictory.

Since #129354 assertion prop folds conditions using these ranges, so the stale range becomes wrong code. In #132879 an enum local's range was computed as [5..7] while its value was 78, folding the op > 69 test guarding a switch to false and sending execution to default:

#197 VN $502 == 7    -> pRange [<7, 7>]
#202 VN $502 == 12   -> [<12, 7>] invalid range after tightening
         Computed Range [008382] => <7, 7>   <- stale range escapes

Fix: bail out to Unknown.

.NET 11 regression (.NET 10 unaffected). Needs full opts without PGO, which is what crossgen2 does -- hence it only showed up on a PublishReadyToRun=true publish, and why DOTNET_ReadyToRun=0 didn't help.

Same root cause as #132841, whose analysis points at this exact return. #132849 fixes the ComputeDoesOverflow path instead: that resolves #132841's repro but not #132879 (verified). This change fixes both, so #132849 may be redundant.

SPMI: replay clean on benchmarks.run + libraries.pmi; asmdiffs +48 bytes / 2 contexts (benchmarks.run), +3172 bytes / 46 contexts (libraries.pmi), 0.00% both.

Regression test uses AggressiveOptimization since tier1 profile data hides the bad range.

Fixes #132879

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Fixes an unsound RangeCheck range-tightening behavior where encountering contradictory assertions could leave a previously-tightened (stale) range in place, enabling incorrect assertion-prop folding in optimized JIT/crossgen2 scenarios. Adds a targeted JIT regression test for the reported miscompile involving an enum-backed switch.

Changes:

• In RangeCheck::MergeEdgeAssertionsWorker, when tightening yields an empty range, explicitly bail out by setting *pRange to Unknown instead of leaving the prior range intact.
• Add a new JitBlue regression test (Runtime_132879) exercising the miscompile shape under AggressiveOptimization.
• Wire the new test into Regression_ro_2.csproj.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/coreclr/jit/rangecheck.cpp	Makes contradictory assertion tightening conservative by resetting the output range to Unknown on empty intersections.
src/tests/JIT/Regression/JitBlue/Runtime_132879/Runtime_132879.cs	New xUnit regression test covering the switch/enum miscompile scenario.
src/tests/JIT/Regression/Regression_ro_2.csproj	Includes the new regression test in the merged test project.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

src/coreclr/jit/rangecheck.cpp:1686

• assertedRange.IsValid() bail-out returns without resetting *pRange. Since assertedRange is accumulated across assertions in this loop, it can become invalid when assertions contradict each other; returning here can still leak a partially-tightened (stale) range to the caller, similar to the empty-range case fixed below. To keep range inference sound in the presence of self-contradictory assertion sets, set *pRange to Unknown before returning (same pattern as the copy.IsValid() failure path).

            JITDUMP("invalid range after tightening\n");
            // The tightened range is empty, i.e. the assertions contradict the range we computed.
            // If the assertion set really did hold here the block would be unreachable, but we get
            // here with sets that do not hold at this point (e.g. assertions of a use block merged
            // into the range of a definition that lives in another block). Returning while leaving
            // the previously tightened range in place lets a fact that has just been disproven
            // escape to the caller, which then folds branches with it. Bail out to Unknown instead.
            *pRange = Range(Limit(Limit::keUnknown));

[Copilot]

🟢 Approval recommended

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite