aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-02-18[ELF] Fix .strtab corruption when a symbol name is emptyorigin/release/14.xFangrui Song1-0/+1
This is a simplified c12d49c4e286fa108d4d69f1c6d2b8d691993ffd in main which just fixes the bug but does not affect the -O2 deduplication.
2022-02-17ReleaseNotes: add BOLT subsectionAmir Ayupov1-0/+7
For the release/14.x branch. Reviewed By: tstellar Differential Revision: https://reviews.llvm.org/D119889
2022-02-18[RISCV] add the MC layer support of Zfinx extensionShao-Ce SUN30-224/+1548
This patch added the MC layer support of Zfinx extension. Authored-by: StephenFan Co-Authored-by: Shao-Ce Sun Reviewed By: asb Differential Revision: https://reviews.llvm.org/D93298 (cherry picked from commit 7798ecca9c3db42241169d31fea4fb820ed01830)
2022-02-16[OpenCL] Guard atomic_double with cl_khr_int64_*Sven van Haastregt1-0/+6
It is necessary to guard atomic_double type according to https://www.khronos.org/registry/OpenCL/specs/3.0-unified/html/OpenCL_C.html#_footnotedef_54. Platform that disable cl_khr_int64_base_atomics and cl_khr_int64_extended_atomics will have compiling errors even if atomic_double is not used. Patch by Haonan Yang. Differential Revision: https://reviews.llvm.org/D119398 (cherry picked from commit 477bc8e8b9311fdac4c360b1fe7d29d0d10aac6c)
2022-02-16clang-analyzer plugins require LLVM_ENABLE_PLUGINS alsoJameson Nash9-15/+25
The clang-analyzer plugins are not linked to a particular tool, so they can only be compiled if plugins are broadly supported. We could opt instead to decide whether to link them to specifically against clang or with undefined symbols, depending on the value of LLVM_ENABLE_PLUGINS, but we do not currently expect there to be a use case for that rather niche configuration. Differential Revision: https://reviews.llvm.org/D119591 (cherry picked from commit 9d59cfc67eadbe4b4088d70f8bbc61c96568d2f1)
2022-02-16[OpenMP][CUDA] Refine the logic to determine grid sizeShilei Tian1-4/+6
This patch refines the logic to determine grid size as previous method can escape the check of whether `CudaBlocksPerGrid` could be greater than the actual hardware limit. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D119311 (cherry picked from commit f6685f774697c85d6a352dcea013f46a99f9fe31)
2022-02-16[Debuginfod] [Symbolizer] Break debuginfod out of libLLVM.Daniel Thornburgh12-119/+272
Debuginfod can pull in libcurl as a dependency, which isn't appropriate for libLLVM. (See https://gitlab.freedesktop.org/mesa/mesa/-/issues/5732). This change breaks out debuginfod into a separate non-component library that can be used directly in llvm-symbolizer. The tool can inject debuginfod into the Symbolizer library via an abstract DebugInfoFetcher interface, breaking the dependency of Symbolizer on debuinfod. See https://github.com/llvm/llvm-project/issues/52731 Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D118413
2022-02-16[SDAG] enable binop identity constant folds for fmul/fdivSanjay Patel2-25/+17
The test diffs are identical to D119111. This only affects x86 currently because no other target has an override for the TLI hook that controls this transform. (cherry picked from commit 905abc5b7db27fa26f49f668b47a57b462be24c9)
2022-02-16[X86] Add test cases for fmul/fdiv with select.Luo, Yuanke1-0/+282
(cherry picked from commit 24562babdf16093052230e91332f1b1f13e2c4de)
2022-02-16[runtimes] Move warning messages for FOO_SYSROOT & friends above their ↵Louis Dionne3-28/+28
default value Otherwise, the warnings always trigger. (cherry picked from commit 2e3bb910e3f7f5cc92e7c5c8acc7e6e7328afcce)
2022-02-16[runtimes] Add release note for deprecation of FOO_SYSROOT & friendsLouis Dionne1-0/+5
2022-02-16[runtimes] Deprecate FOO_SYSROOT & friendsLouis Dionne3-0/+30
As suggested in https://reviews.llvm.org/D112155. Differential Revision: https://reviews.llvm.org/D119836 (cherry picked from commit 641a141da1f22de319e891bdfd61e614632b39f0)
2022-02-16[lld] One more formatting fix for the release notesJez Ng1-1/+1
2022-02-16[lld] Fix RST formatting in release notesJez Ng1-10/+10
2022-02-16[Docs][OpenCL] Update OpenCL 3.0 status in docs.Anastasia Stulova2-42/+41
Reflect the latest achievements in clang docs. Differential Revision: https://reviews.llvm.org/D119719
2022-02-16[Docs][OpenCL] Release 14 notes.Anastasia Stulova1-4/+33
Differential Revision: https://reviews.llvm.org/D119710
2022-02-16[Docs] Release 14 notes for SPIR-V in clang.Anastasia Stulova1-0/+13
Differential Revision: https://reviews.llvm.org/D119713
2022-02-15[libc++] Mark test as unsupported with apple-clangLouis Dionne1-1/+1
This is to avoid spurious test failures in case apple-clang-14 doesn't support _BitInt. (cherry picked from commit 87b218b42b14e392aa0363a413d440b77bf04bd4)
2022-02-15[ELF][PPC64] Fix assertion failure for branches to hidden undefined weak for ↵Fangrui Song5-53/+55
-no-pie Reported by Stefan Pintilie in D119773. For a branch to a hidden undefined weak symbol, there is an `assert(sym->getVA());` failure in PPC64LongBranchTargetSection::writeTo for a -no-pie link. The root cause is that we unnecessarily create the thunk for the -no-pie link. Fix this by changing the condition to just `s.isUndefined()`. See the inline comment. Rename ppc64-weak-undef-call.s to ppc64-undefined-weak.s to be consistent with other architectures. Reviewed By: sfertile, stefanp Differential Revision: https://reviews.llvm.org/D119787 (cherry picked from commit 53b59fdc52bf6c8bf15ce7c146d2cebe338f34a7)
2022-02-15[libc++] Temporarily silence failing debug mode testLouis Dionne2-1/+12
Also, fix the actual code so that the test would pass if we fixed the issue that the method is instantiated in the dylib, and hence the debug assertion will never fire except if the debug mode is enabled when the dylib is being compiled. (cherry picked from commit 5c53afe5aac0d295a9345cd439c6caf3ac5eb8ba)
2022-02-15[libc++][NFC] Work around false positive ODR violations from ASan.Konstantin Varlamov1-0/+2
This works around a known issue in ASan. ASan doesn't instrument weak symbols. Because instrumentation increases object size, the binary can end up with two versions of the same object, one instrumented and one not instrumented, with different sizes, which ASan will report as an ODR violation. In libc++, this affects typeinfo for `std::bad_function_call` which is emitted as a weak symbol in the test executable and as a strong symbol in the shared library. The main open issue for ASan appears to be https://github.com/google/sanitizers/issues/1017. Differential Revision: https://reviews.llvm.org/D119410 (cherry picked from commit 10953974ed6b61247fd4b070b3a6e390e02d0edb)
2022-02-15[libc++] Add missing UNSUPPORTED for the has-no-incomplete-ranges testLouis Dionne1-0/+1
This wasn't caught because we don't test the combination of no-filesystem and no-experimental-features in the CI. (cherry picked from commit 7dad5f84f1b8a7aafd5a27ce2889bd72a1e54002)
2022-02-15[libc++] Guard much of std::ranges under _LIBCPP_HAS_NO_INCOMPLETE_RANGES.Arthur O'Dwyer85-132/+185
The logic here is that we are disabling *only* things in `std::ranges::`. Everything in `std::` is permitted, including `default_sentinel`, `contiguous_iterator`, `common_iterator`, `projected`, `swappable`, and so on. Then, we include anything from `std::ranges::` that is required in order to make those things work: `ranges::swap`, `ranges::swap_ranges`, `input_range`, `ranges::begin`, `ranges::iter_move`, and so on. But then that's all. Everything else (including notably all of the "views" and the `std::views` namespace itself) is still locked up behind `_LIBCPP_HAS_NO_INCOMPLETE_RANGES`. Originally reviewed as https://reviews.llvm.org/D118736. (cherry picked from commit 53406fb691db38b21decf233e091f648f8317b2d) Differential Revision: https://reviews.llvm.org/D119853
2022-02-15[lld-macho] Fill out release notes for 14.xJez Ng1-4/+79
Differential Revision: https://reviews.llvm.org/D119811
2022-02-15[OpenMP][FIX] The `llvm.amdgcn.s.barrier` is actually not alignedJohannes Doerfert2-5/+6
If we assume `llvm.amdgcn.s.barrier` is aligned we may remove it and cause OpenMP GPU applications on the AMD GPU to be stuck or wrongly synchronized. Reported by Carlo Bertolli. (cherry picked from commit ede248e614bb2c232b7b1815829eb3d5c1aab1e4)
2022-02-15InferAddressSpaces: Fix assert on inferred source for inttoptr/ptrtointMatt Arsenault2-4/+61
If we had some source value we could infer an address space from that went through a ptrtoint/inttoptr pair, this would fail since bitcast can't change the address space. Fixes issue 53665. (cherry picked from commit 52fbb786a638ecc7349641b45b62a5abafffdf75)
2022-02-15ReleaseNotes: add notes for binary utilitiesFangrui Song1-0/+32
For the release/14.x branch. Reviewed By: alexander-shaposhnikov, jhenderson Differential Revision: https://reviews.llvm.org/D119611
2022-02-15[libc++] Disable back-deployment CI on the release branchLouis Dionne1-28/+31
As explained in the comment, we don't have macOS 10.15 builders anymore in the fleet. Enabling those tests on the release branch would require cherry-picking too many changes from `main`.
2022-02-15Revert "[RISCV] Enable shrink wrap by default"Dimitry Andric11-321/+538
This reverts commit 5ebdb07e7eb366c20fa2d914e07a4d380975f266. Enabling shrink wrap by default can cause assertions or crashes, and these should first be investigated and fixed. For now, reverting the change so it can be cherry-picked into 14.0.0 is the safest choice. (cherry picked from commit 7af3d4ab3d5da07256e1a7a0438e7308e14b9fd5)
2022-02-15[lldb] [Commands] Implement "thread siginfo"Michał Górny3-0/+99
Differential Revision: https://reviews.llvm.org/D118473 (cherry picked from commit 287ce6b51675aee43870bebfff68bb144d1ab90e)
2022-02-15[RISCV] Insert VSETVLI at the end of a basic block if we didn't produce ↵Craig Topper2-3/+16
BlockInfo.Exit. This is an alternative to D118667 that instead of fixing the store to match phase 1, it tries to detect the mismatch with the expected value at the end of the block. This inserts a vsetvli after the vse to satisfy the requirement of the other basic block. We still have serious design issues in the pass, that is going to require some rethinking. Differential Revision: https://reviews.llvm.org/D119518 (cherry picked from commit 541c9ba842256023611e5a6c5f01e01c40688044)
2022-02-15Revert "[RISCV] Fix a vsetvli insertion bug involving loads/stores." and ↵Craig Topper2-21/+6
"[RISCC] Add missing words to comment. NFC" This reverts commit f943c58cae2480755cecdac5be832274f238df93. and commit 7eb781072744b31a60e82b5a5903471032d4845f. This introduced a new bug that appears to be easier to hit. Differential Revision: https://reviews.llvm.org/D119517 (cherry picked from commit f35ac872b8224f771808a9ecd5c4da0fe307ac9c)
2022-02-15[RISCV] Add test case for a vsetvli insertion bug found after D118667.Craig Topper1-0/+134
We're missing a vsetvli before a vse after a redsum in this test. This appears to be because the vmv.s.x has a VL of 1, but did not trigger a vsetvli because it is a scalar move op and any non-zero VL would work. So it looked at it the predecessors and decided it was that they all had a non-zero vl. Then the redsum was visited, it also took the VL from the predecessors since the vmv.s.x and the 4 was found compatible. Finally we visit the vse and it looks at the BBLocalInfo and sees that is compatible because it contains a VL of 1 from the vmv.s.x, the first instruction in the block. BBLocalInfo was not updated when the vredsum was visited because BBLocalInfo was valid and no vsetvli was generated. I think fundamentally the vmv.s.x optimization has the same first phase and third phase not matching problem that D118667 was trying to fix for stores. Differential Revision: https://reviews.llvm.org/D119516 (cherry picked from commit ba9a7ae798053d7cf741143739351b5a4ac29d8b)
2022-02-15[OpenMP][libomp] Replace accidental VLA with KMP_ALLOCAJonathan Peyton1-1/+1
MSVC does not support variable length arrays. Replace with KMP_ALLOCA which is already used in the same file for stack-allocated variables. (cherry picked from commit 6be7c21b57e4a45b012209974ab9038b679134f5)
2022-02-15Reland "[lldb] Remove non address bits when looking up memory regions"David Spickett19-49/+193
(cherry picked from 2937b282188bafb6bdb65ee87c70e9109aa910b7) This reverts commit 0df522969a7a0128052bd79182c8d58e00556e2f. Additional checks are added to fix the detection of the last memory region in GetMemoryRegions or repeating the "memory region" command when the target has non-address bits. Normally you keep reading from address 0, looking up each region's end address until you get LLDB_INVALID_ADDR as the region end address. (0xffffffffffffffff) This is what the remote will return once you go beyond the last mapped region: [0x0000fffffffdf000-0x0001000000000000) rw- [stack] [0x0001000000000000-0xffffffffffffffff) --- Problem is that when we "fix" the lookup address, we remove some bits from it. On an AArch64 system we have 48 bit virtual addresses, so when we fix the end address of the [stack] region the result is 0. So we loop back to the start. [0x0000fffffffdf000-0x0001000000000000) rw- [stack] [0x0000000000000000-0x0000000000400000) --- To fix this I added an additional check for the last range. If the end address of the region is different once you apply FixDataAddress, we are at the last region. Since the end of the last region will be the last valid mappable address, plus 1. That 1 will be removed by the ABI plugin. The only side effect is that on systems with non-address bits, you won't get that last catch all unmapped region from the max virtual address up to 0xf...f. [0x0000fffff8000000-0x0000fffffffdf000) --- [0x0000fffffffdf000-0x0001000000000000) rw- [stack] <ends here> Though in some way this is more correct because that region is not just unmapped, it's not mappable at all. No extra testing is needed because this is already covered by TestMemoryRegion.py, I simply forgot to run it on system that had both top byte ignore and pointer authentication. This change has been tested on a qemu VM with top byte ignore, memory tagging and pointer authentication enabled. Reviewed By: omjavaid Differential Revision: https://reviews.llvm.org/D115508
2022-02-15[OpenMP][Offloading] Fix infinite loop in applyToShadowMapEntriesShilei Tian2-0/+59
This patch fixes the issue that the for loop in `applyToShadowMapEntries` is infinite because `Itr` is not incremented in `CB`. Fixes #53727. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D119471 (cherry picked from commit c27f530d4c6306b2010306131f66e771d6a66594)
2022-02-14[release] Use a supported way of building libc++ when building the documentationLouis Dionne1-3/+15
Instead of using the deprecated LLVM_ENABLE_PROJECTS build, use the default runtimes build. This is just as fast, but it's supported. Differential Revision: https://reviews.llvm.org/D119275 (cherry picked from commit f34f7dfe3a3d8a6ec2c582f5672c3ca37d9aed7c)
2022-02-14[scan-build] Fix deadlock at failures in libears/ear.cBalazs Benics1-0/+4
We experienced some deadlocks when we used multiple threads for logging using `scan-builds` intercept-build tool when we used multiple threads by e.g. logging `make -j16` ``` (gdb) bt #0 0x00007f2bb3aff110 in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f2bb3af70a3 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f2bb3d152e4 in ?? () #3 0x00007ffcc5f0cc80 in ?? () #4 0x00007f2bb3d2bf5b in ?? () from /lib64/ld-linux-x86-64.so.2 #5 0x00007f2bb3b5da27 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x00007f2bb3b5dbe0 in exit () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x00007f2bb3d144ee in ?? () #8 0x746e692f706d742f in ?? () #9 0x692d747065637265 in ?? () #10 0x2f653631326b3034 in ?? () #11 0x646d632e35353532 in ?? () #12 0x0000000000000000 in ?? () ``` I think the gcc's exit call caused the injected `libear.so` to be unloaded by the `ld`, which in turn called the `void on_unload() __attribute__((destructor))`. That tried to acquire an already locked mutex which was left locked in the `bear_report_call()` call, that probably encountered some error and returned early when it forgot to unlock the mutex. All of these are speculation since from the backtrace I could not verify if frames 2 and 3 are in fact corresponding to the `libear.so` module. But I think it's a fairly safe bet. So, hereby I'm releasing the held mutex on *all paths*, even if some failure happens. PS: I would use lock_guards, but it's C. Reviewed-by: NoQ Differential Revision: https://reviews.llvm.org/D118439 (cherry picked from commit d919d027ba2a41df5d51ce82ae7f2fb64d2cba41)
2022-02-14[test-release.sh] Set TEST_SUITE_HOST_CC to the release testing build ↵Amy Kwan1-1/+4
compiler when compiling test-suite tools. The tools used by test-suite are originally configured to compile with cc by default, and this is dictated by TEST_SUITE_HOST_CC. However, it is possible that on some systems that the version of cc may either not be present or it may not be able to compile the tools as it may be too old, which could be an issue seen during release testing. This patch updates the compiler to be the default build compiler that is used for release testing. If no such compiler it specified, then cc will be set as the test-suite tools build compiler by default (as it already is set under TEST_SUITE_HOST_CC). Differential Revision: https://reviews.llvm.org/D118357 (cherry picked from commit 413b35cd74e42f6371641bc9dc6c707aedac82ff)
2022-02-14[clang] [MinGW] Recognize -lcrtdll as a library replacing -lmsvcrtMartin Storsjö2-1/+6
Differential Revision: https://reviews.llvm.org/D119234 (cherry picked from commit 079b6d02d1f52301e2d3276fadba822bf87b75b2)
2022-02-14[OpenCL] Adjust diagnostic for subgroup support.Anton Zabaznov2-5/+11
OpenCL C 3.0 __opencl_c_subgroups feature is slightly different then other equivalent features and extensions (fp64 and 3d image writes): OpenCL C 3.0 device can support the extension but not the feature. cl_khr_subgroups requires subgroup independent forward progress. This patch adjusts the check which is used when translating language builtins to check either the extension or feature is supported. Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D118999 (cherry picked from commit bfb1a33bec7c88170b0809b8a7c9cb860e7cc19b)
2022-02-14[OpenCL] Add support of language builtins for OpenCL C 3.0Anton Zabaznov9-72/+93
OpenCL C 3.0 introduces optionality to some builtins, in particularly to those which are conditionally supported with pipe, device enqueue and generic address space features. The idea is to conditionally support such builtins depending on the language options being set for a certain feature. This allows users to define functions with names of those optional builtins in OpenCL (as such names are not reserved). Reviewed By: Anastasia Differential Revision: https://reviews.llvm.org/D118605 (cherry picked from commit bee4bd70f76952b2c6296feb46a087b497322376)
2022-02-14[OpenCL] Add OpenCL 3.0 atomics to -fdeclare-opencl-builtinsSven van Haastregt3-54/+118
Add the atomic overloads for the `global` and `local` address spaces, which are new in OpenCL 3.0. Ensure the preexisting `generic` overloads are guarded by the generic address space feature macro. Ensure a subset of the atomic builtins are guarded by the `__opencl_c_atomic_order_seq_cst` and `__opencl_c_atomic_scope_device` feature macros, and enable those macros for SPIR/SPIR-V targets in `opencl-c-base.h`. Also guard the `cl_ext_float_atomics` builtins with the atomic order and scope feature macros. Differential Revision: https://reviews.llvm.org/D119420 (cherry picked from commit 50f8abb9f40a6c4974ec71e760773a711732648f)
2022-02-14[OpenCL] Refactor cl_ext_float_atomics declarations; NFCSven van Haastregt1-117/+55
Reduce the amount of repetition in the declarations by leveraging more TableGen constructs. This is in preparation for adding the OpenCL 3.0 atomics feature optionality. (cherry picked from commit 8d37043520f57e63e032c9d0ba4cba8701a3cd35)
2022-02-14[OpenCL] Fix atomic_fetch_add/sub with half typeSven van Haastregt1-3/+3
An error in the tablegen description affects the declarations provided by `-fdeclare-opencl-builtins` for `atomic_fetch_add` and `atomic_fetch_sub`. The atomic argument should be an atomic_half, not an atomic_float. (cherry picked from commit fe690587bedb23dec2753549d4216059a7f894a1)
2022-02-14[OpenCL] Move OpenCL 2.0 atomics into multiclass; NFCSven van Haastregt1-18/+24
This is in preparation for adding the OpenCL 3.0 builtins with named address space arguments. (cherry picked from commit 31fa3a4d44316fd36e11f92729ea9596ee3bf3f8)
2022-02-14[OpenCL] Move most _explicit atomics into multiclass; NFCSven van Haastregt1-170/+46
This will simplify future conditionalization for OpenCL 3.0 optionality of atomic features. The only set of atomic functions not using the multiclass is atomic_compare_exchange_strong/weak, as these don't fit the common pattern due to having 2 MemoryOrder arguments. (cherry picked from commit d97a4dfea6c2781494f6fe54ce265128f5c08dc2)
2022-02-14[OpenCL] Test -fdeclare-opencl-builtins with CL3 and CLC++2021Sven van Haastregt1-0/+2
But only test in combination with -finclude-default-header, as the headerless tests may be dropped soon. (cherry picked from commit e0e6f3a6a2e13ee11b014ca45a48997e78d3efc5)
2022-02-14[clang-format] Honour "// clang-format off" when using QualifierOrder.Marek Kurdej2-0/+26
Fixes https://github.com/llvm/llvm-project/issues/53643. Reviewed By: MyDeveloperDay, HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D119218 (cherry picked from commit e329b5866f1732f5c24cf2ae96479971f7101914)
2022-02-14replace clang LLVM_ENABLE_PLUGINS -> CLANG_PLUGIN_SUPPORT in testsJameson Nash12-14/+25
Ensure CLANG_PLUGIN_SUPPORT is compatible with llvm_add_library. Fixes an issue noted in D111100. Differential Revision: https://reviews.llvm.org/D119199 (cherry picked from commit 76cad51ba700233d6e3492eddcbb466b6adbc2eb)
generated by cgit v1.1 at 2024-09-07 01:51:27 +0000