Pull Request on 2026年10月12日

dotnet/runtimeにマージされたPull RequestをAIで日本語要約

注意点

このページは、dotnet/runtimeリポジトリにマージされたPull Requestを自動的に収集し、その内容をAIが要約した内容を表示しています。そのため、必ずしも正確な要約ではない場合があります。

目次

  1. #135633 [release/10.0] Remove unused client certificate from TLS host resumption test
  2. #135632 [release/9.0-staging] Give the nested process chain in ProcessWaitingTests depth-proportional wait budgets
  3. #135629 JIT: Simplify ReadUtf8 immutable data extraction
  4. #135619 Fix duplicate browser library-test publish symbols
  5. #135614 [release/10.0] Fix Dragon4 shortest formatting for exact powers of two
  6. #135608 Give the nested process chain in ProcessWaitingTests depth-proportional wait budgets
  7. #135605 JIT: exclude handles from numeric range reasoning
  8. #135597 [release/11.0] Size the RESOLVE_UPDATE_METADATA events in DbgTransportSession::GetEventSize
  9. #135572 Pass CMAKE_ICU_DIR headers to System.Globalization.Native configure checks
  10. #135569 Treat a missing /etc like a missing /etc/resolv.conf in NetworkInformation
  11. #135546 [release/10.0] Fix software EH memory leak on Unix
  12. #135541 [release/11.0] Fix software EH memory leak on Unix
  13. #135516 cDAC: fix inverted IncludeAvailableToProfilers check in Loader_1.GetModuleHandles
  14. #135481 [wasm] Keep larger field alignment for Align8 auto-layout structs
  15. #135478 [release/10.0] Handle TAR uid/gid values larger than int.MaxValue
  16. #135474 Fix fat calls in native AOT/WASM
  17. #135472 [cDAC] Fix stale contract docs and README
  18. #135436 [release/10.0] Fix Duplicate ownership state machine under concurrency for NCrypt handles
  19. #135408 Improve parallel connect failure diagnostics
  20. #135382 JIT: Restore insertps source-lane fold for floating-point inserts
  21. #135376 [release/10.0] Preserve module initialization across ReadyToRun inlining
  22. #135375 [release/11.0] Preserve module initialization across ReadyToRun inlining
  23. #135359 Throw CborContentException for dangling tag at end of root-level sequence
  24. #135356 Await chained key computation in AsyncEnumerable ordering
  25. #135261 [release/10.0] Fix operator precedence bug in SystemNative_FSync causing silent fsync errors
  26. #135256 [release/8.0-staging] Update dependencies from dotnet/icu
  27. #135243 [release/8.0] Update dependencies from dotnet/emsdk
  28. #135105 [release/11.0] Fix direct thread-static alignment fallback
  29. #135104 [release/10.0] Fix direct thread-static alignment fallback
  30. #135003 [release/8.0] Update dependencies from dotnet/arcade
  31. #135002 [release/8.0-staging] Update dependencies from dotnet/arcade
  32. #134773 [release/11.0] Update dependencies from dotnet/xharness
  33. #134772 [release/8.0-staging] Update dependencies from dotnet/xharness
  34. #134563 [release/9.0-staging] Update dependencies from dotnet/icu
  35. #134562 [release/10.0] Update dependencies from dotnet/runtime-assets
  36. #134561 [release/8.0-staging] Update dependencies from dotnet/runtime-assets
  37. #134430 [release/11.0] Preserve contained-load exceptions during embedded masking
  38. #134421 [release/11.0] Fix unsigned vector division correction lane width
  39. #134420 [release/11.0] Fix VNNI blend merge operand preservation
  40. #134393 [release/11.0] Update dependencies from dotnet/icu, dotnet/runtime-assets
  41. #134322 [release/10.0] Update dependencies from dotnet/xharness
  42. #134132 [release/9.0] Update dependencies from dotnet/emsdk
  43. #134020 [release/9.0] Update dependencies from dotnet/arcade
  44. #133926 [release/10.0] Update dependencies from dotnet/icu
  45. #133387 [release/9.0-staging] Update dependencies from dotnet/runtime-assets
  46. #133337 [release/11.0] Update dependencies from dnceng/internal/dotnet-optimization

#135633 [release/10.0] Remove unused client certificate from TLS host resumption test

概要

release/10.0 へのバックポート（元PR: #134422）です。TLS再開（resumption）テスト DifferentHost_NoResume から、未使用のクライアント証明書を削除します。この証明書が存在すると、Windowsで資格情報キャッシュが空（cold）の状態のときにTLS再開が妨げられ、テストが失敗していました。main で確認されていた同様の失敗が release/10.0 でも発生していたとのことです。

製品コードの変更はなく、テストのセットアップ修正のみです。

変更内容

  • src/libraries/System.Net.Security/tests/FunctionalTests/SslStreamAllowTlsResumeTests.cs（+0/-1）
    • DifferentHost_NoResume で使用されていたクライアント証明書の指定を1行削除（サーバー側はクライアント証明書を要求しないため不要）
    • 既存の再開に関するアサーションは変更なし

パフォーマンスへの影響

影響なし

関連Issue

  • 元PR: #134422（バックポート元）

その他

  • 顧客影響: 社内で発見されたテスト失敗で、サービシング検証に影響していました。製品の挙動変更はありません。
  • リグレッション: なし（発生時期は不明で、製品のリグレッションではなくテストセットアップの修正）
  • テスト: 元PRでは Windows x64 で3つのプロトコルバリアントすべてがパスし、新規プロセスでの追加30回の実行も成功、機能テスト・ユニットテストも実施されたと報告されています。このバックポートでは追加のローカルテストは未実施で、CIの結果待ちです。
  • リスク: 低（テストのみ、1行削除）

#135632 [release/9.0-staging] Give the nested process chain in ProcessWaitingTests depth-proportional wait budgets

概要

release/9.0-staging へのバックポートで、ProcessWaitingTests のネストしたプロセスチェーン（WaitChain / WaitAsyncChain）で発生していたタイムアウト起因の断続的なテスト失敗（#118977）を修正します。各待機バジェットを、そのチェーンが含むネストプロセスの数（深さ）に比例させる、テストのみの変更です。main の #135608 の変更に対応します。

変更内容

  • src/libraries/System.Diagnostics.Process/tests/ProcessWaitingTests.cs（+12/-8）
    • ネストしたプロセスチェーンの各待機のタイムアウトを、カバーするプロセス数に応じてスケールさせるように変更。
    • アサーションおよびプロダクトコードは変更なし。

パフォーマンスへの影響

影響なし（テストコードのみの変更）。

関連Issue

その他

  • 互換性への影響・公開API変更・破壊的変更はありません。
  • 顧客影響は、CI での断続的なテスト失敗のみ（社内で発見）。リグレッションではなく、既存のテストタイムアウト問題とされています。
  • 作成者によるリスク評価は「低（テストのみのタイムアウト調整）」です。
  • テストについて、#135608 では両チェーンテストが Windows x86、Linux x64、macOS arm64 でパスしたと報告されています。このバックポートでは追加のローカルテストは未実施で、CI は実行中かつ現時点で失敗が出ている状態です。

#135629 JIT: Simplify ReadUtf8 immutable data extraction

概要

JITの ReadUtf8 展開処理において、不変データ（immutable data）の抽出ロジックを GetImmutableDataFromAddress に統合して簡素化するPRです。ReadUtf8 展開内の「RVAバッキングされた入力」に関する既存のTODO風コメントにも対応しています。作成者は UTF8EncodingSealed.GetByteCount を定数/不変入力に対してintrinsic化する検討（#102246）の過程で、assertionpropsで定数入力長の畳み込みに使われている GetImmutableDataFromAddress に気づき、これを流用したとのことです。

変更内容

  • src/coreclr/jit/helperexpansion.cpp（+4/-33）
    • ReadUtf8 展開内の不変データ抽出ロジックを GetImmutableDataFromAddress に置き換え、約30行を削減。
    • getObjectContent 呼び出し用バッファを、512バイトのスタックバッファからJITのアリーナ割り当てに変更。

パフォーマンスへの影響

ベンチマーク結果の記載はありません。変更点としては、getObjectContent 用のバッファが512バイトのスタックバッファからJITのアリーナ割り当てに変わります。これはJIT（コンパイラ）内部の実装であり、生成コードの実行性能への影響は示されていません。

関連Issue

  • #102246（UTF8EncodingSealed.GetByteCount のintrinsic化の検討。直接の解決対象ではなく、背景として言及）

その他

  • 公開APIの変更や互換性への影響に関する記載はありません。
  • 既存の src\tests\JIT\opt\Vectorization\ReadUtf8.cs のリグレッションテストでカバーされると作成者は述べています。
  • 作成者自身が「この程度の簡素化がマージ基準を満たすか不明」と述べており、ひとまず提案する位置づけのPRです。

#135619 Fix duplicate browser library-test publish symbols

概要

ブラウザ向けライブラリテストの publish 時に、プロジェクト参照由来の PDB とランタイムパック由来の PDB が重複して残り、NETSDK1152 が発生する問題の修正です。publish 対象として選択された DLL に対応するシンボルのみを使用するようにしています。

作成者によれば、net12 への retarget で顕在化したとのことです。bootstrap SDK に net12 の pruning データがないため、推移的なライブラリのプロジェクト参照が残るのに対し、net11 では pruning により除去されます。修正自体は TFM に依存せず、重複入力の発生経路にかかわらず publish シンボルを選択済み DLL に合わせる内容です。

変更内容

  • eng/testing/tests.wasm.targets (+8/-6)
    • publish シンボルを、選択された DLL に対応するものに合わせるよう変更
    • ネストされたパスを維持
    • 隣接する PDB が存在しない場合は、既存のシンボルを維持

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • ビルド/テスト用のターゲットファイルのみの変更で、公開 API やランタイム実装への影響はありません。
  • 作成者による検証内容:
    • main 上でのターゲットのエッジケース確認
    • Mono / CoreCLR / EAT の browser ビルド
    • net12-retarget 上での linked publishing
  • Windows での実行と、main ブランチでのフルの browser ビルドは未実施とのことです。
  • GitHub Copilot の支援で作成されたとのことです。

#135614 [release/10.0] Fix Dragon4 shortest formatting for exact powers of two

概要

Number.Dragon4 が2の累乗の厳密値を判定する際、1U << TNumber.DenormalMantissaBits の 1U が32ビットであるため、double（仮数部52ビット）ではシフト量がマスクされ、マージン判定が誤っていました。これにより 2^-25 や 2^-958 などで最短ラウンドトリップ書式化の桁数が不足していました。リテラルを 1UL に拡げて修正しています。.NET 10 でのリグレッションの release/10.0 向けバックポートです（main PR: #131131）。

変更内容

  • src/libraries/System.Private.CoreLib/src/System/Number.Dragon4.cs: 不均等な丸めマージン判定のリテラルを 1U から 1UL に変更（+1/-1）
  • src/libraries/System.Runtime/tests/System.Runtime.Tests/System/DoubleTests.cs: DoubleTests.ToString_ExactPowerOfTwo_Roundtrips を追加（+17）。±2^-25 と ±2^-958 について ToString("R")、既定の ToString()、期待出力のパース結果を検証

パフォーマンスへの影響

影響なし

関連Issue

  • #135582
  • 回帰の原因: #102683（浮動小数点書式化実装の統合時に32ビットシフトが残った）

