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

Git repository change summary for qt/clang/llvm
Pushed by mirror-service into branch 'upstream/users/pierre-vh/synthetic-apertures'.
Changed from 95027b8b760f48336e1edf5e23d706ae2f75c2b6 to 11f6bcbc1e83906f188f8b85d3591cefcb8d8aa7
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 840060f2f85c2d3f8ebe1c9304770d682e4141f6 by GitHub (on behalf of Pengcheng Wang) on 28/07/2026 at 11:19..
[RISCV] Don't move memory instructions across calls in isSafeToMove (#212236)

RISCVInstrInfo::isSafeToMove scans the instructions between From and To
to decide whether a memory instruction can be moved, but it only treated
mayStore() instructions as barriers. Calls on RISC-V are modeled with
isCall() and a register mask rather than mayStore(), so a load could be
moved across a call even though the callee may clobber the loaded
memory.

RISCVVectorPeephole::foldVMergeToMask uses this helper via ensureDominates()
to sink a load into a masked load when folding it into a vmerge, which
produced wrong code when the load was sunk past a call.

Instead of hand-rolling the barrier check, call MachineInstr::isSafeToMove
on each intervening instruction to populate SawStore. That is the same
helper used on From below, and it already treats calls (as well as PHIs
and ordered memory references) as stores.

This fixes #212226.

Assisted-by: TRAE CLI (DeepSeek V4 Pro)
https://invent.kde.org/qt/clang/llvm/-/commit/840060f2f85c2d3f8ebe1c9304770d682e4141f6

