[wasm] Bump chrome for testing - linux: 119.0.6045.105, windows: 119.0.6045.105 by github-actions[bot] · Pull Request #3 · AndyAyersMS/runtime

github-actions · 2023-11-05T00:11:07Z

No description provided.

…#102133) This generalizes the indir reordering optimization (that currently only triggers for loads) to kick in for GT_STOREIND nodes. The main complication with doing this is the fact that the data node of the second indirection needs its own reordering with the previous indirection. The existing logic works by reordering all nodes between the first and second indirection that are unrelated to the second indirection's computation to happen after it. Once that is done we know that there are no uses of the first indirection's result between it and the second indirection, so after doing the necessary interference checks we can safely move the previous indirection to happen after the data node of the second indirection. Example: ```csharp class Body { public double x, y, z, vx, vy, vz, mass; } static void Advance(double dt, Body[] bodies) { foreach (Body b in bodies) { b.x += dt * b.vx; b.y += dt * b.vy; b.z += dt * b.vz; } } ``` Diff: ```diff @@ -1,18 +1,17 @@ -G_M55007_IG04: ;; offset=0x001C +G_M55007_IG04: ;; offset=0x0020 ldr x3, [x0, w1, UXTW #3] ldp d16, d17, [x3, #0x08] ldp d18, d19, [x3, #0x20] fmul d18, d0, d18 fadd d16, d16, d18 - str d16, [x3, #0x08] - fmul d16, d0, d19 - fadd d16, d17, d16 - str d16, [x3, #0x10] + fmul d18, d0, d19 + fadd d17, d17, d18 + stp d16, d17, [x3, #0x08] ldr d16, [x3, #0x18] ldr d17, [x3, #0x30] fmul d17, d0, d17 fadd d16, d16, d17 str d16, [x3, #0x18] add w1, w1, #1 cmp w2, w1 bgt G_M55007_IG04 ```

* bug #1: don't allow for values out of the SerializationRecordType enum range * bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type * bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use) * bug #4: document the fact that IOException can be thrown * bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails * bug #6: 0 and 17 are illegal values for PrimitiveType enum * bug #7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)

Currently, offsets are incorrectly treated as indices which is leading to incorrect code being emitted. e.g., `ScatterWithByteOffsets<long>` emits `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D, lsl #3]` instead of, `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D]`

…128163) > [!NOTE] > This PR was authored with assistance from GitHub Copilot. Fixesdotnet#128044. ## Problem createdump SIGSEGVs on Linux when generating a Heap-type minidump for a process running interpreted code. The crash reproduces locally with the `InterpreterStack` DumpTests debuggee and matches the CI failure that prompted `<DumpTypes>Full</DumpTypes>` to be added as a temporary workaround. The faulting backtrace is: ``` #0 Thread::IsAddressInStack threads.cpp:6741 #1 Thread::EnumMemoryRegionsWorker threads.cpp:6909 (calls IsAddressInStack(currentSP)) #2 Thread::EnumMemoryRegions threads.cpp #3 ThreadStore::EnumMemoryRegions #4 ClrDataAccess::EnumMemDumpAllThreadsStack #5 ClrDataAccess::EnumMemoryRegionsWorkerHeap (HEAP2-only path) ``` ## Root cause `Thread::m_pInterpThreadContext` was declared as a raw `InterpThreadContext *`. In non-DAC code that's a normal host pointer, but in DAC mode the field's value is a target-process address. When `IsAddressInStack` (a DAC-callable helper) dereferenced `m_pInterpThreadContext->pStackStart` it read from a target-process address as if it were a host address, which faults inside createdump. ## Fix Change the field type to `PTR_InterpThreadContext` (DPTR), matching the treatment of other Thread fields like `m_pFrame`. In non-DAC builds `DPTR(T)` is just `T*`, so there is no overhead or behavior change. In DAC builds the read goes through `__DPtr<T>` and marshals correctly from the target. Also remove the `<DumpTypes>Full</DumpTypes>` workaround on the `InterpreterStack` DumpTests debuggee so the Heap path that originally failed is exercised again. ## Validation Locally reproduced the original SIGSEGV on Linux x64 with the auto-dump mechanism (`DOTNET_DbgMiniDumpType=2` + `DOTNET_Interpreter=MethodA`) running the `InterpreterStack` debuggee. With this fix applied, createdump produces a complete Heap dump (~74 MB) instead of crashing. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

In Compiler::optNarrowTree, the GT_CAST case bails when `tree->CastToType() != srct`. For unsigned widening casts produced by the C# compiler (e.g. an implicit uint->long widening synthesized when unary minus promotes uint to long), CastToType is TYP_ULONG even though tree->TypeGet() is TYP_LONG. The strict comparison rejects narrowing, even though both representations are bit-identical and the subsequent transformation (rewriting an int<->long cast as an int<->int identity) is correct for either signedness. The user-visible effect was that patterns like (uint)-(a >> 20) (uint)-(a << 2) (uint)~(ulong)(a >> 3) failed to fold the redundant widening cast left over after morph pushes the outer narrowing cast through GT_NEG/GT_NOT. The leftover cast serialized as a no-op `mov w0, w0` between the shift and the negate, preventing arm64 lowering from containing the shift into the negate: lsr w0, w0, dotnet#20 ; was 3 instructions mov w0, w0 neg w0, w0 Compare with the equivalent NegLSL pattern (no intermediate cast), which already produces `neg w0, w0, LSL #2`. Switching the comparison to `genActualType(CastToType()) != genActualType(srct)` lets ULONG-as-cast-target match LONG-as-srct, so the inner cast is narrowed away, lowering sees a direct NEG/MVN over the shift, and codegen emits the single-instruction shifted form: neg w0, w0, LSR dotnet#20 neg w0, w0, LSL #2 mvn w0, w0, LSR #3 The companion `tree->TypeIs(TYP_LONG)` check is also replaced with `genActualType(tree) == TYP_LONG` for consistency; the two are functionally equivalent for well-formed IR (cast nodes' TypeGet always returns the actual type, never the unsigned variant). Fixesdotnet#111888 Test updates in src/tests/JIT/opt/InstructionCombining/: - Cmn.cs CmnLSR, Neg.cs NegLSR: documented the old `lsr+cmn`/`lsr+neg` buggy codegen as expected, updated to expect the single-instruction shifted form. - Casts.cs CastUIntULongUInt: documented `mov w0, w0` (a no-op cast round trip) as expected; the fix eliminates the cast entirely so the method body has no instructions. Changed to ARM64-NOT: mov to assert absence of the redundant move. - Mvn.cs: added MvnCastChainLSR covering the cast-chain bug for MVN. Co-authored-by: Andy Ayers <andya@microsoft.com>

…dotnet#131279) [wasm] Restrict enclosing-try throw-helper attach to the same funclet ## Problem crossgen2 emits an invalid WASM (wasm32) R2R module for methods with certain try/catch shapes: the terminal `end` opcode (0x0b) is dropped for an EH funclet, so `wasm-tools validate` (and V8) reject the module with *"function body must end with end opcode"*. A related symptom is a miscomputed branch target depth in the same funclet (tracked as dotnet#131252). ## Root cause The defect is in wasm block layout, in `FgWasm::VisitWasmSuccs` (`src/coreclr/jit/fgwasm.h`). dotnet#130945 added an "enclosing try" relaxation: when a block is a try side-entry and the throw-helper ACD key is `KD_TRY`, the helper is also attached as a successor if ```cpp comp->bbInTryRegions(key.RegionIndex(), block) ``` is true. `bbInTryRegions` is a purely **lexical** try-nesting test — it does not check that the throw helper and the side-entry live in the same **function region (funclet)**. So a throw helper for an outer try region that belongs to the **main method** can be attached to a catch-resumption side-entry (`BBF_CATCH_RESUMPTION`) that merely nests inside that try but physically lives in a **handler funclet**. RPO layout then lays the main-method helper *inside* the funclet, interleaving it with funclet blocks. Because a funclet is a distinct wasm function body, that interleaving drops the funclet's terminal `end` and corrupts its branch target depths. Concrete trace from `System.Data.DataColumn:set_Expression` (instrumented `VisitWasmSuccs`, deduped): ``` sideEntry BB50 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=2] pulls dst BB76 (hndIdx=0) crossFunclet=1 sideEntry BB73 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=0] pulls dst BB76 (hndIdx=0) crossFunclet=1 ``` BB76 is the throw helper for root try region #4 (`KD_TRY`, no handler index → main method); BB50/BB73 are catch-resumption side-entries in handler funclet #3 (which lexically nests in try #4), so the enclosing-try rule pulls the main-method helper into funclet #3. This is an ordinary catch-resumption EH shape (`async=0`); it is independent of runtime-async, and `fgwasm.h` is byte-identical to `main`. It is latent on `main` only because R2R-wasm codegen isn't enabled there yet. ## Fix Gate the enclosing-try relaxation on same-function-region ownership. A new `funcRegionOf` lambda returns the funclet index that physically contains an arbitrary block (0 == main method); it mirrors `funGetFuncIdx` but works for non-entry blocks and distinguishes a filter funclet from its filter-handler. The helper is attached only when it shares the side-entry's function region: ```cpp if (!viaEnclosingTry || (funcRegionOf(block) == funcRegionOf(acd->acdDstBlk))) { RETURN_ON_ABORT(func(acd->acdDstBlk)); } ``` The exact-match path (a helper keyed to the block's own region) is unchanged, and dotnet#130945's intended case (an inner-try side-entry pulling its enclosing try's helper *within the same funclet*) still matches — so this only removes the cross-funclet edge. ## Validation Standalone `System.Data.Common` R2R wasm crossgen, release JIT, `wasm-tools validate` (only `fgwasm.h` differs between runs): | | `wasm-tools validate` | |---|---| | baseline (`origin/main` layout) | `func 597 failed to validate` ❌ | | with this fix | passes ✅ | ## Notes - Supersedes dotnet#131251, which hardened the terminal-`end` emission (the *effect*); this fixes the *cause* in layout. Closing dotnet#131251 in favor of this. - Related: dotnet#129335 (incomplete predecessor for this defect class, do not reopen); dotnet#130945 (introduced the lexical enclosing-try match); dotnet#131252 (miscomputed branch target depth — same corrupted layout, very likely subsumed by this fix). - Follow-up idea (not in this PR): a JIT-time assert that a funclet's blocks form a contiguous RPO range, so any future mis-layout traps at compile time instead of surfacing as an invalid module. > [!NOTE] > This change was authored with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9