その他

  • 影響: 対象の値で最短ラウンドトリップ書式化の結果が隣接する double にパースされてしまうため、RFC 8785 JSON canonicalization など、ラウンドトリップに依存する処理が壊れます。.NET 8 では期待どおりの文字列が生成されます。
  • リスク: 低。サポートされる DenormalMantissaBits の値はすべて64未満で、リテラルの幅を広げるだけの変更です。
  • テスト: 作成者の環境では、ビルドの失敗（MSVC警告C4005のエラー化、crossgen2_inbuild が jitinterface_x64.dll を見つけられない、共有フレームワーク不足）により、このバックポートのランタイムテストは未検証です。main の元PRでは、浮動小数点書式化テスト、2,098個の2の累乗の全数確認、float/double のランダムなラウンドトリップ検証が通過したと報告されています。

#135608 Give the nested process chain in ProcessWaitingTests depth-proportional wait budgets

概要

ProcessWaitingTests.WaitChain / WaitAsyncChain は4段の RemoteExecutor プロセスチェーンを起動しますが、全階層が同一の WaitInMS で待機していました。ルートの待機は4プロセス分の起動・処理・終了を含むため、葉と同じ予算では不足し、x86 Checked レーンで約30秒のタイムアウトによる失敗が発生していました（#118977）。本PRでは、各階層の待機時間を「その下にあるプロセス数」に比例させるよう変更します（葉 1×、2×、3×、ルート 4×）。テストコードのみの変更で、製品コードは変更されていません。

変更内容

  • src/libraries/System.Diagnostics.Process/tests/ProcessWaitingTests.cs（+12/-8）
    • ChainWaitInMS(int processesBelow) を追加し、WaitInMS に配下プロセス数を乗じた待機時間を返すようにしました。
    • WaitChain と WaitAsyncChain の両方で、各階層の待機にこのヘルパーを使用します。
    • 製品コードの待機パスおよび単一プロセスの待機テストは変更されていません。

パフォーマンスへの影響

影響なし（テストのみの変更）。待機の上限が拡大するだけで、実処理量は変わりません。作成者による検証結果は以下のとおりです。

  • windows-x86: WaitChain 約11〜11.6秒、WaitAsyncChain 約12秒で、修正前後で差はノイズの範囲です。アセンブリ全体は698件で失敗0でした。
  • linux-x64 / osx-arm64: 各チェーンのテストは約1.2〜1.8秒で、修正前後で変化はありません。
  • Windows ローカルでは修正前でもチェーンが通過したため、Helix での失敗自体は再現していません。修正により当該レーンの失敗が解消するかは、今後のCI履歴で確認する必要があります。

関連Issue

#118977

その他

  • 作成者の記載によると、Unix 2環境で6件の POSIX シグナル関連テスト（SignalHandler_CanDisposeInHandler ×2、TestCreateNewProcessGroup_HandlerReceivesExpectedSignal ×4）が修正前後で同様に失敗しています。これは本変更以前からのもので、nohup 起動時に子プロセスの SIGHUP/SIGINT/SIGQUIT が無視される起動環境に起因すると推測されています。
  • 2つのテストだけを直列化する案も検討されましたが、測定はされていません。並列化を有効にした #135160 の目的に反するため採用されていません。
  • 本PRはAI（Anthropic Claude、OpenAI Codex によるチェック）の支援のもとで作成され、作成者が内容と測定結果を確認しています。

#135605 JIT: exclude handles from numeric range reasoning

  • 作成者: @EgorBo
  • 作成日時: 2026年10月11日 19:26:46(UTC)
  • マージ日時: 2026年10月12日 14:11:46(UTC)
  • ラベル: area-CodeGen-coreclr

概要

JIT において、リロケーションが必要なハンドル（relocatable handle）を数値範囲・符号の推論から除外する修正です。#135484 で VN（Value Numbering）によるハンドル比較の畳み込みは止められましたが、ARM32 ではアサーション伝播（assertion propagation）中に、コンパイル時のハンドル用プレースホルダー値を使って比較が畳み込まれてしまう問題が残っていました。本 PR はこの経路を塞ぎます（Fixes #135604）。

変更内容

  • src/coreclr/jit/assertionprop.cpp (+5/-0): アサーション伝播側で、リロケーションが必要な定数から数値範囲・符号を導出しないようにする処理を追加
  • src/coreclr/jit/gentree.cpp (+2/-2), src/coreclr/jit/gentree.h (+1/-1): ツリー上の定数がリロケーションを必要とする場合に、数値範囲や符号の導出を避けるための変更
  • src/coreclr/jit/valuenum.cpp (+2/-2), src/coreclr/jit/valuenum.h (+2/-1): 数値定数クエリおよび非負クエリでハンドルの VN を拒否するよう変更
  • ハンドルの同一性（identity）に基づく等価性の畳み込みは従来どおり維持されます。

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載なし）。作成者はいくつかの JIT diff（asm diffs）へのリンクを提示しています。なお、ハンドルを数値として扱った最適化が抑制されるため、一部で生成コードが変わる可能性があります。

関連Issue

#135604（本 PR で修正） 関連 PR: #135484（ハンドル比較の VN 畳み込みを停止した変更）

その他

  • ARM32 で顕在化していた問題への対応です。
  • 変更は JIT 内部実装（src/coreclr/jit）に限られ、公開 API や互換性への影響は記載されていません。

#135597 [release/11.0] Size the RESOLVE_UPDATE_METADATA events in DbgTransportSession::GetEventSize

概要

Linux（および同じトランスポートを使うmacOS）で、プロファイラーが SetILFunctionBody でメソッドに新しいローカル変数を追加している場合に、デバッガーがそのメソッドのローカル変数を要求するとデバッgrees対象プロセスがクラッシュし得る問題の修正です（#134717 の release/11.0 へのバックポート）。DbgTransportSession::GetEventSize において、RESOLVE_UPDATE_METADATA 系の3つのイベントにサイズ計算が追加され、これまでヘッダーのみが送信されていたイベントのペイロードも送信されるようになります。

変更内容

  • src/coreclr/debug/shared/dbgtransportsession.cpp（+7/-0）
    • GetEventSize のサイズ判定 switch に、RESOLVE_UPDATE_METADATA 系イベント用の case を追加。
    • 影響するのはこれら3イベントの送信長のみで、ペイロード分だけ増加します。他のイベント、構造体、フレーミングの変更はありません。

パフォーマンスへの影響

影響なし（対象3イベントの送信サイズがペイロード分増えるのみ）。

関連Issue

その他

  • 顧客影響: Linux上で、IDEのVariablesペインが例外停止時などに自動でローカル変数を要求した際、デバッグ対象がクラッシュし得ます。macOSは同じトランスポートを使いますが未検証です。標準のWindowsビルドはこのトランスポートを使いません。
  • リグレッション: なし（少なくとも 6.0（v6.0.36）から存在）。
  • テスト: #134714 の最小再現コードで、10.0.12 のrelease/checkedビルド（linux-x64）、release（linux-arm64）、11.0 RC1タグおよび main（linux-x64, VS Code）を確認。既存のテストにデバッガートランスポートを扱うものが見つからなかったため、自動テストは追加されていません。
  • リスク: 低。ただしデバッガー（libmscordbi.so）とランタイム（libcoreclr.so）は同時に出荷する必要があります。修正済み mscordbi と未修正の coreclr の組み合わせでは、_2 に古いポインターが返され、ランタイム側が解放してしまう可能性があります（詳細は #134714）。両者は同じランタイムパッケージに含まれます。

#135572 Pass CMAKE_ICU_DIR headers to System.Globalization.Native configure checks

概要

Unix系ターゲット（Android/Apple/Browser/WASI以外）で CMAKE_ICU_DIR を指定してビルドした際、System.Globalization.Native の configure チェック（HAVE_UDAT_STANDALONE_SHORTER_WEEKDAYS、HAVE_UCOL_CLONE）が CMAKE_ICU_DIR 配下のICUヘッダーを参照せずにコンパイルされる問題を修正します。

従来は ${CMAKE_ICU_DIR}/include が include(configure.cmake) の後でしか追加されなかったため、次の問題が生じていました。

  • システムにICUヘッダーがない場合、両チェックが "file not found" で失敗し、config.h に両方とも0が設定される（ビルド自体は成功する）
  • システムICUヘッダーがある場合、CMAKE_ICU_DIR ではなくシステム側のヘッダーでチェックされる
  • HAVE_UCOL_CLONE が0かつ STATIC_ICU 定義時（LOCAL_BUILD 構成）、pal_collation.c が ICU 78.3 で非推奨の ucol_safeClone を呼び、-Werror でビルドが失敗する
  • HAVE_UDAT_STANDALONE_SHORTER_WEEKDAYS が0の場合、pal_calendarData.c は super-short の曜日名に UDAT_STANDALONE_NARROW_WEEKDAYS を使用する

変更内容

  • src/native/libs/System.Globalization.Native/configure.cmake（+19/-0）
    • CMAKE_ICU_DIR が定義されている場合、${CMAKE_ICU_DIR}/include を CMAKE_REQUIRED_INCLUDES に追加
    • ucol_clone のチェックを静的ライブラリとしてビルドし、コンパイルのみで判定するように変更。ICUのシンボルリネーミングを無効化した場合、ucol_clone は関数宣言となり、リンクチェックではこのパスで設定されないICUライブラリへのリンクが必要になるため
  • CMAKE_ICU_DIR を設定しないビルドには影響なし

パフォーマンスへの影響

影響なし（ビルド時の configure チェックの修正のみ）。CMAKE_ICU_DIR なしのビルドでは、config.h と libSystem.Globalization.Native.so が変更前後でバイト単位で同一であることが確認されています。

関連Issue

#135571

その他

  • System.Globalization.Native には専用テストがないため、ビルドによる検証のみです。静的ICU 78.3での config.h の値の変化、システムICUヘッダー有無での挙動、--disable-renaming 使用時、-Werror でのビルド成否などを確認したとのことです。
  • 変更前に CMAKE_ICU_DIR を指定して構成済みのビルドディレクトリは、チェック結果がキャッシュされているため、空のディレクトリから再構成する必要があります。

#135569 Treat a missing /etc like a missing /etc/resolv.conf in NetworkInformation

概要

Linuxで /etc ディレクトリが存在しない場合に NetworkInterface.GetAllNetworkInterfaces() が DirectoryNotFoundException をスローする問題を修正します。/etc/resolv.conf の読み取りを共通ヘルパー StringParsingHelpers.ReadResolvConfFile に集約し、ファイル未存在・ディレクトリ未存在・アクセス拒否のいずれの場合も null を返す（DNS情報なしとして扱う）ようにしました。公開APIの変更はありません。

変更内容

  • StringParsingHelpers.Dns.cs: ReadResolvConfFile ヘルパーを追加。FileNotFoundException、DirectoryNotFoundException、UnauthorizedAccessException を捕捉して null を返す
  • LinuxNetworkInterface.cs: resolv.conf の読み取りにヘルパーを使用するよう変更（従来は FileNotFoundException と UnauthorizedAccessException のみ捕捉）
  • UnixIPInterfaceProperties.cs: BSD/Apple向けの2か所の読み取り処理（従来は FileNotFoundException のみ捕捉）をヘルパー経由に置き換え。これによりBSD/Appleでも UnauthorizedAccessException が無視されるようになる（挙動の変更点）
  • DnsParsingTests.cs: 以下のテストを追加・更新
    • 存在しないファイル、および存在しないディレクトリ配下のファイルに対して null を返すことを検証する新規theory
    • ディレクトリを渡した場合に null を返すことを検証する新規fact
    • 既存の resolv.conf パース系テストの入力読み取りをヘルパー経由に変更

パフォーマンスへの影響

影響なし

関連Issue

#135568

