Add redhat to vendor list #2
Open
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
Remove the vector base class as suggested by @ldionne Reviewed By: ldionne, Quuxplusone, #libc Spies: libcxx-commits, ldionne Differential Revision: https://reviews.llvm.org/D117108 (cherry picked from commit b82da8b)
We are removing support for the Standalone build altogether on the main branch, so this is going to help give an additional heads up to users that don't read our release notes. Also, as a fly-by fix, fixup incorrect documentation for libcxxabi and mention libunwind in our release notes. Differential Revision: https://reviews.llvm.org/D119341
The warning was introduced with the recently merged SPARCv9 support in 2b9554b. The cast matches the existing surrounding cases. Differential Revision: https://reviews.llvm.org/D119353 (cherry picked from commit dfa5ab7)
I think this was just being ignored before, but now it crashes because we're checking if the projects that we're trying to enable are valid. There is no test-suite project (it's a separate repo with separate handling), so we should never try to enable it. Differential Revision: https://reviews.llvm.org/D119322
Neither LLDB nor GDB seem to work with DWARF 5 debug information on Windows right now. This applies the same change as in 9c62728 (Default to DWARFv4 on Windows) to the MinGW driver too. Differential Revision: https://reviews.llvm.org/D119326 (cherry picked from commit 6cf64b2)
…ECTS We are moving away from building the runtimes with LLVM_ENABLE_PROJECTS, however the documentation was largely outdated. This commit updates all the documentation I could find to use LLVM_ENABLE_RUNTIMES instead of LLVM_ENABLE_PROJECTS for building runtimes. Note that in the near future, libcxx, libcxxabi and libunwind will stop supporting being built with LLVM_ENABLE_PROJECTS altogether. I don't know what the plans are for other runtimes like libc, openmp and compiler-rt, so I didn't make any changes to the documentation that would imply something for those projects. Once this lands, I will also cherry-pick this on the release/14.x branch to make sure that LLVM's documentation is up-to-date and reflects what we intend to support in the future. Differential Revision: https://reviews.llvm.org/D119351 (cherry picked from commit 4ae83bb)
…code This brings the mingw build back to zero build warnings as it was at some earlier time. Differential Revision: https://reviews.llvm.org/D119134 (cherry picked from commit 8cffea0)
This reverts commit 83620bd. It's causing miscompilations, see review comments at https://reviews.llvm.org/D115955 (cherry picked from commit 0c3d22a)
Fix passing the port and IP address with the wrong endianness in get_sock_peer_name() that causes the connect() to fail inside without an outgoing network interface (it's trying to connect to 1.0.0.127 instead of 127.0.0.1). Differential Revision: https://reviews.llvm.org/D119461 (cherry picked from commit c65fb0c)
D116208 may cause a macro clash on older versions of linux, where fs.h defines a READ macro. This is resolved by switching to a more typical casing style for non-macro symbols. Reapplying with changes to the symbol names in various platform specific code, which I missed previously. Differential Revision: https://reviews.llvm.org/D118783 (cherry picked from commit 36cae42)
clang-cl MSVC required version is 19.20 now. Update the default -fms-compatibility-version to 19.20. Differential Revision: https://reviews.llvm.org/D114639
VS2019 version 1920 in now the default and get tested in llvm/include/llvm/Support/Compiler.h. This patch propagates LLVM_FORCE_USE_OLD_TOOLCHAIN macro to disable testing for VS2019. Differential Revision: https://reviews.llvm.org/D114639
(cherry picked from commit 6a7f6e9)
…_threading_support This reverts commit 2722ac6. As explained in D115906, this was actually unnecessary and it broke the external threading configuration. Differential Revision: https://reviews.llvm.org/D119484 (cherry picked from commit c74b192)
This fixes Linux musl build after D118423. (cherry picked from commit da2a16f)
For the release/14.x branch. Differential Revision: https://reviews.llvm.org/D119318
When we privatize a pointer (~argument promotion) we introduce new private allocas as replacement. These need to be placed in the alloca address space as later passes cannot properly deal with them otherwise. Fixes llvm#53725 (cherry picked from commit e39b419)
This ensures that the Windows unwinder will work at every instruction boundary, and allows other targets to read and write flags without setting up a frame pointer. Fixes llvmGH-46875 Differential Revision: https://reviews.llvm.org/D119391 (cherry picked from commit f3481f4)
…ring release testing. This patch adds an option (no-clang-tools) to disable building clang-tools-extra when performing release testing. Prior to this patch, clang-tools-extra was built by default, but on some platforms (such as AIX), clang-tools-extra is not supported, and so we do not normally build it. Furthermore, this change should not change the invocation for targets that build clang-tools-extra normally. Differential Revision: https://reviews.llvm.org/D119520 (cherry picked from commit db69190)
…ok; NFC This is no-functional-change-intended because only the x86 target enables the TLI hook currently. We can add fmul/fdiv opcodes to the switch similar to the proposal D119111, but we don't need to make other changes like enabling target-specific combines. We can also add integer opcodes (add, or, shl, etc.) to the switch because this function is called from all of the generic binary opcodes. The goal is to incrementally enable the profitable diffs from D90113 while avoiding regressions. Differential Revision: https://reviews.llvm.org/D119150 (cherry picked from commit a68e098)
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 76cad51)
Fixes llvm#53643. Reviewed By: MyDeveloperDay, HazardyKnusperkeks, owenpan Differential Revision: https://reviews.llvm.org/D119218 (cherry picked from commit e329b58)
But only test in combination with -finclude-default-header, as the headerless tests may be dropped soon. (cherry picked from commit e0e6f3a)
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 d97a4df)
This is in preparation for adding the OpenCL 3.0 builtins with named address space arguments. (cherry picked from commit 31fa3a4)
…n-to-Arm cross toolchain cache file. NFC. Avoid using TARGET_TRIPLE argument for the cross toolchain cmake cache file and replace it with TOOLCHAIN_TARGET_TRIPLE. Reference: https://reviews.llvm.org/D119918 Differential Revision: https://reviews.llvm.org/D121029 (cherry picked from commit d860ac5)
…rs. NFC. * fixed remote test script arguments for libc++/compiler-rt libraries. * disabled shared libc++abi libraries (to let remote tests get passed). (cherry picked from commit 41f74bc)
The Linux kernel build uses absolute expressions suffixed with @lo/@ha relocations. This currently doesn't work for DS/DQ form instructions and there is no reason for it not to. It also works with GAS. This patch allows this as long as the value is a multiple of 4/16 for DS/DQ form. Differential revision: https://reviews.llvm.org/D115419 (cherry picked from commit 2aaba44)
dd91734 (Add clear_cache implementation for ppc64. Fix buffer to meet ppc64 alignment., 2017-07-28), adds an implementation for __builtin___clear_cache on powerpc64, which was promptly ammended to also be used with big endian mode in f67036b (This ppc64 implementation of clear_cache works for both big and little endian., 2017-08-02) clang will use this implementation for it's builtin on FreeBSD and result in an abort() in the cases where 32-bit generation was requested (ex in macppc or when the big endian powerpc64 build was done with "-m32") and as reported[1] recently with pcre2, but there is no reason why the same code couldn't be used in those cases, so use instead the more generic identifier for the PowerPC architecture. While at it, update the comment to reflect that POWER8/9 have a 128 byte wide cache line and so the code could instead use 64 byte windows instead but that possible optimization has been punted for now. [1] PCRE2Project/pcre2#92 Reviewed By: jhibbits, #powerpc, MaskRay Differential Revision: https://reviews.llvm.org/D122640 (cherry picked from commit 81f5c62)
Otherwise, with recent versions of libstdc++, clang can't tell that the atomic operations are properly aligned, and generates calls to libatomic. (Actually, because of the use of reinterpret_cast, it wasn't guaranteed to be aligned, but I think it ended up being aligned in practice.) Fixes llvm#54790 , the part where LLVM failed to build. Differential Revision: https://reviews.llvm.org/D123872 (cherry picked from commit 13fc178)
Variable locations now come in two modes, instruction referencing and DBG_VALUE. At -O0 we pick DBG_VALUE to allow fast construction of variable information. Unfortunately, SelectionDAG edits the optimisation level in the presence of opt-bisect-limit, meaning different passes have different views of what variable location mode we should use. That causes assertions when they're mixed. This patch plumbs through a boolean in SelectionDAG from start to instruction emission, so that we don't rely on the current optimisation level for correctness. Differential Revision: https://reviews.llvm.org/D123033 (cherry picked from commit fb6596f)
Cherry-picked from c3b9819 which was originally reviewed as https://reviews.llvm.org/D121707. This reverts commit edb7ba7. This changes BLR_BTI to take variable_ops meaning that we can accept a register or a label. The pattern still expects one argument so we'll never get more than one. Then later we can check the type of the operand to choose BL or BLR to emit. (this is what BLR_RVMARKER does but I missed this detail of it first time around) Also require NoSLSBLRMitigation which I missed in the first version.
When an inline builtin declaration is shadowed by an actual declaration, we must reference the actual declaration, even if it's not the last, following GCC behavior. This fixes llvm#54715 Differential Revision: https://reviews.llvm.org/D123308 (cherry picked from commit 301e0d9)
The issue affects targets supporting fast-lzcnt such as btver2. This removes extraneous zext/trunc node insertions to fix the infinite loop. This fixes Issue llvm#54694 Differential Revision: https://reviews.llvm.org/D122900 Reviewed By: RKSimon, spatel, lebedev.ri (cherry picked from commit a3d5f1c) Signed-off-by: Warren Ristow <[email protected]> In https://reviews.llvm.org/D122900 a new function (to exercise the infinite-loop bug) was added to llvm/test/CodeGen/X86/lzcnt-zext-cmp.ll. In applying the fix in the main branch, two previously existing functions in that test also changed behavior slightly, and in the review it was noted: The instructions generated end up being reordered in some cases but I think it is equivalent. That reordering did not happen in those pre-existing functions when applying the fix to the slightly older code-base of the llvm14 branch, and so they are suppressed here. So the updated version of the test in this commit has the additional function added to it, but it is otherwise identical to the previous llvm14 version of the test.
This is part of solving issue llvm#54750 - in that example we have both forms of the compare and do not recognize the equivalence. (cherry picked from commit 2c2568f)
Reduced test for llvm#54427.
In the integer case, step will be negative and InductionOpCode will be Sub for inductions counting down. By using the InductionOpCode for integers, we would incorrectly subtract a negative value, when it should be added instead. This fixes llvm#54427 on the 14.x branch.
Reviewed By: Mordante Differential Revision: https://reviews.llvm.org/D122861 (cherry picked from commit a0d40a5)
…tion is synthetic
addSectionSymbols suppresses the STT_SECTION symbol if the first input section
is non-SHF_MERGE synthetic. This is incorrect when the first input section is synthetic
while a non-synthetic input section exists:
* `.bss : { *(COMMON) *(.bss) }`
(abc388e regressed the case because
COMMON symbols precede .bss in the absence of a linker script)
* Place a synthetic section in another section: `.data : { *(.got) *(.data) }`
For `%t/a1` in the new test emit-relocs-synthetic.s, ld.lld produces incorrect
relocations with symbol index 0.
```
0000000000000000 <_start>:
0: 8b 05 33 00 00 00 movl 51(%rip), %eax # 0x39 <bss>
0000000000000002: R_X86_64_PC32 *ABS*+0xd
6: 8b 05 1c 00 00 00 movl 28(%rip), %eax # 0x28 <common>
0000000000000008: R_X86_64_PC32 common-0x4
c: 8b 05 06 00 00 00 movl 6(%rip), %eax # 0x18
000000000000000e: R_X86_64_GOTPCRELX *ABS*+0x4
```
Fix the issue by checking every input section.
Reviewed By: ikudrin
Differential Revision: https://reviews.llvm.org/D122463
(cherry picked from commit 7370a48)
…SH*ADD failed. There's an assert in LUI+SH*ADD+ADDI materialization that makes sure the lower 12 bits aren't zero since that case should have been handled as LUI+ADDI+SH*ADD. But nothing prevented the LUI+SH*ADD+ADDI checks from running after the earlier code handled it. The sequence would be the same length or longer so it wouldn't replace the earlier sequence, but the assert happened before that was checked. The vector holding the sequence also wasn't reset before the second check so that guaranteed the sequence would never be found to be shorter. This patch fixes this by only trying the second expansion when the earlier fails. Fixes PR54812. Reviewed By: benshi001 Differential Revision: https://reviews.llvm.org/D123406 (cherry picked from commit 7004643)
`/notify_update` is an undocumented feature used by CMake. From their usage, it looks like this feature just changes `mt`'s exit code if the output file was changed. See https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmcmd.cxx#L2300 this is also consistent with some testing I have done of the mt.exeshipped with Visual Studio. See also the comment at https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmcmd.cxx#L2440. There might be a more performant way to implement this by first checking calling `llvm::sys::fs::file_size()` and if it is the same as the new output's size use `llvm::WritableMemoryBuffer` and fallback to `llvm::FileOutputBuffer` otherwise, but these don't inherit from a common ancestor so any implementation doing this would be really ugly. Fixes llvm#54329 Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D121438 (cherry picked from commit e970d28)
These tests both use vector constants misidentified as VID sequences. Because the initial run of elements has a zero step, the elements are skipped until such a step can be identified. The bug is that the skipped elements are never validated, even though the computed step is incompatible across the entire sequence. A fix will follow in a subseqeuent patch. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D123785 (cherry picked from commit 0053794)
This patch fixes a bug when lowering BUILD_VECTOR via VID sequences. After adding support for fractional steps in D106533, elements with zero steps may be skipped if no step has yet been computed. This allowed certain sequences to slip through the cracks, being identified as VID sequences when in fact they are not. The fix for this is to perform a second loop over the BUILD_VECTOR to validate the entire sequence once the step has been computed. This isn't the most efficient, but on balance the code is more readable and maintainable than doing back-validation during the first loop. Fixes the tests introduced in D123785. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D123786 (cherry picked from commit c5cac48)
This test shows a (contrived) BUILD_VECTOR which is correctly identified as a sequence of ((vid * -3) / 8) + 5. However, the issue is that using shift-right for the divide is invalid as the step values are negative. This patch just adds the test: the fix is added in D123796. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D123989 (cherry picked from commit 627e210)
We can't shift-right negative numbers to divide them, so avoid emitting such sequences. Use negative numerators as a proxy for this situation, since the indices are always non-negative. An alternative strategy could be to add a compiler flag to emit division instructions, which would at least allow us to test the VID sequence matching itself. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D123796 (cherry picked from commit 3e678cb)
All platforms return the main executable as the first dl_phdr_info. FreeBSD, NetBSD, Solaris, and Linux-musl place the executable name in the dlpi_name field of this entry. It appears that only Linux-glibc uses the empty string. To make this work generically on all platforms, unconditionally skip the first object (like is currently done for FreeBSD and NetBSD). This fixes first DSO detection on Linux-musl. It also would likely fix detection on Solaris/Illumos if it were to gain PIE support (since dlpi_addr would not be NULL). Additionally, only skip the Linux VDSO on linux. Finally, use the empty string as the "seen first dl_phdr_info" marker rather than (char *)-1. If there was no other object, we would try to dereference it for a string comparison. Reviewed By: MaskRay, vitalybuka Differential Revision: https://reviews.llvm.org/D119515 (cherry picked from commit 795b07f)
The existing code wasn't getting the subtarget info from the fragment, so the current status of RVC would be ignored. This would cause a crash for the new test case when the target then reported it couldn't write the requested number of code alignment bytes. Differential Revision: https://reviews.llvm.org/D122236 (cherry picked from commit d09d297)
poechsel
pushed a commit
that referenced
this pull request
Apr 22, 2025
```
UBSan-Standalone-sparc :: TestCases/Misc/Linux/diag-stacktrace.cpp
```
`FAIL`s on 32 and 64-bit Linux/sparc64 (and on Solaris/sparcv9, too: the
test isn't Linux-specific at all). With
`UBSAN_OPTIONS=fast_unwind_on_fatal=1`, the stack trace shows a
duplicate innermost frame:
```
compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:31: runtime error: execution reached the end of a value-returning function without returning a value
#0 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35
#1 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35
#2 0x7003a714 in g() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:17:38
```
which isn't seen with `fast_unwind_on_fatal=0`.
This turns out to be another fallout from fixing
`__builtin_return_address`/`__builtin_extract_return_addr` on SPARC. In
`sanitizer_stacktrace_sparc.cpp` (`BufferedStackTrace::UnwindFast`) the
`pc` arg is the return address, while `pc1` from the stack frame
(`fr_savpc`) is the address of the `call` insn, leading to a double
entry for the innermost frame in `trace_buffer[]`.
This patch fixes this by moving the adjustment before all uses.
Tested on `sparc64-unknown-linux-gnu` and `sparcv9-sun-solaris2.11`
(with the `ubsan/TestCases/Misc/Linux` tests enabled).
(cherry picked from commit 3368a32)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.