github-actions · 2023-11-05T00:11:07Z

No description provided.

…#102133) This generalizes the indir reordering optimization (that currently only triggers for loads) to kick in for GT_STOREIND nodes. The main complication with doing this is the fact that the data node of the second indirection needs its own reordering with the previous indirection. The existing logic works by reordering all nodes between the first and second indirection that are unrelated to the second indirection's computation to happen after it. Once that is done we know that there are no uses of the first indirection's result between it and the second indirection, so after doing the necessary interference checks we can safely move the previous indirection to happen after the data node of the second indirection. Example: ```csharp class Body { public double x, y, z, vx, vy, vz, mass; } static void Advance(double dt, Body[] bodies) { foreach (Body b in bodies) { b.x += dt * b.vx; b.y += dt * b.vy; b.z += dt * b.vz; } } ``` Diff: ```diff @@ -1,18 +1,17 @@ -G_M55007_IG04: ;; offset=0x001C +G_M55007_IG04: ;; offset=0x0020 ldr x3, [x0, w1, UXTW #3] ldp d16, d17, [x3, #0x08] ldp d18, d19, [x3, #0x20] fmul d18, d0, d18 fadd d16, d16, d18 - str d16, [x3, #0x08] - fmul d16, d0, d19 - fadd d16, d17, d16 - str d16, [x3, #0x10] + fmul d18, d0, d19 + fadd d17, d17, d18 + stp d16, d17, [x3, #0x08] ldr d16, [x3, #0x18] ldr d17, [x3, #0x30] fmul d17, d0, d17 fadd d16, d16, d17 str d16, [x3, #0x18] add w1, w1, #1 cmp w2, w1 bgt G_M55007_IG04 ```

* bug #1: don't allow for values out of the SerializationRecordType enum range * bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type * bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use) * bug #4: document the fact that IOException can be thrown * bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails * bug #6: 0 and 17 are illegal values for PrimitiveType enum * bug #7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)

Currently, offsets are incorrectly treated as indices which is leading to incorrect code being emitted. e.g., `ScatterWithByteOffsets<long>` emits `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D, lsl #3]` instead of, `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D]`

…128163) > [!NOTE] > This PR was authored with assistance from GitHub Copilot. Fixesdotnet#128044. ## Problem createdump SIGSEGVs on Linux when generating a Heap-type minidump for a process running interpreted code. The crash reproduces locally with the `InterpreterStack` DumpTests debuggee and matches the CI failure that prompted `<DumpTypes>Full</DumpTypes>` to be added as a temporary workaround. The faulting backtrace is: ``` #0 Thread::IsAddressInStack threads.cpp:6741 #1 Thread::EnumMemoryRegionsWorker threads.cpp:6909 (calls IsAddressInStack(currentSP)) #2 Thread::EnumMemoryRegions threads.cpp #3 ThreadStore::EnumMemoryRegions #4 ClrDataAccess::EnumMemDumpAllThreadsStack #5 ClrDataAccess::EnumMemoryRegionsWorkerHeap (HEAP2-only path) ``` ## Root cause `Thread::m_pInterpThreadContext` was declared as a raw `InterpThreadContext *`. In non-DAC code that's a normal host pointer, but in DAC mode the field's value is a target-process address. When `IsAddressInStack` (a DAC-callable helper) dereferenced `m_pInterpThreadContext->pStackStart` it read from a target-process address as if it were a host address, which faults inside createdump. ## Fix Change the field type to `PTR_InterpThreadContext` (DPTR), matching the treatment of other Thread fields like `m_pFrame`. In non-DAC builds `DPTR(T)` is just `T*`, so there is no overhead or behavior change. In DAC builds the read goes through `__DPtr<T>` and marshals correctly from the target. Also remove the `<DumpTypes>Full</DumpTypes>` workaround on the `InterpreterStack` DumpTests debuggee so the Heap path that originally failed is exercised again. ## Validation Locally reproduced the original SIGSEGV on Linux x64 with the auto-dump mechanism (`DOTNET_DbgMiniDumpType=2` + `DOTNET_Interpreter=MethodA`) running the `InterpreterStack` debuggee. With this fix applied, createdump produces a complete Heap dump (~74 MB) instead of crashing. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

In Compiler::optNarrowTree, the GT_CAST case bails when `tree->CastToType() != srct`. For unsigned widening casts produced by the C# compiler (e.g. an implicit uint->long widening synthesized when unary minus promotes uint to long), CastToType is TYP_ULONG even though tree->TypeGet() is TYP_LONG. The strict comparison rejects narrowing, even though both representations are bit-identical and the subsequent transformation (rewriting an int<->long cast as an int<->int identity) is correct for either signedness. The user-visible effect was that patterns like (uint)-(a >> 20) (uint)-(a << 2) (uint)~(ulong)(a >> 3) failed to fold the redundant widening cast left over after morph pushes the outer narrowing cast through GT_NEG/GT_NOT. The leftover cast serialized as a no-op `mov w0, w0` between the shift and the negate, preventing arm64 lowering from containing the shift into the negate: lsr w0, w0, dotnet#20 ; was 3 instructions mov w0, w0 neg w0, w0 Compare with the equivalent NegLSL pattern (no intermediate cast), which already produces `neg w0, w0, LSL #2`. Switching the comparison to `genActualType(CastToType()) != genActualType(srct)` lets ULONG-as-cast-target match LONG-as-srct, so the inner cast is narrowed away, lowering sees a direct NEG/MVN over the shift, and codegen emits the single-instruction shifted form: neg w0, w0, LSR dotnet#20 neg w0, w0, LSL #2 mvn w0, w0, LSR #3 The companion `tree->TypeIs(TYP_LONG)` check is also replaced with `genActualType(tree) == TYP_LONG` for consistency; the two are functionally equivalent for well-formed IR (cast nodes' TypeGet always returns the actual type, never the unsigned variant). Fixesdotnet#111888 Test updates in src/tests/JIT/opt/InstructionCombining/: - Cmn.cs CmnLSR, Neg.cs NegLSR: documented the old `lsr+cmn`/`lsr+neg` buggy codegen as expected, updated to expect the single-instruction shifted form. - Casts.cs CastUIntULongUInt: documented `mov w0, w0` (a no-op cast round trip) as expected; the fix eliminates the cast entirely so the method body has no instructions. Changed to ARM64-NOT: mov to assert absence of the redundant move. - Mvn.cs: added MvnCastChainLSR covering the cast-chain bug for MVN. Co-authored-by: Andy Ayers <andya@microsoft.com>

…dotnet#131279) [wasm] Restrict enclosing-try throw-helper attach to the same funclet ## Problem crossgen2 emits an invalid WASM (wasm32) R2R module for methods with certain try/catch shapes: the terminal `end` opcode (0x0b) is dropped for an EH funclet, so `wasm-tools validate` (and V8) reject the module with *"function body must end with end opcode"*. A related symptom is a miscomputed branch target depth in the same funclet (tracked as dotnet#131252). ## Root cause The defect is in wasm block layout, in `FgWasm::VisitWasmSuccs` (`src/coreclr/jit/fgwasm.h`). dotnet#130945 added an "enclosing try" relaxation: when a block is a try side-entry and the throw-helper ACD key is `KD_TRY`, the helper is also attached as a successor if ```cpp comp->bbInTryRegions(key.RegionIndex(), block) ``` is true. `bbInTryRegions` is a purely **lexical** try-nesting test — it does not check that the throw helper and the side-entry live in the same **function region (funclet)**. So a throw helper for an outer try region that belongs to the **main method** can be attached to a catch-resumption side-entry (`BBF_CATCH_RESUMPTION`) that merely nests inside that try but physically lives in a **handler funclet**. RPO layout then lays the main-method helper *inside* the funclet, interleaving it with funclet blocks. Because a funclet is a distinct wasm function body, that interleaving drops the funclet's terminal `end` and corrupts its branch target depths. Concrete trace from `System.Data.DataColumn:set_Expression` (instrumented `VisitWasmSuccs`, deduped): ``` sideEntry BB50 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=2] pulls dst BB76 (hndIdx=0) crossFunclet=1 sideEntry BB73 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=0] pulls dst BB76 (hndIdx=0) crossFunclet=1 ``` BB76 is the throw helper for root try region #4 (`KD_TRY`, no handler index → main method); BB50/BB73 are catch-resumption side-entries in handler funclet #3 (which lexically nests in try #4), so the enclosing-try rule pulls the main-method helper into funclet #3. This is an ordinary catch-resumption EH shape (`async=0`); it is independent of runtime-async, and `fgwasm.h` is byte-identical to `main`. It is latent on `main` only because R2R-wasm codegen isn't enabled there yet. ## Fix Gate the enclosing-try relaxation on same-function-region ownership. A new `funcRegionOf` lambda returns the funclet index that physically contains an arbitrary block (0 == main method); it mirrors `funGetFuncIdx` but works for non-entry blocks and distinguishes a filter funclet from its filter-handler. The helper is attached only when it shares the side-entry's function region: ```cpp if (!viaEnclosingTry || (funcRegionOf(block) == funcRegionOf(acd->acdDstBlk))) { RETURN_ON_ABORT(func(acd->acdDstBlk)); } ``` The exact-match path (a helper keyed to the block's own region) is unchanged, and dotnet#130945's intended case (an inner-try side-entry pulling its enclosing try's helper *within the same funclet*) still matches — so this only removes the cross-funclet edge. ## Validation Standalone `System.Data.Common` R2R wasm crossgen, release JIT, `wasm-tools validate` (only `fgwasm.h` differs between runs): | | `wasm-tools validate` | |---|---| | baseline (`origin/main` layout) | `func 597 failed to validate` ❌ | | with this fix | passes ✅ | ## Notes - Supersedes dotnet#131251, which hardened the terminal-`end` emission (the *effect*); this fixes the *cause* in layout. Closing dotnet#131251 in favor of this. - Related: dotnet#129335 (incomplete predecessor for this defect class, do not reopen); dotnet#130945 (introduced the lexical enclosing-try match); dotnet#131252 (miscomputed branch target depth — same corrupted layout, very likely subsumed by this fix). - Follow-up idea (not in this PR): a JIT-time assert that a funclet's blocks form a contiguous RPO range, so any future mis-layout traps at compile time instead of surfacing as an invalid module. > [!NOTE] > This change was authored with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9