その他

  • 互換性: 公開APIの変更なし。BSD/Appleの実装では UnauthorizedAccessException を無視するようになる点が従来との差分
  • 作成者によるテスト結果:
    • Windowsでは機能テストが合格
    • Linuxでは IPGlobalProperties_DomainName_ReturnsEmptyStringWhenNotSet を除き合格。このテストは本変更の有無にかかわらずテストマシン上で失敗（DomainName が "localdomain" を返す）
    • Issueの再現手順は、/etc が存在しない場合と /etc に resolv.conf がない場合の両方で修正後に成功
    • BSD/Appleの実装はコンパイル確認のみで、実行はされていない

#135546 [release/10.0] Fix software EH memory leak on Unix

概要

release/10.0 向けの #135290 のバックポート。Unix 上で、ネイティブランタイムコードからスローされたソフトウェアマネージド例外に対して DispatchManagedException が実行されると、動的に確保された CONTEXT と EXCEPTION_RECORD が解放されずリークする問題を修正します（amd64 で約 3400 バイト）。マネージド例外処理側が、動的確保されたコンテキスト／例外レコードの所有権を引き継いでいないことが原因です。.NET 9 の新しい例外処理（#88034）で混入したリグレッションで、顧客からの報告 (#135234) に基づく修正です。

修正内容は、ソフトウェア例外処理におけるコンテキストの所有権の扱いを、従来からあるハードウェア例外処理と同じ方式に揃えるものです。

変更内容

  • src/coreclr/vm/exceptionhandling.cpp (+29/-7): ソフトウェア例外処理で、動的確保された CONTEXT / EXCEPTION_RECORD の所有権を例外処理側が引き継ぐように変更
  • src/coreclr/vm/exceptionhandling.h (+3/-1): 上記に対応する宣言の変更
  • src/tests/Regressions/coreclr/GitHub_135234/test135234.cs (+109/-0): 本問題の回帰テスト（directed test）を追加
  • src/tests/Regressions/coreclr/GitHub_135234/test135234.csproj (+11/-0): 上記テストのプロジェクトファイル

パフォーマンスへの影響

実行速度への言及はなし。メモリ面では、例外発生ごとに約 3400 バイト（amd64）リークしていた問題が解消されます。

関連Issue

#135234（顧客報告） 元の修正 PR: #135290 リグレッション導入元: #88034

その他

  • 影響範囲は Unix 上の CoreCLR のソフトウェア例外処理（ネイティブランタイムコードからスローされる例外）
  • テストは CoreCLR およびライブラリのテストと、本問題向けの directed test で実施
  • リスクは低いとされています（ハードウェア例外処理で従来から採用されているコンテキスト所有権の方式に合わせる変更のため）

#135541 [release/11.0] Fix software EH memory leak on Unix

概要

Unix上で、ネイティブランタイムコードからスローされるソフトウェアマネージド例外（DispatchManagedException経路）において、動的に確保された CONTEXT と EXCEPTION_RECORD が解放されず、メモリリークする問題の修正です。マネージド例外処理側が、動的確保された context / exception record の所有権を引き取っていなかったことが原因です。これは #135290 の release/11.0 へのバックポートです。

変更内容

  • src/coreclr/vm/exceptionhandling.cpp（+28/-6）: ソフトウェア例外処理における CONTEXT / EXCEPTION_RECORD の所有権の扱いを、従来のハードウェア例外処理と同じ方式に変更
  • src/coreclr/vm/exceptionhandling.h（+1/-0）: 上記に伴う宣言の追加
  • src/tests/Regressions/coreclr/GitHub_135234/test135234.cs（+109/-0）: 本件の回帰テスト（directed test）を追加
  • src/tests/Regressions/coreclr/GitHub_135234/test135234.csproj（+11/-0）: 上記テストのプロジェクトファイルを追加

パフォーマンスへの影響

実行速度への影響は記載されていません。メモリ面では、amd64で例外1回あたり約3400バイトのリークが解消されます。ベンチマーク結果の記載はありません。

関連Issue

その他

  • .NET 9 で導入された新しい例外処理（#88034）によるリグレッションです。
  • リスクは低いと評価されています。ハードウェア例外処理で従来から採用されている context の所有権の扱いに、ソフトウェア例外処理を揃える変更であるためです。
  • テストはCoreclrおよびライブラリのテストに加え、本件用の directed test が追加されています。

#135516 cDAC: fix inverted IncludeAvailableToProfilers check in Loader_1.GetModuleHandles

概要

cDAC の Loader_1.GetModuleHandles において、IncludeAvailableToProfilers フラグの判定が反転していた不具合を修正します。ネイティブの AppDomain::AssemblyIterator::Next_Unlocked は、アセンブリが profiler 通知済みで、かつ呼び出し側が kIncludeAvailableToProfilers を渡した場合のみ loaded/loading チェックをスキップします。cDAC は !iterationFlags.HasFlag(...) と逆の条件を使っていました。

// 修正の趣旨（概念）
// 誤: !iterationFlags.HasFlag(AssemblyIterationFlags.IncludeAvailableToProfilers)
// 正: iterationFlags.HasFlag(AssemblyIterationFlags.IncludeAvailableToProfilers)

変更内容

  • docs/design/datacontracts/Loader.md: 擬似コードにあった同じ反転を修正
  • Loader_1.cs: 判定条件の反転を修正（+1/-1）
  • LoaderTests.cs: GetModuleHandles_ProfilerNotified テストを追加（4つのモックアーキテクチャで、profiler 通知／ロード状態／フラグの組み合わせを検証）
  • MockDescriptors.Loader.cs: モックローダービルダーに AddAppDomain（AppDomain の AssemblyList に最初のインラインブロックでアセンブリを保持）と、Assembly.NotifyFlags／Assembly.IsLoaded のセッターを追加

パフォーマンスへの影響

影響なし

関連Issue

#135469

その他

  • 実際の挙動差: ランタイムは Assembly::BeforeTypeLoad（FILE_LOAD_BEFORE_TYPE_LOAD）で PROFILER_NOTIFIED を設定し、IsLoaded は FILE_LOAD_DELIVER_EVENTS で true になります。この間、IncludeLoaded | IncludeExecution を渡す SOSDacImpl.IXCLRDataProcess.cs の4つの IXCLRDataProcess 列挙が、ロード中のアセンブリを返していました（ネイティブ DAC は返さない）。IncludeLoading も渡す SOSDacImpl／DacDbiImpl の呼び出しには影響しません。
  • テスト結果: linux-x64、osx-arm64、windows-x64 で Microsoft.Diagnostics.DataContractReader.Tests が 3321 件成功。テスト変更のみ適用した場合は 3309 件成功で、同じ 12 ケースが失敗しており、本修正で解消されます。

#135481 [wasm] Keep larger field alignment for Align8 auto-layout structs

概要

FEATURE_64BIT_ALIGNMENT ターゲット（ARM32 と wasm）で、MethodTableBuilder::HandleAutoLayout が Align8 候補の auto-layout 値型のアラインメントを、フィールドがそれ以上を要求する場合でも常に 8 に固定していた問題を修正します。wasm では Int128/UInt128、Decimal128、Vector128<T> が 16 を要求するため、ランタイムは 8、crossgen2 は 16 と食い違っていました。

修正後は max(8, 最大フィールドアラインメント) を使用します（GCポインタを含む場合は従来どおり 8）。これは crossgen2 の MetadataFieldLayoutAlgorithm.ComputeAutoFieldLayout と同じ規則です。構造体内のフィールドオフセットは変わらず、構造体自身のアラインメント（末尾パディングや他の型のフィールドとして配置される位置）のみが変わります。ARM32 では 8 を超えるフィールドがないため挙動は変わりません。

変更内容

  • src/coreclr/vm/methodtablebuilder.cpp（+2/-1）: auto-layout のアラインメント計算を修正。
  • src/coreclr/tools/aot/ILCompiler.TypeSystem.Tests/ArchitectureSpecificFieldLayoutTests.cs（+14/-0）: TestAlignmentBehavior_AutoAlignmentRulesWithOSDependence に Wasm32 の行を追加し、Int128/UInt128/Decimal128 の auto ラッパーで crossgen2 の 16/32 を固定。
  • src/tests/readytorun/fieldlayout/fieldlayouttests.cs（+35/-2）: browser CoreCLR で readytorun/fieldlayout を再有効化（ActiveIssue は #131421 を指していたが、原因は本バグだった）。auto-layout の Int128 ペアを派生クラスのフィールドに持つケースを追加し、リフレクション経由で検証。

パフォーマンスへの影響

実行速度の変更ではなく、wasm CoreCLR の composite ReadyToRun perf パイプラインを通すための正しさの修正です。

  • BenchmarkDotNet が生成する Runnable_N クラスは、引数を auto-layout の FieldsContainer 構造体に格納します。Perf_Int128（TryFormat、ToString、CopySign）ではこれが Int128 を保持します。
  • composite R2R では crossgen2 がフィールドオフセットをコードに焼き込むため、コードはオフセット 16 に書き込む一方、ランタイムはオフセット 8 前提でオブジェクトを確保し、オブジェクト末尾を越えて書き込んでいました。結果として Fatal error. Invalid Program: attempted to call a UnmanagedCallersOnly method from managed code. で異常終了しました（この領域外書き込みとエラーの因果関係は推測であり、スタックでは確認されていません）。
  • 修正後は、ローカルで再現した Perf_Int128 の composite R2R 実行で、以前失敗していたベンチマーク（benchmarkId 2, 5, 6, 9）が完走。

検証結果:

  • ILCompiler.TypeSystem.Tests（ArchitectureSpecificFieldLayoutTests）: 44 件成功（新規 Wasm32 の3行を含む）。
  • fieldlayouttests.cs を composite wasm R2R アプリとして --verify-type-and-field-layout 付きで実行: 修正なしでは Derived.Pair のオフセット不一致（16 != 8）と Auto.Wrapper_int8x16x2 の失敗、修正ありでは成功。
  • 未実施: src/tests ハーネス経由のテスト（browser R2R の CI レーンが担当）、ARM32 ビルド。

関連Issue

その他

  • Vector256/Vector512 のアラインメント（#135483、本PR対象外）: 本変更により、wasm 上で Vector256<T>/Vector512<T> を含む auto-layout 構造体のアラインメントは 32/64 になります。crossgen2 とは一致しますが、wasm では疑問があります。
    • Wasm Basic C ABI は v128 を超える型を定義していません（clang 22 で確認: __BIGGEST_ALIGNMENT__ は 16、struct { v128 lo, hi; } のアラインメントは 16）。
    • wasm の GC ヒープはオブジェクトを 8 バイトアラインメントまでしか保証しないため、8 を超えるアラインメントは実質的な整列ではなくパディングを増やすだけです。
    • 変更する場合は VM と crossgen2 の双方に影響する R2R 互換性の判断となり、wasm CoreCLR の出荷前に別PRで行う必要があります。
  • cDAC は保存されたフィールドオフセットとサイズを読むため変更不要です。
  • 自動レビューでは未解決の指摘は0件ですが、低レベルの wasm 型レイアウトを変更するため、メンテナによる最終確認が推奨されています。

#135478 [release/10.0] Handle TAR uid/gid values larger than int.MaxValue

概要

GNU tar形式では int.MaxValue より大きい UID/GID が表現され得ますが、System.Formats.Tar でそのようなアーカイブを処理すると OverflowException がスローされていました。本PRは release/10.0 へのバックポートで、そのような値を読み込めるようにし、書き込み時もラウンドトリップできるようにします。main ブランチの修正 #134850 に対応します。

PR記載によると、現在知られているUNIXプラットフォームでは UID/GID は32ビット値として定義されているため、オーバーフロー時に負の数へ折り返すことを許容することで、有効なユースケースがラウンドトリップ可能になるとのことです。

