Windows版PyTorch nightlyがビルド失敗する「HIP compilerが動かない」「/machine:x64が見つからない」問題の原因と直し方

Windows環境でPyTorchのnightlyビルドを回していたら、CMakeのHIPコンパイラチェックで突然コケる――そんな事例がROCm/TheRockのIssue #3172として報告されています。症状は「HIP compilerが簡単なテストすらコンパイルできない」→ 追いかけると clang++: error: no such file or directory: '/machine:x64' が出て止まる、というものです。GitHub

Windows版PyTorch nightlyがビルド失敗する「HIP compilerが動かない」「/machine:x64が見つからない」問題の原因と直し方

何が起きているのか（結論：リンカ向けのMSVC形式フラグが“入力ファイル扱い”されている）

Issue #3172 のログでは、HIPコンパイラとして clang++.exe（Clang 22系）が見つかり、CMakeが「HIPコンパイラのABI情報」を検出しようとして失敗しています。ポイントはここです。GitHub

-- The HIP compiler identification is Clang 22.0.0 with GNU-like command-line（GNUライクなドライバ）
その直後、リンク工程で clang++: error: no such file or directory: '/machine:x64'

/machine:x64 や /ignore:4099 は、MSVCのリンカ（link.exe）や lld-link に渡すための 「/から始まるオプション」 です。ところが、ログ上の clang++ は “GNU-like command-line” と認識されており、/machine:x64 をオプションではなく「パス（入力ファイル）」として解釈してしまいます。結果として「そんなファイルはない」と怒られて落ちます。GitHub

つまり本質は「MSVC流のリンカフラグを、GNUライクなclang++にそのまま渡している」ミスマッチです。

ログの読みどころ：失敗しているのは“コンパイル”ではなく“リンク”

Issueの該当箇所では、まず .hip をオブジェクト化する工程（-x hip -c）は進んでいます。落ちているのは次のリンク工程で、ここに /machine:x64 が“素の引数”として混ざっています。GitHub

-fuse-ld=lld-link は付いている（＝最終的に lld-link を使いたい意図はある）
しかし /machine:x64 などが -Xlinker で包まれていない
→ clang++ 側が受け取ってしまい、ファイル扱いでエラー

このため、「HIPコンパイラが壊れている」というより、CMakeのTryCompile（CMakeTestHIPCompiler）が作るリンクコマンドの引数の渡し方が原因になっています。GitHub

すぐ効く回避策（CIでもローカルでも優先度順）

ここからは“今すぐビルドを通す”ための実務寄りの選択肢です。プロジェクト側での恒久対応が入るまでの応急処置として使えます。

1) clang-cl（MSVC互換ドライバ）に寄せる：最も安定しやすい

根本は「GNUライクなclang++にMSVC形式フラグが混ざる」ことなので、最初からMSVC互換のフロントエンド（clang-cl）で統一できると事故が減ります。

C/C++/HIPでコンパイラの“フロントエンド流儀”を揃える
可能なら、CMakeに「clang-clを使う」前提で設定する

プロジェクトによって指定方法は異なりますが、狙いは一貫して「/machine:x64 を“オプション”として解釈できるドライバにする」ことです。

2) clang++ を使うなら、MSVCリンカフラグを `-Xlinker` で渡す

ログを見ると /subsystem:console だけは -Xlinker が付いている一方、/machine:x64 や /ignore:**** が裸で渡されています。GitHub
この場合の筋の良い修正は、それらもリンカ引数として明示的に渡すことです。

例：-Xlinker /machine:x64 -Xlinker /ignore:4049 ...

「どの変数／どのCMakeモジュールがそのフラグを足しているか」は環境次第ですが、考え方は単純で、“/で始まるものはclang++の引数にしない” がルールになります。

3) “混線”を防ぐ：途中でツールチェーンの流儀を切り替えない

今回のログでは、HIPコンパイラはGNUライク、しかしリンクフラグはMSVC流儀、という混線が起きています。GitHub
WindowsのCMakeは、コンパイラ検出やジェネレータ（Ninja/VS）選択、環境変数、SDKの取り込み順で挙動が変わりがちです。

C/C++/HIPで「同じ系統（MSVC互換 or GNU互換）」に揃える
CIではセットアップ手順を固定化し、途中でPATHや環境を差し替えない
可能なら「既知の動く組み合わせ（CMake/LLVM/Windows SDK）」をピン留めする

恒久対応の方向性：直すべきは「/machine:x64 を clang++ の生引数にしない」一点

Issue #3172 は、Windows×nightly×複数Pythonバージョン×全アーキに影響し得る、と報告されています。GitHub
このタイプの失敗は、個別のGPUアーキやPyTorch側のソース変更というより、ビルド基盤（CMakeの検出・ツールチェーンの取り回し）が“ある日突然”崩れるのが厄介です。

恒久対応としては次のどれかに収束するのが現実的です。

HIPコンパイラに clang-cl系（MSVC互換） を採用して、/オプションが自然に通るようにする
clang++系を使うなら、CMake側（HIPのTryCompile含む）で MSVCリンカフラグを必ず -Xlinker 経由にする
そもそもCMakeの「GNU-like / MSVC-like判定」とフラグ付与がズレないよう、ツールチェーン記述を整理する

今回のエラーメッセージは派手ですが、実体は「引数の渡し方の事故」です。ログのリンク行を見て、/machine:x64 が “リンカへ渡っているか”ではなく、“clang++が食っていないか” をチェックすると、切り分けが一気に進みます。GitHub

まとめ：まずは“/フラグの扱い”を疑うと最短で直せる

clang++: error: no such file or directory: '/machine:x64' は、ファイル欠損というより オプション解釈のズレ
“GNU-like clang++” に “MSVC形式の/リンカフラグ” が混ざるのがトリガー
回避は clang-clに寄せる か、/フラグを -Xlinker で包む のが鉄板

Windows上でAMD ROCm系のPyTorchビルドを回しているなら、同種の崩れ方（リンク段でのオプション解釈ミス）は再発しやすいです。CIが落ちたときは、最初に「リンクコマンドに“裸の /machine:*”が混ざっていないか」を確認するのが、いちばんコスパの良い初動になります。GitHub