github-actions · 2023-11-05T00:11:07Z

No description provided.

…#102133) This generalizes the indir reordering optimization (that currently only triggers for loads) to kick in for GT_STOREIND nodes. The main complication with doing this is the fact that the data node of the second indirection needs its own reordering with the previous indirection. The existing logic works by reordering all nodes between the first and second indirection that are unrelated to the second indirection's computation to happen after it. Once that is done we know that there are no uses of the first indirection's result between it and the second indirection, so after doing the necessary interference checks we can safely move the previous indirection to happen after the data node of the second indirection. Example: ```csharp class Body { public double x, y, z, vx, vy, vz, mass; } static void Advance(double dt, Body[] bodies) { foreach (Body b in bodies) { b.x += dt * b.vx; b.y += dt * b.vy; b.z += dt * b.vz; } } ``` Diff: ```diff @@ -1,18 +1,17 @@ -G_M55007_IG04: ;; offset=0x001C +G_M55007_IG04: ;; offset=0x0020 ldr x3, [x0, w1, UXTW #3] ldp d16, d17, [x3, #0x08] ldp d18, d19, [x3, #0x20] fmul d18, d0, d18 fadd d16, d16, d18 - str d16, [x3, #0x08] - fmul d16, d0, d19 - fadd d16, d17, d16 - str d16, [x3, #0x10] + fmul d18, d0, d19 + fadd d17, d17, d18 + stp d16, d17, [x3, #0x08] ldr d16, [x3, #0x18] ldr d17, [x3, #0x30] fmul d17, d0, d17 fadd d16, d16, d17 str d16, [x3, #0x18] add w1, w1, #1 cmp w2, w1 bgt G_M55007_IG04 ```

* bug #1: don't allow for values out of the SerializationRecordType enum range * bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type * bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use) * bug #4: document the fact that IOException can be thrown * bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails * bug #6: 0 and 17 are illegal values for PrimitiveType enum * bug #7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)

Currently, offsets are incorrectly treated as indices which is leading to incorrect code being emitted. e.g., `ScatterWithByteOffsets<long>` emits `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D, lsl #3]` instead of, `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D]`

…128163) > [!NOTE] > This PR was authored with assistance from GitHub Copilot. Fixesdotnet#128044. ## Problem createdump SIGSEGVs on Linux when generating a Heap-type minidump for a process running interpreted code. The crash reproduces locally with the `InterpreterStack` DumpTests debuggee and matches the CI failure that prompted `<DumpTypes>Full</DumpTypes>` to be added as a temporary workaround. The faulting backtrace is: ``` #0 Thread::IsAddressInStack threads.cpp:6741 #1 Thread::EnumMemoryRegionsWorker threads.cpp:6909 (calls IsAddressInStack(currentSP)) #2 Thread::EnumMemoryRegions threads.cpp #3 ThreadStore::EnumMemoryRegions #4 ClrDataAccess::EnumMemDumpAllThreadsStack #5 ClrDataAccess::EnumMemoryRegionsWorkerHeap (HEAP2-only path) ``` ## Root cause `Thread::m_pInterpThreadContext` was declared as a raw `InterpThreadContext *`. In non-DAC code that's a normal host pointer, but in DAC mode the field's value is a target-process address. When `IsAddressInStack` (a DAC-callable helper) dereferenced `m_pInterpThreadContext->pStackStart` it read from a target-process address as if it were a host address, which faults inside createdump. ## Fix Change the field type to `PTR_InterpThreadContext` (DPTR), matching the treatment of other Thread fields like `m_pFrame`. In non-DAC builds `DPTR(T)` is just `T*`, so there is no overhead or behavior change. In DAC builds the read goes through `__DPtr<T>` and marshals correctly from the target. Also remove the `<DumpTypes>Full</DumpTypes>` workaround on the `InterpreterStack` DumpTests debuggee so the Heap path that originally failed is exercised again. ## Validation Locally reproduced the original SIGSEGV on Linux x64 with the auto-dump mechanism (`DOTNET_DbgMiniDumpType=2` + `DOTNET_Interpreter=MethodA`) running the `InterpreterStack` debuggee. With this fix applied, createdump produces a complete Heap dump (~74 MB) instead of crashing. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

In Compiler::optNarrowTree, the GT_CAST case bails when `tree->CastToType() != srct`. For unsigned widening casts produced by the C# compiler (e.g. an implicit uint->long widening synthesized when unary minus promotes uint to long), CastToType is TYP_ULONG even though tree->TypeGet() is TYP_LONG. The strict comparison rejects narrowing, even though both representations are bit-identical and the subsequent transformation (rewriting an int<->long cast as an int<->int identity) is correct for either signedness. The user-visible effect was that patterns like (uint)-(a >> 20) (uint)-(a << 2) (uint)~(ulong)(a >> 3) failed to fold the redundant widening cast left over after morph pushes the outer narrowing cast through GT_NEG/GT_NOT. The leftover cast serialized as a no-op `mov w0, w0` between the shift and the negate, preventing arm64 lowering from containing the shift into the negate: lsr w0, w0, dotnet#20 ; was 3 instructions mov w0, w0 neg w0, w0 Compare with the equivalent NegLSL pattern (no intermediate cast), which already produces `neg w0, w0, LSL #2`. Switching the comparison to `genActualType(CastToType()) != genActualType(srct)` lets ULONG-as-cast-target match LONG-as-srct, so the inner cast is narrowed away, lowering sees a direct NEG/MVN over the shift, and codegen emits the single-instruction shifted form: neg w0, w0, LSR dotnet#20 neg w0, w0, LSL #2 mvn w0, w0, LSR #3 The companion `tree->TypeIs(TYP_LONG)` check is also replaced with `genActualType(tree) == TYP_LONG` for consistency; the two are functionally equivalent for well-formed IR (cast nodes' TypeGet always returns the actual type, never the unsigned variant). Fixesdotnet#111888 Test updates in src/tests/JIT/opt/InstructionCombining/: - Cmn.cs CmnLSR, Neg.cs NegLSR: documented the old `lsr+cmn`/`lsr+neg` buggy codegen as expected, updated to expect the single-instruction shifted form. - Casts.cs CastUIntULongUInt: documented `mov w0, w0` (a no-op cast round trip) as expected; the fix eliminates the cast entirely so the method body has no instructions. Changed to ARM64-NOT: mov to assert absence of the redundant move. - Mvn.cs: added MvnCastChainLSR covering the cast-chain bug for MVN. Co-authored-by: Andy Ayers <andya@microsoft.com>

…dotnet#131279) [wasm] Restrict enclosing-try throw-helper attach to the same funclet ## Problem crossgen2 emits an invalid WASM (wasm32) R2R module for methods with certain try/catch shapes: the terminal `end` opcode (0x0b) is dropped for an EH funclet, so `wasm-tools validate` (and V8) reject the module with *"function body must end with end opcode"*. A related symptom is a miscomputed branch target depth in the same funclet (tracked as dotnet#131252). ## Root cause The defect is in wasm block layout, in `FgWasm::VisitWasmSuccs` (`src/coreclr/jit/fgwasm.h`). dotnet#130945 added an "enclosing try" relaxation: when a block is a try side-entry and the throw-helper ACD key is `KD_TRY`, the helper is also attached as a successor if ```cpp comp->bbInTryRegions(key.RegionIndex(), block) ``` is true. `bbInTryRegions` is a purely **lexical** try-nesting test — it does not check that the throw helper and the side-entry live in the same **function region (funclet)**. So a throw helper for an outer try region that belongs to the **main method** can be attached to a catch-resumption side-entry (`BBF_CATCH_RESUMPTION`) that merely nests inside that try but physically lives in a **handler funclet**. RPO layout then lays the main-method helper *inside* the funclet, interleaving it with funclet blocks. Because a funclet is a distinct wasm function body, that interleaving drops the funclet's terminal `end` and corrupts its branch target depths. Concrete trace from `System.Data.DataColumn:set_Expression` (instrumented `VisitWasmSuccs`, deduped): ``` sideEntry BB50 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=2] pulls dst BB76 (hndIdx=0) crossFunclet=1 sideEntry BB73 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=0] pulls dst BB76 (hndIdx=0) crossFunclet=1 ``` BB76 is the throw helper for root try region #4 (`KD_TRY`, no handler index → main method); BB50/BB73 are catch-resumption side-entries in handler funclet #3 (which lexically nests in try #4), so the enclosing-try rule pulls the main-method helper into funclet #3. This is an ordinary catch-resumption EH shape (`async=0`); it is independent of runtime-async, and `fgwasm.h` is byte-identical to `main`. It is latent on `main` only because R2R-wasm codegen isn't enabled there yet. ## Fix Gate the enclosing-try relaxation on same-function-region ownership. A new `funcRegionOf` lambda returns the funclet index that physically contains an arbitrary block (0 == main method); it mirrors `funGetFuncIdx` but works for non-entry blocks and distinguishes a filter funclet from its filter-handler. The helper is attached only when it shares the side-entry's function region: ```cpp if (!viaEnclosingTry || (funcRegionOf(block) == funcRegionOf(acd->acdDstBlk))) { RETURN_ON_ABORT(func(acd->acdDstBlk)); } ``` The exact-match path (a helper keyed to the block's own region) is unchanged, and dotnet#130945's intended case (an inner-try side-entry pulling its enclosing try's helper *within the same funclet*) still matches — so this only removes the cross-funclet edge. ## Validation Standalone `System.Data.Common` R2R wasm crossgen, release JIT, `wasm-tools validate` (only `fgwasm.h` differs between runs): | | `wasm-tools validate` | |---|---| | baseline (`origin/main` layout) | `func 597 failed to validate` ❌ | | with this fix | passes ✅ | ## Notes - Supersedes dotnet#131251, which hardened the terminal-`end` emission (the *effect*); this fixes the *cause* in layout. Closing dotnet#131251 in favor of this. - Related: dotnet#129335 (incomplete predecessor for this defect class, do not reopen); dotnet#130945 (introduced the lexical enclosing-try match); dotnet#131252 (miscomputed branch target depth — same corrupted layout, very likely subsumed by this fix). - Follow-up idea (not in this PR): a JIT-time assert that a funclet's blocks form a contiguous RPO range, so any future mis-layout traps at compile time instead of surfacing as an invalid module. > [!NOTE] > This change was authored with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9