変更内容

  • TarHeader.Read.cs: UID/GID の読み取り処理を変更（+4/-4）
  • TarHeader.Write.cs: UID/GID の書き込み処理を変更（+28/-13）
  • TarHelpers.cs: 新規ヘルパー処理を追加（+32）
  • TarReader.Tests.cs: 大きな UID/GID を持つアーカイブの読み取りテストを追加（+127）
  • TarWriter.WriteEntry.Entry.Roundtrip.Tests.cs: ラウンドトリップのテストを追加（+34）

公開API／内部実装の別、および互換性（破壊的変更）への影響についての記載はPR情報にはありません。

パフォーマンスへの影響

影響なし（PR情報にパフォーマンスに関する記載はありません）。

関連Issue

#127006（顧客報告）

その他

  • リグレッション: なし
  • リスク: 低（変更が小さく、テストでカバーされているとPRに記載）
  • テスト: 対象を絞ったユニットテストを追加
  • 顧客報告の問題であり、外部/サードパーティ実装を使わなければ該当アーカイブを処理できなかった状況の解消が目的です。

#135474 Fix fat calls in native AOT/WASM

概要

Native AOT/WASM における fat call（fat function pointer を介した呼び出し）の修正です。RyuJIT 側の変更のみで対応でき、コンパイラ/CoreLib 側には CoreRT リポジトリの WASM プロトタイプ由来の実装がすでに残っているため追加変更は不要とのことです。

作成者は、#135414 の reprozero.cs に fat call を追加して、fat call が行えることを確認したと説明しています。

変更内容

  • src/coreclr/jit/indirectcalltransformer.cpp（+6/-2、計8行）
    • 変更ファイルは RyuJIT の間接呼び出し変換処理のみ。具体的な差分内容は提供情報に含まれていません。

パフォーマンスへの影響

影響なし（提供情報にパフォーマンスに関する記載はありません）

関連Issue

  • 作成者の説明で言及されているのは #135414 です（reprozero.cs での検証に使用）。

その他

  • feature/NativeAOT-LLVM ブランチでは TARGET_LLVM_WASM32 / TARGET_LLVM_WASM64 が使われているため、本変更とはコンフリクトが生じる見込みです。作成者はできるだけ競合しない形での実装を意図していたとのことです。

#135472 [cDAC] Fix stale contract docs and README

概要

cDAC（data contract）に関するドキュメントとREADMEの記述が現行のソースコードと食い違っていた箇所を修正するPRです。各項目は現行ソースと照合して確認されたと記載されています。コードの変更はなく、ドキュメントのみの修正です。

変更内容

  • Exception.md: GetNestedExceptionInfo の疑似コードが ExceptionInfo::ThrownObject をハンドルとして参照していましたが、実際のフィールドは OBJECTREF 型の ExInfo::m_exception です。実装（Exception_1.cs）はフィールドのアドレスを疑似ハンドルとして、その値をオブジェクトとして返します。この内容に合わせて記述を修正しました。
  • data-descriptor-meanings.json: ディスクリプタの意味の記述「Handle to the thrown exception object」を修正しました。
  • Thread.md: GetThreadData の記述から、#116743 で削除済みの FeatureEHFunclets グローバルの参照を除去しました。Thread_1 は常に Thread::ExceptionTracker 経由で読み取ります。
  • ReJIT.md: GetRejitIds の疑似コードに、cDAC実装と ReJitManager::GetReJITIDs の双方が行っている Source == ReJIT のチェックを追記しました。
  • WindowsErrorReporting.md: Exception.md / Thread.md とあわせて、CdacUsageGraph docs で生成テーブルを再生成しました。
  • cDAC README.md:
    • レガシーDACがcDACへ委譲するにはDebugランタイムが必要という記述を修正しました。cDACが有効な場合、サポートされるプラットフォームではDebug / Checked / Releaseのいずれのランタイムビルドでも委譲が機能します（CAN_USE_CDAC は USE_DAC_TABLE_RVA のみに依存し、ReleaseランタイムのSOSテストでもcDAC構成が実行されます）。
    • #if DEBUG のクロスバリデーションには、ランタイムビルドと一致するレガシーDACが必要である旨を明記しました。
    • SOSテストがWindows x64で実行されるという記述を、runtime-diagnostics.yml の7つの sosPlatforms すべてで実行される旨に修正しました。

パフォーマンスへの影響

影響なし（ドキュメントのみの変更）

関連Issue

  • #116743（FeatureEHFunclets グローバルを削除した変更として言及）

その他

  • CdacUsageGraph docs --check と Usage.Tests は通過していると記載されています。
  • 作成者によると、本PRはAI支援（Anthropic Claude、OpenAI Codexでレビュー）で作成され、各主張はローカルでソースと照合済みとのことです。

#135436 [release/10.0] Fix Duplicate ownership state machine under concurrency for NCrypt handles

概要

release/10.0 向けのバックポートPR（元: #130804）です。NCryptハンドル（NCryptSafeHandles.cs）の「重複所有権」ステートマシンが、複数スレッドが同時に鍵オブジェクトを初めて使用する際に競合状態で不正な状態に陥る問題を修正します。コードパス上の競合箇所をロックで保護するシンプルな変更です。

  • 不正な状態はCI実行中のassertで検出されました（https://github.com/dotnet/runtime/issues/130760）。
  • 最悪の場合、ファイナライズ時に ObjectDisposedException がスローされてプロセスが終了します。顧客からも同様の報告があり、同じ問題と見られます。
  • 競合が起きるのは、2つのスレッドが同時に鍵オブジェクトを初めて使用する場合に限られます。最初の使用が完了した後の並列アクセスは影響を受けません。
  • 回帰ではありません（ロジックは .NET Core 1.0 から変更されていません）。

変更内容

  • src/libraries/System.Security.Cryptography/src/Microsoft/Win32/SafeHandles/NCryptSafeHandles.cs（+22/-11）: 競合の影響を受けるコードにロックを追加。
  • src/libraries/System.Security.Cryptography/tests/CngKeyTests.cs（+60/-0）: 積極的な並列実行を行うテストを追加。

パフォーマンスへの影響

影響なし（ロック追加による影響についての記載はありません）

関連Issue

その他

  • 作成者による評価ではリスクは低い（"Low"）とされています。
  • 影響区分は「顧客報告あり」かつ「社内でも発見」です。
  • レビュー依頼: @bartonjs @vcsjones

#135408 Improve parallel connect failure diagnostics

  • 作成者: @wfurt
  • 作成日時: 2026年10月08日 03:27:54(UTC)
  • マージ日時: 2026年10月12日 16:31:42(UTC)
  • ラベル: area-System.Net.Sockets

概要

SocketAsyncEventArgsTest.Connect_Parallel_FailsOver テストの失敗時診断情報を強化するPRです。#134107 で追跡されている断続的な失敗について、同期失敗・非同期失敗・IPv4-mapped IPv6 の挙動を区別できるようにすることが目的です。成功時のテスト動作は変更しません。

変更内容

  • src/libraries/System.Net.Sockets/tests/FunctionalTests/SocketAsyncEventArgsTest.cs (+35/-9)
    • 非同期の並列接続が、テストタイムアウト前に完了コールバックを呼び出すことを検証
    • ConnectAsync が同期的に完了したかどうか、最終的なソケットエラーを報告
    • ソケットが返されない場合に、同等の SocketException メッセージを報告
    • 想定外のアドレスファミリーやエンドポイントで接続された場合に、接続済みソケットのローカル/リモートエンドポイント、テストでバインドした両エンドポイント、現在の localhost の名前解決結果を報告

パフォーマンスへの影響

影響なし（テストコードのみの変更）

関連Issue

#134107

その他

  • 動機: Kusto の調査では失敗は 1〜3 ms で完了しており、ある事例ではテストが IPv4 を期待したにもかかわらず IPv6 ソケットが返されました。従来の失敗情報ではこれらを切り分けられませんでした。
  • テスト結果:
    • ローカルでは localhost が IPv4/IPv6 の両方に解決されないホストだったため、テストはスキップされました（ビルドは成功）。
    • 失敗が発生した環境と同じ Ubuntu 26.04 x64 の Helix コンテナイメージ上でビルド済み Mono ランタイムを用いて実行し、2 passed / 0 failed / 0 skipped でした。
    • 診断変更前に、同コンテナ4つで1,000回ずつフォーカステストをストレス実行し、2,000件の theory ケースがすべて成功しました。

#135382 JIT: Restore insertps source-lane fold for floating-point inserts

概要

x64/x86 JITのlowering（lowerxarch.cpp）で、Insert(v, CreateScalarUnsafe(v2.GetElement(n)), imm) を単一の insertps（count_s でレーンnを選択）に書き換える最適化（#130422）が機能しなくなっていた問題の修正です。

#130444 以降、ユーザーが別のHW intrinsicである浮動小数点の CreateScalarUnsafe ノードが削除されるようになりました。オペランドはユーザーより先にlowerされるため、Insertのlowering時点ではラッパーが常に消えており、op2が CreateScalarUnsafe であることを前提とした条件が成立しませんでした。その結果、insertps の前に冗長な movshdup / unpckhps / shufps が残っていました。

本PRでは、CreateScalarUnsafe を介さない「素の要素抽出」もop2として認識するようにして、このfoldを復活させています。

変更内容

  • src/coreclr/jit/lowerxarch.cpp：浮動小数点Insertに対するsource-lane foldの条件を拡張し、op2がラッパーなしの抽出であるケースも認識するよう変更（+13/-4）
  • src/tests/JIT/opt/Vectorization/InsertScalarFromVectorDisasm.cs：生成された逆アセンブリを検証するテストを追加（+41）
  • src/tests/JIT/opt/Vectorization/InsertScalarFromVectorDisasm.csproj：上記テスト用プロジェクトファイルを追加（+15）

既存の機能テストでは最適化が失われたことを検出できなかったため、disasmチェック付きのテストを追加したとのことです。

パフォーマンスへの影響

コード生成の改善です。浮動小数点Insertごとに生成されていた冗長なシャッフル命令（movshdup / unpckhps / shufps）が除去され、insertps 単体になります。ベンチマーク結果などの具体的な数値は提供されていません。

関連Issue

#134942（Fixes） 関連：#130422（foldの導入）、#130444（CreateScalarUnsafe 削除の変更）

その他

  • 作成者によると、本PRはAIの支援を受けて作成されたとのことです。
  • 変更はJITのlowering内部に限られ、公開APIや互換性への影響についての記載はありません。

#135376 [release/10.0] Preserve module initialization across ReadyToRun inlining

概要

release/10.0 へのバックポートです（main の #134359 が元）。Composite ReadyToRun では、別アセンブリを有効化（activation）する呼び出しがインライン化で消え、そのモジュールの module initializer が実行されない場合があります。この修正で、クロスモジュールインライン時にも activation の依存関係が保持されるようになります。

報告されたケースでは、module initializer 内の UnsafeAccessor による書き込みが観測されず、private static フィールドが未設定のままになります。.NET 10 でも再現することが元の報告で確認されており、リグレッションではありません。

