[qt/clang/llvm]: Summary of bulk changes made

KDE Git Services - Bulk Change <[email protected]> Wed, 5 Aug 2026 12:12:21 +0000 (UTC)
Newsgroups gmane.comp.kde.cvs
Message-ID <[email protected]>
Git repository change summary for qt/clang/llvm
Pushed by mirror-service into branch 'upstream/users/vchuravy/hlfir-pipeline-plugin-example'.
Changed from 4e51478f4397689a74bca7e24f6708a1791df26f to 3e8c6925cc0b5f40b0d6231a80bef8e5b317a950
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.

This change contains the following new commits:

Git commit 2edd9676cfe19fb1594bda71268492532d65dbdc by GitHub (on behalf of Alexander Richardson) on 05/08/2026 at 05:20..
[ELF][RISC-V] Add baseline test for ignored ABI behaviour

No change intended here, just adding this test coverage to show that
https://github.com/llvm/llvm-project/pull/213410 does not change it.

Pull Request: https://github.com/llvm/llvm-project/pull/214079
https://invent.kde.org/qt/clang/llvm/-/commit/2edd9676cfe19fb1594bda71268492532d65dbdc

Git commit c08ed4c1ab086aad6f22cfc499e74d92953045ae by GitHub (on behalf of Zeyi Xu) on 05/08/2026 at 05:41..
[Clang] Define `__SIG_ATOMIC_TYPE__` macro (#213934)

Define `__SIG_ATOMIC_TYPE__` for compatibility with GCC.

This fixes `riscv32-netbsd` and `riscv64-netbsd` system headers that
define `sig_atomic_t` using this macro.

Reference:
https://gcc.gnu.org/onlinedocs/gcc-16.1.0/cpp/Common-Predefined-Macros.html

Follow up of #199678, Closes #213895
https://invent.kde.org/qt/clang/llvm/-/commit/c08ed4c1ab086aad6f22cfc499e74d92953045ae

Git commit d46f1e166a5692b816dfe373babc7ad760912711 by GitHub (on behalf of fabrizio-indirli) on 05/08/2026 at 06:15..
[mlir][gpu][spirv] Convert memref<mma_matrix> to spv.array<coopmatrix> (#212806)

In a gpu.func, allow allocating local arrays of gpu.mma_matrix, e.g.
`memref.alloca() : memref<Nx!gpu.mma_matrix<HxW, ...>`. Extend the SPIRV
conversion to convert such memrefs to `%ARR = spirv.Variable:
spv.ptr<spv.array<N x coopmatrix>, Function>`, which can be conveniently
indexed with `spirv.AccessChain %ARR[i]`. This enables arrays of CoopMMA
matrices both at the `gpu` and `spirv` levels.

Signed-off-by: Fabrizio Indirli <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/d46f1e166a5692b816dfe373babc7ad760912711

Git commit 953318dd3ae5ca9f4e5306c51f80e6928634cc57 by GitHub (on behalf of Joshua Batista) on 05/08/2026 at 06:38..
[SPIRV][HLSL] Fix Vulkan-invalid SPIR-V for Interlocked* on groupshared/UAV memory  (#212663)

Compiling HLSL `InterlockedOr`/`InterlockedAdd`/`InterlockedXor` against
`groupshared` (or UAV) destinations through the clang HLSL -> SPIR-V
path produced SPIR-V that `spirv-val` rejects for Vulkan.

Illegal OpCapability Linkage: groupshared variables are emitted
as `external hidden addrspace(3)` (Workgroup)
declarations. `getSpirvLinkageTypeFor` gave any non-interface
declaration `Import` linkage, which adds a
`LinkageAttributes` decoration and forces `OpCapability` Linkage, which
is illegal in a Vulkan shader.
Fix: in a shader environment (no linker), Workgroup/Private declarations
get no linkage.

Fixes: https://github.com/llvm/offload-test-suite/issues/1404
Assisted by: Github Copilot
https://invent.kde.org/qt/clang/llvm/-/commit/953318dd3ae5ca9f4e5306c51f80e6928634cc57

Git commit 48a2c650cb4566a36ae769d8e4ab32286ca9d158 by GitHub (on behalf of Baranov Victor) on 05/08/2026 at 06:41..
[clang-tidy][NFC] Use 'or-earlier' suffix in tests (#213835)
https://invent.kde.org/qt/clang/llvm/-/commit/48a2c650cb4566a36ae769d8e4ab32286ca9d158

Git commit 0d3f129f835343233181f2b829407c2c39a28b04 by GitHub (on behalf of Baranov Victor) on 05/08/2026 at 06:42..
[clang-tidy][Docs] write guidline about -or-later suffix (#213962)
https://invent.kde.org/qt/clang/llvm/-/commit/0d3f129f835343233181f2b829407c2c39a28b04

Git commit 010bd79afba4bbabb6486ee75a590141a1cc1696 by GitHub (on behalf of Baranov Victor) on 05/08/2026 at 06:42..
[clang-tidy] Fix clang-tidy-diff with not producing blank lines (#213873)

clang-tidy-diff.py unconditionally wrote `stdout + "\n"` for every file
it processed, even when clang-tidy produced no output so this bloated
output with needless blank line (happened with `-quiet` flag enabled
which made tidy produce 0 diagnostics).
https://invent.kde.org/qt/clang/llvm/-/commit/010bd79afba4bbabb6486ee75a590141a1cc1696

Git commit 51e8f76e2883013a7e6452d06e0835291bd78403 by GitHub (on behalf of Yao Qi) on 05/08/2026 at 06:44..
[lldb] Clear stale error in Target::ReadMemory on file-cache fallback (#213451)

Load the checked-in core `linux-aarch64-pac.core` from
`lldb/test/API/functionalities/postmortem/elf-core/` with its binary and ask for
a `char16_t *` summary at the start of `.text`:

```
(lldb) settings set target.max-string-summary-length 8
(lldb) expression -l c++ -- (char16_t *)0x400140
(char16_t *) $0 = 0x0000000000400140 unable to read data
(lldb) memory read -s1 -c16 0x400140
0x00400140: 3f 23 03 d5 ff 83 00 d1 fd 7b 01 a9 fd 43 00 91  ?#.......{...C..
```

`memory read` prints the very bytes the summary just claimed it could not read.
Both go through `Target::ReadMemory()`, which reuses a single `Status &error` for
the process read and for the file-cache fallback at the end of the function, and
`Target::ReadMemoryFromFileCache()` only ever sets that `Status`, it never clears
it.  So when the process read fails outright and the fallback then satisfies the
whole request, `ReadMemory()` returns the correct bytes with the failed process
read's message still in `error`.  `memory read` only compares the returned count
against the requested length, so it is fine, but
`Target::ReadStringFromMemory()`, which `StringPrinter` uses for UTF-16 and
UTF-32, gives up on `error.Fail()`, and `SBTarget::ReadMemory()` hands the same
stale `Status` to any scripted client.

Core files reach this routinely.  `ProcessMachCore` and `ProcessElfCore` both
report `IsAlive()`, so the process read is attempted and fails for a page that
was not dumped into the core, and the fallback then serves that page out of the
binary on disk.  In this core the `PT_LOAD` covering `.text` has
`p_filesz == 0`.

Clear `error` before the fallback so the bytes and the `Status` describe the same
read, and let the fallback report a short read itself:
`ReadMemoryFromFileCache()` sets an error when it reads nothing, but not when
`ObjectFile::ReadSectionData()` clamps a request that overruns the section.  A
short read is only a failure when a live read already produced nothing, hence the
`ProcessIsValid()` guard: without it a target with no process, say one made from
a `.o` file where the fallback is the only reader, fails legitimate short reads.
`Target::ReadInstructions()` asks for `GetMaximumOpcodeByteSize() * count` bytes
and bails on `error.Fail()`, so it could no longer disassemble the tail of a
section.

The one change for callers is that a full read served by the fallback now
reports success.  (The session lowers `target.max-string-summary-length` to keep
the request inside this binary's small `.text`; a larger request really is a
short read and still reports an error.)

```
(lldb) expression -l c++ -- (char16_t *)0x400140
(char16_t *) $0 = 0x0000000000400140 u"⌿픃菿턀篽꤁䏽"
```

A unit test in `lldb/unittests/Target/MemoryTest.cpp` drives the fallback with a
process that cannot produce a byte, checking that a full read succeeds and a
short one does not, and `test_read_only_cstring` in `TestLinuxCore.py` gains an
`SBTarget::ReadMemory()` check on the core it already loads.
https://invent.kde.org/qt/clang/llvm/-/commit/51e8f76e2883013a7e6452d06e0835291bd78403

Git commit 13034b3a22058f6bc49553268b051bdc6aa4efa1 by GitHub (on behalf of Valentin Churavy) on 05/08/2026 at 06:54..
[flang] Add HLFIR-to-FIR pass pipeline extension points (#212194)

The FIR optimizer extension points (FIROptEarly, FIRInliner, FIROptLast)
all
run after HLFIR has been lowered to FIR, so the HLFIR intrinsic
operations
(hlfir.sum, hlfir.matmul, ...) are gone by the time they run.
Transformations
that need to see those operations have nowhere to attach.

Add two extension points to createHLFIRToFIRPassPipeline:

  * HLFIROptEarly, at the start of the pipeline, before any HLFIR
    simplification or inlining.
  * HLFIROptLast, just before createLowerHLFIRIntrinsics.

Drivers register passes through registerHLFIROptEarlyEPCallbacks and
registerHLFIROptLastEPCallbacks on MLIRToLLVMPassPipelineConfig. The
invoke
methods are const so they can be called on the const config the HLFIR
pipeline
receives.

Co-authored-by: Claude Opus 5 <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/13034b3a22058f6bc49553268b051bdc6aa4efa1

Git commit dce57cf279d65b0ce871a77f1b493e5141a99379 by GitHub (on behalf of Berke Ates) on 05/08/2026 at 06:55..
[MLIR][SCCP] Fix in-place folds leaking into IR during simulation (#213933)

SparseConstantPropagation restored the operation only when `fold` did
not return any fold results. But a folder can mutate the op in place and
still return out-of-place results or fail, e.g. `vector.extract` folds
constant dynamic positions into static ones before attempting further
folds.
The constants fed to `fold` are speculative lattice values, so the
mutation bakes a possibly-wrong constant into the IR. SCCP would
permanently replace a loop-carried dynamic index with its first lattice
value for example.

Fix: Restore the original operands and attributes after every fold call,
regardless of its outcome.

Co-authored-by: Claude Fable 5 <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/dce57cf279d65b0ce871a77f1b493e5141a99379

Git commit a4c7c486b76b0fa0e894a5871a7599fb18f8ddd5 by GitHub (on behalf of Arseniy Obolenskiy) on 05/08/2026 at 08:10..
[SPIR-V] Preserve sign and payload when printing NaN as hex float (#212438)

NaN was always printed as the canonical `0x1.8p+<MaxExp>`, silently
dropping the sign bit and any signaling/payload bits

Discussed in https://github.com/llvm/llvm-project/pull/212295
https://invent.kde.org/qt/clang/llvm/-/commit/a4c7c486b76b0fa0e894a5871a7599fb18f8ddd5

Git commit d31b11c260ae09545222743ab5c61841dfe248da by GitHub (on behalf of David Sherwood) on 05/08/2026 at 08:14..
[LV] Make greater use of ScalarEvolution in addDiffRuntimeChecks (#213668)

When the loop vectoriser calls addDiffRuntimeChecks it goes to a lot of
effort to avoid generating multiple copies of the VF calculation by
caching the first instance. However, now that ScalarEvolution has a
getElementCount function we can simplify this code significantly,
especially since SCEVs are also implicitly cached. Make greater use of
SCEVs for computation also has the side-effect of improving code quality
in the memory check blocks, which is important when estimating costs of
these checks. You can see this in some tests like

LoopVectorize/AArch64/sve-runtime-check-size-based-threshold.ll

where the threshold for entering the loop has been relaxed.

Ideally, all computation in addDiffRuntimeChecks should be done using
SCEV because there are presumably other folds that can be applied to the
comparisons. However, I'd keep things simple in this PR and deal with
that in a follow-on PR.
https://invent.kde.org/qt/clang/llvm/-/commit/d31b11c260ae09545222743ab5c61841dfe248da

Git commit a5b9b6900655feea616ee2337920b85709d9757d by GitHub (on behalf of Michael G. Kazakov) on 05/08/2026 at 08:20..
[libc++] Add InsertNewlineAtEOF=True to .clang-format (#214078)

Newline at the end of a file is a standard convention in the `libc++`
codebase, but it's not enforced via `clang-format`.
Current PR enables this check:

https://clang.llvm.org/docs/ClangFormatStyleOptions.html#insertnewlineateof
https://invent.kde.org/qt/clang/llvm/-/commit/a5b9b6900655feea616ee2337920b85709d9757d

Git commit a8def69f6c1a7a14ecab1ede638a21660086ab47 by GitHub (on behalf of forking-google-bazel-bot[bot]) on 05/08/2026 at 08:27..
[Bazel] Fixes 13034b3 (#214141)

This fixes 13034b3a22058f6bc49553268b051bdc6aa4efa1 (#212194).

Buildkite error link:
https://buildkite.com/llvm-project/upstream-bazel/builds?commit=13034b3a22058f6bc49553268b051bdc6aa4efa1

Co-authored-by: Google Bazel Bot <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/a8def69f6c1a7a14ecab1ede638a21660086ab47

Git commit 20d5962141fd3f340840b86666f58c7f230f717c by GitHub (on behalf of Chris Copeland) on 05/08/2026 at 08:27..
[ARM][NFC] Fix invalid target triples in tests (#213588)

Update the expected codegen as-needed.
https://invent.kde.org/qt/clang/llvm/-/commit/20d5962141fd3f340840b86666f58c7f230f717c

Git commit 96e02c05f343ce697d6dbf243e1b3c218a4d4631 by Valentin Churavy on 05/08/2026 at 08:38..
[flang] Add a pass-pipeline config callback hook for plugins

The HLFIR-to-FIR pipeline extension points live on MLIRToLLVMPassPipelineConfig,
which the frontend builds as a local of CodeGenAction, out of reach of a plugin.

Add a process-global registry of callbacks that run on the config before the
pipeline is built. A plugin registers one from a static initializer, so it is in
place before any compilation begins, as FrontendPluginRegistry does for plugin
actions. Both code generation entry points invoke the callbacks, lowerHLFIRToFIR
for -emit-fir and generateLLVMIR for -emit-llvm/-emit-obj, and are mutually
exclusive for a given compilation, so a plugin sees the same behaviour whichever
output was asked for.

Co-Authored-By: Claude Opus 5 <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/96e02c05f343ce697d6dbf243e1b3c218a4d4631

Git commit 3e8c6925cc0b5f40b0d6231a80bef8e5b317a950 by Valentin Churavy on 05/08/2026 at 09:12..
[flang] Add an example plugin exercising the HLFIR pipeline extension points

The HLFIR extension points, the pipeline config callback registry and fir-opt's
symbol export all exist to let an out-of-tree MLIR pass run while the HLFIR
intrinsic operations (hlfir.sum, hlfir.matmul, ...) are still present. None of
that was covered end to end, and nothing showed how to use it.

Add flang/examples/HLFIRPipelinePlugin, modelled on PrintFlangFunctionNames. It
contributes a pass that prints the HLFIR operations still present in the module,
tagged with the pipeline position it was inserted at, and exposes it through
both plugin entry points: a static initializer calling
fir::registerPassPipelineConfigCallback for the `flang -fc1 -load` path, and
mlirGetPassPluginInfo so fir-opt can load it with --load-pass-plugin.

Nothing is linked into the shared object; MLIR, FIR and flang symbols resolve
against the host tool, which is what export_executable_symbols_for_plugins on
flang and fir-opt provides.

Two tests use it. Examples/hlfir-pipeline-plugin.f90 covers -emit-fir and
-emit-llvm, so both callback invocation sites, plus a no-plugin negative check.
It checks -O0 and -O2 because at -O0 the intrinsics reach both extension points,
while at -O2 SimplifyHLFIRIntrinsics has expanded them before the Last one -
which is why both points exist. Examples/fir-opt-pass-plugin.fir covers
--load-pass-plugin and the pass showing up in fir-opt's registry.

Co-Authored-By: Claude Opus 5 <[email protected]>
https://invent.kde.org/qt/clang/llvm/-/commit/3e8c6925cc0b5f40b0d6231a80bef8e5b317a950