commit d851524a91bf5b3f3719b01ee3320524d426a990
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 09:15:49 2026 +0200

llvm-core/rocm-llvm: normalize LTO bug reference

commit ee1a8b887b6e599fa4ee67e614b393ee5cfc7195
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Thu Sep 10 00:14:19 2026 +0200

llvm-core/rocm-llvm: trim 10.0.0-r1 comment prose

commit 0036a272edf452880c22f036f5570b4ff2f0d59e
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Sep 9 17:30:20 2026 +0200

llvm-core/rocm-llvm: take ::gentoo's LLVM build-flag policy

Three settings llvm-core/llvm carries that this ebuild did not. All
three are about building LLVM itself, not about the -flto consumers
later hand to the compiler it produces -- that is the gold plugin's
job, and the two changes are complementary.

- tc-is-gcc && filter-lto. ::gentoo drops LTO from its own LLVM
build for GCC only, citing ODR violations and GCC being the
likelier of the two compilers to miscompile LLVM under LTO
(Gentoo bugs 917536 and 926529). Same sources, same exposure. It
also stops an LTO user from building this compiler with GCC LTO
while asking it to link their own code with LTO.
- append-flags -fno-strict-aliasing, for llvm-project issue 219693.
- LLVM_UNREACHABLE_OPTIMIZE=OFF. With assertions off,
llvm_unreachable() degrades to __builtin_unreachable(): reaching
one stops being a crash and becomes undefined behaviour the
optimiser may exploit. OFF makes it a guaranteed trap instead.
This ebuild already records a case of LLVM's own invariants being
violated in AMDGPU codegen, so a trap is worth more here than a
quietly miscompiled kernel.

Adopted rather than re-derived: the miscompiles behind the first two
were not reproduced. What was checked is that filter-lto really does
remove -flto from the configure flags, that -fno-strict-aliasing
survives into them, and that LLVM_UNREACHABLE_OPTIMIZE is a real
option in this snapshot rather than one cmake ignores.

commit a5be8d8470db5bdf51960233b997c20922d9ef95
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Sep 9 17:25:07 2026 +0200

llvm-core/rocm-llvm: build LLVMgold.so for -flto through GNU ld

GNU ld is this compiler's default linker, and clang puts

-plugin <its own bin dir>/../lib/LLVMgold.so

on the ld command line for every -flto link, and only for those. The
plugin was never built, so a user whose flags carry -flto cannot
configure any ROCm library that goes through rocm_use_clang(): cmake's
compiler test fails at the link step with "error loading plugin: ...
No such file or directory". Nearly fifty ebuilds here route through
that eclass helper. clang skips the plugin for lld, so selecting that
linker is a way out, but the default GNU path has to work.

LLVM_BINUTILS_INCDIR is all it takes. llvm/tools/gold already ships in
the subtree src_unpack extracts, LLVM_ENABLE_PIC is on, and the plugin
installs to ${prefix}/lib/LLVMgold.so -- the exact path clang probes,
since this build sets no libdir suffix.

Unconditional rather than a USE flag. plugin-api.h comes from
sys-libs/binutils-libs, which is needed at build time only: ld dlopens
the finished plugin, which resolves libLLVM through its own
origin-relative RPATH. It is the same header llvm-core/llvm already
pulls for its default +binutils-plugin, and llvm-core/llvm is in this
package's own dependency graph through dev-libs/rocm-device-libs.
Switching it off would buy nothing but a way back into this failure
for everyone who has not also moved to lld.

llvm-core/llvmgold is deliberately not pulled the way llvm-core/llvm
pulls it: that package symlinks the plugin into
/usr/<CHOST>/binutils-bin/lib/bfd-plugins, where ld autoloads it for
every link on the system, and this compiler stays out of shared paths.

Rides the same revision as the compiler-rt flag fix, so one rebuild
covers both. Reported in https://github.com/istitov/stuff/issues/284

commit 21e92df0cf918af123da16b5620d1cfe8a5c9454
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Wed Sep 9 17:25:07 2026 +0200

llvm-core/rocm-llvm: revbump 10.0.0 for the compiler-rt flag leak

LLVM_ENABLE_RUNTIMES hands compiler-rt to two nested ExternalProjects
that are configured part-way through the build and compiled with the
clang this package has just produced, not with the compiler that built
the host side. Those nested cmake runs inherit the build environment,
and cmake seeds CMAKE_<LANG>_FLAGS from CFLAGS and CXXFLAGS, and the
three CMAKE_*_LINKER_FLAGS from LDFLAGS, whenever the variable is not
given explicitly. A GCC-only flag from make.conf -- -fipa-pta,
-fgraphite-identity, -fdevirtualize-at-ltrans, -flto-partition=none --
is therefore handed to clang, which rejects it outright, and the build
dies hours in, after gcc has already compiled the entire compiler with
those same flags without complaint. The report carries no log, so the
particular flag is not known; the mechanism is what was reproduced.

Set the six flag variables for both sub-builds explicitly, since a
value on the command line beats the environment. The compiler ones go
over empty. LDFLAGS is filtered rather than emptied, down to its -Wl,*
and -L entries: those keep their meaning under any driver, and dropping
them would cost the user's link-time hardening and search paths. It is
a whitelist, so a GCC-only driver option in LDFLAGS is discarded
without anyone having to enumerate it first. The remaining cost is that
compiler-rt is compiled with no user CFLAGS or CXXFLAGS at all -- no
user optimisation level, no -march. Everything else here is still
built with the full set.

Two fixes ride along, because they land in those same sub-builds:

- CMAKE_BUILD_TYPE=Release moves from mycmakeargs to the eclass
variable. cmake.eclass appends its own -DCMAKE_BUILD_TYPE after
mycmakeargs, so the old form never took and the build ran as
RelWithDebInfo. The flags this build compiles with are unchanged
either way; what changes is the per-config default the sub-builds
inherit, from -O2 -g -DNDEBUG to -O3 -DNDEBUG, on top of which
compiler-rt still layers its own per-target flags.
- LLVM_ENABLE_TERMINFO no longer exists in LLVM 23 and cmake was
reporting it unused, so drop it. Nothing pulls in tinfo or
ncurses without it.

Reported in https://github.com/istitov/stuff/issues/282

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.