変更内容

  • ReadyToRun コンパイラ（ILCompiler.ReadyToRun）
    • ModuleTokenResolver.cs / SignatureBuilder.cs / TypeFixupSignature.cs: version bubble 外にあるグローバルモジュール型の安定したトークンを許可するようにトークン解決・シグネチャ処理を調整
    • CorInfoImpl.ReadyToRun.cs: クロスモジュールインライン時に activation の依存関係を保持するロジックを追加
  • VM
    • jitinterface.cpp: RVA 静的フィールドの解決前に、宣言元モジュールを有効化するよう変更
  • ビルド関連
    • crosscomp.h: CONTEXT_UNWOUND_TO_CALL の再定義を回避するための変更（+6行）。Windows SDK 10.0.28000.0 との衝突によるビルド失敗への対処と思われますが、PR 本文にはこの変更自体の説明はありません
  • テスト（src/tests/readytorun/ModuleInitializer/）
    • main の PR のリグレッションテストを追加（UnsafeAccessorModuleInitializer、InitializerLibrary、FieldLibrary、RvaFieldLibrary.il、ValueTypeLibrary とそれぞれのプロジェクトファイル）
    • main の PR で変更された compiler-test runner は release/10.0 に存在しないため、その変更は意図的に省略され、修正は旧トークン解決実装に合わせて調整されています

パフォーマンスへの影響

影響なし（記載なし）。

関連Issue

その他

  • リスクは「Moderate」とされています。main にマージ済みの修正を旧実装向けに調整したものです。
  • ローカル検証は、crosscomp.h と Windows SDK 間の CONTEXT_UNWOUND_TO_CALL 再定義エラー（C4005 がエラー扱いになる C2220）でベースラインビルドが失敗したため、実質的にできていません。このため CI での検証が必須とされています。

#135375 [release/11.0] Preserve module initialization across ReadyToRun inlining

概要

Composite ReadyToRun（R2R）でクロスモジュールのインライン化により、他アセンブリをアクティベートする呼び出しが消えてしまい、そのモジュールのモジュール初期化子が実行されない問題の修正を、main の #134359 から release/11.0 へバックポートするものです。

具体的には以下の3点を行っています。

  • クロスモジュールのインライン化時に、アクティベーション依存関係を保持する
  • バージョンバブル外にあるグローバルモジュール型の安定トークンを許可する
  • RVA静的フィールドを解決する前に、宣言元モジュールをアクティベートする

報告されたケースでは、モジュール初期化子内で UnsafeAccessor を使って行った書き込みが観測されず、private static フィールドが未設定のままになっていました。.NET 10 と .NET 11 RC1 の両方で再現し、リグレッションではありません。

変更内容

  • R2Rコンパイラ（ILCompiler.ReadyToRun）
    • CorInfoImpl.ReadyToRun.cs: +14行（モジュールのアクティベーション依存関係の保持に関する変更）
    • ModuleTokenResolver.cs / SignatureBuilder.cs / TypeFixupSignature.cs: グローバルモジュール型のトークン扱いに関する小規模な変更
  • ランタイム（VM）
    • src/coreclr/vm/jitinterface.cpp: +5行（RVA静的フィールド解決前に宣言元モジュールをアクティベート）
  • R2Rコンパイラテスト基盤
    • R2RResultChecker.cs / R2RTestRunner.cs: release/11.0 のテストランナー構成に合わせ、動的生成された依存アセンブリが R2R イメージ検証時に解決できるよう調整
  • 回帰テスト（src/tests/readytorun/ModuleInitializer/）
    • UnsafeAccessorModuleInitializer.cs/.csproj のほか、InitializerLibrary、FieldLibrary、ValueTypeLibrary、RvaFieldLibrary（IL）を追加

パフォーマンスへの影響

影響なし（記載された情報の範囲では、パフォーマンスに関する言及やベンチマーク結果はありません）。

関連Issue

その他

  • 影響範囲は R2R のモジュールアクティベーションに限定されており、リスクは「低〜中」と記載されています。
  • テスト結果:
    • ランタイム/ライブラリ/ホストのビルドは警告・エラー 0 件で成功
    • UnsafeAccessorModuleInitializer は Composite R2R 下で期待どおり終了コード 100 を返して成功
    • ILCompiler.ReadyToRun.Tests は 92 件成功、1 件失敗。失敗は MissingVirtualSignature のアサーションで、リゾルバ調整の前後で再現しており、本バックポートが対象とする参照欠落系の失敗はすべて解消済みと記載されています。
  • 本 PR は GitHub Copilot の支援で作成されています。

#135359 Throw CborContentException for dangling tag at end of root-level sequence

概要

System.Formats.Cbor の CborReader において、AllowMultipleRootLevelValues を有効にしたルートレベルのシーケンスが「後続のデータ項目を持たないタグ」で終わる場合に、従来は Finished を返していましたが、CborContentException をスローするように変更します。単一バッファのリーダーと、インクリメンタル（SlideData）のリーダーの両方に適用され、等価な状態では同じ例外型が発生するようになります。

変更内容

  • CborReader.PeekState.cs（+6）: PeekStateCore で、ルートレベルのシーケンス終端にタグが保留中であれば例外をスローするようにしました。
  • CborReader.cs（+6）: PeekInitialByte で、シーケンス終端のガードより前に同様のチェックを追加しました。これは、消費したトークンがタグのみで、SlideData がオフセットを 0 に巻き戻すケースに対応します。
  • CborReaderTests.SlideData.cs（+28/-7）: 旧挙動（Finished）をアサートしていた PeekState_DanglingTagAtEndOfRootSequence を更新し、タグのみのケースのテストを追加しました。

パフォーマンスへの影響

影響なし（提供された情報にパフォーマンスに関する記載はありません）。

関連Issue

#135191

その他

  • 既存挙動の変更（互換性への影響）: ルートレベルの末尾にタグが残っている場合、PeekState() は従来 Finished を返していましたが、今後は CborContentException をスローします。
  • テスト状況: 作成者は、ライブラリのソースをコンパイルするスクラッチ用コンソールプロジェクトで、Issue のシナリオを変更前後で確認しています。System.Formats.Cbor のテストスイート全体はローカルで実行できておらず、CI での検証に依存しています。

#135356 Await chained key computation in AsyncEnumerable ordering

  • 作成者: @Copilot
  • 作成日時: 2026年10月07日 18:01:42(UTC)
  • マージ日時: 2026年10月12日 15:54:39(UTC)
  • ラベル: area-System.Linq

概要

AsyncEnumerable の ThenBy / ThenByDescending において、連鎖したソーターのキー計算タスクが await されず破棄されていた問題の修正です。セレクターが非同期に中断（suspend）すると、未初期化のキーを読んだままソートされる可能性があり、またセレクターの例外が無視される場合がありました。修正では、後続ソーターのキー計算を await してからソートするようにしています。

if (_next is not null)
{
    await _next.ComputeKeysAsync(elements, count, cancellationToken);
}

変更内容

  • src/libraries/System.Linq.AsyncEnumerable/src/System/Linq/OrderBy.cs (+4/-1)
    • 連鎖した次のソーターの ComputeKeysAsync を await するよう修正。
  • src/libraries/System.Linq.AsyncEnumerable/tests/OrderByTests.cs (+69/-0)
    • セレクターが中断するケースの決定的な回帰テストを追加（2段目・3段目の並べ替え、昇順・降順の両方）。
    • 主キーが異なる場合でもセレクターの例外が伝播することを検証するテストを追加。

パフォーマンスへの影響

影響なし（ベンチマーク結果の記載はありません）。

関連Issue

#135343

その他

  • 公開APIの変更や互換性への影響に関する記載はありません。
  • 本PRはCopilot coding agentによって作成されています。

#135261 [release/10.0] Fix operator precedence bug in SystemNative_FSync causing silent fsync errors

概要

SystemNative_FSync（pal_io.c）における演算子優先順位のバグを修正し、Unix上で fsync/fcntl(fd, F_FULLFSYNC) のエラーが無視されていた問題を解消するバックポート（main への #124725 を release/10.0 へ）です。このバグにより、SMBネットワーク共有上でファイルの破損・切り捨てが発生し得ました。修正後は FileStream.Flush(flushToDisk: true) が ENOSPC や EIO などのストレージエラーを例外として伝播します。

変更内容

  • src/native/libs/System.Native/pal_io.c（+11/-6）: syscall結果の代入を修正して実際の戻り値を保持するようにし、既存の EINTR リトライ動作は維持。macOS向けのフォールバックも main の PR から含まれる。
  • src/native/libs/Common/pal_config.h.in（+0/-1）: 設定定義の削除。
  • src/native/libs/configure.cmake（+0/-5）: 設定チェックの削除。
  • マネージドAPIの公開面の変更なし（ネイティブ実装のみ）。

パフォーマンスへの影響

影響なし

関連Issue

  • #135201（顧客からのバックポート要望）
  • 元PR: #124725（main にマージ済み）

その他

  • .NET 6 に起源を持つ長期的なリグレッションの修正です。
  • リスクは低いと記載されています。
  • テスト: ./build.sh clr+libs -rc release が警告・エラー0で成功。System.IO.FileSystem.Tests は 8,760件中失敗0、スキップ54。strace で fsync に EIO を注入した環境で、FileStream.Flush(true) が IOException をスローすることを確認。

#135256 [release/8.0-staging] Update dependencies from dotnet/icu

概要

release/8.0-staging ブランチ向けの、dotnet-maestro[bot] による自動依存関係更新です。dotnet/icu リポジトリの dotnet/release/8.0 ブランチの新しいビルド（20261005.4）を取り込み、Microsoft.NETCore.Runtime.ICU.Transport パッケージのバージョンを 8.0.0-rtm.26457.3 から 8.0.0-rtm.26505.4 に更新します。

変更内容

  • eng/Version.Details.xml: Microsoft.NETCore.Runtime.ICU.Transport のバージョンおよび参照コミット（d691c320a3fd6069bc95a9d8b3bac66a7a4104a7）を更新
  • eng/Versions.props: 対応するバージョンプロパティを更新

パフォーマンスへの影響

影響なし（提供された情報にパフォーマンスに関する記載はありません）。

関連Issue

なし

その他

  • 更新元: dotnet/icu（コミット差分）
  • ICU側で具体的にどのような変更が含まれているかは、提供された情報からは確認できません。

#135243 [release/8.0] Update dependencies from dotnet/emsdk

概要

dotnet-maestro[bot] による自動依存関係更新です。release/8.0 ブランチ向けに、dotnet/emsdk の最新ビルド（Build 20261008.4、コミット f47ea836）へ依存関係を更新します。

変更内容

  • NuGet.config: 1行変更（提供情報からは具体的な変更内容は不明）
  • eng/Version.Details.xml: 依存関係のバージョン/コミット情報の更新（4行追加・4行削除）
    • Microsoft.SourceBuild.Intermediate.emsdk: 8.0.32-servicing.26464.4 → 8.0.33-servicing.26508.4
    • Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100: 8.0.32 → 8.0.33
  • eng/Versions.props: 1行変更（バージョン更新と思われるが、提供情報からは詳細不明）

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

#135105 [release/11.0] Fix direct thread-static alignment fallback

概要

release/11.0 へのバックポート（元PR: #134982）です。direct thread-static のアライメントが原因で割り当てに失敗した場合のフォールバック処理にバグがあり、データ破損によるクラッシュを引き起こす可能性がありました。これを修正しています。PR #129749 でアライメントロジックがより正確になった際、割り当て失敗ケースの扱いが不十分だったことによるリグレッションです。

具体的には、「割り当てに成功した」ことを示すフラグの設定位置を正しい箇所に移動する修正です。

変更内容

  • src/coreclr/vm/threadstatics.cpp (+1/-1): 割り当て成功を示すフラグを正しい位置へ移動（ランタイム内部実装の修正で、公開APIの変更はありません）
  • src/tests/baseservices/threading/threadstatic/threadstatic09.cs (+72/-0): 該当シナリオ（direct thread-static のアライメントフォールバック）を検証する新規テストを追加
  • src/tests/baseservices/threading/threadstatic/threadstatic09.csproj (+13/-0): 上記テスト用のプロジェクトファイルを追加