github-actions · 2023-11-05T00:11:07Z

No description provided.

…#102133) This generalizes the indir reordering optimization (that currently only triggers for loads) to kick in for GT_STOREIND nodes. The main complication with doing this is the fact that the data node of the second indirection needs its own reordering with the previous indirection. The existing logic works by reordering all nodes between the first and second indirection that are unrelated to the second indirection's computation to happen after it. Once that is done we know that there are no uses of the first indirection's result between it and the second indirection, so after doing the necessary interference checks we can safely move the previous indirection to happen after the data node of the second indirection. Example: ```csharp class Body { public double x, y, z, vx, vy, vz, mass; } static void Advance(double dt, Body[] bodies) { foreach (Body b in bodies) { b.x += dt * b.vx; b.y += dt * b.vy; b.z += dt * b.vz; } } ``` Diff: ```diff @@ -1,18 +1,17 @@ -G_M55007_IG04: ;; offset=0x001C +G_M55007_IG04: ;; offset=0x0020 ldr x3, [x0, w1, UXTW #3] ldp d16, d17, [x3, #0x08] ldp d18, d19, [x3, #0x20] fmul d18, d0, d18 fadd d16, d16, d18 - str d16, [x3, #0x08] - fmul d16, d0, d19 - fadd d16, d17, d16 - str d16, [x3, #0x10] + fmul d18, d0, d19 + fadd d17, d17, d18 + stp d16, d17, [x3, #0x08] ldr d16, [x3, #0x18] ldr d17, [x3, #0x30] fmul d17, d0, d17 fadd d16, d16, d17 str d16, [x3, #0x18] add w1, w1, #1 cmp w2, w1 bgt G_M55007_IG04 ```

* bug #1: don't allow for values out of the SerializationRecordType enum range * bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type * bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use) * bug #4: document the fact that IOException can be thrown * bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails * bug #6: 0 and 17 are illegal values for PrimitiveType enum * bug #7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)

Currently, offsets are incorrectly treated as indices which is leading to incorrect code being emitted. e.g., `ScatterWithByteOffsets<long>` emits `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D, lsl #3]` instead of, `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D]`

…128163) > [!NOTE] > This PR was authored with assistance from GitHub Copilot. Fixesdotnet#128044. ## Problem createdump SIGSEGVs on Linux when generating a Heap-type minidump for a process running interpreted code. The crash reproduces locally with the `InterpreterStack` DumpTests debuggee and matches the CI failure that prompted `<DumpTypes>Full</DumpTypes>` to be added as a temporary workaround. The faulting backtrace is: ``` #0 Thread::IsAddressInStack threads.cpp:6741 #1 Thread::EnumMemoryRegionsWorker threads.cpp:6909 (calls IsAddressInStack(currentSP)) #2 Thread::EnumMemoryRegions threads.cpp #3 ThreadStore::EnumMemoryRegions #4 ClrDataAccess::EnumMemDumpAllThreadsStack #5 ClrDataAccess::EnumMemoryRegionsWorkerHeap (HEAP2-only path) ``` ## Root cause `Thread::m_pInterpThreadContext` was declared as a raw `InterpThreadContext *`. In non-DAC code that's a normal host pointer, but in DAC mode the field's value is a target-process address. When `IsAddressInStack` (a DAC-callable helper) dereferenced `m_pInterpThreadContext->pStackStart` it read from a target-process address as if it were a host address, which faults inside createdump. ## Fix Change the field type to `PTR_InterpThreadContext` (DPTR), matching the treatment of other Thread fields like `m_pFrame`. In non-DAC builds `DPTR(T)` is just `T*`, so there is no overhead or behavior change. In DAC builds the read goes through `__DPtr<T>` and marshals correctly from the target. Also remove the `<DumpTypes>Full</DumpTypes>` workaround on the `InterpreterStack` DumpTests debuggee so the Heap path that originally failed is exercised again. ## Validation Locally reproduced the original SIGSEGV on Linux x64 with the auto-dump mechanism (`DOTNET_DbgMiniDumpType=2` + `DOTNET_Interpreter=MethodA`) running the `InterpreterStack` debuggee. With this fix applied, createdump produces a complete Heap dump (~74 MB) instead of crashing. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

In Compiler::optNarrowTree, the GT_CAST case bails when `tree->CastToType() != srct`. For unsigned widening casts produced by the C# compiler (e.g. an implicit uint->long widening synthesized when unary minus promotes uint to long), CastToType is TYP_ULONG even though tree->TypeGet() is TYP_LONG. The strict comparison rejects narrowing, even though both representations are bit-identical and the subsequent transformation (rewriting an int<->long cast as an int<->int identity) is correct for either signedness. The user-visible effect was that patterns like (uint)-(a >> 20) (uint)-(a << 2) (uint)~(ulong)(a >> 3) failed to fold the redundant widening cast left over after morph pushes the outer narrowing cast through GT_NEG/GT_NOT. The leftover cast serialized as a no-op `mov w0, w0` between the shift and the negate, preventing arm64 lowering from containing the shift into the negate: lsr w0, w0, dotnet#20 ; was 3 instructions mov w0, w0 neg w0, w0 Compare with the equivalent NegLSL pattern (no intermediate cast), which already produces `neg w0, w0, LSL #2`. Switching the comparison to `genActualType(CastToType()) != genActualType(srct)` lets ULONG-as-cast-target match LONG-as-srct, so the inner cast is narrowed away, lowering sees a direct NEG/MVN over the shift, and codegen emits the single-instruction shifted form: neg w0, w0, LSR dotnet#20 neg w0, w0, LSL #2 mvn w0, w0, LSR #3 The companion `tree->TypeIs(TYP_LONG)` check is also replaced with `genActualType(tree) == TYP_LONG` for consistency; the two are functionally equivalent for well-formed IR (cast nodes' TypeGet always returns the actual type, never the unsigned variant). Fixesdotnet#111888 Test updates in src/tests/JIT/opt/InstructionCombining/: - Cmn.cs CmnLSR, Neg.cs NegLSR: documented the old `lsr+cmn`/`lsr+neg` buggy codegen as expected, updated to expect the single-instruction shifted form. - Casts.cs CastUIntULongUInt: documented `mov w0, w0` (a no-op cast round trip) as expected; the fix eliminates the cast entirely so the method body has no instructions. Changed to ARM64-NOT: mov to assert absence of the redundant move. - Mvn.cs: added MvnCastChainLSR covering the cast-chain bug for MVN. Co-authored-by: Andy Ayers <andya@microsoft.com>

…dotnet#131279) [wasm] Restrict enclosing-try throw-helper attach to the same funclet ## Problem crossgen2 emits an invalid WASM (wasm32) R2R module for methods with certain try/catch shapes: the terminal `end` opcode (0x0b) is dropped for an EH funclet, so `wasm-tools validate` (and V8) reject the module with *"function body must end with end opcode"*. A related symptom is a miscomputed branch target depth in the same funclet (tracked as dotnet#131252). ## Root cause The defect is in wasm block layout, in `FgWasm::VisitWasmSuccs` (`src/coreclr/jit/fgwasm.h`). dotnet#130945 added an "enclosing try" relaxation: when a block is a try side-entry and the throw-helper ACD key is `KD_TRY`, the helper is also attached as a successor if ```cpp comp->bbInTryRegions(key.RegionIndex(), block) ``` is true. `bbInTryRegions` is a purely **lexical** try-nesting test — it does not check that the throw helper and the side-entry live in the same **function region (funclet)**. So a throw helper for an outer try region that belongs to the **main method** can be attached to a catch-resumption side-entry (`BBF_CATCH_RESUMPTION`) that merely nests inside that try but physically lives in a **handler funclet**. RPO layout then lays the main-method helper *inside* the funclet, interleaving it with funclet blocks. Because a funclet is a distinct wasm function body, that interleaving drops the funclet's terminal `end` and corrupts its branch target depths. Concrete trace from `System.Data.DataColumn:set_Expression` (instrumented `VisitWasmSuccs`, deduped): ``` sideEntry BB50 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=2] pulls dst BB76 (hndIdx=0) crossFunclet=1 sideEntry BB73 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=0] pulls dst BB76 (hndIdx=0) crossFunclet=1 ``` BB76 is the throw helper for root try region #4 (`KD_TRY`, no handler index → main method); BB50/BB73 are catch-resumption side-entries in handler funclet #3 (which lexically nests in try #4), so the enclosing-try rule pulls the main-method helper into funclet #3. This is an ordinary catch-resumption EH shape (`async=0`); it is independent of runtime-async, and `fgwasm.h` is byte-identical to `main`. It is latent on `main` only because R2R-wasm codegen isn't enabled there yet. ## Fix Gate the enclosing-try relaxation on same-function-region ownership. A new `funcRegionOf` lambda returns the funclet index that physically contains an arbitrary block (0 == main method); it mirrors `funGetFuncIdx` but works for non-entry blocks and distinguishes a filter funclet from its filter-handler. The helper is attached only when it shares the side-entry's function region: ```cpp if (!viaEnclosingTry || (funcRegionOf(block) == funcRegionOf(acd->acdDstBlk))) { RETURN_ON_ABORT(func(acd->acdDstBlk)); } ``` The exact-match path (a helper keyed to the block's own region) is unchanged, and dotnet#130945's intended case (an inner-try side-entry pulling its enclosing try's helper *within the same funclet*) still matches — so this only removes the cross-funclet edge. ## Validation Standalone `System.Data.Common` R2R wasm crossgen, release JIT, `wasm-tools validate` (only `fgwasm.h` differs between runs): | | `wasm-tools validate` | |---|---| | baseline (`origin/main` layout) | `func 597 failed to validate` ❌ | | with this fix | passes ✅ | ## Notes - Supersedes dotnet#131251, which hardened the terminal-`end` emission (the *effect*); this fixes the *cause* in layout. Closing dotnet#131251 in favor of this. - Related: dotnet#129335 (incomplete predecessor for this defect class, do not reopen); dotnet#130945 (introduced the lexical enclosing-try match); dotnet#131252 (miscomputed branch target depth — same corrupted layout, very likely subsumed by this fix). - Follow-up idea (not in this PR): a JIT-time assert that a funclet's blocks form a contiguous RPO range, so any future mis-layout traps at compile time instead of surfacing as an invalid module. > [!NOTE] > This change was authored with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9

github-actions · 2023-11-05T00:11:07Z

