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

KDE Git Services - Bulk Change <[email protected]>
Newsgroups gmane.comp.kde.cvs
Message-ID <[email protected]>
Git repository change summary for qt/clang/llvm-project
Pushed by mirror-service into branch 'upstream/users/arsenm/amdgpu/split-r600-archfeature-enum'.
Changed from 0000000000000000000000000000000000000000 to 1dc1db7ceb497aa1c85a32fd0c8d2b1ed47bfcd5
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-project/-/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-project/-/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-project/-/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-project/-/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-project/-/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-project/-/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-project/-/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-project/-/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-project/-/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-project/-/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-project/-/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-project/-/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-project/-/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-project/-/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-project/-/commit/c154f4aa5483915702d8447d541d5d9a4dfaac46

Git commit 1dc1db7ceb497aa1c85a32fd0c8d2b1ed47bfcd5 by Matt Arsenault on 28/07/2026 at 13:11..
AMDGPU: Split R600 feature bitmask into separate enum from amdgcn

Co-authored-by: Claude (Claude-Opus-4.8)
https://invent.kde.org/qt/clang/llvm-project/-/commit/1dc1db7ceb497aa1c85a32fd0c8d2b1ed47bfcd5
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.