commit f80760b390e3549cfa0ed4b5074c49c2847896f6
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Aug 30 18:58:05 2026 +0200

llvm-core/rocm-llvm: use an explicit sentinel in src_install

The resource-dir loop signalled "found" by assigning to t, which is the
iteration variable of the preceding `for t in clang clang++` loop. The
die-on-no-resource-dir guard therefore rested on an accident: it worked only
because that loop leaves t="clang++", which happens not to equal "found".
Change the first loop's last element to "found", or reorder the two blocks,
and the guard silently stops guarding -- rocm-llvm would then install without
the device-lib symlink and every HIP compile through it would fail with
"cannot find ROCm device library", with no build-time error.

The loop already declared `local rd` but no sentinel. Declare `found=` beside
it and test -n instead.

No behaviour change: verified in isolation that both forms pass when a clang
resource dir exists and both die when none does, and that only the new form
still dies under the aliasing case above.

commit acf1c594cd5d76fc276a2d0500c3de86aefbc7ef
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sun Aug 30 00:50:55 2026 +0200

llvm-core/rocm-llvm: new package, AMD's LLVM fork at 10.0.0

The ROCm math libraries cannot be compiled by a vanilla LLVM. AMD builds ROCm
against its own fork, and two divergences block the build outright -- verified
with minimal reproducers against clang 23.1.0 vs this package:

__builtin_amdgcn_wmma_f32_16x16x16_bf16_w32
vanilla declares it taking short __attribute__((ext_vector_type(16)));
AMD's fork uses bf16, which is what sci-libs/composable-kernel passes.
v_max_f16 with an abs() source modifier on gfx1150
vanilla's assembler rejects it ("operands are not valid for this GPU or
mode"); AMD's accepts it. TensileLite GENERATES this, so it cannot be
patched away in sci-libs/hipBLASLt.

Adds no new distfile: this is the SAME llvm-project-therock archive that
dev-libs/rocm-device-libs, dev-libs/rocm-comgr and dev-util/hipcc already
fetch, so MY_P is byte-identical to theirs and the DIST entry is shared. They
unpack amd/; this unpacks the compiler.

Scoped to what ROCm needs rather than a general LLVM: AMDGPU;X86, clang+lld,
compiler-rt as a runtime, no tests/docs/bindings. src_unpack extracts only the
needed subtrees -- the archive also carries flang, mlir, lldb, bolt and libsycl.
Three of those subtrees are non-obvious and are commented in place: libc/ (llvm
unconditionally include()s FindLibcCommonUtils), openmp/ (an AMD-fork addition
-- clang/lib/CodeGen/CGEmitEmissaryExec.cpp hard-includes an OpenMP device
header), and libunwind/include/mach-o (lld's MachO backend, exactly as
::gentoo's llvm-core/lld does it).

Installs to a private /usr/lib/rocm-llvm with NO env.d and NO /usr/bin
symlinks: shadowing the system clang would be far worse than the problem this
solves. Two integration details make it usable from Gentoo:
- CHOST-prefixed clang/clang++ symlinks, because rocm.eclass's
rocm_use_clang() builds CC/CXX as "${hipclangpath}/$-clang".
- a device-library symlink into this clang's resource dir, since
rocm-device-libs only wires up the system clang's. Note the layout differs:
::gentoo's llvm sets LLVM_LIBDIR_SUFFIX so it uses lib64/amdgcn, this build
wants lib/amdgcn, so the version component is globbed rather than hardcoded.

Not masked: it collides with nothing and is inert unless something asks for it.