Your message dated Sun, 27 Sep 2026 06:49:29 +0000
with message-id <[email protected]>
and subject line Bug#1141868: fixed in llvm-toolchain-22 1:22.1.8-2
has caused the Debian Bug report #1141868,
regarding llvm-toolchain-22: AMDGPU codegen crash on gfx110x (RDNA3):
"Unsupported instruction : <MCInst NNNN ...>"
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1141868: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141868
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Source: llvm-toolchain-22
Version: 1:22.1.2-1ubuntu1
Severity: important
Dear Maintainer,
clang-22 (Debian package `1:22.1.8-1+b1`, upstream `llvmorg-22.1.8`) fatally
aborts on any HIP or LLVM IR translation unit that contains an `amdgpu_kernel`
whose CFG includes a block ending in `llvm.trap()` with no successors, when
targeting **gfx1100, gfx1101, or gfx1102** (RDNA3 desktop: RX 7900, RX 7800, RX
7700, RX 7600):
``` fatal error: error in backend: Unsupported instruction : <MCInst 4399
<MCOperand Reg:7675> <MCOperand Reg:7679> <MCOperand Reg:7675>> clang++: error:
clang frontend command failed with exit code 70 ```
The trigger is common enough to make real packages FTBFS. In particular,
`pytorch-rocm` 2.12 (built from `src:pytorch`) hits this on
`aten/src/ATen/native/hip/Loss.hip` (NLL loss backward) for every ROCm 7.2 build
on gfx110x; the pytorch packaging currently ships a `debian/rules` workaround
that filters gfx1100/gfx1101/gfx1102 out of `PYTORCH_ROCM_ARCH`, so those RDNA3
desktop cards get no accelerated PyTorch in Debian.
## Root cause
`SIInstrInfo::insertSimulatedTrap` returns `HaltLoopBB` when the trap sits in a
block with no successors and is the last instruction. Since `HaltLoopBB` is
appended to the end of the function, `FinalizeISel` jumps there and skips any
intermediate blocks, **leaving their pseudos unexpanded**. Those unexpanded
pseudos reach the MC layer, which has no encoding for pseudo opcodes — hence
"Unsupported instruction : <MCInst NNNN ...>".
Full details, minimal reproducer, and arch matrix in the upstream issue:
https://github.com/llvm/llvm-project/issues/208912
## Fix
Upstream commit `9429a1e809fdf05e1eef1350f27569ae53ccd721`
(https://github.com/llvm/llvm-project/pull/174774) — *"[AMDGPU] Fix
insertSimulatedTrap to return correct continuation block"*.
Merged to `main` on 2026-01-21. `release/22.x` was cut from `main` at merge-base
`e9f758a59b2f` (2026-01-13), **eight days before this fix landed**, and no
subsequent 22.x point release has picked it up. The fix will first appear in an
upstream LLVM 23 release.
The patch is small (10 lines in `llvm/lib/Target/AMDGPU/SIInstrInfo.cpp`;
upstream also adds a 56-line MIR test) and self-contained — no dependent
commits, no API changes.
## Reproducer
```llvm
target triple = "amdgcn-amd-amdhsa"
declare void @llvm.trap() #0
define amdgpu_kernel void @kern(i64 %0, i1 %1, ptr %2) {
br i1 %1, label %5, label %4
4:
call void @llvm.trap()
unreachable
5:
%6 = getelementptr double, ptr %2, i64 %0
store double 0.000000e+00, ptr %6, align 8
ret void
}
attributes #0 = { cold noreturn nounwind memory(inaccessiblemem: write) }
```
Save as `reduced.ll`, then:
```
llc-22 -mtriple=amdgcn-amd-amdhsa -mcpu=gfx1102 -O3 -filetype=obj reduced.ll -o
/tmp/out.o
```
- Without the fix (current `1:22.1.8-1+b1`): fatal error, exit 134.
- With the fix (patched 22.1.8, or clang-23 nightly from apt.llvm.org): exits
0, produces a valid `.o`.
Same arch matrix: only gfx1100, gfx1101, gfx1102 fail. All other AMDGPU targets
(gfx803, gfx900, gfx906, gfx908, gfx90a, gfx942, gfx1010, gfx1030, gfx1151,
gfx1200, gfx1201) build cleanly with and without the fix.
## Verification
I have cherry-picked the upstream commit onto `1:22.1.8-1` as a quilt patch,
rebuilt `llvm-toolchain-22` locally with the patch applied, then rebuilt
`src:pytorch` (ROCm variant) with `gfx1100/gfx1101/gfx1102` re-enabled in
`PYTORCH_ROCM_ARCH`. The pytorch build succeeded —
`aten/src/ATen/native/hip/Loss.hip` (previously the FTBFS point) compiles
cleanly on all three affected archs, and the resulting `libtorch_hip.so` links.
## Regression risk
Very low.
- Fix is a 10-line diff in a single AMDGPU-specific file (`SIInstrInfo.cpp`).
- It only changes what `insertSimulatedTrap` returns; the previously-returned
block was an incorrect "signal to skip intermediate expansion" that produced
the malformed MI stream the MC layer refuses to encode.
- Every AMDGPU target uses the same code; the visible failure was
gfx110x-specific because the MCInst opcode table happens to slot a pseudo
there in a way that the gfx11 MC encoder catches. Other targets were saved by
ordering luck; the corrected return value strictly improves behavior across
the board.
- Upstream ships an accompanying MIR test
(`llvm/test/CodeGen/AMDGPU/simulated-trap-pseudo-expand.ll`) to lock it in.
## Cross-references
- Upstream LLVM: https://github.com/llvm/llvm-project/issues/208912
- Ubuntu Launchpad: https://bugs.launchpad.net/bugs/2160428
-- System Information:
Debian Release: forky/sid
APT prefers resolute-updates
APT policy: (500, 'resolute-updates'), (500, 'resolute-security'), (500,
'resolute')
Architecture: amd64 (x86_64)
Kernel: Linux 7.0.0-27-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---
Source: llvm-toolchain-22
Source-Version: 1:22.1.8-2
Done: Matthias Klose <[email protected]>
We believe that the bug you reported is fixed in the latest version of
llvm-toolchain-22, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Matthias Klose <[email protected]> (supplier of updated llvm-toolchain-22 package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sat, 25 Jul 2026 18:43:43 +0200
Source: llvm-toolchain-22
Architecture: source
Version: 1:22.1.8-2
Distribution: unstable
Urgency: medium
Maintainer: LLVM Packaging Team <[email protected]>
Changed-By: Matthias Klose <[email protected]>
Closes: 1137244 1138702 1141868 1142548 1142778 1147573
Changes:
llvm-toolchain-22 (1:22.1.8-2) unstable; urgency=medium
.
[ Sylvestre Ledru ]
* d/rules: retry the documentation build serially when sphinx's parallel
workers die (bare "EOFError" from multiprocessing after a successful
compile, trixie amd64/arm64 2026-09-02/03)
* d/rules: set SCCACHE_IDLE_TIMEOUT=0 so the sccache server stays alive for
the whole build; otherwise it idles out (default 600s) during the quiet
final-link phase and the libfuzzer step auto-spawns a default-config server
writing to $HOME/.cache/sccache, which fails with HOME=/nonexistent
* d/rules: use the shared GCS sccache cache on arm64 too (add arm64 to the
GCP arch filter)
* d/rules: Disable sccache on the releases whose glibc is too old for the
binary the build host provides. /opt/sccache/sccache comes from
mozilla/sccache's latest release and, on s390x (the only arch without a
static musl build), needs glibc >= 2.34 since v0.17.0. On focal
(glibc 2.31) it cannot even start, and the build died at --start-server
with "version `GLIBC_2.34' not found" in stamps/configure.
* d/rules: Drop llvm-mt from the install list when it wasn't built.
Upstream only builds llvm-mt when it detects libxml2 at configure
time; on Ubuntu focal/arm64 the libxml2 symbol check fails and the
tool is silently skipped, which made dh_install --fail-missing abort
on usr/lib/llvm-22/bin/llvm-mt and usr/bin/llvm-mt-22.
* Add a test for the wasi path detection. Thanks Max Gilmour for the work
(Closes: #1138702)
* d/control.in: libfuzzer-X.Y-dev now depends on libclang-rt-X.Y-dev.
-fsanitize=fuzzer links libclang_rt.fuzzer*.a (and
libclang_rt.ubsan_standalone.a) from the compiler-rt resource
directory, which lives in libclang-rt-X.Y-dev. As it was only a
Recommends of libclang-common-X.Y-dev, it was not pulled into build
chroots and the link failed. Closes: #1147573.
* d/debian-llvm-testsuite.bats: don't skip the libFuzzer compilation test
when the compiler-rt libraries are missing, fail instead.
* d/libmlir-X.Y.links.in: new, keep a /usr/lib/llvm-X.Y/lib symlink to the
libMLIR SONAME now installed in /usr/lib/<triplet>. libmlir-X.Y-dev
ships /usr/lib/llvm-X.Y/lib/libMLIR.so as a relative symlink to it and
the mlir tools have that directory in their RUNPATH, so both were left
dangling.
* d/debian-llvm-testsuite.bats: link the fuzzer runtime from the
compiler-rt resource directory instead of the removed
/usr/lib/llvm-X.Y/lib/libFuzzer.a, and check that it is present.
* d/control.in: document that libfuzzer-X.Y-dev is now a dependency
package: the fuzzer runtime (libclang_rt.fuzzer*.a) and
FuzzedDataProvider.h come from the compiler-rt resource directory in
libclang-rt-X.Y-dev, which is what clang links for -fsanitize=fuzzer.
This also avoids the empty-binary-package lintian warning.
.
[ Talha Can Havadar ]
* d/p/amdgpu-fix-simulated-trap-continuation-block.diff: cherry-pick
llvm/llvm-project@9429a1e809fd (PR #174774,
"[AMDGPU] Fix insertSimulatedTrap to return correct continuation block")
Fixes a codegen crash on gfx1100/gfx1101/gfx1102 (RDNA3 desktop:
RX 7900/7800/7700/7600) where clang aborts with
"fatal error: error in backend: Unsupported instruction : <MCInst NNNN
...>"
from the AMDGPU AsmPrinter whenever a kernel contains a block that ends in
llvm.trap() with no successors — an unlowered pseudo reaches the MC layer.
Notably affects pytorch-rocm 2.12's Loss.hip (FTBFS). Reported upstream as
llvm/llvm-project#208912. Fix landed on main branch on 2026-01-21 (LLVM
23);
release/22.x was cut 8 days before and never received it. This cherry-pick
lets 22.1.x carry the fix without waiting for a 22.1.9 or 22.2.0 point
release upstream. (Closes: #1141868)
.
[ Matthias Klose ]
* Fix removing RUNPATH, broken in Nov. 2025. Closes: #1142548.
* Stop building, shipping and testing the obsolete libFuzzer.a.
Closes: #1147573.
* Install libmlir shared library in /usr/lib. Closes: #1142778.
* libmlir: Remove provides, conflicts and replaces. Not needed.
Closes: #1137244.
Checksums-Sha1:
441066bfcd3adc8e2d99092a416906683559e6fb 15824 llvm-toolchain-22_22.1.8-2.dsc
ac4e52194d08bd94088cc58c0a3afd9bc6823eae 183300
llvm-toolchain-22_22.1.8-2.debian.tar.xz
58bf3666d647d57bc4e001cc8fcba9bf97cc8fe8 39282
llvm-toolchain-22_22.1.8-2_amd64.buildinfo
Checksums-Sha256:
4df4e778010d03006998ff484996c9d12e7875da129bcaad1cf4e4dbc76abe62 15824
llvm-toolchain-22_22.1.8-2.dsc
ecee9142cfd59c24ddd97710838cdad4c77558885911f97fa5a310c9e756d842 183300
llvm-toolchain-22_22.1.8-2.debian.tar.xz
c01220676b53d2f10d65f51afe65d40e1390084263859b04526a3d0c21718f53 39282
llvm-toolchain-22_22.1.8-2_amd64.buildinfo
Files:
d8b0a2317fb951bb40bd920273db37b9 15824 devel optional
llvm-toolchain-22_22.1.8-2.dsc
9c21723eb868497995784b37aa5c48d1 183300 devel optional
llvm-toolchain-22_22.1.8-2.debian.tar.xz
5772cfc89523702690dbaa2c71d9569e 39282 devel optional
llvm-toolchain-22_22.1.8-2_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEtg21mU05vsTRqVzPfmUo2nUvG+EFAmq4uYEACgkQfmUo2nUv
G+F+2w//T1x5wwShiqYbEO5m37NwCnNo5ANLiHFmDotqPRZtWDcJQr7BRX+PMBUh
XaeumbpRBjid960fbOhCeRUO9250iBe3qvpxtX9naL6uhE1hYxFFzTM6HIOJkCc7
Wf7vvHY7p9IFFivvSh+WTPC+dQJveIfEg9h3CH+aauLvKzLnwqUMltc/WPfUTwxE
HnmT+JVQVJNqid74mPCmD3GByBvqewm6+IpLNvXpIPQdPsDQQ+YcxturAnYAei27
ybr1n9jozrdCu4MiCOhSL3Pvi0zFeoq+EaD9ptFPnAD7JdY+Z7pdd6VMqWSPU+uH
7B/omJQXinGMwKTtY/sRWM5nntvkkdS/LDk/kosUl/+xJ3o064o/8flZlnyvxV15
ndKU7K0qjzwAJLI8ML+1H+8sjiSkGPhpY3ZCVhIQJShywfhSPTMS/icCqUFq14pr
8zGAqDjKEMPRRf2YKC8H4SRU40t4k2PRDHJxiczGa65kAqDNIyXdwXjtYPIbSR+C
Cc7J7kwjRZyfJaZaMqdnpEzmqRJJUa0ddIjJNi30CobghdiCwhF5mHUjGmUPgKK/
oYMTlPwTsLX/BW6XLyXyusrADZWa8SVfWUwZZMP9k/ELZgNXcU/3gUDL7GgoWUXx
qflZVIqNhicqtdWTTo81NB1u4SXBJyKApXhSBxw9H4jYuoIiJwk=
=Q/6H
-----END PGP SIGNATURE-----
pgpGiwA2iY2hL.pgp
Description: PGP signature
--- End Message ---