No description provided.

…#102133) This generalizes the indir reordering optimization (that currently only triggers for loads) to kick in for GT_STOREIND nodes. The main complication with doing this is the fact that the data node of the second indirection needs its own reordering with the previous indirection. The existing logic works by reordering all nodes between the first and second indirection that are unrelated to the second indirection's computation to happen after it. Once that is done we know that there are no uses of the first indirection's result between it and the second indirection, so after doing the necessary interference checks we can safely move the previous indirection to happen after the data node of the second indirection. Example: ```csharp class Body { public double x, y, z, vx, vy, vz, mass; } static void Advance(double dt, Body[] bodies) { foreach (Body b in bodies) { b.x += dt * b.vx; b.y += dt * b.vy; b.z += dt * b.vz; } } ``` Diff: ```diff @@ -1,18 +1,17 @@ -G_M55007_IG04: ;; offset=0x001C +G_M55007_IG04: ;; offset=0x0020 ldr x3, [x0, w1, UXTW #3] ldp d16, d17, [x3, #0x08] ldp d18, d19, [x3, #0x20] fmul d18, d0, d18 fadd d16, d16, d18 - str d16, [x3, #0x08] - fmul d16, d0, d19 - fadd d16, d17, d16 - str d16, [x3, #0x10] + fmul d18, d0, d19 + fadd d17, d17, d18 + stp d16, d17, [x3, #0x08] ldr d16, [x3, #0x18] ldr d17, [x3, #0x30] fmul d17, d0, d17 fadd d16, d16, d17 str d16, [x3, #0x18] add w1, w1, #1 cmp w2, w1 bgt G_M55007_IG04 ```

* bug #1: don't allow for values out of the SerializationRecordType enum range * bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type * bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use) * bug #4: document the fact that IOException can be thrown * bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails * bug #6: 0 and 17 are illegal values for PrimitiveType enum * bug #7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)

Currently, offsets are incorrectly treated as indices which is leading to incorrect code being emitted. e.g., `ScatterWithByteOffsets<long>` emits `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D, lsl #3]` instead of, `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D]`

…128163) > [!NOTE] > This PR was authored with assistance from GitHub Copilot. Fixesdotnet#128044. ## Problem createdump SIGSEGVs on Linux when generating a Heap-type minidump for a process running interpreted code. The crash reproduces locally with the `InterpreterStack` DumpTests debuggee and matches the CI failure that prompted `<DumpTypes>Full</DumpTypes>` to be added as a temporary workaround. The faulting backtrace is: ``` #0 Thread::IsAddressInStack threads.cpp:6741 #1 Thread::EnumMemoryRegionsWorker threads.cpp:6909 (calls IsAddressInStack(currentSP)) #2 Thread::EnumMemoryRegions threads.cpp #3 ThreadStore::EnumMemoryRegions #4 ClrDataAccess::EnumMemDumpAllThreadsStack #5 ClrDataAccess::EnumMemoryRegionsWorkerHeap (HEAP2-only path) ``` ## Root cause `Thread::m_pInterpThreadContext` was declared as a raw `InterpThreadContext *`. In non-DAC code that's a normal host pointer, but in DAC mode the field's value is a target-process address. When `IsAddressInStack` (a DAC-callable helper) dereferenced `m_pInterpThreadContext->pStackStart` it read from a target-process address as if it were a host address, which faults inside createdump. ## Fix Change the field type to `PTR_InterpThreadContext` (DPTR), matching the treatment of other Thread fields like `m_pFrame`. In non-DAC builds `DPTR(T)` is just `T*`, so there is no overhead or behavior change. In DAC builds the read goes through `__DPtr<T>` and marshals correctly from the target. Also remove the `<DumpTypes>Full</DumpTypes>` workaround on the `InterpreterStack` DumpTests debuggee so the Heap path that originally failed is exercised again. ## Validation Locally reproduced the original SIGSEGV on Linux x64 with the auto-dump mechanism (`DOTNET_DbgMiniDumpType=2` + `DOTNET_Interpreter=MethodA`) running the `InterpreterStack` debuggee. With this fix applied, createdump produces a complete Heap dump (~74 MB) instead of crashing. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

In Compiler::optNarrowTree, the GT_CAST case bails when `tree->CastToType() != srct`. For unsigned widening casts produced by the C# compiler (e.g. an implicit uint->long widening synthesized when unary minus promotes uint to long), CastToType is TYP_ULONG even though tree->TypeGet() is TYP_LONG. The strict comparison rejects narrowing, even though both representations are bit-identical and the subsequent transformation (rewriting an int<->long cast as an int<->int identity) is correct for either signedness. The user-visible effect was that patterns like (uint)-(a >> 20) (uint)-(a << 2) (uint)~(ulong)(a >> 3) failed to fold the redundant widening cast left over after morph pushes the outer narrowing cast through GT_NEG/GT_NOT. The leftover cast serialized as a no-op `mov w0, w0` between the shift and the negate, preventing arm64 lowering from containing the shift into the negate: lsr w0, w0, dotnet#20 ; was 3 instructions mov w0, w0 neg w0, w0 Compare with the equivalent NegLSL pattern (no intermediate cast), which already produces `neg w0, w0, LSL #2`. Switching the comparison to `genActualType(CastToType()) != genActualType(srct)` lets ULONG-as-cast-target match LONG-as-srct, so the inner cast is narrowed away, lowering sees a direct NEG/MVN over the shift, and codegen emits the single-instruction shifted form: neg w0, w0, LSR dotnet#20 neg w0, w0, LSL #2 mvn w0, w0, LSR #3 The companion `tree->TypeIs(TYP_LONG)` check is also replaced with `genActualType(tree) == TYP_LONG` for consistency; the two are functionally equivalent for well-formed IR (cast nodes' TypeGet always returns the actual type, never the unsigned variant). Fixesdotnet#111888 Test updates in src/tests/JIT/opt/InstructionCombining/: - Cmn.cs CmnLSR, Neg.cs NegLSR: documented the old `lsr+cmn`/`lsr+neg` buggy codegen as expected, updated to expect the single-instruction shifted form. - Casts.cs CastUIntULongUInt: documented `mov w0, w0` (a no-op cast round trip) as expected; the fix eliminates the cast entirely so the method body has no instructions. Changed to ARM64-NOT: mov to assert absence of the redundant move. - Mvn.cs: added MvnCastChainLSR covering the cast-chain bug for MVN. Co-authored-by: Andy Ayers <andya@microsoft.com>

…dotnet#131279) [wasm] Restrict enclosing-try throw-helper attach to the same funclet ## Problem crossgen2 emits an invalid WASM (wasm32) R2R module for methods with certain try/catch shapes: the terminal `end` opcode (0x0b) is dropped for an EH funclet, so `wasm-tools validate` (and V8) reject the module with *"function body must end with end opcode"*. A related symptom is a miscomputed branch target depth in the same funclet (tracked as dotnet#131252). ## Root cause The defect is in wasm block layout, in `FgWasm::VisitWasmSuccs` (`src/coreclr/jit/fgwasm.h`). dotnet#130945 added an "enclosing try" relaxation: when a block is a try side-entry and the throw-helper ACD key is `KD_TRY`, the helper is also attached as a successor if ```cpp comp->bbInTryRegions(key.RegionIndex(), block) ``` is true. `bbInTryRegions` is a purely **lexical** try-nesting test — it does not check that the throw helper and the side-entry live in the same **function region (funclet)**. So a throw helper for an outer try region that belongs to the **main method** can be attached to a catch-resumption side-entry (`BBF_CATCH_RESUMPTION`) that merely nests inside that try but physically lives in a **handler funclet**. RPO layout then lays the main-method helper *inside* the funclet, interleaving it with funclet blocks. Because a funclet is a distinct wasm function body, that interleaving drops the funclet's terminal `end` and corrupts its branch target depths. Concrete trace from `System.Data.DataColumn:set_Expression` (instrumented `VisitWasmSuccs`, deduped): ``` sideEntry BB50 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=2] pulls dst BB76 (hndIdx=0) crossFunclet=1 sideEntry BB73 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=0] pulls dst BB76 (hndIdx=0) crossFunclet=1 ``` BB76 is the throw helper for root try region #4 (`KD_TRY`, no handler index → main method); BB50/BB73 are catch-resumption side-entries in handler funclet #3 (which lexically nests in try #4), so the enclosing-try rule pulls the main-method helper into funclet #3. This is an ordinary catch-resumption EH shape (`async=0`); it is independent of runtime-async, and `fgwasm.h` is byte-identical to `main`. It is latent on `main` only because R2R-wasm codegen isn't enabled there yet. ## Fix Gate the enclosing-try relaxation on same-function-region ownership. A new `funcRegionOf` lambda returns the funclet index that physically contains an arbitrary block (0 == main method); it mirrors `funGetFuncIdx` but works for non-entry blocks and distinguishes a filter funclet from its filter-handler. The helper is attached only when it shares the side-entry's function region: ```cpp if (!viaEnclosingTry || (funcRegionOf(block) == funcRegionOf(acd->acdDstBlk))) { RETURN_ON_ABORT(func(acd->acdDstBlk)); } ``` The exact-match path (a helper keyed to the block's own region) is unchanged, and dotnet#130945's intended case (an inner-try side-entry pulling its enclosing try's helper *within the same funclet*) still matches — so this only removes the cross-funclet edge. ## Validation Standalone `System.Data.Common` R2R wasm crossgen, release JIT, `wasm-tools validate` (only `fgwasm.h` differs between runs): | | `wasm-tools validate` | |---|---| | baseline (`origin/main` layout) | `func 597 failed to validate` ❌ | | with this fix | passes ✅ | ## Notes - Supersedes dotnet#131251, which hardened the terminal-`end` emission (the *effect*); this fixes the *cause* in layout. Closing dotnet#131251 in favor of this. - Related: dotnet#129335 (incomplete predecessor for this defect class, do not reopen); dotnet#130945 (introduced the lexical enclosing-try match); dotnet#131252 (miscomputed branch target depth — same corrupted layout, very likely subsumed by this fix). - Follow-up idea (not in this PR): a JIT-time assert that a funclet's blocks form a contiguous RPO range, so any future mis-layout traps at compile time instead of surfacing as an invalid module. > [!NOTE] > This change was authored with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9

github-actions · 2023-11-05T00:11:07Z

No description provided.