パフォーマンスへの影響

影響なし

関連Issue

  • 元PR: #134982（バックポート元）
  • リグレッションの原因となったPR: #129749

関連するIssueの記載はありません。

その他

  • カスタマーへの影響: 社内で発見された問題で、顧客からの報告ではありません。データ破損によるクラッシュの可能性があります。
  • リグレッション: あり（#129749 が原因）
  • テスト: 手動テストに加え、このシナリオを正確に検証する新規テストを追加。これまで各種シナリオに対するテストが不足していたとの記載があります。
  • リスク: 低（フラグの設定位置を修正するのみ）

#135104 [release/10.0] Fix direct thread-static alignment fallback

概要

dotnet/runtime の release/10.0 ブランチに対する #134982 のバックポートです。#129785 で追加されたスレッド静的変数のアライメント処理が引き起こした回帰を修正します。#129785 により、アライメントは正しくなった一方で、領域の確保に失敗することがあるにもかかわらず、確保済みとして扱ってしまう新たな失敗パターンが生じていました。

本PRでは、「静的変数が確保された」と見なすロジックを正しい分岐へ移動することでこの問題を解消します。社内で発見されたもので、顧客からの報告はありません。

変更内容

  • src/coreclr/vm/threadstatics.cpp: 1行追加、1行削除。確保済みとして扱うロジックを正しい分岐へ移動
  • src/tests/baseservices/threading/threadstatic/threadstatic09.cs: 新規テストを追加 (+72行)
  • src/tests/baseservices/threading/threadstatic/threadstatic09.csproj: 上記テスト用のプロジェクトファイルを追加 (+13行)

動作確認は手動テストと、新規にチェックインされたテストで行われています。リスクは Low とされています。

パフォーマンスへの影響

影響なし

関連Issue

  • #134982: バックポート元のPR
  • #129785: 回帰の原因となったPR

その他

  • 回帰の有無: あり（servicing regression）
  • サービシングリリース向けのバックポートのため、.NET 10 以降では PR のターゲットブランチが release/X.0（-staging なし）であることの確認が必要です。

#135003 [release/8.0] Update dependencies from dotnet/arcade

概要

release/8.0 ブランチにおいて、dotnet/arcade の依存関係を自動更新する Maestro bot による PR です。Arcade 関連パッケージを 8.0.0-beta.26431.7 から 8.0.0-beta.26468.3 へ、Microsoft.DotNet.XUnitConsoleRunner を 2.5.1-beta.26431.7 から 2.5.1-beta.26468.3 へ更新しています。あわせて .NET SDK を 8.0.131 に更新しています。

  • 更新元: dotnet/arcade の release/8.0 ブランチ（ビルド 20260918.3、コミット c0cf2702a670a20e5103532c2a4910ea7ac94ce1）
  • 差分: 25da4e8f08...c0cf2702a6

変更内容

  • eng/Version.Details.xml / eng/Versions.props: Arcade 関連パッケージ（Microsoft.DotNet.Arcade.Sdk、Microsoft.DotNet.Build.Tasks.*、Microsoft.DotNet.GenAPI、Microsoft.DotNet.GenFacades、Microsoft.DotNet.Helix.Sdk、Microsoft.DotNet.RemoteExecutor、Microsoft.DotNet.XUnitExtensions など）のバージョンを更新
  • global.json: sdk.version と tools.dotnet を 8.0.131 に更新
  • eng/common/templates/ および eng/common/templates-official/ 配下:
    • job/job.yml: 小規模な変更（+2/-1）
    • job/onelocbuild.yml: 変更量が大きい（+16/-29）
    • steps/send-to-helix.yml: 追加が多い（+40/-6）
    • いずれも通常版と official 版で同じ変更量。変更の具体的な中身は提供された情報からは確認できません。

パフォーマンスへの影響

影響なし（ランタイムのコード変更ではなく、ビルド/CI インフラの依存関係更新）

関連Issue

なし

その他

  • ランタイム本体やライブラリの公開 API に対する変更は含まれていません。
  • eng/common 配下のパイプラインテンプレート（OneLocBuild、Helix 送信ステップ、ジョブ定義）が更新されているため、CI の挙動に影響する可能性があります。具体的な差分内容は提供情報からは判断できません。

#135002 [release/8.0-staging] Update dependencies from dotnet/arcade

概要

release/8.0-staging ブランチ向けに、dotnet/arcade（release/8.0 ブランチ）からの依存関係を自動更新するPRです（dotnet-maestro[bot]による作成）。Arcade関連パッケージを 8.0.0-beta.26431.7 から 8.0.0-beta.26468.3 に、Microsoft.DotNet.XUnitConsoleRunner を 2.5.1-beta.26431.7 から 2.5.1-beta.26468.3 に更新します。あわせて .NET SDK のバージョンも 8.0.131 に更新されます。

変更内容

  • eng/Version.Details.xml、eng/Versions.props: Arcade関連パッケージ（Microsoft.DotNet.Arcade.Sdk、Microsoft.DotNet.Build.Tasks.*、Microsoft.DotNet.Helix.Sdk、Microsoft.DotNet.RemoteExecutor、Microsoft.DotNet.XUnitExtensions など）のバージョンとコミットSHAを更新
  • global.json: sdk.version と tools.dotnet を 8.0.131 に更新
  • eng/common/templates/ および eng/common/templates-official/ 配下:
    • job/job.yml: 各2行追加・1行削除
    • job/onelocbuild.yml: 各16行追加・29行削除（記述の簡略化）
    • steps/send-to-helix.yml: 各40行追加・6行削除
  • 更新元のArcadeビルドは 20260918.3（コミット c0cf2702a670a20e5103532c2a4910ea7ac94ce1）

パフォーマンスへの影響

影響なし（ランタイムやライブラリのコードではなく、ビルド・テスト基盤の依存関係とパイプラインテンプレートの更新のみ）

関連Issue

なし

その他

  • 公開APIやランタイム実装の変更はなく、互換性への影響も提供情報からは確認できません。
  • eng/common 配下のテンプレート更新の具体的な動作変更は、提供された情報からは判断できません。

#134773 [release/11.0] Update dependencies from dotnet/xharness

概要

dotnet-maestro[bot] による自動依存関係更新です。release/11.0 ブランチで、dotnet/xharness の依存パッケージを 11.0.0-prerelease.26466.1 から 11.0.0-prerelease.26506.1 に更新します（xharness ビルド 20261006.1、コミット 91708f0daf）。

変更内容

  • .config/dotnet-tools.json: xharness 関連ツールのバージョン更新（+1/-1）
  • eng/Version.Details.props: 依存パッケージのバージョン値を更新（+3/-3）
  • eng/Version.Details.xml: 依存パッケージのバージョンおよび参照情報を更新（+6/-6）

更新対象パッケージ:

  • Microsoft.DotNet.XHarness.CLI
  • Microsoft.DotNet.XHarness.TestRunners.Common
  • Microsoft.DotNet.XHarness.TestRunners.Xunit

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 変更はビルド/テスト基盤（XHarness）の依存バージョン更新に限られ、ランタイム・ライブラリのコードや公開APIへの変更は含まれません。
  • xharness 側の差分は compare で確認できます。提供された情報には個々の変更内容が含まれていないため、更新による具体的な挙動の変化は不明です。

#134772 [release/8.0-staging] Update dependencies from dotnet/xharness

概要

release/8.0-staging ブランチで、dotnet/xharness の依存関係をMaestroボットが自動更新するPull Requestです。 11.0.0-prerelease.26466.1 から 11.0.0-prerelease.26506.1 に更新されます（xharness の Build 20261006.1、コミット 91708f0）。

変更内容

  • .config/dotnet-tools.json: xharness 関連ツールのバージョン更新（+1/-1）
  • eng/Version.Details.xml: 依存関係のバージョン／コミット情報の更新（+6/-6）
  • eng/Versions.props: バージョンプロパティの更新（+3/-3）

更新対象パッケージ:

  • Microsoft.DotNet.XHarness.CLI
  • Microsoft.DotNet.XHarness.TestRunners.Common
  • Microsoft.DotNet.XHarness.TestRunners.Xunit

いずれもビルド／テスト基盤（エンジニアリング）に関する依存関係の更新であり、ライブラリの公開APIやランタイム実装には変更ありません。

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 互換性に関する情報（破壊的変更など）は提供された情報からは確認できません。
  • 差分の詳細は xharness の比較 を参照してください。

#134563 [release/9.0-staging] Update dependencies from dotnet/icu

概要

release/9.0-staging ブランチに対して、dotnet-maestro[bot] による自動依存関係更新が行われました。dotnet/icu の dotnet/release/9.0 ブランチ（ビルド 20261009.1、コミット 4b5609920f97434d2100323e5dc47ad9c9f58dac）から、Microsoft.NETCore.Runtime.ICU.Transport を更新しています。

変更内容

  • eng/Version.Details.xml: Microsoft.NETCore.Runtime.ICU.Transport のバージョンおよびコミット情報の更新（+2/-2）
  • eng/Versions.props: 対応するバージョンプロパティの更新（+1/-1）

パフォーマンスへの影響

影響なし（提供された情報に、パフォーマンスに関する記載やベンチマーク結果はありません）

関連Issue

なし

その他

  • 自動生成されたPRで、コード変更はなくビルド依存関係のバージョン更新のみです。
  • ICU のどの変更が含まれるか（バグ修正・セキュリティ修正・Unicode/CLDR データ更新など）は、提供された情報からは判断できません。詳細は上記の比較リンクをご確認ください。

#134562 [release/10.0] Update dependencies from dotnet/runtime-assets

概要

release/10.0 ブランチ向けに、dotnet-maestro[bot] が dotnet/runtime-assets からの依存関係を自動更新するPRです。バージョンは 10.0.0-beta.26462.2 から 10.0.0-beta.26506.2 に更新されます（対象ビルド: 20261006.2、コミット c3ed7764f5）。

変更内容

  • eng/Version.Details.props: 15件のバージョン定義を更新
  • eng/Version.Details.xml: 30行（15依存関係分）の更新
  • 更新対象の依存パッケージ（すべてテストデータ/アセット系）:
    • Microsoft.DotNet.CilStrip.Sources
    • Microsoft.NET.HostModel.TestData
    • System.ComponentModel.TypeConverter.TestData
    • System.Data.Common.TestData
    • System.Drawing.Common.TestData
    • System.Formats.Tar.TestData
    • System.IO.Compression.TestData
    • System.IO.Packaging.TestData
    • System.Net.TestData
    • System.Private.Runtime.UnicodeData
    • System.Runtime.Numerics.TestData
    • System.Runtime.TimeZoneData
    • System.Security.Cryptography.X509Certificates.TestData
    • System.Text.RegularExpressions.TestData
    • System.Windows.Extensions.TestData

パフォーマンスへの影響

影響なし（バージョン情報ファイルのみの変更で、ランタイム/ライブラリのコード変更は含まれません）

関連Issue

なし

その他

  • 差分の詳細は dotnet/runtime-assets の比較 で確認できます。
  • 公開API・互換性への影響に関する情報は、提供された内容からは確認できません。

#134561 [release/8.0-staging] Update dependencies from dotnet/runtime-assets

概要

dotnet-maestro[bot] による自動依存関係更新PRです。release/8.0-staging ブランチ向けに、dotnet/runtime-assets（release/8.0 ブランチ）からの依存関係をビルド 20260923.6（コミット 8b1613b）に更新します。バージョンは 8.0.0-beta.26462.3 から 8.0.0-beta.26473.6 に上がります。

