[wasm] Bump chrome for testing - linux: 119.0.6045.105, windows: 119.0.6045.105#3
Open
github-actions[bot] wants to merge 1 commit into
Open
[wasm] Bump chrome for testing - linux: 119.0.6045.105, windows: 119.0.6045.105#3github-actions[bot] wants to merge 1 commit into
github-actions[bot] wants to merge 1 commit into
Conversation
AndyAyersMS
pushed a commit
that referenced
this pull request
Jun 3, 2024
…#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 ```
AndyAyersMS
pushed a commit
that referenced
this pull request
Sep 7, 2024
* 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)
AndyAyersMS
pushed a commit
that referenced
this pull request
Sep 30, 2025
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]`
AndyAyersMS
pushed a commit
that referenced
this pull request
May 14, 2026
…128163) > [!NOTE] > This PR was authored with assistance from GitHub Copilot. Fixes dotnet#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>
AndyAyersMS
added a commit
that referenced
this pull request
Jun 9, 2026
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).
Fixes dotnet#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>
AndyAyersMS
added a commit
that referenced
this pull request
Jun 10, 2026
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).
Fixes dotnet#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>
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.
No description provided.