[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