変更内容

  • eng/Version.Details.xml（+28/-28）: 依存関係のバージョンおよびコミット情報を更新
  • eng/Versions.props（+14/-14）: 対応するバージョンプロパティを更新

更新対象のパッケージ（いずれも 8.0.0-beta.26462.3 → 8.0.0-beta.26473.6）:

  • Microsoft.DotNet.CilStrip.Sources
  • System.ComponentModel.TypeConverter.TestData
  • System.Data.Common.TestData
  • System.Drawing.Common.TestData
  • System.Formats.Tar.TestData
  • System.IO.Compression.TestData
  • System.IO.Packaging.TestData
  • System.Net.TestData
  • System.Private.Runtime.UnicodeData
  • System.Runtime.Numerics.TestData
  • System.Runtime.TimeZoneData
  • System.Security.Cryptography.X509Certificates.TestData
  • System.Text.RegularExpressions.TestData
  • System.Windows.Extensions.TestData

差分: 80d652f8b5...8b1613bf99

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 変更はバージョン管理ファイル（eng/ 配下）のみで、ソースコードの変更は含まれません。
  • 提供された情報からは、各テストデータパッケージ内の具体的な変更内容までは確認できません。

#134430 [release/11.0] Preserve contained-load exceptions during embedded masking

概要

AVX-512のembedded masking（マスク適用の融合）が、eagerに評価されるロードの例外（NullReferenceExceptionなど）を抑制してしまう問題を修正する release/11.0 へのバックポートです（元PR: dotnet/runtime#134366）。AVX-512対応のx64環境で、最適化された vector の条件選択が、null参照に対して本来スローすべき例外を出さずにフォールバック値を返すことがありました。

修正は、算術演算のcontained load と、masked-blendの直接メモリオペランド（broadcast、intrinsic loadを含む）の両方を対象とします。JITの既存の例外解析を再利用し、例外を投げる可能性があるオペランドではmasking/containmentを行わず、非フォールトが証明できるオペランドは従来どおりmasking対象とします。

変更内容

  • src/coreclr/jit/gentree.cpp（+13/-2）: masked operationの適用可否判定に、例外を投げる可能性の確認を追加
  • src/coreclr/jit/gentree.h（+1/-1）: 上記に伴う宣言の変更
  • src/coreclr/jit/lowerxarch.cpp（+8/-0）: masked-blendのcontainment判定で、例外を投げ得るロードを除外
  • src/tests/JIT/Regression_ro_2/Runtime_134197.cs（+108/-0）: 回帰テストを追加。算術ロード、入れ子のスカラーbroadcast、直接ベクトルロード、直接broadcast、aligned-load intrinsicsを128/256/512ビット幅で検証し、empty/partial/fullマスクを有効値・null入力の両方で確認

互換性・リスク: 公開API・データレイアウトの変更はなく、xarchのJIT内部実装に限定されます。リスクは「低」と評価されています。顧客報告あり、.NET 11固有のリグレッションではなく、.NET 10.0.12でも再現と報告されています。

パフォーマンスへの影響

例外を投げ得るロードを無条件評価のまま残すため、追加の命令やレジスタが必要になり、コードが若干大きくなる場合があります（影響を受けた例では6バイト増）。安全なケースでは命令・サイズとも同一でした。直接broadcastのローカルベンチマークは1.551 ns → 1.553 nsでした。ただし、同一JITでもタイミングのばらつきが大きいため、厳密な性能の上限とは言えません。

関連Issue

#134197（Resolves）

その他

  • main向け修正の検証はWindows x64（AVX-512F/VL有効）で実施済み。修正前のJITでは空マスクの5ケースすべてが失敗し、完全な修正では15ケースすべてが成功。算術のみの中間修正では、直接ロード/broadcast/intrinsic loadの3ケースが失敗する
  • embedded masking無効時とレジスタストレスは成功。AVX-512/AVX2無効やソフトウェアフォールバック構成では、移植可能な12ケースが成功し、AVX-512固有の3ケースはスキップ
  • 関連回帰テストは通常時とDOTNET_JitStress=2で356件成功
  • バックポートはボットが競合解消なしで適用。release/11.0上でのローカルビルド・実行は未実施で、リリースブランチのCI検証が必要
  • x86、ARM64、非Windows、NativeAOT実行は未検証。従来のテストで見逃された理由は特定されていない

#134421 [release/11.0] Fix unsigned vector division correction lane width

概要

Vector128<uint> / Vector256<uint> の符号なし整数ベクトル除算（x86/x64、AVX-512 非対応のパス）において、商が 2^31 に達すると誤った結果を返す不具合の修正です（release/11.0 へのバックポート、元PR: dotnet/runtime#134362）。

最終的な商の補正に使われていた blendvpd 命令が、2つの32bitレーンを1組として選択していたため、正しい隣接レーンの値まで上書きしていました。これを blendvps に置き換え、32bitレーン単位で選択するようにしています。

  • 例: <uint.MaxValue, 9, 1, 1> / <1, 3, 1, 1> の期待値は <4294967295, 3, 1, 1> ですが、修正前は <2147483648, 3, 1, 1> になっていました。

変更内容

  • src/coreclr/jit/hwintrinsiccodegenxarch.cpp (+4/-2): 商の最終補正における2箇所の blendvpd を blendvps に変更
  • src/coreclr/jit/lsraxarch.cpp (+1/-1): 対応するレジスタ割り当て側の調整
  • src/tests/JIT/Regression_ro_2/Runtime_133752.cs (+37/-0): 回帰テストの追加

影響範囲は JIT（コンパイラ）内部の実装で、公開APIの変更はありません。倍精度による入力補正は変更されていません。AVX/AVX2 と従来の SSE4.1 フォールバックの両パスが対象で、AVX-512 とソフトウェアフォールバックは影響を受けません。

パフォーマンスへの影響

影響なし。説明によると、逆アセンブリ比較ではブレンド命令のオペコード以外に差はなく、命令数・コードサイズも変わりません。ローカルの BenchmarkDotNet の計測区間は重なっており、スループット改善は主張されていません。

関連Issue

  • #133752（本PRで解決）
  • 元PR: #134362
  • 回帰の原因: #117996（commit be7db811、2025年9月15日マージ）

その他

  • 回帰: .NET 11 開発中に #117996 で混入しました。.NET 10.0.0 ではこのパスが符号付き int のみのため、uint は対象外です（ソース・履歴の確認に基づくもので、.NET 10 上での実行確認はありません）。
  • 影響: 社内で発見されたもので、顧客からの報告はありません。
  • テスト: main ブランチの実装で Windows x64 の Checked/Release JIT をビルドし、AVX2・AVX のみ・SSE4.1 の各構成で、修正なしでは失敗し修正ありでは成功することを確認しています。AVX-512 とソフトウェアフォールバックは修正前後とも成功しました。なお release/11.0 のバックポートそのものは、ローカルでビルド・実行されていません。x86 および非Windows環境での実行も未確認です。
  • リスク: 低（実行コードの変更は2つのブレンド命令のみ）。
  • ターゲットブランチ: release/11.0（.NET 10+ のためサフィックスなしで正しい）。パッケージ作成の変更は不要です。

#134420 [release/11.0] Fix VNNI blend merge operand preservation

概要

VNNI（乗加算）系のイントリンシックを「read-modify-write (RMW)」として扱うようJITのメタデータを修正し、blend と融合する最適化で不正な折りたたみが行われないようにする release/11.0 へのバックポート（元PR: dotnet/runtime#134364）です。

従来は、VNNI乗加算の結果と独立したフォールバック値をブレンドする最適化コードが、AVX-512対応ハードウェア上で誤った値を返す場合がありました。融合後の命令がデスティネーションをアキュムレータと非アクティブレーンのマージ値の両方に使うため、フォールバック値が失われていました。

  • 例: フォールバック=7、加数=5、積=0、マスクが交互のレーンの場合、期待値は7と5が交互に並びますが、影響を受けるコードはすべて5を返します。
  • 通常形と飽和形の両方が影響を受けます。

変更内容

  • src/coreclr/jit/hwintrinsiclistxarch.h: 8個のイントリンシックエントリに既存の HW_Flag_RmwIntrinsic フラグを追加（+8/-8）。新しいloweringやcodegenのロジックは追加せず、既存のRMWコンテインメント制限を利用します。
  • src/tests/JIT/Regression_ro_2/Runtime_133753.cs: 回帰テストを新規追加（12ケース）。
    • 128/256/512ビットのベクトル、byte/short積、飽和/非飽和形をカバーします。
    • フォールバック値とアキュムレータ値を区別し、積ゼロと交互マスクでマージ値の保持を検証します。
    • 非インライン化の最適化ヘルパーで、問題の最適化経路を確実に通します。
    • ハードウェアイントリンシックが無効な場合は、テストをパスとせずスキップします。

パフォーマンスへの影響

  • 既存のRMW制限により、ゼロフォールバックの融合も抑止されます。計測したプローブでは、コードサイズが63→69バイト、命令数が9→10に増加しました。
  • 報告された再現コードは70バイト/14命令のままで、マスクなしのVNNIや通常のマスク付き加算はコードが変わりません。
  • ローカルのベンチマーク計測値は不安定だったため、スループットに関する主張はありません。
  • ゼロフォールバック融合を安全に維持するには、別途レジスタ割り当ての作業が必要です。

関連Issue

  • #133753（SDK 11.0.100-rc.2.26467.112 で報告）
  • 元PR: #134364
  • 回帰の契機となった変更: #128365（AvxVnni.V512 の導入）
  • blend折りたたみ機構の導入: #116983

その他

  • 回帰性: AvxVnni.V512 での再現は #128365 により.NET 11で可能になりました。ただしRMW分類の欠落自体は.NET 11以前からあり、ソース確認上は.NET 10でも、AVX-VNNIとAVX-512 VLの両方をサポートするハードウェアで128/256ビットの類似ケースが同じ経路に到達しうると見られています（実行による検証は未実施）。
  • リスク: Low。リスクは低く、既存のRMW制限を使うのみです。新しい整数バリアントは別の特別なcodegenにより、この融合経路から独立して除外されており、メタデータも整合的に修正されています。
  • 検証状況: テスト結果はmainブランチ修正（Windows x64、AMD Ryzen 9 7950X）のものです。
    • 12ケースすべてが、修正前のChecked JITで失敗し、修正後のChecked JITで成功しました。
    • tiering無効時は、修正後のChecked/Release JITの両方で成功しました。
    • release/11.0へのバックポート自体はローカルでビルド・実行されていません。
    • VEXのみのVNNI経路や、新しいVNNI Int8/Int16のハードウェア経路はローカルで実行できていません。
  • 対象ブランチ: release/11.0（確認済み）。

#134393 [release/11.0] Update dependencies from dotnet/icu, dotnet/runtime-assets

概要

Maestro（dotnet-maestro[bot]）による release/11.0 ブランチ向けの依存関係の自動更新PRです。dotnet/icu と dotnet/runtime-assets から、それぞれ新しいビルドの成果物バージョンへ更新しています。

変更内容

  • eng/Version.Details.props：依存パッケージのバージョン定義を更新（+17/-17）
  • eng/Version.Details.xml：依存関係のバージョンおよび参照コミットを更新（+34/-34）

