Update LLVM to 21.1.5 #190
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…through all targets (llvm#159308) When quitting LLDB on Windows while a process was still running, LLDB would take unusually long to exit. This was due to a temporary deadlock: The main thread was destroying the processes. In doing so, it iterated over the target list: https://github.com/llvm/llvm-project/blob/88c64f76ed2ca226da99b99f60d316b1519fc7d8/lldb/source/Core/Debugger.cpp#L1095-L1098 This locks the list for the whole iteration. Finalizing the process would eventually lead to `DebuggerThread::StopDebugging`, which terminates the process and waits for it to exit: https://github.com/llvm/llvm-project/blob/88c64f76ed2ca226da99b99f60d316b1519fc7d8/lldb/source/Plugins/Process/Windows/Common/DebuggerThread.cpp#L196 The debugger loop (on a separate thread) would see that the process exited and call [`ProcessWindows::OnExitProcess`](https://github.com/llvm/llvm-project/blob/88c64f76ed2ca226da99b99f60d316b1519fc7d8/lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp#L656-L673). This calls the static function [`Process::SetProcessExitStatus`](https://github.com/llvm/llvm-project/blob/0a7a7d56fc882653335beba0d1f8ea9f26089c22/lldb/source/Target/Process.cpp#L1098-L1126). This tries to find the process by its ID from the debugger's target list. Doing so requires locking the list, so the debugger thread would then be stuck on https://github.com/llvm/llvm-project/blob/0a7a7d56fc882653335beba0d1f8ea9f26089c22/lldb/source/Target/TargetList.cpp#L403 After 5s, the main thread would give up waiting. So every exit where the process was still running would be delayed by about 5s. Since `ProcessWindows` would find itself when calling `SetProcessExitStatus`, we can call `SetExitStatus` directly. This can also make some tests run faster. For example, the DIA PDB tests previously took 15s to run on my PC (24 jobs) and now take 5s. For all shell tests, the difference isn't that big (only about 3s), because most don't run into this and the tests run in parallel. (cherry picked from commit a868f28)
…delay (llvm#152942) Fix llvm#152922 MIPS III also has load delay, so libunwind::Registers_mips_newabi::jumpto() is also fixed. (cherry picked from commit a3d7c46)
We have a list of people authorized to create release assets to prevent someone adding a release asset to a release without someone getting alerted. Add dyung and c-rhodes now that they are also release managers. Fixes llvm#162463 (maybe after backport). (cherry picked from commit 348ffe8)
…ns with --arch=mips (llvm#156413) From clang version 4, mips append new instruction BeqImm and BEQLImm, the second operand format of instruction is imm64:$imm. 1.When Mips process `beql $t0, ($t0), 1`, it think the second operand was an imm, so match success. Then mips backend process expandBranchImm, check the second operand `$t0` was not imm, reported asserts. We can strengthen the second operand matching restrictions. 2.Similarly, when Mips process `beql $t0, (1), 1`, it think the second was an imm. so match success. Then mips backend process expandBranchImm, check the third operand `1` was not expression, reported asserts. Permit the third operand of `beql` to be imm. Fixes llvm#151453. (cherry picked from commit 51eee20)
…llvm#162421) Also, ignore the test results since they almost always fail. This allows us to simplify the build process and skip uploading and downloading the build and source directories which are huge. (cherry picked from commit 9f0f6e8)
…vm#158347) The outer iterator needs to move to the next segment when calling __compose. Without this change, `find_segment_if` would never reach the end of the join_view which caused erroneous result when calling `ranges::find` on a join_view of bidirectional ranges. Other specializations using the segmented iterator trait were likely to be affected as well. Fixes llvm#158279 Fixes llvm#93180 (cherry picked from commit d1b5607)
Fixes llvm#162402 (cherry picked from commit 72d6d6e)
…llvm#162808) llvm#78454 converted readability-identifier-naming fixes to use rename mechanism to rename the symbol project-wide. However, it set the code action kind to "refactor" instead of "quickfix", which caused the fixes to be filtered out when editors (like VS Code) request quick fixes for diagnostics. On VS Code, for example, users would see "No quick fixes available" despite the diagnostic indicating "(fix available)". Fix that by changing the code action kind back to "quickfix". Signed-off-by: Ruoyu Zhong <zhongruoyu@outlook.com>
This makes the tests pass on my AArch64 machine with 16K pages. Not sure why some of the AArch64-specific test failures don't seem to occur on sanitizer-aarch64-linux. I could also reproduce them by running buildbot_cmake.sh on my machine. Pull Request: llvm#153860
It passes on some buildbots, so we can't expect failure.
With gcc 15 we end up emitting a reference to the std::__glibcxx_assert_fail function because of this change: gcc-mirror/gcc@361d230 combined with assertion checks in the std::atomic implementation. This reference is undefined with dfsan causing the test to fail. Fix it by defining the macro that disables assertions. Pull Request: llvm#153873
Fixes llvm#155746 (cherry picked from commit c62a5bf)
Fixes llvm#160775 (cherry picked from commit 56d920d)
llvm#158740) Resolves instruction selection failure for v64f16 and v32f32 vector types. Patch by: Fateme Hosseini --------- Co-authored-by: Kaushik Kulkarni <quic_kauskulk@quicinc.com>
llvm#161844) lld would fail with "error: relocation out of range" if the thunk was laid out more than 128 MB away from __delayLoadHelper2. This patch changes the call sequence to load the offset into a register and call through that, allowing for 32-bit offsets. Fixes llvm#161812 (cherry picked from commit 69b8d6d)
For sret arguments on aarch64, the x8 register is used as input parameter to functions, even though x8 normally isn't an input parameter register. When delayloading a DLL, the first call of a delayloaded function ends up calling a helper which resolves the function. Therefore, any input arguments to the actual function to be called need to be backed up and restored - this also includes x8. This matches how MS link.exe also changed its delayloading trampoline, between MSVC 2019 16.7 and 16.8 (between link.exe 14.27.29110.0 and 14.28.29333.0). This fixes running LLDB on aarch64 mingw, after ec28b95 and 93d3260. Those commits make LLDB load liblldb.dll with delayloading, and the first function to be called, SBDebugger::InitializeWithErrorHandling(), returns an SBError, which in the itanium C++ ABI is returned as an sret via a pointer in x8. (cherry picked from commit 7e69051)
…m#162965) llvm#137363 was supposed to be NFC for the `CrossProcessModuleCache` (a.k.a normal implicit module builds), but accidentally passed the wrong path to `sys::fs::status`. Then, llvm#141358 removed the correct path that should've been passed instead. (The variable was flagged as unused.) None of our existing tests caught this regression, we only found out due to a SourceKit-LSP benchmark getting slower. This PR re-implements the original behavior, adds new remark to Clang for PCM input file validation, and uses it to create more reliable tests of the `-fmodules-validate-once-per-build-session` flag. (cherry picked from commit ce8abef)
…lvm#163466) Hexagon packets can visually straddle labels when data (e.g. jump tables) in the text section does not carry end-of-packet bits. In such cases the next instruction, even at a new symbol, appears to continue the previous packet. This patch resets packet state when encountering a new symbol so that packets at symbol starts are guaranteed to start in their own packet. (cherry picked from commit 0cdebda)
) For this specific case, when catching a pointer data type, by reference, Clang generates a special code pattern, which directly accesses the exception data by skipping past the `_Unwind_Exception` manually (rather than using the return value of `__cxa_begin_catch`). On most platforms, `_Unwind_Exception` is 32 bytes, but in some configurations it's different. (ARM EHABI is one preexisting case.) In the case of SEH, it's also different - it is 48 bytes in 32 bit mode and 64 bytes in 64 bit mode. (See the SEH ifdef in `_Unwind_Exception` in `clang/lib/Headers/unwind.h`.) Handle this case in `TargetCodeGenInfo::getSizeOfUnwindException`, fixing the code generation for catching pointers by reference. This fixes mstorsjo/llvm-mingw#522. (cherry picked from commit 10be254)
The dependency analysis in MachinePipeliner checks dependencies for every pair of store instructions in the target basic block. This means the time complexity of the analysis is `O(N^2)`, where `N` is the number of store instructions. Therefore, compilation time can become significantly long when there are too many store instructions. To mitigate it, this patch introduces logic to count the number of store instructions at the beginning of the pipeliner and bail out if it exceeds the threshold. The default value if the threshold should be large enough. Thus, in most practical cases where the pipeliner is beneficial, this patch should not cause any performance regression. Related issue: llvm#150262 (cherry picked from commit 22b79fb)
This PR adds a testcase where pipeliner bails out early because the number of the store instructions exceeds the threshold set by `pipeliner-max-num-stores`. The test should have been added in llvm#154940, but it was missed.
…162867) See LuaJIT/LuaJIT#593 (comment) for the original explanation of the problem. In short; when a debugger is attached, there's a function KiUserExceptionDispatcher in the stack that is being unwound. The function KiUserExceptionDispatcher contains a CONTEXT, with a copy of the context from where the exception was raised. When unwinding through this function, this whole CONTEXT gets restored. This CONTEXT is what we receive a pointer to in the callbacks, as the ms_ctx pointer. When we unwind manually using RtlUnwindEx, the unwinding overwrites the CONTEXT that is passed to it. Thus, to avoid clobbering the CONTEXT that needs to be restored by KiUserExceptionDispatcher, we could either declare a new temporary CONTEXT on the stack before calling RtlUnwindEx, or just use disp->ContextRecord as we already have available. Fixes: llvm#161851 Co-authored-by: Peter Cawley <corsix@corsix.org> Co-authored-by: Hannes Domani <ssbssa@yahoo.de> (cherry picked from commit a17afee)
When we implemented array cookie support for hardening std::unique_ptr, the implementation was only done for the Itanium ABI. I did not initially realize that ARM was using a different ABI for array cookies, so unique_ptr should not have been hardened on ARM. However, we were also incorrectly setting the ABI-detection macro: we were pretending to be using a vanilla Itanium ABI when in reality the (similar but different) ARM ABI was in use. As a result, unique_ptr was using the wrong representation for array cookies on ARM, which fortunately only mattered in the case of overaligned types. This patch fixes that. rdar://160852193 (cherry picked from commit b3a1994)
…lvm#159908) This in effect reverts 05fb840 and 7e1a88b, the latter of which erroneously changed the behavior of formatting `ObjC` header files when both the default and `ObjC` styles were absent. Now the previous behavior of treating that as an error is restored. Fixes llvm#158704 (cherry picked from commit d7921de)
…lvm#163111) (cherry picked from commit 059f2df)
…or (llvm#163183) Since llvm#138103 , the `Cursor` class throws an error when any of its methods is called on a null cursor. Simultaneously, we adapted all methods to return `None` instead of a null cursor, so users should not encounter these. We have overlooked one way to end up with null cursors, namely the `Token.cursor` property, which may return null cursors under some circumstances. Fixes llvm#163180
…164048) This effectively reverts commit b5f6689 and fixes llvm#111011 more narrowly. Fixes llvm#160513 (cherry picked from commit 3bb9d4a)
As fixed in commits llvm/llvm-project@913f7e9, llvm/llvm-project@4a8b124, and llvm/llvm-project@4eef2e3, also fix the stack-depth tracking code to use InstrumentationIRBuilder, and set the Call's Debug location to EntryLoc. ClangBuiltLinux/linux#2125 cc @nathanchance @melver @JustinStitt @bwendling (cherry picked from commit 28b7f66)
…r` (llvm#163358) In `buildClearRegister` use the correct pseudo-opcode for each register class: - For `VR128`, use `V_SET0` - For `VR256`, use `AVX_SET0` - For `VR512`, use `AVX512_512_SET0` - For `VK*`, use `KSET0Q/KSET0W` This avoids illegal register/opcode pairings and machine verifier errors when clearing call-used registers under `-fzero-call-used-regs=used`. Fixes: llvm#163053 --------- Co-authored-by: Simon Pilgrim <llvm-dev@redking.me.uk> (cherry picked from commit 228dae7)
This test has been reported to fail on a release bot, but nothing in the content of the test on the release branch should cause this problem: ld.lld: error: cannot open output file /home/buildbot/as-worker-92/clang-with-thin-lto-ubuntu-rel/build/stage1/tools/lld/test/ELF/Output/aarch64-build-attributes.s.tmp: Is a directory The reason this is happening is that if the same builder happened to run the extended version of this test, from a build of main, it would create a directory with that name. The test on main stashes the temporary files in that directory. $ tree tools/lld/test/ tools/lld/test/ ├── CMakeFiles ├── ELF │ └── Output │ ├── aarch64-build-attributes.s.tmp │ │ ├── pauth-bti-gcs.s │ │ └── pauth-bti-pac.s │ ├── aarch64-build-attributes.s.tmp.merged.o │ ├── aarch64-build-attributes.s.tmp1.o │ ├── aarch64-build-attributes.s.tmp2.o │ └── aarch64-build-attributes.s.tmp3.o ├── Unit │ └── lit.site.cfg.py ├── cmake_install.cmake └── lit.site.cfg.py If you then had a 21.x build run, it would find that pre-existing directory and try to write to it as if it were a file. ld.lld: error: cannot open output file /home/david.spickett/build-llvm-aarch64/tools/lld/test/ELF/Output/aarch64-build-attributes.s.tmp: Is a directory To fix this, remove the file or directory names we're going to use, before the test starts. (if this were main I'd put all the files in one direcory, but in the interest of keeping release changes small I'm just adding the rm line)
Otherwise we're looking for a commit that does not exist given the fetch depth. Fixes llvm#164430. (cherry picked from commit 288ef04)
…ing workflow (llvm#162765) This should fix the part of the workflow that creates a PR with the new documentation. (cherry picked from commit 59d4d5c)
UTF-16 to UTF-16 conversions seems widespread, and lone surrogate have a distinct representation in UTF-32. Lets not warn on this case to make the warning easier to adopt. This follows SG-16 guideline https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3695r2.html#changes-since-r1 Fixes llvm#163719
`FEAT_FPRCVT` is removed from being mandatory in Armv9.6-A `FEAT_SVE2p2` is removed from being mandatory in Armv9.6-A (cherry picked from commit 0e87811)
The "hexinsert" pass tries to replace bitfield operations with Hexagon `insert` instructions. To limit memory usage, there is a limit on the internal table size. When the limit is reached, the state is not correctly cleaned up so defs from from new `insert` instructions are not deleted after processing the basic block. Later, these defs can be incorrectly used in other basic blocks even they are not reachable. Then compiler will crash with: *** Bad machine code: Virtual register defs don't dominate all uses. *** Fixes: llvm#163774 (cherry picked from commit f3a60cf)
This test uses -debug-only, so needs an assertion-enabled build.
Variant part, represented by `DW_TAG_variant_part` is a structure with a
discriminant and different variants, from which only one can be active
and valid at the same time. The discriminant is the main difference
between variant parts and unions represented by `DW_TAG_union` type.
Variant parts are used by Rust enums, which look like:
```rust
pub enum MyEnum {
First { a: u32, b: i32 },
Second(u32),
}
```
This type's debug info is the following `DICompositeType` with
`DW_TAG_structure_type` tag:
```llvm
!4 = !DICompositeType(tag: DW_TAG_structure_type, name: "MyEnum",
scope: !2, file: !5, size: 96, align: 32, flags: DIFlagPublic,
elements: !6, templateParams: !16,
identifier: "faba668fd9f71e9b7cf3b9ac5e8b93cb")
```
With one element being also a `DICompositeType`, but with
`DW_TAG_variant_part` tag:
```llvm
!6 = !{!7}
!7 = !DICompositeType(tag: DW_TAG_variant_part, scope: !4, file: !5,
size: 96, align: 32, elements: !8, templateParams: !16,
identifier: "e4aee046fc86d111657622fdcb8c42f7", discriminator: !21)
```
Which has a discriminator:
```llvm
!21 = !DIDerivedType(tag: DW_TAG_member, scope: !4, file: !5,
baseType: !13, size: 32, align: 32, flags: DIFlagArtificial)
```
Which then holds different variants as `DIDerivedType` elements with
`DW_TAG_member` tag:
```llvm
!8 = !{!9, !17}
!9 = !DIDerivedType(tag: DW_TAG_member, name: "First", scope: !7,
file: !5, baseType: !10, size: 96, align: 32, extraData: i32 0)
!10 = !DICompositeType(tag: DW_TAG_structure_type, name: "First",
scope: !4, file: !5, size: 96, align: 32, flags: DIFlagPublic,
elements: !11, templateParams: !16,
identifier: "cc7748c842e275452db4205b190c8ff7")
!11 = !{!12, !14}
!12 = !DIDerivedType(tag: DW_TAG_member, name: "a", scope: !10,
file: !5, baseType: !13, size: 32, align: 32, offset: 32,
flags: DIFlagPublic)
!13 = !DIBasicType(name: "u32", size: 32, encoding: DW_ATE_unsigned)
!14 = !DIDerivedType(tag: DW_TAG_member, name: "b", scope: !10,
file: !5, baseType: !15, size: 32, align: 32, offset: 64,
flags: DIFlagPublic)
!15 = !DIBasicType(name: "i32", size: 32, encoding: DW_ATE_signed)
!16 = !{}
!17 = !DIDerivedType(tag: DW_TAG_member, name: "Second", scope: !7,
file: !5, baseType: !18, size: 96, align: 32, extraData: i32 1)
!18 = !DICompositeType(tag: DW_TAG_structure_type, name: "Second",
scope: !4, file: !5, size: 96, align: 32, flags: DIFlagPublic,
elements: !19, templateParams: !16,
identifier: "a2094b1381f3082d504fbd0903aa7c06")
!19 = !{!20}
!20 = !DIDerivedType(tag: DW_TAG_member, name: "__0", scope: !18,
file: !5, baseType: !13, size: 32, align: 32, offset: 32,
flags: DIFlagPublic)
```
BPF backend was assuming that all the elements of any `DICompositeType`
have tag `DW_TAG_member` and are instances of `DIDerivedType`. However,
the single element of the outer composite type `!4` has tag
`DW_TAG_variant_part` and is an instance of `DICompositeType`. The
unconditional call of `cast<DIDerivedType>` on all elements was causing
an assertion failure when any Rust code with enums was compiled to the
BPF target.
Fix that by:
* Handling `DW_TAG_variant_part` in `visitStructType`.
* Replacing unconditional call of `cast<DIDerivedType>` over
`DICompositeType` elements with a `switch` statement, handling both
`DW_TAG_member` and `DW_TAG_variant_part` and casting the element to an
appropriate type (`DIDerivedType` or `DICompositeType`).
Fixes: llvm#155778
…es (llvm#163174) We currently raise a warning in `print_btf.py` when any of these types have a name. Linux kernel doesn't allow names in these types either.[0] However, there is nothing stopping frontends from giving names to these types. To make sure that they are always anonymous, explicitly skip the name emission. [0] https://elixir.bootlin.com/linux/v6.17.1/source/kernel/bpf/btf.c#L2586
After deleting debug sections, symbol indices are shifted but sections consisting of .symidx directives are completely ignored. Update symbol indices as well. (cherry picked from commit 74d52f9)
Fix manifest `trustInfo` to use the `urn:schemas-microsoft-com:asm.v3` namespace. Fixes llvm#120394. (cherry picked from commit 6ab8e8f)
Haiku requires linking in libnetwork. Co-authored-by: Jérôme Duval <jerome.duval@gmail.com> (cherry picked from commit 21bcd00)
…loc (llvm#158349) Fix llvm#156679 There is a mismatch between the preprocessor guards around the include of `hwloc.h` and those protecting its usages, leading to build failures on Darwin: spack/spack-packages#1212 This change introduces `KMP_HWLOC_ENABLED` that reflects whether hwloc is actually used. (cherry picked from commit cd24d10)
LLVM Release 21.1.5
dianqk
merged commit 16b5ac8
into
rust-lang:rustc/21.1-2025-08-01
29 of 30 checks passed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
32 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
LLVM 21.1.5 contains fixes for the LLVM DI -> BTF translation for IR produced by Rust:
DW_TAG_variant_partin BTF generation llvm/llvm-project#155783(backported in llvm#165154)
Including these fixes in Rust nightly will allow us to: