[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/gandhi56/sandbox-vectorizer/rename-bottom-up-vec'. Changed from 531f8af7eb59eec403ea41856a507998f9c88a09 to 87e45f4ad4f655591ce85250f713cf0ba64b2e4a 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 7a618a2e7fd15d4fea352f2f5d7f67b07e0ccd24 by GitHub (on behalf of Tanmay Gulhane) on 03/08/2026 at 00:01.. [RISCV] Fix assertion in combineBinOpOfExtractToReduceTree on type mismatch (#202201) combineBinOpOfExtractToReduceTree asserts that the extract source vector's element type equals the binop's value type (SrcVecVT.getVectorElementType() == VT). This invariant does not hold for all valid inputs. A <1 x i1> binary operation under -mattr=+zve32x reaches this point with the source vector element type differing from VT, which trips the assertion in an assertions-enabled build and silently proceeds on a false assumption otherwise. Convert the assertion into an early return, so the combine declines when its precondition is not met. This matches the existing bail-out style in the same function (the isScalableVector and getScalarSizeInBits() > getELen() checks immediately following). The change only ever skips the fold; it never alters correct output. Generative AI was used for the test case. The fix is mine. Bug found by fuzzing with llvm-stress (seed 96) and reduced with llvm-reduce. Signed-off-by: Tanmay Gulhane <[email protected]> https://invent.kde.org/qt/clang/llvm-project/-/commit/7a618a2e7fd15d4fea352f2f5d7f67b07e0ccd24 Git commit 41322057c3af16d75e239ec6679c6c2bf7aec157 by GitHub (on behalf of Zane Hambly) on 03/08/2026 at 00:18.. [X86] Don't shrink VEX3 to VEX2 on a symbolic compare predicate (#213172) `llvm-mc` asserts on a VCMP predicate given as a symbol: ```asm vcmpps $f0, %xmm0, %xmm1, %xmm2 ``` ``` Assertion failed: isImm() && "This is not an immediate", MCInst.h:85 ``` `optimizeInstFromVEX3ToVEX2` reads the predicate with `getImm()` to decide whether the operands commute. A symbolic predicate is not known until link time, so that decision cannot be made here. Decline the shrink instead. Unlike the sibling FPCLASS issues (#185364, #185365) this one is on the encoding path and asserts under `--filetype=obj` too, so a release build would be making the commutation decision on whatever `getImm()` returns for a non-immediate. Literal predicates are unaffected and still commute to reach the two-byte VEX prefix. The test covers both. Fixes #185355 https://invent.kde.org/qt/clang/llvm-project/-/commit/41322057c3af16d75e239ec6679c6c2bf7aec157 Git commit 87e45f4ad4f655591ce85250f713cf0ba64b2e4a by Anshil Gandhi on 03/08/2026 at 04:33.. [SBVec] Rename BottomUpVec to BundleVec https://invent.kde.org/qt/clang/llvm-project/-/commit/87e45f4ad4f655591ce85250f713cf0ba64b2e4a