更新された依存関係：

  • dotnet/icu（Build 20261005.3、コミット bbfd5321）
    • Microsoft.NETCore.Runtime.ICU.Transport：11.0.0-alpha.1.26469.1 → 11.0.0-alpha.1.26505.3
  • dotnet/runtime-assets（Build 20261006.3、コミット 60aef74b）
    • 11.0.0-beta.26462.1 → 11.0.0-beta.26506.3 へ更新（対象は以下の16パッケージ）
    • Microsoft.DotNet.CilStrip.Sources、Microsoft.DotnetFuzzing.TestData、Microsoft.NET.HostModel.TestData
    • System.ComponentModel.TypeConverter.TestData、System.Data.Common.TestData、System.Drawing.Common.TestData
    • System.Formats.Tar.TestData、System.IO.Compression.TestData、System.IO.Packaging.TestData
    • System.Net.TestData、System.Private.Runtime.UnicodeData、System.Runtime.Numerics.TestData
    • System.Runtime.TimeZoneData、System.Security.Cryptography.X509Certificates.TestData
    • System.Text.RegularExpressions.TestData、System.Windows.Extensions.TestData

パフォーマンスへの影響

影響なし（提供された情報に、パフォーマンスに関する記述はありません）

関連Issue

なし

その他

  • 変更はバージョン管理ファイル2点のみで、ランタイム・ライブラリのコード変更は含まれていません。
  • 提供された情報からは、公開APIの変更や破壊的変更の有無は読み取れません。
  • 更新差分：dotnet/icu、dotnet/runtime-assets

#134322 [release/10.0] Update dependencies from dotnet/xharness

概要

dotnet-maestro[bot] による自動依存関係更新のPRで、release/10.0 ブランチ向けに dotnet/xharness の依存パッケージを 11.0.0-prerelease.26461.1 から 11.0.0-prerelease.26506.1 へ更新します。更新元は xharness の main ブランチのビルド 20261006.1（コミット 91708f0daf7d7ffc3b5d61da591c3e598c1d600e）です。

変更内容

  • .config/dotnet-tools.json: xharness 関連ツールのバージョン更新（+1/-1）
  • eng/Version.Details.props: 依存パッケージのバージョンプロパティ更新（+3/-3）
  • eng/Version.Details.xml: 依存関係の定義（バージョンおよびコミット情報）更新（+6/-6）

更新対象パッケージ:

  • Microsoft.DotNet.XHarness.CLI
  • Microsoft.DotNet.XHarness.TestRunners.Common
  • Microsoft.DotNet.XHarness.TestRunners.Xunit

差分: cf433ea2ef...91708f0daf

パフォーマンスへの影響

影響なし（ビルド/テスト基盤の依存関係更新のみで、ランタイムの実装変更は含まれません）

関連Issue

なし

その他

  • 公開APIや内部実装の変更、互換性への影響は、提供された情報からは確認できません。
  • 更新後のバージョンは 11.0.0-prerelease 系で、PRの対象ブランチは release/10.0 です。
  • xharness 側の具体的な変更内容は提供情報に含まれていないため、上記の比較リンクで確認してください。

#134132 [release/9.0] Update dependencies from dotnet/emsdk

概要

Maestroボットによるrelease/9.0ブランチ向けの自動依存関係更新PRです。dotnet/emsdkの最新ビルド（20261008.5、コミット a84b7393）を取り込み、emsdk関連パッケージを 9.0.21 から 9.0.22 に更新します。あわせて、親依存関係との整合性を保つCoherency Updatesとして、LLVM/JITツール系パッケージを 19.1.0-alpha.1.26457.4 から 19.1.0-alpha.1.26505.5 に更新しています。

変更内容

  • eng/Version.Details.xml: 依存関係のバージョンとコミット情報を更新
    • Microsoft.SourceBuild.Intermediate.emsdk と Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport: 9.0.21-servicing.26464.5 → 9.0.22-servicing.26508.5
    • Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100: 9.0.21 → 9.0.22
    • Coherency Updates: Microsoft.NETCore.Runtime.JIT.Tools および Microsoft.NETCore.Runtime.Mono.LLVM.Sdk/Tools の各RID向けパッケージ（linux-arm64/x64、linux-musl-arm64/x64、win-x64、osx-arm64/x64 など）を更新
  • eng/Versions.props: 上記に対応するバージョンプロパティを更新
  • NuGet.config: 1行の変更（詳細は提供情報からは不明）

パフォーマンスへの影響

影響なし（提供された情報にパフォーマンスに関する記載はありません）。

関連Issue

なし

その他

  • 変更はバージョン番号・フィード設定などの依存関係メタデータに限られ、ランタイムやライブラリのソースコード、公開APIの変更は含まれません。
  • 影響範囲は主にWebAssembly（Emscripten）ワークロードおよびMono LLVM関連のビルド・ツールチェーンです。
  • 互換性への影響（破壊的変更など）は、提供情報からは確認できません。

#134020 [release/9.0] Update dependencies from dotnet/arcade

概要

release/9.0 ブランチで、Maestro（dotnet-maestro[bot]）により dotnet/arcade からの依存関係が自動更新されました。arcade のビルド 20261007.8（コミット ca4c91e、ブランチ release/9.0）が取り込まれ、9.0.0-beta.26458.10 から 9.0.0-beta.26507.8 へ、XUnit 関連は 2.9.0-beta.26458.10 から 2.9.0-beta.26507.8 へ更新されています。

変更内容

  • eng/Version.Details.xml: 依存パッケージ（Microsoft.DotNet.Arcade.Sdk、Build.Tasks 系、Helix.Sdk、RemoteExecutor、XUnit 系など）のバージョンとコミットSHAを更新 (+42/-42)
  • eng/Versions.props: 上記に対応するバージョンプロパティを更新 (+16/-16)
  • eng/common/core-templates/job/job.yml: 小規模な変更 (+2/-1)
  • eng/common/core-templates/steps/send-to-helix.yml: 大幅な変更 (+163/-61)
  • eng/common/sdl/extract-artifact-packages.ps1: ファイル全体が削除 (+0/-82)
  • global.json: 更新 (+5/-5)

更新対象の主な依存関係:

  • Microsoft.SourceBuild.Intermediate.arcade
  • Microsoft.DotNet.Arcade.Sdk
  • Microsoft.DotNet.Build.Tasks.（Archives / Feed / Installers / Packaging / TargetFramework / Templating / Workloads）
  • Microsoft.DotNet.（CodeAnalysis / GenAPI / GenFacades / Helix.Sdk / PackageTesting / RemoteExecutor / SharedFramework.Sdk / VersionTools.Tasks / XliffTasks / XUnitExtensions）
  • Microsoft.DotNet.XUnitAssert、Microsoft.DotNet.XUnitConsoleRunner（2.9.0-beta 系）

パフォーマンスへの影響

影響なし（ビルド・CI インフラおよび依存関係の更新であり、提供された情報にランタイムのパフォーマンスに関する変更は含まれていません）

関連Issue

なし

その他

  • 本PRは自動生成されたもので、変更はビルドインフラ（arcade）の更新に限られます。
  • 提供された情報からは、send-to-helix.yml や global.json の変更の具体的な内容、および互換性への影響の有無は確認できません。

#133926 [release/10.0] Update dependencies from dotnet/icu

概要

release/10.0 ブランチにおいて、dotnet-maestro[bot] による自動依存関係更新として、dotnet/icu からの Microsoft.NETCore.Runtime.ICU.Transport パッケージのバージョンを更新します。

  • 更新前: 10.0.0-rtm.26457.2
  • 更新後: 10.0.0-rtm.26505.2
  • 参照ビルド: dotnet/icu dotnet/release/10.0 ブランチ、コミット c526f8d7ef0c1c612cc232e509efb4e1cf881f1a

変更内容

  • eng/Version.Details.props: Microsoft.NETCore.Runtime.ICU.Transport のバージョン指定を更新 (+1/-1)
  • eng/Version.Details.xml: 同依存関係のバージョンおよびコミット情報を更新 (+2/-2)

公開API・ランタイム/ライブラリのソースコードの変更は含まれず、依存関係メタデータのみの更新です。

パフォーマンスへの影響

影響なし（提供された情報にパフォーマンスに関する記載はありません）。

関連Issue

なし

その他

  • Maestro サブスクリプション ID: db1ca3c9-37b3-43b6-a420-6f1f4040ce77
  • 更新の差分: dotnet/icu compare (771a0b0fc6...c526f8d7ef)
  • 新しい ICU Transport パッケージにどのような変更（ICUのバージョン更新、データ更新など）が含まれるかは、提供された情報からは確認できません。

#133387 [release/9.0-staging] Update dependencies from dotnet/runtime-assets

概要

release/9.0-staging ブランチ向けに、Maestro（dotnet-maestro[bot]）が dotnet/runtime-assets からの依存関係を自動更新するPRです。対象は各種テストデータ・補助パッケージで、バージョンを 9.0.0-beta.26404.4 から 9.0.0-beta.26473.1 へ更新します（取得元ビルド: 20260923.1、release/9.0 ブランチ、コミット ac1dbd1987d7ca08b7347ef51130b7d69f6cf58c）。

変更内容

  • eng/Version.Details.xml: 依存関係のバージョン定義を更新（+28/-28）
  • eng/Versions.props: 対応するバージョンプロパティを更新（+14/-14）

更新対象パッケージ（14件）:

  • Microsoft.DotNet.CilStrip.Sources
  • System.ComponentModel.TypeConverter.TestData
  • System.Data.Common.TestData
  • System.Drawing.Common.TestData
  • System.Formats.Tar.TestData
  • System.IO.Compression.TestData
  • System.IO.Packaging.TestData
  • System.Net.TestData
  • System.Private.Runtime.UnicodeData
  • System.Runtime.Numerics.TestData
  • System.Runtime.TimeZoneData
  • System.Security.Cryptography.X509Certificates.TestData
  • System.Text.RegularExpressions.TestData
  • System.Windows.Extensions.TestData

変更はバージョン定義ファイルのみで、ランタイム/ライブラリのコードや公開APIへの変更は含まれません。互換性への影響（破壊的変更・非推奨化）に関する記載もありません。

パフォーマンスへの影響

影響なし

関連Issue

なし

その他

  • 差分: dotnet/runtime-assets compare
  • Maestroサブスクリプション: e06e39ae-771e-498d-7895-08dcbc301dc2
  • 更新内容の詳細（各パッケージの具体的な変更点）は、提供された情報からは確認できません。

#133337 [release/11.0] Update dependencies from dnceng/internal/dotnet-optimization

概要

dotnet-maestro[bot] による自動依存関係更新PRです。release/11.0 ブランチで、dnceng/internal/dotnet-optimization から取得している最適化関連パッケージを 1.0.0-prerelease.26420.2 から 1.0.0-prerelease.26502.1 に更新します（ビルド 20261002.1、コミット f76644a0ec7ae579dd7ab1992dff419814c9f71f）。コードやAPIの変更はなく、バージョン定義の更新のみです。

変更内容

  • eng/Version.Details.props (+6/-6): 依存パッケージのバージョン値を更新
  • eng/Version.Details.xml (+12/-12): 依存パッケージのバージョンと参照コミット情報を更新
  • 更新対象パッケージ:
    • optimization.linux-arm64.MIBC.Runtime
    • optimization.linux-x64.MIBC.Runtime
    • optimization.windows_nt-arm64.MIBC.Runtime
    • optimization.windows_nt-x64.MIBC.Runtime
    • optimization.windows_nt-x86.MIBC.Runtime
    • optimization.PGO.CoreCLR

パフォーマンスへの影響

提供された情報にベンチマーク結果はありません。MIBC/PGO（プロファイル誘導最適化）関連のデータが更新されるため、ビルド成果物の最適化プロファイルに間接的な影響がある可能性がありますが、具体的な数値や影響範囲は情報からは不明です。

関連Issue

なし

その他

  • 公開API・ランタイム実装・互換性（破壊的変更や非推奨化）への影響を示す情報はありません。
  • セキュリティ修正やバグ修正に関する記載もありません。
目次