…#102133) This generalizes the indir reordering optimization (that currently only triggers for loads) to kick in for GT_STOREIND nodes. The main complication with doing this is the fact that the data node of the second indirection needs its own reordering with the previous indirection. The existing logic works by reordering all nodes between the first and second indirection that are unrelated to the second indirection's computation to happen after it. Once that is done we know that there are no uses of the first indirection's result between it and the second indirection, so after doing the necessary interference checks we can safely move the previous indirection to happen after the data node of the second indirection. Example: ```csharp class Body { public double x, y, z, vx, vy, vz, mass; } static void Advance(double dt, Body[] bodies) { foreach (Body b in bodies) { b.x += dt * b.vx; b.y += dt * b.vy; b.z += dt * b.vz; } } ``` Diff: ```diff @@ -1,18 +1,17 @@ -G_M55007_IG04: ;; offset=0x001C +G_M55007_IG04: ;; offset=0x0020 ldr x3, [x0, w1, UXTW #3] ldp d16, d17, [x3, #0x08] ldp d18, d19, [x3, #0x20] fmul d18, d0, d18 fadd d16, d16, d18 - str d16, [x3, #0x08] - fmul d16, d0, d19 - fadd d16, d17, d16 - str d16, [x3, #0x10] + fmul d18, d0, d19 + fadd d17, d17, d18 + stp d16, d17, [x3, #0x08] ldr d16, [x3, #0x18] ldr d17, [x3, #0x30] fmul d17, d0, d17 fadd d16, d16, d17 str d16, [x3, #0x18] add w1, w1, #1 cmp w2, w1 bgt G_M55007_IG04 ```

* bug #1: don't allow for values out of the SerializationRecordType enum range * bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type * bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use) * bug #4: document the fact that IOException can be thrown * bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails * bug #6: 0 and 17 are illegal values for PrimitiveType enum * bug #7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)

Currently, offsets are incorrectly treated as indices which is leading to incorrect code being emitted. e.g., `ScatterWithByteOffsets<long>` emits `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D, lsl #3]` instead of, `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D]`

…128163) > [!NOTE] > This PR was authored with assistance from GitHub Copilot. Fixesdotnet#128044. ## Problem createdump SIGSEGVs on Linux when generating a Heap-type minidump for a process running interpreted code. The crash reproduces locally with the `InterpreterStack` DumpTests debuggee and matches the CI failure that prompted `<DumpTypes>Full</DumpTypes>` to be added as a temporary workaround. The faulting backtrace is: ``` #0 Thread::IsAddressInStack threads.cpp:6741 #1 Thread::EnumMemoryRegionsWorker threads.cpp:6909 (calls IsAddressInStack(currentSP)) #2 Thread::EnumMemoryRegions threads.cpp #3 ThreadStore::EnumMemoryRegions #4 ClrDataAccess::EnumMemDumpAllThreadsStack #5 ClrDataAccess::EnumMemoryRegionsWorkerHeap (HEAP2-only path) ``` ## Root cause `Thread::m_pInterpThreadContext` was declared as a raw `InterpThreadContext *`. In non-DAC code that's a normal host pointer, but in DAC mode the field's value is a target-process address. When `IsAddressInStack` (a DAC-callable helper) dereferenced `m_pInterpThreadContext->pStackStart` it read from a target-process address as if it were a host address, which faults inside createdump. ## Fix Change the field type to `PTR_InterpThreadContext` (DPTR), matching the treatment of other Thread fields like `m_pFrame`. In non-DAC builds `DPTR(T)` is just `T*`, so there is no overhead or behavior change. In DAC builds the read goes through `__DPtr<T>` and marshals correctly from the target. Also remove the `<DumpTypes>Full</DumpTypes>` workaround on the `InterpreterStack` DumpTests debuggee so the Heap path that originally failed is exercised again. ## Validation Locally reproduced the original SIGSEGV on Linux x64 with the auto-dump mechanism (`DOTNET_DbgMiniDumpType=2` + `DOTNET_Interpreter=MethodA`) running the `InterpreterStack` debuggee. With this fix applied, createdump produces a complete Heap dump (~74 MB) instead of crashing. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

In Compiler::optNarrowTree, the GT_CAST case bails when `tree->CastToType() != srct`. For unsigned widening casts produced by the C# compiler (e.g. an implicit uint->long widening synthesized when unary minus promotes uint to long), CastToType is TYP_ULONG even though tree->TypeGet() is TYP_LONG. The strict comparison rejects narrowing, even though both representations are bit-identical and the subsequent transformation (rewriting an int<->long cast as an int<->int identity) is correct for either signedness. The user-visible effect was that patterns like (uint)-(a >> 20) (uint)-(a << 2) (uint)~(ulong)(a >> 3) failed to fold the redundant widening cast left over after morph pushes the outer narrowing cast through GT_NEG/GT_NOT. The leftover cast serialized as a no-op `mov w0, w0` between the shift and the negate, preventing arm64 lowering from containing the shift into the negate: lsr w0, w0, dotnet#20 ; was 3 instructions mov w0, w0 neg w0, w0 Compare with the equivalent NegLSL pattern (no intermediate cast), which already produces `neg w0, w0, LSL #2`. Switching the comparison to `genActualType(CastToType()) != genActualType(srct)` lets ULONG-as-cast-target match LONG-as-srct, so the inner cast is narrowed away, lowering sees a direct NEG/MVN over the shift, and codegen emits the single-instruction shifted form: neg w0, w0, LSR dotnet#20 neg w0, w0, LSL #2 mvn w0, w0, LSR #3 The companion `tree->TypeIs(TYP_LONG)` check is also replaced with `genActualType(tree) == TYP_LONG` for consistency; the two are functionally equivalent for well-formed IR (cast nodes' TypeGet always returns the actual type, never the unsigned variant). Fixesdotnet#111888 Test updates in src/tests/JIT/opt/InstructionCombining/: - Cmn.cs CmnLSR, Neg.cs NegLSR: documented the old `lsr+cmn`/`lsr+neg` buggy codegen as expected, updated to expect the single-instruction shifted form. - Casts.cs CastUIntULongUInt: documented `mov w0, w0` (a no-op cast round trip) as expected; the fix eliminates the cast entirely so the method body has no instructions. Changed to ARM64-NOT: mov to assert absence of the redundant move. - Mvn.cs: added MvnCastChainLSR covering the cast-chain bug for MVN. Co-authored-by: Andy Ayers <andya@microsoft.com>

…dotnet#131279) [wasm] Restrict enclosing-try throw-helper attach to the same funclet ## Problem crossgen2 emits an invalid WASM (wasm32) R2R module for methods with certain try/catch shapes: the terminal `end` opcode (0x0b) is dropped for an EH funclet, so `wasm-tools validate` (and V8) reject the module with *"function body must end with end opcode"*. A related symptom is a miscomputed branch target depth in the same funclet (tracked as dotnet#131252). ## Root cause The defect is in wasm block layout, in `FgWasm::VisitWasmSuccs` (`src/coreclr/jit/fgwasm.h`). dotnet#130945 added an "enclosing try" relaxation: when a block is a try side-entry and the throw-helper ACD key is `KD_TRY`, the helper is also attached as a successor if ```cpp comp->bbInTryRegions(key.RegionIndex(), block) ``` is true. `bbInTryRegions` is a purely **lexical** try-nesting test — it does not check that the throw helper and the side-entry live in the same **function region (funclet)**. So a throw helper for an outer try region that belongs to the **main method** can be attached to a catch-resumption side-entry (`BBF_CATCH_RESUMPTION`) that merely nests inside that try but physically lives in a **handler funclet**. RPO layout then lays the main-method helper *inside* the funclet, interleaving it with funclet blocks. Because a funclet is a distinct wasm function body, that interleaving drops the funclet's terminal `end` and corrupts its branch target depths. Concrete trace from `System.Data.DataColumn:set_Expression` (instrumented `VisitWasmSuccs`, deduped): ``` sideEntry BB50 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=2] pulls dst BB76 (hndIdx=0) crossFunclet=1 sideEntry BB73 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=0] pulls dst BB76 (hndIdx=0) crossFunclet=1 ``` BB76 is the throw helper for root try region #4 (`KD_TRY`, no handler index → main method); BB50/BB73 are catch-resumption side-entries in handler funclet #3 (which lexically nests in try #4), so the enclosing-try rule pulls the main-method helper into funclet #3. This is an ordinary catch-resumption EH shape (`async=0`); it is independent of runtime-async, and `fgwasm.h` is byte-identical to `main`. It is latent on `main` only because R2R-wasm codegen isn't enabled there yet. ## Fix Gate the enclosing-try relaxation on same-function-region ownership. A new `funcRegionOf` lambda returns the funclet index that physically contains an arbitrary block (0 == main method); it mirrors `funGetFuncIdx` but works for non-entry blocks and distinguishes a filter funclet from its filter-handler. The helper is attached only when it shares the side-entry's function region: ```cpp if (!viaEnclosingTry || (funcRegionOf(block) == funcRegionOf(acd->acdDstBlk))) { RETURN_ON_ABORT(func(acd->acdDstBlk)); } ``` The exact-match path (a helper keyed to the block's own region) is unchanged, and dotnet#130945's intended case (an inner-try side-entry pulling its enclosing try's helper *within the same funclet*) still matches — so this only removes the cross-funclet edge. ## Validation Standalone `System.Data.Common` R2R wasm crossgen, release JIT, `wasm-tools validate` (only `fgwasm.h` differs between runs): | | `wasm-tools validate` | |---|---| | baseline (`origin/main` layout) | `func 597 failed to validate` ❌ | | with this fix | passes ✅ | ## Notes - Supersedes dotnet#131251, which hardened the terminal-`end` emission (the *effect*); this fixes the *cause* in layout. Closing dotnet#131251 in favor of this. - Related: dotnet#129335 (incomplete predecessor for this defect class, do not reopen); dotnet#130945 (introduced the lexical enclosing-try match); dotnet#131252 (miscomputed branch target depth — same corrupted layout, very likely subsumed by this fix). - Follow-up idea (not in this PR): a JIT-time assert that a funclet's blocks form a contiguous RPO range, so any future mis-layout traps at compile time instead of surfacing as an invalid module. > [!NOTE] > This change was authored with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9

github-actions · 2023-11-05T00:11:07Z

No description provided.