Git commit ff46298372dc64d8fb56f1397c2914772b815605 by GitHub (on behalf of Arseniy Obolenskiy) on 28/07/2026 at 11:25..
[mlir][SPIR-V] Support bitwise and/or/xor in gpu reduction lowering (#202351)
https://invent.kde.org/qt/clang/llvm/-/commit/ff46298372dc64d8fb56f1397c2914772b815605

Git commit bcdff65a953758e3a72cf99586c6ce809d4aaf9e by GitHub (on behalf of Nikolas Klauser) on 28/07/2026 at 11:33..
[libc++] Simplify some meta-programming in tuple (#212436)

This does two things:
- replace `_Not<T>::value` with `!T::value` when we already evaluate
lazily
- remove `_And`s that aren't useful because they only have a single
argument
https://invent.kde.org/qt/clang/llvm/-/commit/bcdff65a953758e3a72cf99586c6ce809d4aaf9e

Git commit 321642826552ff4e4c7d67ea236f8669d4598c9f by GitHub (on behalf of A. Jiang) on 28/07/2026 at 11:35..
[libc++][test] Disable test coverage for `_BitInt` for non-libc++ implementations (#212435)

Currently, library support for `_BitInt(N)` is an extension explicitly
supported by libc++. However, when using Clang with other standard
library implementations, `TEST_HAS_BITINT` is currently `1` as the
condition only detects compiler support of `_BitInt`.

This patch disables `_BitInt` coverage for other implementations for
now.
https://invent.kde.org/qt/clang/llvm/-/commit/321642826552ff4e4c7d67ea236f8669d4598c9f

Git commit abd3b3a1445b5a8eeffae5c3912883faa9287fb7 by GitHub (on behalf of A. Jiang) on 28/07/2026 at 11:42..
[libc++][test][NFC] Format `test_macros.h` (#212442)

Avoiding errors about untouched lines from clang-format when modifying
conditions in `test_macros.h`.
https://invent.kde.org/qt/clang/llvm/-/commit/abd3b3a1445b5a8eeffae5c3912883faa9287fb7

Git commit 391d298c2ae471c28e7db8538d867a017f9d08df by GitHub (on behalf of Zichen Lu) on 28/07/2026 at 11:52..
[mlir][Target] Make nvptxcompiler passed options high priority to keep consistent with ptxas behavior (#121036)

When using `ptxas` to do ptx->cubin, the options passed (via `cmd`) have
higher priority than the gpuModule target (such as `opt-level`). When
using `nvptxcompiler`, it is the opposite and we need to be consistent.
https://invent.kde.org/qt/clang/llvm/-/commit/391d298c2ae471c28e7db8538d867a017f9d08df

Git commit f11d740e204f0551ac72ab1a2cacd72ae5c41b26 by GitHub (on behalf of Pavel Labath) on 28/07/2026 at 12:11..
[libc] Make hash_test hermetic (#212428)

Aligned allocation is now supported, but the test burns through our 1MB
never-freeing bump pointer allocation buffer. I tweak the test to reuse
the buffer between loop iterations, reducing its memory usage by about
300x :P.
https://invent.kde.org/qt/clang/llvm/-/commit/f11d740e204f0551ac72ab1a2cacd72ae5c41b26

Git commit 2a50c95322bc0ff3bbd976564914ce297b251a1a by GitHub (on behalf of Jameson Nash) on 28/07/2026 at 12:12..
Thread Safety Analysis: Honor try-lock branches of a void conditional (#211973)

Try-locks are not acquired on the arms of a `?:`, because the arms would
then disagree about whether the capability is held and warn where they
join. That reasoning assumes the `?:` produces a result that is branched
on later, which is where the acquisition is handled instead.

A void `?:` has no such result. Its branch is all there is to interpret,
and its arms might not join at all because one of them does not return
(this is how glibc before 2.32 spells `assert()`).

So asserting that a try-lock succeeded left the capability unheld on
every path, and a function documented to acquire it warned that it did
not, if written like so:

  void lock(void) ACQUIRE(mu) {
    int got = trylock();
assert(got); // warning: expecting mutex 'mu' to be held at the end of
function
  }

Only bail out for a `?:` that has a result to be used, so that a void
`?:` acquires on its branch like any other terminator (for example,
including `&&` and `||`).

Assisted-by: Claude Opus 5
https://invent.kde.org/qt/clang/llvm/-/commit/2a50c95322bc0ff3bbd976564914ce297b251a1a

Git commit ac8b30c74b595dd8dfa612912663e57dafcf3355 by GitHub (on behalf of A. Jiang) on 28/07/2026 at 12:22..
[libc++][test] Suppress warning on bitwise shift with `bool` operands in `std::byte` tests for MSVC (#212433)

It was intentional in https://llvm.org/PR204116 that tests for
`operator<<`, `operator<<=`, `operator>>`, `operator>>=` used `bool`
operands, because `bool` is an integral type and thus satisfies the
constraints of these operators.

However, MSVC considers `bool` is unsafe as an operand of bitwise shift
operators and emits warning C4804. So this patch suppresses the warning
for MSVC.
https://invent.kde.org/qt/clang/llvm/-/commit/ac8b30c74b595dd8dfa612912663e57dafcf3355

Git commit c273220275a7cbb8384812e1a4c84e773e1dd820 by GitHub (on behalf of Arseniy Obolenskiy) on 28/07/2026 at 12:25..
[mlir][SCFToSPIRV] Fix iter_args returning undef on zero trip scf.for (#206280)
https://invent.kde.org/qt/clang/llvm/-/commit/c273220275a7cbb8384812e1a4c84e773e1dd820

Git commit 584734513c63b309b46a945cddbf0a516a9d133c by GitHub (on behalf of Lang Hames) on 28/07/2026 at 12:28..
[ORC] Drop ExecutorProcessControl::JITDispatchInfo. (#212434)

The JIT-dispatch mechanism lets JIT'd code call handlers in an ORC
ExecutionSession, via the "__orc_rt_jit_dispatch" and
"__orc_rt_jit_dispatch_ctx" symbols. Until now ExecutorProcessControl
carried the addresses backing those symbols in a dedicated
JITDispatchInfo struct, which every EPC had to populate and each
Platform read back to define the symbols.

That detour couples ExecutorProcessControl to the shape of the dispatch
mechanism -- two symbols with fixed names -- and forces every EPC to
provide the addresses whether or not a given JIT setup uses dispatch.

Represent the two addresses as ordinary bootstrap symbols instead. EPCs
that support dispatch add __orc_rt_jit_dispatch(_ctx) to their bootstrap
symbols; Platforms reexport them from the bootstrap JITDylib rather than
reading JITDispatchInfo. EPCs that don't use dispatch provide nothing,
and ExecutorProcessControl no longer references the mechanism at all.
https://invent.kde.org/qt/clang/llvm/-/commit/584734513c63b309b46a945cddbf0a516a9d133c

Git commit 8c8cc1cfb9f04fc57716b9ccc3ea74c9a5495bf7 by GitHub (on behalf of Akash Agrawal) on 28/07/2026 at 12:28..
[Clang][Parse] Fix assertion when annotating a failed decltype-specifier (#211221)

`ParseDeclaratorInternal's` member-pointer special case enters a
speculative scope-specifier parse whenever it sees `decltype`, without
checking that `( `follows:


```
if (getLangOpts().CPlusPlus &&
    (Tok.is(tok::coloncolon) || Tok.is(tok::kw_decltype) || ...)) {
```
But `decltype-specifier` is always `decltype ( expression ) — decltype`
not followed by `(` can never be valid. When that happens,
`ParseOptionalCXXScopeSpecifier` still tries to parse it as one, fails,
and error recovery skips tokens. The EndLoc returned is then stale by
the time `AnnotateExistingDecltypeSpecifier` uses it to annotate, which
trips the invariant in `Preprocessor::AnnotatePreviousCachedTokens`:


```
int decltype;      // crashed
int *decltype = 0; // crashed
```
Fix: only take this path when decltype is followed by (.


`(Tok.is(tok::kw_decltype) && NextToken().is(tok::l_paren)) ||`

`ParseDecltypeSpecifier` already requires `(` right after `decltype` or
bails with `TST_error`, so this check drops no valid parse —
`decltype(expr)` (including as a member-pointer scope, e.g.` int
decltype(obj)::*p = &S::m;) `is unaffected.

Fixes #211207

Co-authored - Claude-Sonnet
https://invent.kde.org/qt/clang/llvm/-/commit/8c8cc1cfb9f04fc57716b9ccc3ea74c9a5495bf7

Git commit ad6cb6dedc9dc1d965d60e1a34289c2bb30e7cec by GitHub (on behalf of Nikita Taranov) on 28/07/2026 at 12:36..
[X86] Reapply #210739 with a fix (#212020)

This reapplies #210739, which was reverted in #211958 because it could
crash the backend with "Invalid rip-relative address" when an LEA added
a RIP-relative global and an already-materialized value.

Fixes #51707
https://invent.kde.org/qt/clang/llvm/-/commit/ad6cb6dedc9dc1d965d60e1a34289c2bb30e7cec

Git commit 9572596c3951a5fef5eecc011c617c1b264357b7 by GitHub (on behalf of Paul Walker) on 28/07/2026 at 12:45..
[LLVM][CodeGen] Clean up uses of useSVEForFixedLengthVectorVT(). (#211605)

During lowering `useSVEForFixedLengthVectorVT` only serves to separate
NEON sized vectors from those made legal for SVE VLS. When no separation
is required there is no reason to call the function. That means
`useSVEForFixedLengthVectorVT(VT, /*OverrideNEON=*/true)` is largely
synonymous to `isSVEorStreamingSVEAvailable()`.
    
`useSVEForFixedLengthVectorVT` is not a per operation property. For this
reason I have removed the AllowBF16 parameter and replaced it by a
command line option that can be used during SVE VLS bfloat bringup. The
one existing use has been removed because it falls under the previous
issue in there being no need to call `useSVEForFixedLengthVectorVT`.
https://invent.kde.org/qt/clang/llvm/-/commit/9572596c3951a5fef5eecc011c617c1b264357b7

Git commit c154f4aa5483915702d8447d541d5d9a4dfaac46 by GitHub (on behalf of Matt Arsenault) on 28/07/2026 at 13:09..
AMDGPU: Remove dead FEATURE_FP64/FEATURE_LDEXP from ArchFeatureKind (#212479)

No GPU ever sets these bits, and clang's hasFP64()/hasLDEXPF()
short-circuit on isAMDGCN() before testing them, so the bits are 
never observed.

Co-authored-by: Claude (Claude-Opus-4.8)
https://invent.kde.org/qt/clang/llvm/-/commit/c154f4aa5483915702d8447d541d5d9a4dfaac46

Git commit e432cb12962f1619bc73c50a2dc4d2ad5ac6b44c by GitHub (on behalf of Natanael Cintean) on 28/07/2026 at 13:11..
[mlir]Add resultSegmentSizes/operandSegmentSizes to prop-dict. (#211222)

`setPropertiesFromParsedAttr` (generated by `OpFormatGen.cpp` for ops
using a custom `assemblyFormat`) rejects the trait-injected
`operandSegmentSizes` /. `resultSegmentSizes` properties when they
appear in a `prop-dict`, even though the printer emits them there for ops
whose format uses a bulk operand/result type directive
(`type(operands)`, `type(results)`, `functional-type(operands, results)`).

This breaks round-tripping: any op combining `AttrSizedOperandSegments`
/ `AttrSizedResultSegments` with such a bulk directive fails to re-parse
its own printed output, because printer-side elision of these keys
(introduced in #115930) is intentionally skipped in that case — the
sizes can't be reconstructed from individually-typed operand/result 
groups, so they must survive in the text, but the custom parser was never
taught to read them back.

`setPropertiesFromAttr` (used by the generic-form parser, bytecode, and
C++ construction) already special-cases these two keys, so this change
makes `setPropertiesFromParsedAttr` mirror that behavior: keys are
accepted from the dictionary attr when the corresponding trait is present,
and required exactly when the format can't reconstruct the sizes itself
(i.e. when `fmt.allOperands` / `fmt.allResultTypes` is true). Otherwise the
key remains optional, since `genParserVariadicSegmentResolution`
overwrites it with the sizes inferred from the parsed operand/result
groups.

The contents of the PR as well as description has been made using
github-copilot. However I've reviewed the contents and tested locally
the change.

Fixes #211220
https://invent.kde.org/qt/clang/llvm/-/commit/e432cb12962f1619bc73c50a2dc4d2ad5ac6b44c

Git commit 89d39f69cb18f21d92b261cc0ca2a2314453b1fe by GitHub (on behalf of Yingwei Zheng) on 28/07/2026 at 13:18..
[SimplifyCFG] Bail out on trivial cases in `mergeNestedCondBranch` (#212309)

Closes https://github.com/llvm/llvm-project/issues/212300.

When BB3 is identical to BB4, it is no longer profitable to perform this
fold, since it creates an unused xor instruction. The DomTree update
issue is also easy to fix. But I think this solution is better.

The following IR was dumped just before this function:
```
define void @func(i1 %cond1, i1 %cond2, i1 %cond3) {
entry:
  br i1 %cond1, label %bb2, label %else

else:                                             ; preds = %entry
  br i1 %cond2, label %bb0, label %common.ret

bb0:                                              ; preds = %else
  br i1 %cond1, label %bb1, label %bb2

bb2:                                              ; preds = %bb0, %entry
  br i1 %cond3, label %common.ret, label %common.ret

bb1:                                              ; preds = %bb0
  br i1 %cond3, label %common.ret, label %common.ret

common.ret:                                       ; preds = %bb2, %bb1, %bb2, %bb1, %else
  ret void
}
```
The previous functions will simplify it. So the reproducer cannot be
further reduced.
https://invent.kde.org/qt/clang/llvm/-/commit/89d39f69cb18f21d92b261cc0ca2a2314453b1fe

Git commit 857746b37949a87faa42faff4fae12c35b34db51 by GitHub (on behalf of Matt Arsenault) on 28/07/2026 at 13:27..
AMDGPU: Fix missing extended-image-insts missing from feature map (#212418)

Unsurprisingly, this manually maintained table is buggy.
fillAMDGCNFeatureMap never set extended-image-insts, so clang's builtin
feature check rejected every case. The tests were working around this
with manually specified -target-features flags.

Co-authored-by: Claude (Claude-Opus-4.8)
https://invent.kde.org/qt/clang/llvm/-/commit/857746b37949a87faa42faff4fae12c35b34db51

Git commit 34be3a62bf9a309fb00a4a2ec2150fa87750ad96 by GitHub (on behalf of Alex Duran) on 28/07/2026 at 13:40..
[OFFLOAD][L0][NFC] Mark as skip unittest with driver issue (#212466)
https://invent.kde.org/qt/clang/llvm/-/commit/34be3a62bf9a309fb00a4a2ec2150fa87750ad96

Git commit 8d632c0a8eef06b7be509d10a6d87c9bd814a10e by GitHub (on behalf of Akshay K) on 28/07/2026 at 13:45..
[X86] Don't clobber x87 return values when zeroing call-used registers (#211129)

### Summary
`-fzero-call-used-regs=all` / `zero_call_used_regs("all")`
unconditionally push eight `fldz` onto the x87 stack before returning.
When a value is live in `ST0` (`long double`) or `ST0:ST1` (`_Complex
long double`), the pushes overflow the 8-slot x87 stack and the return
value becomes an indefinite NaN. Reproduces on x86-64 at every
optimization level, via both the flag and the attribute.

```c++
__attribute__((zero_call_used_regs("all")))
long double g(long double a) { return a + 1; }
// g(1.0L) returns nan, expected 2.0
```

### Root cause
The x87 return value lives in `ST0` (and `ST1` for `_Complex long
double`), but the FP stackifier's `handleReturn` deletes the `RET`'s FP
register operands after stackification (the `FP0`-`FP6` pseudos no
longer exist) without recording that the top of the x87 stack is live.
The scrub in `emitZeroCallUsedRegs` therefore has nothing telling it
`ST0` is occupied, so it pushes a zero over the return value.

### Fix
`handleReturn` now re-records the returned values as implicit
`ST0`/`ST1` uses on the return instruction — the same way every other
return register (`RAX`, `XMM0`, ...) is modeled — and
`emitZeroCallUsedRegs` pushes only `8 - live` zeros, filling the dead
slots and leaving the return value intact. This matches GCC.

Note: the implicit `ST0`/`ST1` operands are recorded on every
x87-returning `RET`, not only under `zero-call-used-regs`. One
consequence is that a `RET` now satisfies `isX87Instruction`, so
`X86InsertX87Wait` is adjusted so a return no longer suppresses the
strict-FP `wait` (a return performs no exception sync).

### Secondary fix (i386)
The old count was hardcoded `ST.is64Bit() ? 8 : 7`. On i386, a function
with no x87 value live at the return (e.g. an integer return) cleared
only seven of the eight physical x87 registers, so `"all"` silently left
one call-used register uncleared. The unified `8 - live` formula fixes
this too: i386 with no x87 return now pushes 8 (previously 7).

### Tests
`zero-call-used-regs.ll` adds `all_x87_return` (`x86_fp80`, 1 live -> 7
pushes), `all_x87_complex_return` (`_Complex long double`, 2 live -> 6
pushes), and `all_no_x87_live` (no x87 live -> 8 pushes, guarding the
i386 secondary fix). The full X86 CodeGen suite passes.

Fixes #211064

Assisted-by: Cursor
https://invent.kde.org/qt/clang/llvm/-/commit/8d632c0a8eef06b7be509d10a6d87c9bd814a10e

Git commit fd1b1ee56b7923af58a927faa11ab188118ca1df by pvanhout on 28/07/2026 at 14:35..
[clang][AMDGPU] Clean-up handling of named barrier type

- Allow the type in struct/classes in very limited circumstances. The goal is to enable creating trivial wrappers around the named barrier variable, but ensure we can't get into situations where things would get awkward. Currently this means we only allow the named barrier in RecordDecls with exactly 1 field, that have no base class, and are not inherited.
- Use a `amdgpu_barrier` LangAS for this type that currently maps to the local AS. This allows easy switching to the barrier AS in a future patch.
https://invent.kde.org/qt/clang/llvm/-/commit/fd1b1ee56b7923af58a927faa11ab188118ca1df

Git commit b83966bbe5b199209b13c580d0ec37eb3131dd11 by pvanhout on 28/07/2026 at 14:35..
Comment
https://invent.kde.org/qt/clang/llvm/-/commit/b83966bbe5b199209b13c580d0ec37eb3131dd11

Git commit 0c360961ecb8516f9df483fdac4f666a2128daad by pvanhout on 28/07/2026 at 14:35..
Add docs
https://invent.kde.org/qt/clang/llvm/-/commit/0c360961ecb8516f9df483fdac4f666a2128daad

Git commit b1a05168fa5d9d659e2e1d94842087bf9e0a3043 by pvanhout on 28/07/2026 at 14:35..
docs
https://invent.kde.org/qt/clang/llvm/-/commit/b1a05168fa5d9d659e2e1d94842087bf9e0a3043

Git commit cbaa3a2617e85ae23309f4be7ac5821c4cee8a04 by pvanhout on 28/07/2026 at 14:35..
comments
https://invent.kde.org/qt/clang/llvm/-/commit/cbaa3a2617e85ae23309f4be7ac5821c4cee8a04

Git commit e03216381e2c4f269e8d763e649841cedcff153a by pvanhout on 28/07/2026 at 14:35..
Diagnose type on SPIRV
https://invent.kde.org/qt/clang/llvm/-/commit/e03216381e2c4f269e8d763e649841cedcff153a

Git commit 17a12afc947a1a96e924f63e18706ab383fefbe2 by pvanhout on 28/07/2026 at 14:35..
Check field decls too
https://invent.kde.org/qt/clang/llvm/-/commit/17a12afc947a1a96e924f63e18706ab383fefbe2

Git commit bdec06c6388d37e41e32ee469210193b102fb7c6 by pvanhout on 28/07/2026 at 14:35..
[RFC][AMDGPU] Add BARRIER address space

Add a new BARRIER address space that is used for global variables that are used to represent the barrier IDs in GFX12.5.

These barrier addresses just have values corresponding 1-1 to barrier IDs. They are still implemented on top of LDS, but the offsetting happens during an addrspacecast to generic, not whenever the barrier GV is used.

The motivation for this is to make the relation between LDS and barrier GVs explicit in the compiler. It does add a bit more complexity, but that complexity was already there, just hidden by pretending barrier GVs were actual LDS.
https://invent.kde.org/qt/clang/llvm/-/commit/bdec06c6388d37e41e32ee469210193b102fb7c6

Git commit c1975dc74549f00298157689bc1bd7594f02ec5d by pvanhout on 28/07/2026 at 14:35..
Comments
https://invent.kde.org/qt/clang/llvm/-/commit/c1975dc74549f00298157689bc1bd7594f02ec5d

Git commit 62ce82a0e6bfc1a1979a15b8dd77e32b59e16dcd by pvanhout on 28/07/2026 at 14:35..
Add DL auto-upgrade
https://invent.kde.org/qt/clang/llvm/-/commit/62ce82a0e6bfc1a1979a15b8dd77e32b59e16dcd

Git commit 896fc9eecd2d1420ed6b8917bb78f625d376357f by pvanhout on 28/07/2026 at 14:35..
comments
https://invent.kde.org/qt/clang/llvm/-/commit/896fc9eecd2d1420ed6b8917bb78f625d376357f

Git commit 3b851f3ae5375f4ea2d5a6f8f72fa17ad723f0d5 by pvanhout on 28/07/2026 at 14:35..
Add reserved AS to autoupgrade
https://invent.kde.org/qt/clang/llvm/-/commit/3b851f3ae5375f4ea2d5a6f8f72fa17ad723f0d5

Git commit 316e94f8913f0ae940dc045de881603807a4eccf by pvanhout on 28/07/2026 at 14:35..
Fix Autoupgrade
https://invent.kde.org/qt/clang/llvm/-/commit/316e94f8913f0ae940dc045de881603807a4eccf

Git commit 95fcd61ab919495f6edccfc3ab78c5981a5c8cfc by pvanhout on 28/07/2026 at 14:35..
Rebase + comments
https://invent.kde.org/qt/clang/llvm/-/commit/95fcd61ab919495f6edccfc3ab78c5981a5c8cfc

Git commit 3f01cfc8c6c1f4cbd5da63bd431b542ceabf3f13 by pvanhout on 28/07/2026 at 14:35..
[AMDGPU] Add synthetic apertures and use them for barriers

Define what a synthetic aperture is, and adjust the barrier AS
to use this new system. This makes the barrier AS even safer to
use as now we can use all 32 bits of it without ever risking
hitting a valid address of any kind (LDS or outside LDS).
https://invent.kde.org/qt/clang/llvm/-/commit/3f01cfc8c6c1f4cbd5da63bd431b542ceabf3f13

Git commit ae7479ce7a1b6aae75d500ab196ab38c1fc4331e by pvanhout on 28/07/2026 at 14:35..
Update docs
https://invent.kde.org/qt/clang/llvm/-/commit/ae7479ce7a1b6aae75d500ab196ab38c1fc4331e

Git commit 81421bc6c116debf9cea164ab99d4af187390e28 by pvanhout on 28/07/2026 at 14:35..
Comments
https://invent.kde.org/qt/clang/llvm/-/commit/81421bc6c116debf9cea164ab99d4af187390e28

Git commit 11f6bcbc1e83906f188f8b85d3591cefcb8d8aa7 by pvanhout on 28/07/2026 at 14:35..
Comments
https://invent.kde.org/qt/clang/llvm/-/commit/11f6bcbc1e83906f188f8b85d3591cefcb8d8aa7