Revert "Use rangecheck in assertprop (#112766)"

[AndyAyersMS]

This reverts commit 6022adf.

Suspect this is causing a lot of the recent jitstress failures. We'll see.

[Copilot]

Copilot wasn't able to review any files in this pull request.

Files not reviewed (3)

• src/coreclr/jit/assertionprop.cpp: Language not supported
• src/coreclr/jit/rangecheck.cpp: Language not supported
• src/coreclr/jit/rangecheck.h: Language not supported

[dotnet-policy-service]

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

[AndyAyersMS]

/azp run runtime-coreclr libraries-pgo, runtime-coreclr jitstress

[AndyAyersMS]

/azp run runtime-coreclr libraries-pgo, runtime-coreclr jitstress

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jakobbotsch]

/azp run runtime-coreclr libraries-jitstress

[AndyAyersMS]

Jitstress looks good.

Libraries overall looks good. Failures mainly look like #112856

but there are some others in there too:

Assert failure(PID 9076 [0x00002374], Thread: 8544 [0x2160]): Consistency check failed: 
FAILED: pThread->PreemptiveGCDisabled()

CORECLR! CHECK::Trigger + 0x1C4 (0x00007ff9`7e36416c)
CORECLR! HijackHandler + 0x2EC (0x00007ff9`7e27f554)
NTDLL! chkstk + 0x84 (0x00007ff9`dfbbeb44)
NTDLL! RtlPcToFileHeader + 0xF60 (0x00007ff9`dfaa37e0)
<no module>! <no symbol> + 0x0 (0x082a7ff9`dfaa25f4)
    File: D:\a\_work\1\s\src\coreclr\vm\exceptionhandling.cpp:6083

[AndyAyersMS]

Reverting this PR seems to clear up a lot of the new weekend failures.

@EgorBo @dotnet/jit-contrib PTAL

[EgorBo]

With @jakobbotsch's help we identified the root cause, it is not exactly in my PR and was preexisting so is not related to my change, my change just exposed it (mainly, under CSE-related stress modes, but may repro without them too).

[halter73]

@AndyAyersMS could this be the cause of the index out of bounds errors we're seeing in this dependency update? Assuming the regression was caused by a runtime update, it seems to be caused by something between these two commits: 57ed25449ab954595130997679807a471ef85aef..a47ba19bcd61cb271cad74ae850dd1670cc9675b

[EgorBo]

@AndyAyersMS could this be the cause of the index out of bounds errors we're seeing in this dependency update? Assuming the regression was caused by a runtime update, it seems to be caused by something between these two commits: 57ed25449ab954595130997679807a471ef85aef..a47ba19bcd61cb271cad74ae850dd1670cc9675b

Yes, it could