…#102133) This generalizes the indir reordering optimization (that currently only triggers for loads) to kick in for GT_STOREIND nodes. The main complication with doing this is the fact that the data node of the second indirection needs its own reordering with the previous indirection. The existing logic works by reordering all nodes between the first and second indirection that are unrelated to the second indirection's computation to happen after it. Once that is done we know that there are no uses of the first indirection's result between it and the second indirection, so after doing the necessary interference checks we can safely move the previous indirection to happen after the data node of the second indirection. Example: ```csharp class Body { public double x, y, z, vx, vy, vz, mass; } static void Advance(double dt, Body[] bodies) { foreach (Body b in bodies) { b.x += dt * b.vx; b.y += dt * b.vy; b.z += dt * b.vz; } } ``` Diff: ```diff @@ -1,18 +1,17 @@ -G_M55007_IG04: ;; offset=0x001C +G_M55007_IG04: ;; offset=0x0020 ldr x3, [x0, w1, UXTW #3] ldp d16, d17, [x3, #0x08] ldp d18, d19, [x3, #0x20] fmul d18, d0, d18 fadd d16, d16, d18 - str d16, [x3, #0x08] - fmul d16, d0, d19 - fadd d16, d17, d16 - str d16, [x3, #0x10] + fmul d18, d0, d19 + fadd d17, d17, d18 + stp d16, d17, [x3, #0x08] ldr d16, [x3, #0x18] ldr d17, [x3, #0x30] fmul d17, d0, d17 fadd d16, d16, d17 str d16, [x3, #0x18] add w1, w1, #1 cmp w2, w1 bgt G_M55007_IG04 ```

* bug #1: don't allow for values out of the SerializationRecordType enum range * bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type * bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use) * bug #4: document the fact that IOException can be thrown * bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails * bug #6: 0 and 17 are illegal values for PrimitiveType enum * bug #7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)

Currently, offsets are incorrectly treated as indices which is leading to incorrect code being emitted. e.g., `ScatterWithByteOffsets<long>` emits `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D, lsl #3]` instead of, `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D]`

…128163) > [!NOTE] > This PR was authored with assistance from GitHub Copilot. Fixesdotnet#128044. ## Problem createdump SIGSEGVs on Linux when generating a Heap-type minidump for a process running interpreted code. The crash reproduces locally with the `InterpreterStack` DumpTests debuggee and matches the CI failure that prompted `<DumpTypes>Full</DumpTypes>` to be added as a temporary workaround. The faulting backtrace is: ``` #0 Thread::IsAddressInStack threads.cpp:6741 #1 Thread::EnumMemoryRegionsWorker threads.cpp:6909 (calls IsAddressInStack(currentSP)) #2 Thread::EnumMemoryRegions threads.cpp #3 ThreadStore::EnumMemoryRegions #4 ClrDataAccess::EnumMemDumpAllThreadsStack #5 ClrDataAccess::EnumMemoryRegionsWorkerHeap (HEAP2-only path) ``` ## Root cause `Thread::m_pInterpThreadContext` was declared as a raw `InterpThreadContext *`. In non-DAC code that's a normal host pointer, but in DAC mode the field's value is a target-process address. When `IsAddressInStack` (a DAC-callable helper) dereferenced `m_pInterpThreadContext->pStackStart` it read from a target-process address as if it were a host address, which faults inside createdump. ## Fix Change the field type to `PTR_InterpThreadContext` (DPTR), matching the treatment of other Thread fields like `m_pFrame`. In non-DAC builds `DPTR(T)` is just `T*`, so there is no overhead or behavior change. In DAC builds the read goes through `__DPtr<T>` and marshals correctly from the target. Also remove the `<DumpTypes>Full</DumpTypes>` workaround on the `InterpreterStack` DumpTests debuggee so the Heap path that originally failed is exercised again. ## Validation Locally reproduced the original SIGSEGV on Linux x64 with the auto-dump mechanism (`DOTNET_DbgMiniDumpType=2` + `DOTNET_Interpreter=MethodA`) running the `InterpreterStack` debuggee. With this fix applied, createdump produces a complete Heap dump (~74 MB) instead of crashing. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

In Compiler::optNarrowTree, the GT_CAST case bails when `tree->CastToType() != srct`. For unsigned widening casts produced by the C# compiler (e.g. an implicit uint->long widening synthesized when unary minus promotes uint to long), CastToType is TYP_ULONG even though tree->TypeGet() is TYP_LONG. The strict comparison rejects narrowing, even though both representations are bit-identical and the subsequent transformation (rewriting an int<->long cast as an int<->int identity) is correct for either signedness. The user-visible effect was that patterns like (uint)-(a >> 20) (uint)-(a << 2) (uint)~(ulong)(a >> 3) failed to fold the redundant widening cast left over after morph pushes the outer narrowing cast through GT_NEG/GT_NOT. The leftover cast serialized as a no-op `mov w0, w0` between the shift and the negate, preventing arm64 lowering from containing the shift into the negate: lsr w0, w0, dotnet#20 ; was 3 instructions mov w0, w0 neg w0, w0 Compare with the equivalent NegLSL pattern (no intermediate cast), which already produces `neg w0, w0, LSL #2`. Switching the comparison to `genActualType(CastToType()) != genActualType(srct)` lets ULONG-as-cast-target match LONG-as-srct, so the inner cast is narrowed away, lowering sees a direct NEG/MVN over the shift, and codegen emits the single-instruction shifted form: neg w0, w0, LSR dotnet#20 neg w0, w0, LSL #2 mvn w0, w0, LSR #3 The companion `tree->TypeIs(TYP_LONG)` check is also replaced with `genActualType(tree) == TYP_LONG` for consistency; the two are functionally equivalent for well-formed IR (cast nodes' TypeGet always returns the actual type, never the unsigned variant). Fixesdotnet#111888 Test updates in src/tests/JIT/opt/InstructionCombining/: - Cmn.cs CmnLSR, Neg.cs NegLSR: documented the old `lsr+cmn`/`lsr+neg` buggy codegen as expected, updated to expect the single-instruction shifted form. - Casts.cs CastUIntULongUInt: documented `mov w0, w0` (a no-op cast round trip) as expected; the fix eliminates the cast entirely so the method body has no instructions. Changed to ARM64-NOT: mov to assert absence of the redundant move. - Mvn.cs: added MvnCastChainLSR covering the cast-chain bug for MVN. Co-authored-by: Andy Ayers <andya@microsoft.com>

…dotnet#131279) [wasm] Restrict enclosing-try throw-helper attach to the same funclet ## Problem crossgen2 emits an invalid WASM (wasm32) R2R module for methods with certain try/catch shapes: the terminal `end` opcode (0x0b) is dropped for an EH funclet, so `wasm-tools validate` (and V8) reject the module with *"function body must end with end opcode"*. A related symptom is a miscomputed branch target depth in the same funclet (tracked as dotnet#131252). ## Root cause The defect is in wasm block layout, in `FgWasm::VisitWasmSuccs` (`src/coreclr/jit/fgwasm.h`). dotnet#130945 added an "enclosing try" relaxation: when a block is a try side-entry and the throw-helper ACD key is `KD_TRY`, the helper is also attached as a successor if ```cpp comp->bbInTryRegions(key.RegionIndex(), block) ``` is true. `bbInTryRegions` is a purely **lexical** try-nesting test — it does not check that the throw helper and the side-entry live in the same **function region (funclet)**. So a throw helper for an outer try region that belongs to the **main method** can be attached to a catch-resumption side-entry (`BBF_CATCH_RESUMPTION`) that merely nests inside that try but physically lives in a **handler funclet**. RPO layout then lays the main-method helper *inside* the funclet, interleaving it with funclet blocks. Because a funclet is a distinct wasm function body, that interleaving drops the funclet's terminal `end` and corrupts its branch target depths. Concrete trace from `System.Data.DataColumn:set_Expression` (instrumented `VisitWasmSuccs`, deduped): ``` sideEntry BB50 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=2] pulls dst BB76 (hndIdx=0) crossFunclet=1 sideEntry BB73 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=0] pulls dst BB76 (hndIdx=0) crossFunclet=1 ``` BB76 is the throw helper for root try region #4 (`KD_TRY`, no handler index → main method); BB50/BB73 are catch-resumption side-entries in handler funclet #3 (which lexically nests in try #4), so the enclosing-try rule pulls the main-method helper into funclet #3. This is an ordinary catch-resumption EH shape (`async=0`); it is independent of runtime-async, and `fgwasm.h` is byte-identical to `main`. It is latent on `main` only because R2R-wasm codegen isn't enabled there yet. ## Fix Gate the enclosing-try relaxation on same-function-region ownership. A new `funcRegionOf` lambda returns the funclet index that physically contains an arbitrary block (0 == main method); it mirrors `funGetFuncIdx` but works for non-entry blocks and distinguishes a filter funclet from its filter-handler. The helper is attached only when it shares the side-entry's function region: ```cpp if (!viaEnclosingTry || (funcRegionOf(block) == funcRegionOf(acd->acdDstBlk))) { RETURN_ON_ABORT(func(acd->acdDstBlk)); } ``` The exact-match path (a helper keyed to the block's own region) is unchanged, and dotnet#130945's intended case (an inner-try side-entry pulling its enclosing try's helper *within the same funclet*) still matches — so this only removes the cross-funclet edge. ## Validation Standalone `System.Data.Common` R2R wasm crossgen, release JIT, `wasm-tools validate` (only `fgwasm.h` differs between runs): | | `wasm-tools validate` | |---|---| | baseline (`origin/main` layout) | `func 597 failed to validate` ❌ | | with this fix | passes ✅ | ## Notes - Supersedes dotnet#131251, which hardened the terminal-`end` emission (the *effect*); this fixes the *cause* in layout. Closing dotnet#131251 in favor of this. - Related: dotnet#129335 (incomplete predecessor for this defect class, do not reopen); dotnet#130945 (introduced the lexical enclosing-try match); dotnet#131252 (miscomputed branch target depth — same corrupted layout, very likely subsumed by this fix). - Follow-up idea (not in this PR): a JIT-time assert that a funclet's blocks form a contiguous RPO range, so any future mis-layout traps at compile time instead of surfacing as an invalid module. > [!NOTE] > This change was authored with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9

github-actions · 2023-11-05T00:11:07Z

No description provided.

…#102133) This generalizes the indir reordering optimization (that currently only triggers for loads) to kick in for GT_STOREIND nodes. The main complication with doing this is the fact that the data node of the second indirection needs its own reordering with the previous indirection. The existing logic works by reordering all nodes between the first and second indirection that are unrelated to the second indirection's computation to happen after it. Once that is done we know that there are no uses of the first indirection's result between it and the second indirection, so after doing the necessary interference checks we can safely move the previous indirection to happen after the data node of the second indirection. Example: ```csharp class Body { public double x, y, z, vx, vy, vz, mass; } static void Advance(double dt, Body[] bodies) { foreach (Body b in bodies) { b.x += dt * b.vx; b.y += dt * b.vy; b.z += dt * b.vz; } } ``` Diff: ```diff @@ -1,18 +1,17 @@ -G_M55007_IG04: ;; offset=0x001C +G_M55007_IG04: ;; offset=0x0020 ldr x3, [x0, w1, UXTW #3] ldp d16, d17, [x3, #0x08] ldp d18, d19, [x3, #0x20] fmul d18, d0, d18 fadd d16, d16, d18 - str d16, [x3, #0x08] - fmul d16, d0, d19 - fadd d16, d17, d16 - str d16, [x3, #0x10] + fmul d18, d0, d19 + fadd d17, d17, d18 + stp d16, d17, [x3, #0x08] ldr d16, [x3, #0x18] ldr d17, [x3, #0x30] fmul d17, d0, d17 fadd d16, d16, d17 str d16, [x3, #0x18] add w1, w1, #1 cmp w2, w1 bgt G_M55007_IG04 ```

* bug #1: don't allow for values out of the SerializationRecordType enum range * bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type * bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use) * bug #4: document the fact that IOException can be thrown * bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails * bug #6: 0 and 17 are illegal values for PrimitiveType enum * bug #7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)

Currently, offsets are incorrectly treated as indices which is leading to incorrect code being emitted. e.g., `ScatterWithByteOffsets<long>` emits `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D, lsl #3]` instead of, `ST1D Zdata.D, Pg, [Xbase, Zoffsets.D]`

…128163) > [!NOTE] > This PR was authored with assistance from GitHub Copilot. Fixesdotnet#128044. ## Problem createdump SIGSEGVs on Linux when generating a Heap-type minidump for a process running interpreted code. The crash reproduces locally with the `InterpreterStack` DumpTests debuggee and matches the CI failure that prompted `<DumpTypes>Full</DumpTypes>` to be added as a temporary workaround. The faulting backtrace is: ``` #0 Thread::IsAddressInStack threads.cpp:6741 #1 Thread::EnumMemoryRegionsWorker threads.cpp:6909 (calls IsAddressInStack(currentSP)) #2 Thread::EnumMemoryRegions threads.cpp #3 ThreadStore::EnumMemoryRegions #4 ClrDataAccess::EnumMemDumpAllThreadsStack #5 ClrDataAccess::EnumMemoryRegionsWorkerHeap (HEAP2-only path) ``` ## Root cause `Thread::m_pInterpThreadContext` was declared as a raw `InterpThreadContext *`. In non-DAC code that's a normal host pointer, but in DAC mode the field's value is a target-process address. When `IsAddressInStack` (a DAC-callable helper) dereferenced `m_pInterpThreadContext->pStackStart` it read from a target-process address as if it were a host address, which faults inside createdump. ## Fix Change the field type to `PTR_InterpThreadContext` (DPTR), matching the treatment of other Thread fields like `m_pFrame`. In non-DAC builds `DPTR(T)` is just `T*`, so there is no overhead or behavior change. In DAC builds the read goes through `__DPtr<T>` and marshals correctly from the target. Also remove the `<DumpTypes>Full</DumpTypes>` workaround on the `InterpreterStack` DumpTests debuggee so the Heap path that originally failed is exercised again. ## Validation Locally reproduced the original SIGSEGV on Linux x64 with the auto-dump mechanism (`DOTNET_DbgMiniDumpType=2` + `DOTNET_Interpreter=MethodA`) running the `InterpreterStack` debuggee. With this fix applied, createdump produces a complete Heap dump (~74 MB) instead of crashing. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

In Compiler::optNarrowTree, the GT_CAST case bails when `tree->CastToType() != srct`. For unsigned widening casts produced by the C# compiler (e.g. an implicit uint->long widening synthesized when unary minus promotes uint to long), CastToType is TYP_ULONG even though tree->TypeGet() is TYP_LONG. The strict comparison rejects narrowing, even though both representations are bit-identical and the subsequent transformation (rewriting an int<->long cast as an int<->int identity) is correct for either signedness. The user-visible effect was that patterns like (uint)-(a >> 20) (uint)-(a << 2) (uint)~(ulong)(a >> 3) failed to fold the redundant widening cast left over after morph pushes the outer narrowing cast through GT_NEG/GT_NOT. The leftover cast serialized as a no-op `mov w0, w0` between the shift and the negate, preventing arm64 lowering from containing the shift into the negate: lsr w0, w0, dotnet#20 ; was 3 instructions mov w0, w0 neg w0, w0 Compare with the equivalent NegLSL pattern (no intermediate cast), which already produces `neg w0, w0, LSL #2`. Switching the comparison to `genActualType(CastToType()) != genActualType(srct)` lets ULONG-as-cast-target match LONG-as-srct, so the inner cast is narrowed away, lowering sees a direct NEG/MVN over the shift, and codegen emits the single-instruction shifted form: neg w0, w0, LSR dotnet#20 neg w0, w0, LSL #2 mvn w0, w0, LSR #3 The companion `tree->TypeIs(TYP_LONG)` check is also replaced with `genActualType(tree) == TYP_LONG` for consistency; the two are functionally equivalent for well-formed IR (cast nodes' TypeGet always returns the actual type, never the unsigned variant). Fixesdotnet#111888 Test updates in src/tests/JIT/opt/InstructionCombining/: - Cmn.cs CmnLSR, Neg.cs NegLSR: documented the old `lsr+cmn`/`lsr+neg` buggy codegen as expected, updated to expect the single-instruction shifted form. - Casts.cs CastUIntULongUInt: documented `mov w0, w0` (a no-op cast round trip) as expected; the fix eliminates the cast entirely so the method body has no instructions. Changed to ARM64-NOT: mov to assert absence of the redundant move. - Mvn.cs: added MvnCastChainLSR covering the cast-chain bug for MVN. Co-authored-by: Andy Ayers <andya@microsoft.com>

…dotnet#131279) [wasm] Restrict enclosing-try throw-helper attach to the same funclet ## Problem crossgen2 emits an invalid WASM (wasm32) R2R module for methods with certain try/catch shapes: the terminal `end` opcode (0x0b) is dropped for an EH funclet, so `wasm-tools validate` (and V8) reject the module with *"function body must end with end opcode"*. A related symptom is a miscomputed branch target depth in the same funclet (tracked as dotnet#131252). ## Root cause The defect is in wasm block layout, in `FgWasm::VisitWasmSuccs` (`src/coreclr/jit/fgwasm.h`). dotnet#130945 added an "enclosing try" relaxation: when a block is a try side-entry and the throw-helper ACD key is `KD_TRY`, the helper is also attached as a successor if ```cpp comp->bbInTryRegions(key.RegionIndex(), block) ``` is true. `bbInTryRegions` is a purely **lexical** try-nesting test — it does not check that the throw helper and the side-entry live in the same **function region (funclet)**. So a throw helper for an outer try region that belongs to the **main method** can be attached to a catch-resumption side-entry (`BBF_CATCH_RESUMPTION`) that merely nests inside that try but physically lives in a **handler funclet**. RPO layout then lays the main-method helper *inside* the funclet, interleaving it with funclet blocks. Because a funclet is a distinct wasm function body, that interleaving drops the funclet's terminal `end` and corrupts its branch target depths. Concrete trace from `System.Data.DataColumn:set_Expression` (instrumented `VisitWasmSuccs`, deduped): ``` sideEntry BB50 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=2] pulls dst BB76 (hndIdx=0) crossFunclet=1 sideEntry BB73 (tryIdx=4 hndIdx=3) preds[async=0 catch=1 other=0] pulls dst BB76 (hndIdx=0) crossFunclet=1 ``` BB76 is the throw helper for root try region #4 (`KD_TRY`, no handler index → main method); BB50/BB73 are catch-resumption side-entries in handler funclet #3 (which lexically nests in try #4), so the enclosing-try rule pulls the main-method helper into funclet #3. This is an ordinary catch-resumption EH shape (`async=0`); it is independent of runtime-async, and `fgwasm.h` is byte-identical to `main`. It is latent on `main` only because R2R-wasm codegen isn't enabled there yet. ## Fix Gate the enclosing-try relaxation on same-function-region ownership. A new `funcRegionOf` lambda returns the funclet index that physically contains an arbitrary block (0 == main method); it mirrors `funGetFuncIdx` but works for non-entry blocks and distinguishes a filter funclet from its filter-handler. The helper is attached only when it shares the side-entry's function region: ```cpp if (!viaEnclosingTry || (funcRegionOf(block) == funcRegionOf(acd->acdDstBlk))) { RETURN_ON_ABORT(func(acd->acdDstBlk)); } ``` The exact-match path (a helper keyed to the block's own region) is unchanged, and dotnet#130945's intended case (an inner-try side-entry pulling its enclosing try's helper *within the same funclet*) still matches — so this only removes the cross-funclet edge. ## Validation Standalone `System.Data.Common` R2R wasm crossgen, release JIT, `wasm-tools validate` (only `fgwasm.h` differs between runs): | | `wasm-tools validate` | |---|---| | baseline (`origin/main` layout) | `func 597 failed to validate` ❌ | | with this fix | passes ✅ | ## Notes - Supersedes dotnet#131251, which hardened the terminal-`end` emission (the *effect*); this fixes the *cause* in layout. Closing dotnet#131251 in favor of this. - Related: dotnet#129335 (incomplete predecessor for this defect class, do not reopen); dotnet#130945 (introduced the lexical enclosing-try match); dotnet#131252 (miscomputed branch target depth — same corrupted layout, very likely subsumed by this fix). - Follow-up idea (not in this PR): a JIT-time assert that a funclet's blocks form a contiguous RPO range, so any future mis-layout traps at compile time instead of surfacing as an invalid module. > [!NOTE] > This change was authored with the assistance of GitHub Copilot. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2e627b94-2658-41ce-a880-d9c27b7febd9

Automated bump of chrome version
dfc7737