Windows版PyTorch nightlyが突然ビルド不能に？「/machine:x64」エラーの正体とCI修正の勘所

Windows向けのPyTorch nightlyビルドが、ある日を境にまとめて失敗する──しかも原因は「HIPコンパイラが簡単なテストすら通せない」「/machine:x64 が見つからない」という一見ちぐはぐなログ。実はこれ、ROCm系のWindowsビルドで“たまに起きる”典型的な事故パターンです。ログの読み解き方と、CI/ローカル双方で効く回避策・恒久対応の方向性を整理します。 GitHub

Windows版PyTorch nightlyが突然ビルド不能に？「/machine:x64」エラーの正体とCI修正の勘所

何が起きたのか：CMakeのHIPコンパイラ検査で総崩れ

問題が表面化したのは、ROCmの開発用ビルド基盤である TheRock のWindows向けPyTorch nightlyビルド工程です。CMakeが enable_language(HIP) 相当の流れでHIPコンパイラを検査する段階（CMakeTestHIPCompiler.cmake）で失敗し、結果としてビルド全体が止まっています。ログ上は Clang 22.0.0（GNU-like CLI） としてHIPコンパイラを認識しているのに、テストリンク時に落ちています。 GitHub

重要ログはここだけ見ればいい：失敗の瞬間

失敗のコアは次の2点です。

CMakeのTryCompileで clang++.exe がリンク工程まで担当
そのclang++に MSVCリンカ向けの /machine:x64 や /ignore:**** が“そのまま”渡っている

結果、clang++は /machine:x64 を「入力ファイル名」と解釈してしまい、こうなります。

clang++: error: no such file or directory: '/machine:x64'
clang++: error: no such file or directory: '/ignore:4049' …etc GitHub

ここまで来るとHIP以前の問題で、ツールチェーン（コンパイラ/リンカ/フラグ体系）が混線しています。

なぜ「/machine:x64」がファイル扱いになるのか：MSVC系フラグとClangドライバのズレ

ポイントは「ClangにもWindows向けの2つの顔がある」ことです。

clang-cl：MSVC互換のコマンドライン（/machine:x64 などを理解しやすい）
clang++（GNU-like）：GCC風のドライバ。MSVCの/machine:x64は通常“オプション”として処理されず、入力扱いになりがち

今回のログには「GNU-like command-line」と明記されています。つまり “clang-clであるべき場面にclang++が立っている” か、あるいは CMakeがMSVC前提のリンクフラグを生成している のに コンパイラ側がGNU-like というミスマッチです。 GitHub

似た構図（MSVCのフラグがclang++に流れ込む）は、別プロジェクトでも報告されており、根は「途中でC/C++コンパイラ設定が切り替わり、フラグの体系だけがMSVCのまま残る」タイプの事故です。 GitHub

影響範囲：nightly・Windows・アーキ全般が巻き込まれる理由

当該Issueでは「Windows」「PyTorch nightly」「複数Python版」「全サポートアーキ」とされています。これは、問題が特定GPUや特定コードではなく、**CMakeのTryCompile（環境検査）**という“全員が必ず通る関門”で落ちているからです。いったんここが崩れると、対象マトリクスが全部赤くなります。 GitHub

まず通すための実務的な回避策（ローカル/CI共通）

ここからは「いま動かす」ための手当です。基本方針は1つだけ。

CMakeに“同じ流儀のツールチェーン”を最後まで使わせる。

1) clang-clに寄せて、MSVCフラグ体系で統一する（安定寄り）

Windowsで /machine:x64 系が出るなら、最初から clang-cl で統一するのが手堅いです。

bat

cmake -G Ninja -B build ^
  -DCMAKE_C_COMPILER=clang-cl ^
  -DCMAKE_CXX_COMPILER=clang-cl ^
  -DCMAKE_LINKER=lld-link

※環境によっては llvm-rc や mt.exe 等も必要になります。CI側で揃っていないと、別のところで落ちます。

2) GNU-like clang++を使うなら、MSVCフラグを“リンカへ渡す形”にする（攻め寄り）

GNU-like clang++でWindowsリンクをする場合、MSVCスタイルのオプションは通常 -Xlinker（または -Wl,）でリンカへ渡します。今回の失敗は /machine:x64 が裸で渡っている点なので、CMake側が生成するリンクフラグの付け方を直す必要があります（手元で一時的にフラグを差し替える、あるいはCMake/ツールチェーンファイルで調整）。

この方向は“CIの恒久修正”向きで、場当たり対応だと再発しがちです。

3) 「混線」を防ぐ：CMake上でC/C++/HIPを途中で切り替えない

混線の典型は、構成の途中で CMAKE_CXX_COMPILER などが変わり、フラグやリンカ設定だけが置き去りになるケースです。実際、別件でも「CMAKE_CXX_COMPILERがMSVC→clang++に変わった結果、MSVCフラグがclang++に渡る」状況が報告されています。 GitHub

CIでやるなら「最初から最後まで同じコンパイラ体系」を固定するのが最短です。

恒久対応の方向性：CIが直すべき“1行の本質”

この障害の本質は、HIPというより Windowsのリンクフラグ生成がMSVC前提のまま、コンパイラがGNU-like clang++として動いている点です。 GitHub
TheRockは「最新ROCmを軽量に試せる開発用ビルド基盤」を掲げている分、nightlyの更新や環境差分の影響を受けやすい面があります。 GitHub

CIの恒久対応としては、概ね次のどちらかに寄せるのが現実的です。

WindowsのHIPビルドは clang-cl 系で通す（フラグ体系をMSVC互換に固定）
GNU-like clang++ を使うなら、CMake（またはツールチェーンファイル）でリンクフラグの受け渡しを正規化（/machine:x64 を裸で渡さない）

どちらを選んでも、「CMakeのTryCompileでリンクが通る」状態さえ作れれば、夜間ビルドの赤化は止まります。

まとめ：ログの違和感は“HIPの不具合”ではなく“Windowsツールチェーン事故”のサイン

「HIPコンパイラが簡単なテストをコンパイルできない」は表面症状
本当の原因は clang++（GNU-like）にMSVCリンカフラグが裸で渡っていること GitHub
回避の最短ルートは clang-cl寄せでフラグ体系を統一、恒久対応は CIのツールチェーン固定または リンクフラグの正規化

この手の障害は、原因箇所が“コード”ではなく“環境検査（TryCompile）”にあるため、いったん理解すると切り分けが劇的に速くなります。今後同様のエラーを見たときも、まずは「コンパイラのフロントエンド（clang-clかclang++か）」と「リンカフラグの流儀が一致しているか」を疑うのが正解です。