[WIP] Fix missing cases in GenTree::Compare function#7
Draft
[WIP] Fix missing cases in GenTree::Compare function#7
Conversation
…p signals (dotnet#124734) ## Summary Improve the jit-regression-test skill with structured description, stop signals, and consolidated tips. ### Changes 1. **Structured description** — Added USE FOR / DO NOT USE FOR routing keywords for better skill activation. Trigger phrases include: creating JIT regression tests, extracting repro code, "write a test for this JIT bug", "create a regression test for issue #NNNNN". Anti-triggers: non-JIT tests, debugging without repro, performance benchmarks. 2. **Stop signal blockquote** — Added explicit guidance on when NOT to create a test (no reproducible code, duplicate of existing test, bug is in libraries not JIT). This prevents the skill from being misapplied on invalid inputs. 3. **Consolidated tips** — Reduced from 4 verbose items to 2 concise items. Removed tips that duplicate the conventions section (NoInlining, minimize repro). ### Validation Multi-model eval results (5 questions testing trigger routing, stop compliance, structural output, convention compliance, negative routing): | Model | Before | After | |-------|--------|-------| | Claude Sonnet | 25/25 | 25/25 | | Claude Haiku | 22/25 | 25/25 | Key improvement: Haiku stop-signal compliance went from 2/5 to 5/5. The blockquote pattern causes weaker models to correctly refuse when stop conditions are met, rather than inferring from general knowledge. ### Context These patterns (structured descriptions, blockquote stop signals) are documented in the [Copilot Skills Guidance](https://aka.ms/skills/guidance) and have been validated across multiple skills (ci-analysis, flow-analysis, flow-tracing).
Partial implementation of block stores for wasm - handles copies and zeroing of structs via refs and pointers, but not fields or locals yet. Does not handle nonzero init values yet. --------- Co-authored-by: SingleAccretion <62474226+SingleAccretion@users.noreply.github.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Fix comment and spelling issues, fix an incorrect jitdump arg, simplify a Boolean expression, consolidate a pair of visitors into one.
This PR includes a few additions to the runtime-async handling loop to facilitate inspection by a debugger - specifically, Visual Studio. 1. Timestamp tracking for continuations. In VS there is a feature that lets you see, while F5 debugging, the relative start times and durations of different tasks. There is only one actual Task at the root of an await chain, but we intend to replicate the outward behavior in runtime-async by treating Continuations as "virtual Tasks". As such, we populate a dictionary to track the start times for each logical invocation. 2. TPL events. In Concord in asyncv1 we are notified of Task status changes via TPL events; specifically, we use these events to detect which Tasks are currently active and which thread each Task runs on. There are ways to do this without TPL in Concord; however, I believe a change to this would be across different (non-runtime async) Tasks and beyond the scope of this PR. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Jan Kotas <jkotas@microsoft.com> Co-authored-by: Steve Pfister <stpfiste@microsoft.com>
> [!NOTE] > This is a codeflow update. It may contain both source code changes from > [the VMR](https://github.com/dotnet/dotnet) > as well as dependency updates. Learn more [here](https://github.com/dotnet/dotnet/tree/main/docs/Codeflow-PRs.md). This pull request brings the following source code changes [marker]: <> (Begin:f7901f87-9f24-40d6-9bc1-564863937237) ## From https://github.com/dotnet/dotnet - **Subscription**: [f7901f87-9f24-40d6-9bc1-564863937237](https://maestro.dot.net/subscriptions?search=f7901f87-9f24-40d6-9bc1-564863937237) - **Build**: [20260217.1](https://dev.azure.com/dnceng/internal/_build/results?buildId=2906108) ([302104](https://maestro.dot.net/channel/8298/github:dotnet:dotnet/build/302104)) - **Date Produced**: February 17, 2026 1:11:00 PM UTC - **Commit**: [6699c7330bf73b37beb5b19c59b57cbcb4dcafac](dotnet/dotnet@6699c73) - **Commit Diff**: [ba0812f...6699c73](dotnet/dotnet@ba0812f...6699c73) - **Branch**: [main](https://github.com/dotnet/dotnet/tree/main) **Updated Dependencies** - From [5.5.0-2.26116.109 to 5.5.0-2.26117.101][1] - Microsoft.CodeAnalysis - Microsoft.CodeAnalysis.Analyzers - Microsoft.CodeAnalysis.CSharp - Microsoft.Net.Compilers.Toolset - From [11.0.100-preview.2.26116.109 to 11.0.100-preview.2.26117.101][1] - Microsoft.CodeAnalysis.NetAnalyzers - Microsoft.DotNet.ApiCompat.Task - Microsoft.NET.Workload.Emscripten.Current.Manifest-11.0.100.Transport - From [11.0.0-beta.26116.109 to 11.0.0-beta.26117.101][1] - Microsoft.DotNet.Arcade.Sdk - Microsoft.DotNet.Build.Tasks.Archives - Microsoft.DotNet.Build.Tasks.Feed - Microsoft.DotNet.Build.Tasks.Installers - Microsoft.DotNet.Build.Tasks.Packaging - Microsoft.DotNet.Build.Tasks.TargetFramework - Microsoft.DotNet.Build.Tasks.Templating - Microsoft.DotNet.Build.Tasks.Workloads - Microsoft.DotNet.CodeAnalysis - Microsoft.DotNet.GenAPI - Microsoft.DotNet.GenFacades - Microsoft.DotNet.Helix.Sdk - Microsoft.DotNet.PackageTesting - Microsoft.DotNet.RemoteExecutor - Microsoft.DotNet.SharedFramework.Sdk - Microsoft.DotNet.XliffTasks - Microsoft.DotNet.XUnitExtensions - From [0.11.5-preview.26116.109 to 0.11.5-preview.26117.101][1] - Microsoft.DotNet.Cecil - From [2.9.3-beta.26116.109 to 2.9.3-beta.26117.101][1] - Microsoft.DotNet.XUnitAssert - Microsoft.DotNet.XUnitConsoleRunner - From [11.0.0-preview.2.26116.109 to 11.0.0-preview.2.26117.101][1] - Microsoft.NET.Sdk.IL - Microsoft.NETCore.App.Ref - Microsoft.NETCore.ILAsm - runtime.native.System.IO.Ports - System.Reflection.Metadata - System.Reflection.MetadataLoadContext - System.Text.Json - From [7.5.0-rc.11709 to 7.5.0-rc.11801][1] - NuGet.Frameworks - NuGet.Packaging - NuGet.ProjectModel - NuGet.Versioning - From [3.0.0-preview.2.26116.109 to 3.0.0-preview.2.26117.101][1] - System.CommandLine [marker]: <> (End:f7901f87-9f24-40d6-9bc1-564863937237) [1]: dotnet/dotnet@ba0812f...6699c73 [marker]: <> (Start:Footer:CodeFlow PR) ## Associated changes in source repos - dotnet/msbuild@fb68c81...81815e5 <details> <summary>Diff the source with this PR branch</summary> ```bash darc vmr diff --name-only https://github.com/dotnet/dotnet:6699c7330bf73b37beb5b19c59b57cbcb4dcafac..https://github.com/dotnet/runtime:darc-main-1c9ad051-1d09-419c-a55b-6ac1569f5a2c ``` </details> [marker]: <> (End:Footer:CodeFlow PR) Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
…tnet#124564) # [cDAC] Add infrastructure to run cDAC tests using ClrMD and dumps ## Summary Adds dump-based integration tests for the cDAC (contract-based Data Access Component) reader. Purpose-built debuggee apps crash via `FailFast` to produce dumps, which are then loaded through ClrMD to validate that cDAC contracts can correctly read real runtime data structures. ## What's Being Tested Each test class exercises a specific cDAC contract against a real crash dump: | Contract | What's Validated | |----------|-----------------| | **Thread** | Thread store enumeration, thread count, thread data fields | | **RuntimeInfo** | Runtime version, target OS detection | | **GCHeap** | Server GC heap structures and segment enumeration | | **StackWalk** | Stack frame enumeration, MethodDesc resolution, register contexts | | **RuntimeTypeSystem** | Type handles, method tables, free object detection | | **Loader** | Module enumeration, assembly resolution across multiple modules | | **EcmaMetadata** | Cross-module metadata token resolution | ## Debuggees Auto-discovered from `Debuggees/`. | Debuggee | Scenario | Dump Type | |----------|----------|-----------| | **BasicThreads** | Multiple managed threads | Heap | | **ExceptionState** | Nested exception chain via FailFast | Heap | | **GCRoots** | GC object graph with pinned handles | Heap | | **ServerGC** | Server GC mode | Heap | | **StackWalk** | Deterministic call stack (Main→A→B→C→FailFast) | Heap | | **MultiModule** | Multi-assembly app for metadata/loader tests | Full | | **TypeHierarchy** | Class inheritance hierarchy | Full | ## Infrastructure - **`DumpTests.targets`** — MSBuild logic that builds debuggees, runs them with `DOTNET_DbgEnableMiniDump` to collect crash dumps, and organizes output by `{version}/{dumptype}/{debuggee}/`. Supports heap (type 2) and full (type 4) dumps with per-debuggee configuration via the `DumpTypes` MSBuild property. - **`RunDumpTests.ps1`** — Windows helper script for local development. Orchestrates dump generation and test execution with options for filtering, forcing regeneration, and testing against CI dump archives. - **`DumpTestBase.cs`** — Test base class that loads a dump via ClrMD, creates a `ContractDescriptorTarget`, and provides version/OS-aware test skipping. - **`ClrMdDumpHost.cs`** — Wraps ClrMD's `DataTarget` to provide memory read and symbol lookup callbacks. Handles PE, ELF, and Mach-O module formats via ClrMD's built-in export resolution. ## CI Pipeline Defined in `eng/pipelines/runtime-diagnostics.yml`. Runs nightly and on PRs touching `src/native/managed/cdac/**`. | Stage | Purpose | |-------|---------| | **Build** | Builds runtime, runs standard diagnostics tests (with and without cDAC) | | **DumpCreation** | Generates local-version crash dumps on each platform, publishes as artifacts | | **DumpTest** | Downloads dumps from all platforms, runs cross-platform dump analysis | Currently generates **local dumps only** on CI. The net10.0 self-contained publish requires a separate SDK not available on CI agents. Heap dump tests for net10.0 are skipped (cDAC was not supported in net10.0 heap dumps). ## Future plan * Move dump test execution to Helix for broader platform coverage. * Consider only doing x-plat build as an outerloop. * Run with previous version dump in CI.
Changeset dotnet@1fa1745 introduced a stack walking regression where we will crash trying to unwind/report registers. The real fix here is in cgenamd64.cpp/excep.cpp, which will point the context to a local copy before we try to use it. I've also added some changes in gcinfodecoder.cpp that aren't strictly necessary but would have avoided the problem to begin with. Fixes dotnet#124401.
Fix some issues that I noticed while trying to crossgen debug/release System.Private.Corelib * need to be more careful fetching layout when rewriting local stores * handle degenerate BBJ_COND during wasm flow graph reordering * pinvoke prolog can likely be empty * fix VN assert for the extra PE arg we pass at end of arglist * make sure Wasm special call args have names in dumps * handle struct arg passed as field during reg alloc * fix logic for marking `this` as address-exposed
…narios (dotnet#124772) Modifies how MethodDesc sizes are computed. Instead of using the runtime `s_ClassificationSizeTable` which is not present in heap dumps, RuntimeTypeSystem now computes the MethodDesc size from datadescriptors. Modified DumpTests to run on heap dumps for verification.
This PR is a follow-up to dotnet#124161. Change `Requires.Argument(index - count + 1 >= 0)` to `Requires.Range(index - count + 1 >= 0, nameof(count))` in `ImmutableList<T>.Node.LastIndexOf` to align with the validation used in `ImmutableArray<T>.LastIndexOf`. Changes: - Use `Requires.Range` in `ImmutableList<T>.Node.LastIndexOf` for validating the `index` and `count` parameters. - Add a test case to verify that an `ArgumentOutOfRangeException` is thrown when validation of the `index` and `count` parameters in `LastIndexOf` and `FindLastIndex` fails. - Fix test case to also validate the parameter name. - Rename `ImmutableList<T>.Node.LastIndexOf` index param to startIndex
…em (dotnet#124709) Android's scudo heap allocator uses ARM64 Top-Byte Ignore (TBI) to tag heap pointers with a non-zero top byte (e.g., 0xB4). While the CPU ignores this byte during memory access, pread on /proc/<pid>/mem treats the offset as a file position where TBI does not apply, causing EINVAL. Strip the top byte before pread in PAL_ReadProcessMemory and createdump's ReadProcessMemory. This is a no-op on non-Android ARM64 Linux today, but guards against future TBI/MTE adoption on other distributions. See https://www.kernel.org/doc/html/latest/arch/arm64/tagged-address-abi.html
…net#124599) When checking a element of TBase size, ensure that no other bits other than the first bit are set
….Compression (dotnet#124634) There is no real benefit from having the APIs in separate assembly because: - the Managed code size is rather small - it P/Invokes System.IO.Compression.Native just like System.IO.Compression managed assembly does - It would lead to circular dependency if we decide to implement dotnet#123532 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
…#124486) Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: MihaZupan <25307628+MihaZupan@users.noreply.github.com> Co-authored-by: Miha Zupan <mihazupan.zupan1@gmail.com>
…h "file:" relative URI (dotnet#124660) Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: MihaZupan <25307628+MihaZupan@users.noreply.github.com>
Based on [the calendar](https://apireview.net/schedule), Thursday reviews aren't happening since May 2025.
Set `__NumProc` on OpenBSD.
Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com> Co-authored-by: MihaZupan <25307628+MihaZupan@users.noreply.github.com> Co-authored-by: MihaZupan <mihazupan.zupan1@gmail.com>
Fixes dotnet#123858. This PR improves JIT codegen for multi-target `switch`-style tests by converting eligible cases into branchless checks. The goal is to produce optimal codegen that matches the intent of C# pattern matching with `or` (e.g., `x is A or B or C`). When a switch has exactly 2 unique successors (all non-default cases target one block, default targets another), convert it from Switch to an unsigned range comparison (In `fgOptimizeSwitchBranches`). When both targets are simple return blocks, `fgFoldCondToReturnBlock` further folds this into branchless return. ## Example ```csharp private static bool IsLetterCategory(UnicodeCategory uc) { return uc == UnicodeCategory.UppercaseLetter || uc == UnicodeCategory.LowercaseLetter || uc == UnicodeCategory.TitlecaseLetter || uc == UnicodeCategory.ModifierLetter || uc == UnicodeCategory.OtherLetter; } ``` ## Before ```asm cmp ecx, 4 ja SHORT G_M22758_IG05 mov eax, 1 ret G_M22758_IG05: xor eax, eax ret ``` ## After ```asm cmp ecx, 4 setbe al movzx rax, al ret ``` ## Details - The comparison direction is chosen to GT_LT. - Edge dup counts are fixed up after conversion. - Added tests for zero-based and non-zero-based consecutive ranges. ## ASMDiffs - SPMI asmdiffs show code size improvements of 83 bytes. --------- Co-authored-by: Egor Bogatov <egorbo@gmail.com>
Code needing to check for class init would be skipped for R2R
compilation, probably because at runtime we would be likely to detect
the check as redundant. On iOS this means that the entire method would
be interpreted which is way more expensive than a small check for class
initialization. This commit adds a r2r helper for this, which will end
up as a call to the standard jit helper:
System.Runtime.CompilerServices.Helpers.InitClass/InitInstantiatedClass.
In the example below, G<>.Touch was skipped in R2R.
```
public class G<T>
{
static Type theType;
static G()
{
theType = typeof(T);
}
[MethodImpl(MethodImplOptions.NoInlining)]
public static Type Touch()
{
return theType;
}
}
G<string>.Touch();
```
When a test run crashes, the msbuild build would still succeed, and run.py would read stale testRun.xml files from a previous run, reporting old (potentiall passing) results instead of an error. Instead use `ContinueOnError="ErrorAndContinue"` to allow subsequent test runs to continue but still fail the build. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…h small destination buffers (dotnet#124655) Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: MihaZupan <25307628+MihaZupan@users.noreply.github.com>
Add GetStackLimits cDAC API Fixes dotnet#124696
Loading an empty assembly (0-length byte array or stream) throws `BadImageFormatException` with the generic message "Bad IL format." This is a common scenario with bugs in dynamically generated assemblies and provides no actionable information. **Before:** ```csharp Assembly.Load(new byte[0]); // BadImageFormatException: Bad IL format. ``` **After:** ```csharp Assembly.Load(new byte[0]); // BadImageFormatException: Assembly image is empty. The stream or byte array must contain a valid PE file. ```
…nt (dotnet#124300) ## Description `NRange.GetOffsetAndLength` casts its `nint` parameters to `uint` for range validation. On 64-bit platforms, this truncates values larger than `uint.MaxValue`, allowing invalid ranges to pass validation silently. ```csharp // Before: truncates upper 32 bits on 64-bit platforms if ((uint)end > (uint)length || (uint)start > (uint)end) // After: correct comparison for all nint values if ((nuint)end > (nuint)length || (nuint)start > (nuint)end) ``` For example, `start = 0x1_0000_0001` and `end = 2` with `length = 0x1_0000_0003`: the `(uint)` cast truncates start to `1`, making `1 > 2` false and incorrectly passing validation. **Note:** Other `(uint)` conversion issues in `NRange` (e.g., `ToString`) are intentionally not addressed here — those are covered by dotnet#124294. ### Tests - Converted existing `GetOffsetAndLengthTest` `[Fact]` to `[Theory]` with `[InlineData]` - Split success and exception cases into separate theory methods - Added `[ConditionalTheory(Is64BitProcess)]` tests exercising values above `uint.MaxValue`, including a case that directly catches the truncation bug <!-- START COPILOT CODING AGENT TIPS --> --- 💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: vcsjones <361677+vcsjones@users.noreply.github.com>
Implement GetCurrentAppDomain for cDAC
Unity was the last reason to keep this around. We used mcs as a source of different IL for testing code we have that makes changes to method bodies. The time has come that the added test coverage we use it for isn't worth the maintenance costs anymore. I'm going to remove mcs from our test setup which means there's no reason to keep this code around anymore.
Unity is still verifying the ILLink tests mostly pass when ran through an old version of UnityLinker that still supports .NET Framework. We also have tests that will root types in `test.exe`. Both of these scenarios lead to compiler generated polyfills that survive and mess up asserting. `AssemblyChecker` had some logic to deal with compiler generated attributes. These specific attributes no longer appear to require special handling during the illink tests so I've removed them. In order to help Unity deal with it's tests I've exposed a new method `PrepareToVerifyAssembly` that we can hook into and do the same sort of thing that was happening for attributes such as `EmbeddedAttribute` but also do it for other types such as `NullableAttribute`. I've exposed a helper method `IgnoreTypeAndItsMembers` that makes it easier to ignore a type and it's members.
dotnet#120477 removed the virtual on `MarkAssembly`. Unity needs to override this method. Adding back the `virtual`
…mplementation of LIFO policy." (dotnet#125193) Reverts dotnet#123921 This change appears to have caused a large regression in NuGet restore performance. Reverting is confirmed to produce a significant improvement (10-15%).
We could end up calling GetAsyncOtherVariant for explicitly-async methods like AsyncHelpers.Await, which do not have other variants. This was happening under `EnableExtraSuperPmiQueries` mode that queries both variants proactively. Also simplify SPMI implementation of the recording of this function.
…terface allocation apis (dotnet#125091) This makes all allocation of memory for the interpreter which are long-lived be allocated in the one big allocation. This should fix any issues where we have memory leaking from collectible assemblies. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
## Summary
Fix CMake build failure when building `clr.runtime` from a clean build
(instead of `clr.native`).
## Problem
When building `clr.runtime` from clean, the install step fails with:
```
CMake Error at _deps/zstd-build/lib/cmake_install.cmake:53 (file):
file INSTALL cannot find
".../_deps/zstd-build/lib/zstd_static.lib"
```
This happens because zstd's own `install()` rules are included in the
build's install step. When the `runtime` component install runs, it
tries to install `zstd_static.lib` — but that file was never built
because `libzstd_static` is only built as a dependency of
`System.IO.Compression.Native`, which is not part of the `runtime` build
target.
## Fix
Replace `FetchContent` with a direct `add_subdirectory()` call using
`EXCLUDE_FROM_ALL`, which reliably prevents zstd's own `install()` rules
from being included in the component install. The `EXCLUDE_FROM_ALL`
parameter on `add_subdirectory()` has properly suppressed install rules
since CMake 3.14, making it compatible with the project's CMake 3.26
minimum.
The explicit `install()` calls in
`System.IO.Compression.Native/CMakeLists.txt` that install
`libzstd_static` to the correct destinations continue to work as before
since they target the `libzstd_static` target directly (not via zstd's
own install rules).
Fixes dotnet#124234
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
## Description Windows 7 is no longer a supported OS. Remove Win7-specific code paths, dead branches, and outdated comments from System.Net.Security. ### Product code - **`SslCertificateTrust.cs`**: Replace `IsWindowsVersionAtLeast(6, 2)` guard with `IsWindows()` — the version check only excluded Win7, which is no longer reachable. Remove unused `System.Runtime.Versioning` using. - **`SslAuthenticationOptions.cs`**: Remove comment about SSL2+TLS1.2 incompatibility on pre-Win10 (code stays, it's still correct). - **`ExtendedProtectionPolicy.cs`**: Update comment to clarify ExtendedProtection is supported on all Windows versions supported by current .NET version. - **`SslStreamPal.Windows.cs`**: Clarify legacy `SCHANNEL_CRED` comment — it's for older Windows versions, not specific to Win7. ### Test code - **`TestConfiguration.cs`**: Remove dead `!PlatformDetection.IsWindows10OrLater` branch in null encryption detection. - **`SslStreamSystemDefaultsTest.cs`**: Simplify `IsWindows && WindowsVersion >= 10` to `IsWindows`. - **`SslStreamCredentialCacheTest.cs`**: Update comment referencing Win8 behavioral change from Win7. Note: The `SCHANNEL_CRED` / `UseNewCryptoApi` dual-path remains — it serves Win10 builds before 18836 (pre-TLS 1.3), not Win7. <!-- START COPILOT CODING AGENT TIPS --> --- ✨ Let Copilot coding agent [set things up for you](https://github.com/dotnet/runtime/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: rzikm <32671551+rzikm@users.noreply.github.com> Co-authored-by: Stephen Toub <stoub@microsoft.com> Co-authored-by: Jan Kotas <jkotas@microsoft.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
… Windows (dotnet#124720) This PR adds an opt-in `AppContext` switch to enable kernel response buffering in HttpListener (Windows implementation only). When enabled, the flag `HTTP_SEND_RESPONSE_FLAG_BUFFER_DATA` is set on all calls to `HttpSendHttpResponse` and `HttpSendResponseEntityBody` (consistent with [Win32 docs](https://learn.microsoft.com/en-us/windows/win32/api/http/nf-http-httpsendresponseentitybody#:~:text=HTTP_SEND_RESPONSE_FLAG_BUFFER_DATA)). This mirrors the behavior for setting the `HttpSysOptions.EnableKernelResponseBuffering` flag in [ASP.NET HTTP.sys code](https://github.com/dotnet/aspnetcore/blob/2a88012113497bac5056548f16d810738b069198/src/Servers/HttpSys/src/RequestProcessing/ResponseBody.cs#L499). Motivation in [issue dotnet#123425](dotnet#123425). Sample usage: ```csharp AppContext.SetSwitch("System.Net.HttpListener.EnableKernelResponseBuffering", true); using var listener = new HttpListener(); listener.Prefixes.Add("http://localhost:8080/"); listener.Start(); Console.WriteLine("Listening..."); while (true) { var context = await listener.GetContextAsync().ConfigureAwait(false); _ = Task.Run(() => HandleRequestAsync(context)); } ``` Notes: - No public API changes - Default behavior remains unchanged - Since API is internal, tests use reflection to validate flag behavior. - Added dedicated Windows-only test classes for `HttpListener` and `HttpResponseStream`, and consolidated existing Windows-only tests there for consistency. # Repro and validation Setup: - Client: Azure VM in West US 2 - Server: Azure VM in Australia East Client uses HttpClient to send requests to the server and measures total latency. Server is running HttpListener and returns 7MB responses while varying the server-side response buffer size (from 32KB to 7MB). Server also records avg timing per individual response Write() call. ## Benchmark ### Kernel Buffering Disabled (Existing Behavior) | Buffer Size (bytes) | Latency (ms) | Write Time (µs) | |---------------------|--------------|-----------------| | 32768 | 33911 | 158414 | | 65536 | 16923 | 158108 | | 131072 | 8609 | 159346 | | 262144 | 4323 | 159938 | | 524288 | 2296 | 163629 | | 1048576 | 1181 | 168004 | | 2097152 | 701 | 173846 | | 4194304 | 468 | 206004 | | 7000000 | 492 | 384459 | ### Kernel Buffering Enabled (New Behavior) | Buffer Size (bytes) | Latency (ms) | Write Time (µs) | |---------------------|--------------|-----------------| | 32768 | 1154 | 4589 | | 65536 | 1149 | 9211 | | 131072 | 1142 | 18205 | | 262144 | 1107 | 35590 | | 524288 | 1137 | 69975 | | 1048576 | 686 | 75492 | | 2097152 | 386 | 92539 | | 4194304 | 451 | 109173 | | 7000000 | 490 | 2356 | - Enabling HttpListener kernel buffering reduces E2E latency by up to 30x (34s → 1s for 32KB buffers) - Average `Write()` time drops significantly (158,414 µs → 4,589 µs at 32 KB). These results confirm that without kernel buffering, small writes cause RTT amplification. Enabling kernel buffering eliminates small-write fragmentation over the wire and dramatically reduces latency. ## Packet Capture ### Packet analysis Without kernel buffering, when the server sends a 7MB response using a 32KB buffer, packet capture shows that each server Write() results in a 32KB TCP segment (Length=32768, [PSH, ACK]). Each segment is transmitted approx. 1 RTT apart (~0.158s matching Azure-advertised RTT b/w the two regions). Transmission is effectively ACK-gated. <img width="1965" height="702" alt="image" src="https://github.com/user-attachments/assets/5f5eb251-8d79-423a-8c1b-54f139e9f907" /> E2E the request takes ~34s: <img width="1689" height="146" alt="image" src="https://github.com/user-attachments/assets/47080e30-4f84-49bf-be98-36ee50ee59d2" /> With kernel buffering enabled, the TCP stack transmits large bursts of packets rather than one per RTT. <img width="2399" height="1307" alt="image" src="https://github.com/user-attachments/assets/a8d62e17-534c-4b1b-b3f8-a8536e9f9a03" /> E2E latency dropped from ~34s to ~1s (first request ~1.9s due to TCP slow start, subsequent requests stabilize at ~0.95s). <img width="2158" height="360" alt="image" src="https://github.com/user-attachments/assets/9cdfd2df-167a-4917-a354-faef86b033f0" /> ### TCP stream graph The diff in behavior is best visualized using the Stevens TCP stream graph: Without kernel buffering, the graph shows each ~32 KB increment in response transmission is separated by approx. one RTT. The slope is shallow (slow rate of growth) and evenly spaced. <img width="3792" height="1788" alt="image" src="https://github.com/user-attachments/assets/dcc98a89-a2e1-4385-af9a-41fb9e8bb9f9" /> With kernel buffering enabled, the slope becomes significantly steeper. Multiple segments are transmitted back-to-back before the next RTT boundary. <img width="3786" height="1857" alt="image" src="https://github.com/user-attachments/assets/b439ea87-3fea-4b6a-aeb8-5d6ea981c77e" /> This visualizes the core issue: without buffering, small writes are RTT-amplified. With buffering, HTTP.sys aggregates response data in kernel space and transmits in large bursts, eliminating per-write RTT pacing. ### Repro code #### Init HttpListener with EnableKernelResponseBuffering switch ```c# var listener = new HttpListener(); if (enableBuffering) { AppContext.SetSwitch( "System.Net.HttpListener.EnableKernelResponseBuffering", true); } listener.Prefixes.Add("http://+:80/"); listener.Start(); while (true) { var context = await listener.GetContextAsync(); try { long responseSize = long.Parse(context.Request.QueryString["size"]); int bufferSize = int.Parse(context.Request.QueryString["buffer"]); context.Response.StatusCode = 200; await SendListenerResponse(context, responseSize, bufferSize); } finally { context.Response.Close(); } } ``` #### Server multi-write response routine ```c# var buf = new byte[bufferSize]; long totalWriteUs = 0; int writeCount = 0; long totalSent = 0; while (totalSent < size) { int writeSize = (int)Math.Min(size - totalSent, bufferSize); long start = Stopwatch.GetTimestamp(); await stream.WriteAsync(buf.AsMemory(0, writeSize)); long end = Stopwatch.GetTimestamp(); totalWriteUs += (end - start) / 10; writeCount++; totalSent += writeSize; } long avgWriteUs = totalWriteUs / writeCount; ``` Thanks @ManickaP for all the help! --------- Co-authored-by: Marie Píchová <11718369+ManickaP@users.noreply.github.com>
… entries (dotnet#125201) `ProcessTargetInfo` in managed NTLM returns trailing zeros instead of actual target info data when the server challenge includes `TargetName` or `ChannelBindings` AV pairs (which are skipped and replaced). The early-exit path was correct; the fallback return was off-by-one in the wrong direction. ## Changes - **Bug fix** (`NegotiateAuthenticationPal.ManagedNtlm.cs`): One-character fix — `AsSpan(targetInfoOffset)` → `AsSpan(0, targetInfoOffset)`. The old code returned the unused trailing portion of the pre-allocated buffer; the fix returns the written portion. - **Test infrastructure** (`FakeNtlmServer.cs`): Added `SendPreExistingTargetName` and `SendPreExistingChannelBindings` properties (default `false`). When set, the server challenge includes dummy `TargetName`/`ChannelBindings` AV pairs that the client must skip and replace, forcing `targetInfoOffset < targetInfoBuffer.Length` and hitting the previously dead code path. - **Regression test** (`NegotiateAuthenticationTests.cs`): `NtlmWithPreExistingTargetInfoEntriesTest` — `[ConditionalTheory]` gated on `UseManagedNtlm`, exercises all non-trivial flag combinations `(true,false)`, `(false,true)`, `(true,true)` and verifies full authentication succeeds. The test is scoped to managed NTLM platforms (Ubuntu 24/26, OpenSUSE 16) because the bug lives in the managed implementation; platforms using the system gss-ntlmssp library may not handle pre-existing AV pairs in the server challenge consistently across versions. # Customer Impact NTLM authentication fails when the server includes `TargetName` or `ChannelBindings` entries in the challenge's target info. The corrupted target info causes HMAC verification to fail on the server side, breaking authentication entirely for those server configurations. # Regression Not a regression introduced in the most recent release — this is a pre-existing latent bug in the managed NTLM implementation. It was masked because `FakeNtlmServer` never emitted those AV pair types in tests. # Testing Full NTLM exchange tested with each combination of pre-existing `TargetName`/`ChannelBindings` entries in the challenge. All 122 existing unit tests continue to pass. # Risk Low. The fix is a single character change to a slice argument. The affected code path was previously unreachable in tests; the new tests confirm correctness. No protocol logic changed. # Package authoring no longer needed in .NET 9 IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version. Keep in mind that we still need package authoring in .NET 8 and older versions. <!-- START COPILOT ORIGINAL PROMPT --> <details> <summary>Original prompt</summary> > ## Bug Description > > In `src/libraries/System.Net.Security/src/System/Net/NegotiateAuthenticationPal.ManagedNtlm.cs`, the `ProcessTargetInfo` method has a bug on line 563: > > ```csharp > return targetInfoBuffer.AsSpan(targetInfoOffset).ToArray(); > ``` > > This returns the **unused trailing portion** of `targetInfoBuffer` (from `targetInfoOffset` to the end), when it should return the **used portion** (from 0 to `targetInfoOffset`). The fix is: > > ```csharp > return targetInfoBuffer.AsSpan(0, targetInfoOffset).ToArray(); > ``` > > ### Context of the bug > > The `ProcessTargetInfo` method: > 1. Allocates `targetInfoBuffer` with size: `targetInfo.Length + 20 + 4 + spnSize + 8` > 2. Copies AV pairs from the input `targetInfo` into `targetInfoBuffer`, **skipping** any existing `TargetName` or `ChannelBindings` entries > 3. Appends its own `TargetName`, `ChannelBindings`, `Flags`, and `EOL` entries > 4. Uses `targetInfoOffset` as the write cursor tracking how many bytes were written > > At the end: > - Line 558: `if (targetInfoOffset == targetInfoBuffer.Length) return targetInfoBuffer;` — this is the happy path when no entries were skipped > - Line 563: `return targetInfoBuffer.AsSpan(targetInfoOffset).ToArray();` — **BUG**: returns trailing zeros instead of the actual data > > ### Why existing tests don't catch this > > The `FakeNtlmServer.GenerateChallenge()` in `src/libraries/Common/tests/System/Net/Security/FakeNtlmServer.cs` never includes `TargetName` or `ChannelBindings` AV pairs in its challenge message. Therefore, `ProcessTargetInfo` never skips any entries, `targetInfoOffset` always equals `targetInfoBuffer.Length`, and the early return on line 558 always fires. The buggy line 563 is never reached. > > ### Required changes > > 1. **Fix the bug** in `NegotiateAuthenticationPal.ManagedNtlm.cs` line 563: > Change `targetInfoBuffer.AsSpan(targetInfoOffset).ToArray()` to `targetInfoBuffer.AsSpan(0, targetInfoOffset).ToArray()` > > 2. **Add test coverage** by modifying `FakeNtlmServer` in `src/libraries/Common/tests/System/Net/Security/FakeNtlmServer.cs` to support optionally including pre-existing `TargetName` and/or `ChannelBindings` AV pairs in the challenge message's target info. Add a property like `bool SendPreExistingTargetName { get; set; }` and/or `bool SendPreExistingChannelBindings { get; set; }` that, when set to true, inserts dummy `TargetName`/`ChannelBindings` AV pairs into the challenge's target info before the EOL. This will exercise the code path where `ProcessTargetInfo` skips entries, causing `targetInfoOffset < targetInfoBuffer.Length` and reaching the previously-buggy line 563. > > 3. **Add new test(s)** in `src/libraries/System.Net.Security/tests/UnitTests/NegotiateAuthenticationTests.cs` that: > - Create a `FakeNtlmServer` with the pre-existing TargetName/ChannelBindings feature enabled > - Perform a full NTLM exchange and verify authentication succeeds > - This ensures the trimmed target info buffer is correct when entries are filtered out > > The tests should be `[ConditionalFact]` or `[ConditionalTheory]` gated on `IsNtlmAvailable`, consistent with the existing test patterns in the file. </details> <!-- START COPILOT CODING AGENT SUFFIX --> *This pull request was created from Copilot chat.* > <!-- START COPILOT CODING AGENT TIPS --> --- ✨ Let Copilot coding agent [set things up for you](https://github.com/dotnet/runtime/issues/new?title=✨+Set+up+Copilot+instructions&body=Configure%20instructions%20for%20this%20repository%20as%20documented%20in%20%5BBest%20practices%20for%20Copilot%20coding%20agent%20in%20your%20repository%5D%28https://gh.io/copilot-coding-agent-tips%29%2E%0A%0A%3COnboard%20this%20repo%3E&assignees=copilot) — coding agent works faster and does higher quality work when set up for your repo. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: stephentoub <2642209+stephentoub@users.noreply.github.com> Co-authored-by: rzikm <32671551+rzikm@users.noreply.github.com>
Address @AndyAyersMS concerns regarding assertion sets (dotnet#125093 (review)) --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
These are working fine now. Resolves dotnet#124259 and dotnet#124260
Closes dotnet#123085 [Diffs](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1322668&view=ms.vss-build-web.run-extensions-tab) given `(X + negativeConst) u< Y` for int32 vars where `u<` is unsigned less than `Y` is a proven never negative bound `negativeConst` is a negative constant (`> INT32_MIN`) We deduce `X >= -negativeConst`
…net#125236) ## Summary The cDAC's DEBUG validation asserts compare HRESULTs between the cDAC and legacy DAC using exact equality (`Debug.Assert(hrLocal == hr)`). This causes the debugger process to crash when the cDAC and native DAC return different failure HRESULTs for the same invalid input. For example, when `GetMethodTableData` is called with a garbage method table pointer, the cDAC may throw `InvalidOperationException` (`0x80131C49`) while the native DAC returns `E_INVALIDARG` (`0x80070057`). Both correctly reject the input, but the exact HRESULT comparison fires a fatal `Debug.Assert` that terminates the debugger mid-command — causing flaky CI failures like `SOS.VarargPInvokeInteropMD` in the `cDAC_windows_x64_release` job. No consumer (ClrMD, SOS, managed debugger) branches on specific failure codes from these APIs — they only check success vs failure. ## Changes **New file: `DebugExtensions.cs`** — adds `Debug.ValidateHResult()` as a C# 14 static extension method on `System.Diagnostics.Debug`: ```csharp Debug.ValidateHResult(hr, hrLocal); ``` With two validation modes via `HResultValidationMode`: - **`Exact`** — HRESULTs must match exactly (available for APIs where the specific code matters) - **`AllowDivergentFailures`** (default) — success HRESULTs (`S_OK`, `S_FALSE`) must match exactly, but any two failing HRESULTs (negative values) are considered equivalent **Converted all 113 call sites** across 5 files from: ```csharp Debug.Assert(hrLocal == hr, $"cDAC: {hr:x}, DAC: {hrLocal:x}"); ``` to: ```csharp Debug.ValidateHResult(hr, hrLocal); ```
* use gtOverflowEx instead of gtOverflow * not all block stores need null checks * more cases where we don't have putarg stacks * add lowering was bypassing Wasm overflow checking * tolerate nullchecks that can't throw (see dotnet#125203) * storeind nullchecks --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: SingleAccretion <62474226+SingleAccretion@users.noreply.github.com>
Fixes dotnet#123442 The tracee hit the 5s timeout on the jitstress lane. Given that jitstress lanes are known to be slow, I'm expecting non-jitstress lanes to still complete quickly despite the longer timeout. Also added logs to 1) indicate whether the Tracee's EventSource was enabled and 2) reveal which .NET processes record-trace detected and sent an IPC command. Below is an example output with these in effect record-trace emits `Enabled .NET events for process: pid=13803` Tracee EventSource enabled, emitting events. ```bash Starting record-trace: sudo -n /home/mihw/repo/runtime/artifacts/tests/coreclr/linux.x64.Debug/tracing/userevents/common/userevents_common/record-trace --script-file /home/mihw/repo/runtime/artifacts/tests/coreclr/linux.x64.Debug/tracing/userevents/custommetadata/custommetadata/custommetadata.script --out /tmp/tmpBl0cAg.nettrace --log-filter one_collect::helpers::exporting=warn,one_collect::perf_event=warn,one_collect::tracefs=warn,one_collect::scripting=warn,ruwind=warn,engine=warn --log-mode console record-trace started with PID: 13789 Delaying tracee startup 300ms for record-trace setup... [record-trace][stdout] 2026-03-05T18:20:38.062008Z INFO one_collect::helpers::dotnet::os::linux: Enabled .NET events for process: pid=4998 [record-trace][stdout] Recording started. Press CTRL+C to stop. [record-trace][stdout] 2026-03-05T18:20:38.068201Z INFO one_collect::helpers::dotnet::os::linux: Enabled .NET events for process: pid=13767 Starting tracee process: /home/mihw/repo/runtime/artifacts/tests/coreclr/linux.x64.Debug/Tests/Core_Root/corerun /home/mihw/repo/runtime/artifacts/tests/coreclr/linux.x64.Debug/tracing/userevents/custommetadata/custommetadata/custommetadata.dll tracee Tracee process started with PID: 13803 Waiting for tracee process to exit... [record-trace][stdout] 2026-03-05T18:20:38.369549Z INFO one_collect::helpers::dotnet::os::linux: Enabled .NET events for process: pid=13803 [tracee][stdout] Tracee waiting for EventSource to be enabled via IPC... [tracee][stdout] Tracee EventSource enabled, emitting events. Stopping record-trace with SIGINT. Waiting for record-trace to exit... [record-trace][stdout] 2026-03-05T18:20:38.509142Z WARN one_collect::helpers::dotnet::os::linux: Failed to open diagnostic socket: pid=13803, nspid=13803 [record-trace][stdout] Recording stopped. [record-trace][stdout] Resolving symbols. [record-trace][stdout] Finished recording trace. [record-trace][stdout] Trace written to /tmp/tmpBl0cAg.nettrace [record-trace][stdout] 2026-03-05T18:20:38.666852Z INFO record_trace: record-trace exiting: exit_code=0 CustomMetadata event: Id=1, Name=Item1 Ignored 4441 events from processes other than tracee (PID 13803). Expected: 100 Actual: 100 END EXECUTION - PASSED ``` --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
`gtDirectCallAddress` is already always set for all these kinds of calls in lowering.
…tnet#125242) This change removes the unused ILLink dependency analyzer under `src/tools/illink/src/analyzer` and eliminates all repository wiring that still referenced it. The ILLink toolset surface now reflects only actively maintained components. - **Build graph cleanup** - Removed analyzer from `eng/Subsets.props` (`tools.illink` subset no longer builds `src/analyzer/analyzer.csproj`). - **Solution cleanup** - Removed `src/analyzer/analyzer.csproj` from: - `src/tools/illink/illink.slnx` - `src/tools/illink/trimming.slnx` - **Source removal** - Deleted `src/tools/illink/src/analyzer/` (project file, core implementation, and analyzer-specific README). - **Docs alignment** - Updated `src/tools/illink/README.md` to remove the “Dependencies Analyzer” section/link to the removed component. ```xml <!-- removed from eng/Subsets.props --> <ProjectToBuild Include="$(ToolsProjectRoot)illink\src\analyzer\analyzer.csproj" Category="tools" /> ``` <!-- START COPILOT CODING AGENT TIPS --> --- 💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey). --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: sbomer <787361+sbomer@users.noreply.github.com>
- GT_CNS_INT: Compare icon handle flags and field sequences, not just the integer value. Two constants with the same value but different handle types or field sequences are not equivalent. - GT_ALLOCOBJ: Add missing case in the unary ExOp switch. Previously hit the default assert in debug builds. - GT_ARR_ELEM: Compare gtArrElemSize. Resolves existing TODO comment. - GT_SELECT: Add missing case in the special-node switch. Compare all three operands (condition, true value, false value). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- GT_INDEX_ADDR: Compare gtElemType, gtLenOffset, and gtElemOffset in addition to gtElemSize. - GT_FTN_ADDR: Add leaf case comparing gtFptrMethod. Previously returned false for equal function address nodes. - GT_PHI_ARG: Add leaf case comparing local number, predecessor block, and SSA number. Previously returned false for equal phi arg nodes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- GT_JCC/GT_SETCC: Add leaf cases comparing gtCondition. - GT_PHYSREG: Add leaf case comparing gtSrcReg. - GT_JCMP/GT_JTEST/GT_SELECTCC: Compare gtCondition for binary nodes that carry a condition code but are not ExOp. - GT_SELECT_INCCC/GT_SELECT_INVCC/GT_SELECT_NEGCC (ARM64): Compare gtCondition for ARM64-specific conditional select variants. - GT_CCMP (ARM64/AMD64): Compare gtCondition and gtFlagsVal. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.
Original prompt
**Chronological Review:** 1. User asked to review `GenTree::Compare` in the .NET runtime JIT codebase for missing cases/checks 2. I searched for and found the function in `gentree.cpp` (lines 2595-3010) 3. Spawned two background exploration agents to analyze completeness 4. Compiled a comprehensive review identifying HIGH, MEDIUM, and LOW issues 5. User asked where Compare is called in lower.cpp — I found 5 callsites + 1 in lower.h 6. User asked for a reminder of what we were doing — I summarized findings 7. User asked to fix HIGH issues on a new branch `CleanupGenTreeCompare` — done, committed 8. User asked to fix MEDIUM issues in a new commit — done, committed 9. User asked to fix remaining (LOW) issues in a new commit — done, committed 10. User asked what `/delegate` does — I checked CLI docs (not found in help) 11. User asked again via `/research` — I performed web search and fetched official docs, saved reportIntent Mapping:
Technical Inventory:
Code Archaeology:
src/coreclr/jit/gentree.cppCleanupGenTreeCompareProgress Assessment:
Recent Commands Analysis:
/researchtask about/delegate1. Conversation Overview: - Primary Objectives: (1) "review the code for GenTree::Compare and see if it is missing any cases or checks" in the .NET runtime JIT compiler; (2) Fix all identified issues across three priority tiers (HIGH, MEDIUM, LOW) in separate commits on a new branch; (3) Research what `/delegate` does in copilot-cli. - Session Context: Started with a comprehensive code review of `GenTree::Compare` in the .NET runtime JIT, identified issues at three severity levels, then methodically fixed all of them across three commits on branch `CleanupGenTreeCompare`. Ended with a research query about the `/delegate` command. - User Intent Evolution: Review → Fix HIGH → Fix MEDIUM → Fix remaining LOW → Research question about copilot-cli.-
- .NET Runtime JIT Compiler: C++ codebase at
- GenTree Node System: Tree-based IR with node kinds GTK_LEAF, GTK_UNOP, GTK_BINOP, GTK_SPECIAL, and GTK_EXOP for extended fields
- Build System:
- Branch:
-
- Purpose: Core JIT file containing
- Current State: Modified with 3 commits, all building cleanly (0 warnings, 0 errors)
- Key Changes (Commit 1 - HIGH fixes):
- GT_CNS_INT (line ~2661): Added
- GT_ALLOCOBJ (line ~2852): Added to unary ExOp switch with
- GT_ARR_ELEM (line ~2990): Added
- GT_SELECT (line ~3019): Added to special-node switch comparing
- Key Changes (Commit 2 - MEDIUM fixes):
- GT_INDEX_ADDR: Extended to compare
- GT_FTN_ADDR: Added leaf case comparing
- GT_PHI_ARG: Added leaf case comparing local number,
- Key Changes (Commit 3 - LOW fixes):
- GT_JCC/GT_SETCC: Added leaf cases comparing
- GT_PHYSREG: Added leaf case comparing
- GT_JCMP/GT_JTEST/GT_SELECTCC: Added binary condition code comparison
- GT_SELECT_INCCC/GT_SELECT_INVCC/GT_SELECT_NEGCC: ARM64-specific CC comparison (under
- GT_CCMP: Condition +
-
- Issues Encountered: GenTree::Compare had multiple gaps — missing node types in switches, incomplete field comparisons for constants and index addresses, no handling for LIR-only condition code nodes
- Solutions Implemented: Three incremental commits adding proper comparisons for all identified gaps
- Debugging Context: All builds passed with 0...
Technical Foundation:
C:\repos\runtime4\src\coreclr\jit\.\build.cmd clr.jit -c debugfor JIT-only builds (~12-20s incremental)CleanupGenTreeCompare(created frommain)Codebase Status:
src/coreclr/jit/gentree.cpp:GenTree::Compare(structural tree equality) andgtHashValueGetIconHandleFlag()andgtFieldSeqcomparison alongsidegtIconValgtNewHelperandgtAllocObjClsHndchecksgtArrElemSizecomparison, removed TODO commentgtCond,gtOp1,gtOp2gtElemType,gtLenOffset,gtElemOffsetin addition togtElemSizegtFptrMethodgtPredBB, and SSA numbergtCondition.GetCode()gtSrcReg#ifdef TARGET_ARM64)gtFlagsValcomparison (under#if defined(TARGET_ARM64) || defined(TARGET_AMD64))Problem Resolution:
Created from Copilot CLI via the copilot delegate command.
💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.