summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* [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)
* [test] Improve MC/RISCV/riscv64-64b-pcrel.s to demonstrate regression due to ↵Fangrui Song2023-03-281-0/+9
| | | | | | D132262 (cherry picked from commit feb3432a4e9448cee425e610af5b62567a298e2c)
* [test] Improve MC/RISCV/riscv64-64b-pcrel.sFangrui Song2023-03-281-34/+39
| | | | (cherry picked from commit 97f6283c634a5797cc51ba715bbcd4662a4dc00f)
* [X86] AMD Genoa (znver4) Scheduler model updateGanesh Gopalasubramanian2023-03-2474-2/+34544
| | | | (cherry picked from commit ffdd5a330c05fa2b4339f64402f650df068c5767)
* [BOLT] Reject symbols pointing to section endJob Noorman2023-03-242-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | Sometimes, symbols are present that point to the end of a section (i.e., one-past the highest valid address). Currently, BOLT either rejects those symbols when they don't point to another existing section, or errs when they do and the other section is not executable. I suppose BOLT would accept the symbol when it points to an executable section. In any case, these symbols should not be considered while discovering functions and should not result in an error. This patch implements that. Note that this patch checks explicitly for symbols whose value equals the end of their section. It might make more sense to verify that the symbol's value is within [section start, section end). However, I'm not sure if this could every happen *and* its value does not equal the end. Another way to implement this is to verify that the BinarySection we find at the symbol's address actually corresponds to the symbol's section. I'm not sure what the best approach is so feedback is welcome. Reviewed By: yota9, rafauler Differential Revision: https://reviews.llvm.org/D146215 (cherry picked from commit 54ab9541492d808ae4cf9130dd052d602b78ee32)
* No longer issue static lambda pedantic warning for pre-c++2b compatAaron Ballman2023-03-243-3/+4
| | | | | | | | | | | We were accidentally issuing "static lambdas are incompatible with C++ standards before C++2b" with -pedantic because it was an ExtWarn diagnostic rather than a Warning. This corrects the diagnostic category and adds some test coverage. Fixes #61582 (cherry picked from commit b904e68f13ba7d4f4aa86a3495e2441c99247671)
* [BOLT] Fix data reoder for aarch64Vladislav Khmelevsky2023-03-243-1/+10
| | | | | | Use proper relocation for aarch64 Differential Revision: https://reviews.llvm.org/D144095
* [Coroutines] Pass size parameter for deallocation function when qualifiedChuanqi Xu2023-03-242-2/+18
| | | | | | | | | | Close https://github.com/llvm/llvm-project/issues/60545. Previously, we would only pass the size parameter to the deallocation function if the type is completely the same. But it is good enough to make them unqualified the smae. (cherry picked from commit d2b0b26132ce5d3d9022edbf274f01e9de764673)
* [libc++][ranges] Fix incorrect integer typedef in `elements_view` test.Konstantin Varlamov2023-03-241-1/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D142951 (cherry picked from commit 3fe3f9c51cbac91af741e53e96c89f633bd2a6ad)
* [libc++][format] Fix a missing include in tests.Konstantin Varlamov2023-03-241-0/+1
| | | | (cherry picked from commit 78f17b2a98e9c7ce4a28c48955ef312157099a69)
* [libunwind][PowerPC] Fix saving/restoring VSX registers on LE systemsNemanja Ivanovic2023-03-243-0/+119
| | | | | | | | | | | | | | | | Currently, libunwind just uses stxvd2x/lxvd2x to save/restore VSX registers respectively. This puts the registers in doubleword-reversed order into memory on little endian systems. If both the save and restore are done the same way, this isn't a problem. However if the unwinder is just restoring a callee-saved register, it will restore it in the wrong order (since function prologues save them in the correct order). This patch adds the necessary swaps before the saves and after the restores. Differential revision: https://reviews.llvm.org/D137599 (cherry picked from commit 372820bf571c8d32c8165cfc74b0439c7bb397f9)
* JITLink: Add missing EHFrame NULL terminator on aarch64/ELFTom Stellard2023-03-231-0/+1
| | | | | | | | | | | | | This fixes test failures on AArch64 with libgcc-13: Clang :: Interpreter/global-dtor.cpp Clang-Unit :: Interpreter/./ClangReplInterpreterTests/2/4 Reviewed By: lhames, v.g.vassilev Differential Revision: https://reviews.llvm.org/D146067 (cherry picked from commit 68c14f582ce64ae6bd79e78b609fa3469af0ed83)
* Reapply [lld][flang] Add exceptions for Flang runtime libraries on MinGW.Markus Mützel2023-03-231-0/+3
| | | | | | | | | | | | | | | | | | | When linking a shared library with Flang on MinGW, the functions from the Flang runtime are exported from the shared library. When trying to link an executable to that library using Flang, the linker errors out because the functions from the runtime conflict with the functions exported from the shared library. Add the Flang runtime libraries to the list of libraries for which no symbols are exported. Reapplying the patch with the git author name corrected. Reviewed By: mstorsjo Differential Revision: https://reviews.llvm.org/D145389 (cherry picked from commit 0ea8229bf87857e70a38b31b18f6e7c6cd993b9b)
* No longer issue pedantic warning about pre-c++2b compatAaron Ballman2023-03-233-2/+18
| | | | | | | | | We were accidentally issuing "overloaded 'operator[]' with more than one parameter is a C++2b extension" with -pedantic because it was an ExtWarn diagnostic rather than a Warning. This corrects the diagnostic category and adds some test coverage. Fixes #61582
* [libunwind][Modules] Add unwind_arm_ehabi.h and unwind_itanium.h to the ↵Ian Anderson2023-03-232-2/+5
| | | | | | | | | | | | unwind module) Add unwind_arm_ehabi.h and unwind_itanium.h to the unwind module and use angle includes to include them. Reviewed By: ldionne, #libunwind Differential Revision: https://reviews.llvm.org/D144323 (cherry picked from commit 1187d8a62ba288e2221731f1795fa184571cd854)
* [dsymutil] dsymutil produces broken lines info (probably) with LTO on macAlexey Lapshin2023-03-237-207/+398
| | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes #60307 issue. The 8bb4451 introduces the possibility to unite overlapped or adjacent address ranges to keep address ranges in an unambiguous state. The AddressRangesMap is used to normalize address ranges. The AddressRangesMap keeps address ranges and the value of the relocated address. For intersected range, it creates a united range that keeps the last inserted mapping value. The same for adjusted ranges. While it is OK to use the last inserted mapping value for intersected ranges (as there is no way how to resolve ambiguity) It is not OK to use the last inserted value for adjacent address ranges. Currently, two following address ranges are united into a single one: {0,24,17e685c} {24,d8,55afe20} -> {0,d8,55afe20} To avoid the problem, the AddressRangesMap should not unite adjacent address ranges with different relocated addresses. Instead, it should leave adjacent address ranges as separate ranges. So, the ranges should look like this: {0,24,17e685c} {24,d8,55afe20} Differential Revision: https://reviews.llvm.org/D142936 (cherry picked from commit 1e72920c8859771c03177623ad7519543d78eb7d)
* [compiler-rt] Add missing #else clause to fix the build on NetBSD.Frederic Cambus2023-03-231-0/+1
| | | | | | | | | | An #elif SANITIZER_SOLARIS clause was removed in D120048, but it also removed the #else clause for the error fallback, causing the build to fail on NetBSD. Differential Revision: https://reviews.llvm.org/D146316 (cherry picked from commit 8510cf9fc1a431b70737b2b046007d318c62b7a8)
* [X86] Fix encoding for ATOMIC_LOGIC_OPNabeel Omer2023-03-232-4/+4
| | | | | | | | Fixes PR#61384. Differential Revision: https://reviews.llvm.org/D145930 (cherry picked from commit 2ebbcfa07edd9f16bf28cbf1deaaa302503fd330)
* [X86] Add negative test for D145930Nabeel Omer2023-03-231-0/+19
| | | | | | | | This patch adds a negative test for the issue discovered in D145930. Differential Revision: https://reviews.llvm.org/D145933 (cherry picked from commit d8c2a10297f19b708ed0dae8d0fe8415a0f8e5e8)
* [Driver][FreeBSD] Simplify ARM handlingBrad Smith2023-03-236-33/+11
| | | | | | | | | | | | | | | Since FreeBSD 8 / 9 support was dropped from the Driver there is room to simplify things with the ARM handling. The exception model handling function can be removed. EABI is now the default. Reviewed By: dim Differential Revision: https://reviews.llvm.org/D144823 (cherry picked from commit 13a10e7ec90a71c3665491231d468772c19a4b59)
View Lorry Controller Status