summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* clang: allow build on Windows with Visual C++release_16.0.2-basedCristian Adam2023-04-191-1/+1
| | | | | | | | | | | | The CMake code will set HAVE_CLANG_REPL_SUPPORT to ON and the Visual C++ compiler will complain at linking a release build of clang-repl.exe due to the number of symbols bigger than 65k. This patchset allows setting HAVE_CLANG_REPL_SUPPORT to OFF and build fine. Change-Id: I10665ef13c7dfffb5e23c05475ac5f10de48b8ee Reviewed-by: Eike Ziller <eike.ziller@qt.io>
* clang-tools-extra: disable new clang-tidy plugin testsCristian Adam2023-04-191-0/+2
| | | | | Fixes linking errors reported at https://reviews.llvm.org/D111100 and https://reviews.llvm.org/D119199
* Handle user files as volatile in tooling on windowsDavid Schulz2023-04-193-4/+10
| | | | | | | | | | | Prevent locking user files when running clang tools by marking them as volatile. Non volatile files will be mapped into memory and a handle is kept to track file changes. This handle can prevent other processes to access or remove the file. Fixes: QTCREATORBUG-24911 Change-Id: I517e9982972a9e5e20df60c603675a9d370004c6 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Remove UB-implying metadata when promoting speculative instruction.llvmorg-16.0.2DianQK2023-04-182-2/+28
| | | | | | | | | | After D138238 introduced the then/else blocks, we should remove UB-implying metadata for the promoted speculative instruction. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D148456 (cherry picked from commit 2832d7941f4207f1fcf813b27cf08cecc3086959)
* [runtimes][asan] Fix swapcontext interceptionIvan Trofimov2023-04-184-39/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Resetting oucp's stack to zero in swapcontext interception is incorrect, since it breaks ucp cleanup after swapcontext returns in some cases: Say we have two contexts, A and B, and we swapcontext from A to B, do some work on Bs stack and then swapcontext back from B to A. At this point shadow memory of Bs stack is in arbitrary state, but since we can't know whether B will ever swapcontext-ed to again we clean up it's shadow memory, because otherwise it remains poisoned and blows in completely unrelated places when heap-allocated memory of Bs context gets reused later (see https://github.com/llvm/llvm-project/issues/58633 for example). swapcontext prototype is swapcontext(ucontext* oucp, ucontext* ucp), so in this example A is oucp and B is ucp, and i refer to the process of cleaning up Bs shadow memory as ucp cleanup. About how it breaks: Take the same example with A and B: when we swapcontext back from B to A the oucp parameter of swapcontext is actually B, and current trunk resets its stack in a way that it becomes "uncleanupable" later. It works fine if we do A->B->A, but if we do A->B->A->B->A no cleanup is performed for Bs stack after B "returns" to A second time. That's exactly what happens in the test i provided, and it's actually a pretty common real world scenario. Instead of resetting oucp's we make use of uc_stack.ss_flags to mark context as "cleanup-able" by storing stack specific hash. It should be safe since this field is not used in [get|make|swap]context functions and is hopefully never meaningfully used in real-world scenarios (and i haven't seen any). Fixes https://github.com/llvm/llvm-project/issues/58633 Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D137654 (cherry picked from commit b380e8b68951776656f286ecd079e2f30981905e)
* [nfc][asan] Reformat the fileVitaly Buka2023-04-181-65/+65
| | | | (cherry picked from commit 3248ca0da01c73711896ddc86ae8b045b86726c8)
* [test][asan] Simplify testVitaly Buka2023-04-181-14/+4
| | | | | | FileCheck is not very useful here. (cherry picked from commit fd2cafbdc480920bcf4eb598788a906ec1f63c41)
* llvm-exegesis: Only run target specfic tests on native hostsTom Stellard2023-04-182-0/+6
| | | | | | | | | | | | These tests were failing on SystemZ hosts, I don't think JIT'ing non-SystemZ modules on SystemZ is supported. The tests were initiallay enabled on all arches by 7a76140220bd2c4730a2c39b6fd645402040f011. Differential Revision: https://reviews.llvm.org/D145763 (cherry picked from commit e30ce634f75c01cc8784cb0c4972c42987178c1d)
* github: Add manual workflow to build and upload release binariesJack Grigg2023-04-182-0/+147
| | | | | | | | Reviewed By: kwk Differential Revision: https://reviews.llvm.org/D143535 (cherry picked from commit 5b8156bf623042c857150cb9a6039d7e775d90e4)
* [flang] Complex numbers in function arguments on WindowsMarkus Mützel2023-04-182-4/+362
| | | | | | | | | | | | | | | | Function arguments or return values that are complex floating point values aren't correctly lowered for Windows x86 32-bit and 64-bit targets. See: https://github.com/llvm/llvm-project/issues/61976 Add targets that are specific for these platforms and OS. With thanks to @mstorsjo for pointing out the fix. Reviewed By: vzakhari Differential Revision: https://reviews.llvm.org/D147768 (cherry picked from commit 774703ec08f62d702d40e1f97cd35ae5f732c544)
* [clang-format] Fix regression with AlignTrailingComments set to trueOwen Pan2023-04-172-10/+10
| | | | | | | | Fixes #62161. Differential Revision: https://reviews.llvm.org/D148447 (cherry picked from commit 2bcfff6708d293abab87a4d5a1dff25950d55d91)
* Revert "[clang-format] Handle object instansiation in if-statements"Tobias Hieta2023-04-172-20/+1
| | | | | | | | This reverts commit 70de684d44135b4025d92b2b36ad387cf5ab8b5a. This causes a regression as described in #61785 (cherry picked from commit 104cd749f5cca609a79303c0dad22bc041b5448a)
* [StackProtector] don't check stack protector before calling nounwind functionsNick Desaulniers2023-04-173-17/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://reviews.llvm.org/rGd656ae28095726830f9beb8dbd4d69f5144ef821 introduced a additional checks before calling noreturn functions in response to this security paper related to Catch Handler Oriented Programming (CHOP): https://download.vusec.net/papers/chop_ndss23.pdf See also: https://bugs.chromium.org/p/llvm/issues/detail?id=30 This causes stack canaries to be inserted in C code which was unexpected; we noticed certain Linux kernel trees stopped booting after this (in functions trying to initialize the stack canary itself). https://github.com/ClangBuiltLinux/linux/issues/1815 There is no point checking the stack canary like this when exceptions are disabled (-fno-exceptions or function is marked noexcept) or for C code. The GCC patch for this issue does something similar: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a25982ada523689c8745d7fb4b1b93c8f5dab2e7 Android measured a 2% regression in RSS as a result of d656ae280957 and undid it globally: https://android-review.googlesource.com/c/platform/build/soong/+/2524336 Reviewed By: xiangzhangllvm Differential Revision: https://reviews.llvm.org/D147975 (cherry picked from commit fc4494dffa5422b2be5442c235554e76bed79c8a)
* [libunwind][LoongArch] Restore $r1 before $r4 in `jumpto`Weining Lu2023-04-172-7/+2
| | | | | | | | | | | | | $ra should be restored before $a0, otherwise the baseaddress ($a0) would be destroyed. See file `UnwindRegistersSave.S` for reference. This also makes libcxx and libcxxabi regtest pass for the `-DLIBCXXABI_USE_LLVM_UNWINDER=ON` build. Reviewed By: MaskRay, xen0n, #libunwind Differential Revision: https://reviews.llvm.org/D147372 (cherry picked from commit ff0aabf14dfa0a369c38f6e267c56a83ee48d647)
* [libunwind][test] Add test to check for unw_resume()zhanglimin2023-04-171-0/+39
| | | | | | | | | | | | This is here for local unwinding, which unw_resume() restores the machine state and then directly resumes execution in the target stack frame. Reviewed By: wangleiat Differential Revision: https://reviews.llvm.org/D147371 (cherry picked from commit 366c5474a3002114b8980ab278d93baa96046385)
* [AArch64] Basic target(+crypto) handlingDavid Green2023-04-172-1/+54
| | | | | | | | | | This adds some basic handling for target(+crypto) attributes. In this patch it just enabled aes and sha2 regardless of the architecture revision, which matches gccs implementation (and keeps the patch simple). Differential Revision: https://reviews.llvm.org/D142135 (cherry picked from commit 43aa293aeaf04e8da50c3c531694444c0311e0c5)
* [Support] Improve Windows performance of buffered raw_ostreamAndrew Ng2023-04-141-0/+7
| | | | | | | | | | | | | | | | | | The "preferred" buffer size for raw_ostream is set to BUFSIZ which on Windows is only 512. This results in more calls to write and this overhead can have a significant negative impact on performance, especially when Anti-Virus is also involved. Therefore increase the "preferred" buffer size to 16KB for Windows. One example of where this helps is the LLD --Map option which dumps out the symbol map for a link. In a link of UE4, this change has been seen to improve the performance of the symbol map writing by more than a factor of 6. Differential Revision: https://reviews.llvm.org/D147340 (cherry picked from commit a3aa916d019c8deb10c750acecdef650b3365f22)
* [LinkerWrapper] Switch to add_clang_tool() macroEvangelos Foutras2023-04-141-5/+1
| | | | | | | | | | | | Summary: This creates install-clang-linker-wrapper{,-stripped} targets which are useful for Linux distro builds when using LLVM_DISTRIBUTION_COMPONENTS. Fixes: https://bugs.archlinux.org/task/77814 Differential Revision: https://reviews.llvm.org/D145862 (cherry picked from commit c2aabcfc8395ba30884dd3c1ecc2b192ae85a78d)
* Bump version to 16.0.2Tom Stellard2023-04-044-4/+4
|
* [SPARC] Attempt to fix bug introduced by D142458llvmorg-16.0.1Vitaly Buka2023-04-041-1/+1
| | | | | | Reported https://lab.llvm.org/buildbot/#/builders/5/builds/32113 (cherry picked from commit ea4cbbbfa4207c30888acffc499c8fc71cd3d84f)
* [SPARC] Implement hooks for conditional branch relaxationKoakuma2023-04-0410-45/+250
| | | | | | | | | | | | | | | | Integrate the BranchRelaxation pass to help with relaxing out-of-range conditional branches. This is mostly of concern for SPARCv9, which uses conditional branches with much smaller range than its v8 counterparts. (Some large autogenerated code, such as the ones generated by TableGen, already hits this limitation when building in Release) Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D142458 (cherry picked from commit 24e300190a57c97ce88b42bfd6afc84a79fd15e5)
* [Local] Handle size mismatch between pointer/int in copyRangeMetadata()Nikita Popov2023-04-042-1/+20
| | | | | | | | SROA may convert a wide integer load into a narrow pointer load, make sure we don't crash. It would not be legal to transfer the metadata in this case. (cherry picked from commit fc6e91fe8184129d2395b79ce42f4495b95b0d0d)
* [clang-format] Don't annotate left brace of struct as FunctionLBraceOwen Pan2023-04-043-13/+26
| | | | | | | | Related to a02c3af9f19d. Fixes #61700. Differential Revision: https://reviews.llvm.org/D146895 (cherry picked from commit 767aee1de9e98256a62ae8b4c2f84381203613c3)
* [SelectionDAG] Correctly reduce BV to shuffle with zero on big endianNemanja Ivanovic2023-04-042-4/+136
| | | | | | | | This DAG combine is correct on little endian targets but is incorrect on big endian targets. Add big endian code to correct it. Differential revision: https://reviews.llvm.org/D146460
* [llvm-rc] Fix the reference to the option for disabling preprocessing in a ↵Martin Storsjö2023-04-041-3/+9
| | | | | | | | | | | | message This was the original option name from the first iteration of the patch that added the feature, but during review, a different name was suggested and preferred - but the reference in the helpful message was missed. Differential Revision: https://reviews.llvm.org/D146796 (cherry picked from commit 014e5c8d39c172a5b4bb1e1c75ced9bcb9ff2115)
* [llvm-rc] Look for "clang-<major>" when locating a suitable preprocessorMartin Storsjö2023-04-041-1/+4
| | | | | | | | | | | | | | | In some cases, there's no adjacent executable named "clang" or "clang-cl", but one name "clang-<major>". This logic doesn't cover every possible deployment setup of course, but should cover more fairly common/reasonable cases. See https://github.com/curl/curl-for-win/commit/caaae171ac43af5b883403714dafd42030d8de61#commitcomment-105808524 for discussion about a case where this would have been helpful. Differential Revision: https://reviews.llvm.org/D146794 (cherry picked from commit 282744a9ce18120dc0a6eceb02693b36980d9498)
* [llvm-rc] Respect the executable specified in the --preprocessor commandMartin Storsjö2023-04-041-2/+2
| | | | | | | | | | | | | | | | | | The arguments passed in this option were passed onto the child process, but we still blindly used the clang binary that we had found to sys::ExecuteAndWait as the intended executable to run. If the user hasn't specified any custom --preprocessor command, Args[0] is equal to the variable Clang. This doesn't affect any tests, since the tests only print the arguments it would try to execute (but not the first parameter to sys::ExecuteAndWait), but there's no testes for executing it (and validating that it did execute the right thing). Differential Revision: https://reviews.llvm.org/D146793 (cherry picked from commit d2fa6b694c2052cef1ddd507f6569bc84e3bbe35)
* [libc++] Don't try to provide source_location on AppleClang 1403Louis Dionne2023-04-047-14/+18
| | | | | | | | | | | | | | | AppleClang 1403 has some bugs that prevent std::source_location from working properly on it. Consequently, we XFAILed the unit test for source_location with that compiler. However, we should also avoid advertising that the feature is supported on that compiler, otherwise our feature-test macros lie. This was noticed to break Boost.Asio when building with a recent libc++ and AppleClang 14.0.3. rdar://106863087 Differential Revision: https://reviews.llvm.org/D146837 (cherry picked from commit c2a42381c18edf0fedd0fc7e3c8541d4fa3e0bcc)
* [RISCV] Support emulated TLSVitaly Cheptsov2023-04-042-0/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed earlier in the [GitHub issue](https://github.com/llvm/llvm-project/issues/59500), currently LLVM generates invalid code when emulated TLS is used. There were attempts to resolve this previously (D102527), but they were not merged because the component owners raised concerns about emulated TLS efficiency. The current state of the art is that: - OpenBSD team, which raised the initial issue, simply has [patches downstream](https://github.com/openbsd/src/blob/a0747c9/gnu/llvm/llvm/lib/Target/RISCV/RISCVISelLowering.cpp#L2850-L2852). - Our team, which raised the GH issue, has patches downstream as well. We also do not use `malloc` or any [dynamic allocations](https://github.com/llvm/llvm-project/issues/59500#issuecomment-1349046835) with emulated TLS, so the concerns raised in the original issue does not apply to us. - GCC compatibility is broken, because GCC supports emulated TLS. - RISC-V is the only architecture in LLVM that does not support emulated TLS, and work is being done to at least warn the users about it (D143619). With all these in mind I believe it is important to address the consumers' needs especially given that there is little to no maintenance downsides. Differential Revision: https://reviews.llvm.org/D143708 (cherry picked from commit f5e63f8fc9f492944b8432d80c1c49051a7d600a)
* [clang-format] Add MinDigits suboptions to IntegerLiteralSeparatorOwen Pan2023-04-046-22/+137
| | | | | | | | Closes #61209. Differential Revision: https://reviews.llvm.org/D147111 (cherry picked from commit 253985d58caf95db8a84632d5a761b96fb7cd7d6)
* [clang-format] Don't format already formatted integer literalsOwen Pan2023-04-041-6/+5
| | | | | | | | | Fixes a bug in IntegerLiteralSeparatorFixer::checkSeparator() so that only unformatted integer literals will be formatted. Differential Revision: https://reviews.llvm.org/D146501 (cherry picked from commit 5b5c49ad4563f75debccbc6c3017d27a47ca217d)
* [RISCV] Allow llvm-objdump to disassemble objects with unrecognised versions ↵Alex Bradbury2023-04-044-6/+119
| | | | | | | | | | | | | | | | | | | | of known extensions This Moves ELFObjectFile to using RISCVISAInfo::parseNormalizedArchString which does not ignore or produce an error for ISA extensions with a version that isn't recognised/supported by LLVM. As current GCC is marking its objects with a higher version of the A, F, and D extensions than LLVM (see [extension versioning discussion](https://discourse.llvm.org/t/rfc-resolving-issues-related-to-extension-versioning-in-risc-v/68472) this massively improves the usability of llvm-objdump with such binaries. This patch is functionally a cherry-pick of af602edf0ecb4e1d7de4ccce8ebe1be8bb53443d and 91c6174ce35969d7f0d73c645fa47b813e0d99d3, though I've constructed the backport manually because other changes unrelated to this specific fix make a direct cherry pick difficult.
* Revert "[dsymutil] dsymutil produces broken lines info (probably) with LTO ↵Tom Stellard2023-04-047-398/+207
| | | | | | | | on mac" This reverts commit 56edf062bdb64f0ce89860ed3e643f29a2f90e45. This change modified the public API/ABI which is not allowed in stable releases.
* [clang][MinGW] Add asan DLL lib before other libs and objectsAlvin Wong2023-04-032-9/+26
| | | | | | | | | | | | | | | | | As stated in https://github.com/llvm/llvm-project/issues/61685, by passing LLD the import lib of the asan DLL first, the asan DLL will be listed as the first entry in the Import Directory Table, making it be loaded first before other user DLLs. This allows asan to be initialized as early as possible to increase its instrumentation coverage to include other DLLs not built with asan. This also avoids some false asan reports on `realloc` for memory allocated during initialization of user DLLs being loaded earlier than asan, because after this change they will be loaded later than asan. Differential Revision: https://reviews.llvm.org/D146908 (cherry picked from commit 81358e9193a9282372c145b63042b2852d3afa18)
* ARMFrameLowering.cpp - fix MSVC "result of 32-bit shift implicitly converted ↵Simon Pilgrim2023-04-031-2/+2
| | | | | | to 64 bits" warning. NFC. (cherry picked from commit b206145323fafc75d82efcc7e154218e37480953)
* [ARM] Handle generating SEH unwind info for t2STR_PRE/t2LDR_POSTMartin Storsjö2023-04-032-0/+56
| | | | | | | | This fixes compiling some uncommon cases. Differential Revision: https://reviews.llvm.org/D147212 (cherry picked from commit c5383536cb6824391f99f8f5963fc1427dd1673f)
* [libc++] Mark a test relying on `typeid` as unsupported without RTTI.Konstantin Varlamov2023-04-031-0/+3
| | | | (cherry picked from commit f50cad2c55dfab4ff3da010a64119b4a93522289)
* [release/16.x][libc++] Revert the bitset sort optimizationLouis Dionne2023-04-032-432/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | Part of the bitset sort optimization can cause code using an invalid comparator to go out-of-bounds, which is potentially dangerous. This was an unintended consequence of the original patch, or at least the fact that we didn't have anything in place to catch that or announce that to vendors was unintended. More specifically, std::sort assumes that the comparison predicate is a strict weak order (which is a pre-condition to the algorithm). However, in practice, some predicates may not satisfy the pre-condition in subtle ways. While that is technically a user problem, we need a good answer for how to handle this given that we know this exists in the wild and unconditionally reading out-of-bounds data is not a great answer. We can't weaken the preconditions of the algorithm, however letting this situation happen without even a way of diagnosing the issue is pretty bad. Hence, this patch reverts the optimization from release/16.x so that we can buy a bit of time to figure out how to properly handle and communicate this change in the LLVM 17 release. The bitset sort optimization was 4eddbf9f10a (aka https://llvm.org/D122780). This patch is not a pure revert of the patch, I also fixed up the includes a bit. Differential Revision: https://reviews.llvm.org/D146421
* [libc++] Fix CI on release/16.xLouis Dionne2023-04-0311-9/+20
| | | | | | | | | This patch is aimed directly at release/16.x -- it ensures that we can run the CI successfully on the release branch. It's a collection of changes that were made on main and not backported to release/16.x because the CI had been failing since we created the branch. Differential Revision: https://reviews.llvm.org/D147065
* [clang-format] Handle '_' in ud-suffix for IntegerLiteralSeparatorOwen Pan2023-04-032-2/+22
| | | | | | | | | | | Also, handle imaginary numbers, i.e., those with suffixes starting with an 'i'. Fixes #61676. Differential Revision: https://reviews.llvm.org/D146844 (cherry picked from commit 4d21868b09681dffb9997f1a8d0c0dac12a226d3)
* Bump version to 16.0.1Tobias Hieta2023-03-284-4/+4
|
* [CMake] Respect variables for specifying host tools even without ↵Martin Storsjö2023-03-281-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLVM_USE_HOST_TOOLS set When LLVM_NATIVE_TOOL_DIR was introduced in d3da9067d143f3d4ce59b6d9ab4606a8ef1dc937 / D131052, it consisted of refactoring a couple cases of manual logic for tools in clang-tools-extra/clang-tidy, clang-tools-extra/pseudo/include and mlir/tools/mlir-linalg-ods-gen. The former two had the same consistent behaviour while the latter was slightly different, so the refactoring would end up slightly adjusting one or the other. The difference was that the clang-tools-extra tools respected the external variable for setting the tool name, regardless of the LLVM_USE_HOST_TOOLS variable, while mlir-linalg-ods-gen tool only checked its external variable if LLVM_USE_HOST_TOOLS was set. LLVM_USE_HOST_TOOLS is supposed to be enabled automatically whenever cross compiling, so this shouldn't have been an issue. In https://github.com/llvm/llvm-project/issues/60784, it seems like some users do cross compile LLVM, without CMake knowing about it (without CMAKE_CROSSCOMPILING being set). In these cases, their build broke, as the variables for pointing to external host tools no longer were being respected. The fact that CMAKE_CROSSCOMPILING wasn't set stems from a non-obvious behaviour of CMake; CMAKE_CROSSCOMPILING isn't supposed to be set by the user (and if it was, it gets overridden), but one has to set CMAKE_SYSTEM_NAME to indicate that one is cross compiling, even if the target OS is the same as the current host. Skip the checks for LLVM_USE_HOST_TOOLS and always respect the variables for pointing to external tools (both the old tool specific variables, and the new LLVM_NATIVE_TOOL_DIR), if they're set. This makes the logic within setup_host_tool more exactly match the logic for the clang-tools-extra tools from before the refactoring in d3da9067d143f3d4ce59b6d9ab4606a8ef1dc937. This makes the behaviour consistent with that of the tablegen executables, which also respect the externally set variables regardless of LLVM_USE_HOST_TOOLS. This fixes https://github.com/llvm/llvm-project/issues/60784. Differential Revision: https://reviews.llvm.org/D146666 (cherry picked from commit 4a5bc791f38a5156bdba87a0572642b1bf3521e9)
* [llvm-objdump] Fix help message for --print-imm-hexYi Kong2023-03-281-2/+2
| | | | | | Commit cc2457ca1bbd changed the default but forgot to update the help message. (cherry picked from commit 3d65cd405d64afd86a59c1f58098dfe891841271)
* [sanitizer][win] Change cmdline check to allow double backslashsAlvin Wong2023-03-282-3/+1
| | | | | | | | | | | | | | | | | | | | | | | When `llvm-symbolizer.exe` is on the PATH in an entry containing two consecutive backslashes, sanitizers will try to launch llvm-symbolizer with its absolute path containing these consecutive backslashes. This fails a sanity check in `sanitizer_symbolizer_win.cpp`. According to the documentation of `CommandLineToArgvW` [1] and a MS blog post [2], backslashes in general, regardless of how many of them in a row, do not have any special effect, unless when immediately followed by a double quote. There already exists a check that fails when the command line arguments contains double quote, therefore the check for double backslashes can simply be removed. [1]: https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw [2]: https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way Differential Revision: https://reviews.llvm.org/D146621 (cherry picked from commit b1871ceb1cf6c6954380867d41db3812e9e0dbfc)
* [BOLT] Search section based on relocation symbolyavtuk2023-03-283-2/+50
| | | | | | | | | | | | | We need to search referenced section based on relocations symbol section to properly match end section symbols. For example on some binaries we can observe that init_array_end/fini_array_end might be "placed" in to the gap and since no section could be found for address the relocation would be skipped resulting in wrong ADRP imm after emitting new text resulting in binary sigsegv. Credits for the test to Vladislav Khmelevskii aka yota9. (cherry picked from commit 0776fc32b15dc76c6b43c41fc4471552833265de)
* [libc++] Avoid ODR violations in __exception_guardNikolas Klauser2023-03-285-26/+78
| | | | | | | | | | | | Having an ODR violation with `__exception_guard` seems to be problematic in LTO builds. To avoid the ODR violation, give the class different names for exception/no-exceptions mode and have an alias to the correct class. Reviewed By: ldionne, #libc, alexfh Spies: aeubanks, dblaikie, joanahalili, alexfh, rupprecht, libcxx-commits Differential Revision: https://reviews.llvm.org/D143071 (cherry picked from commit 1a17739d3aa78599c32f6106e05dcfa7f3f9e823)
* [BOLT][AArch64] Replace NOP with adrp in AdrRelaxationPass to preserve ↵Denis Revunov2023-03-282-0/+24
| | | | | | | | | | | | | relative offsets. Avoid replacing one adr instruction with two adrp+add by utilizing linker-provided nops when they are present. By doing so we preserve relative offsets of next instructions in a function which reduces chances to break undetected jump tables. This commit makes release-mode lld-linked clang, lld and etc work after BOLT. Reviewed By: rafauler, yota9 Differential Revision: https://reviews.llvm.org/D143887
* [BOLT][NFC] Remove C-style out of bounds array refRafael Auler2023-03-281-5/+3
| | | | | | Old code breaks build with libstdc++ with assertions. Fix it. (cherry picked from commit 7768f63e5b7adc8a92b8f8041e9c1d298b011128)
* [RISCV][MC] Adjust conditions to emit R_RISCV_ADD*/R_RISCV_SUB* pairsFangrui Song2023-03-282-9/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | D132262 tried to simplify `IsMetadataOrEHFrameSection` originally introduced in D127549 but caused a regression as `.quad` directives in ``` .section .note,"a",@note; note: .quad extern-note # extern is undefined .section .rodata,"a",@progbits; rodata: .quad extern-rodata # extern is undefined .section .nonalloc,"",@progbits; nw: .quad extern-nw ``` are incorrectly rejected: these differences may be link-time constants and are allowed in GNU assembler and LLVM MC's non-RISC-V ports. Relax the conditions to allow these cases. For A-B, A may be defined later, but this requiresFixups call has to eagerly make a decision. For now, emit ADD/SUB unless A is `.L*`. This euristic handles many temporary label differences for .debug_* and .apple_types sections. Ideally we should delay the decision of PC-relative vs ADD/SUB until A is defined. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D145474 (cherry picked from commit 2f5fe16e6d29c55ebd9ec098b03d4de47a804a18)
* [test] Add some interesting cases to MC/RISCV/riscv64-64b-pcrel.sFangrui Song2023-03-281-1/+23
| | | | (cherry picked from commit c598828b1beb8a67271b5e56cb7033ae4e40da88)
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 21:53:43 +0000