Release 19.x backport #111444
Closed
Release 19.x backport #111444
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
…in LIT tests (llvm#101196) This patch fixes/unifies AIX target triples used in libc++, libc++abi, and libunwind LIT tests. (cherry picked from commit 2d36550)
... using the temporary section type code 0x40000020 (`clang -c -Wa,--crel,--allow-experimental-crel`). LLVM will change the code and break compatibility (Clang and lld of different versions are not guaranteed to cooperate, unlike other features). CREL with implicit addends are not supported. --- Introduce `RelsOrRelas::crels` to iterate over SHT_CREL sections and update users to check `crels`. (The decoding performance is critical and error checking is difficult. Follow `skipLeb` and `R_*LEB128` handling, do not use `llvm::decodeULEB128`, whichs compiles to a lot of code.) A few users (e.g. .eh_frame, LLDDwarfObj, s390x) require random access. Pass `/*supportsCrel=*/false` to `relsOrRelas` to allocate a buffer and convert CREL to RELA (`relas` instead of `crels` will be used). Since allocating a buffer increases, the conversion is only performed when absolutely necessary. --- Non-alloc SHT_CREL sections may be created in -r and --emit-relocs links. SHT_CREL and SHT_RELA components need reencoding since r_offset/r_symidx/r_type/r_addend may change. (r_type may change because relocations referencing a symbol in a discarded section are converted to `R_*_NONE`). * SHT_CREL components: decode with `RelsOrRelas` and re-encode (`OutputSection::finalizeNonAllocCrel`) * SHT_RELA components: convert to CREL (`relToCrel`). An output section can only have one relocation section. * SHT_REL components: print an error for now. SHT_REL to SHT_CREL conversion for -r/--emit-relocs is complex and unsupported yet. Link: https://discourse.llvm.org/t/rfc-crel-a-compact-relocation-format-for-elf/77600 Pull Request: llvm#98115 (cherry picked from commit 0af07c0)
llvm#99888 added a check (and corresponding options) to flag uses of `#pragma mc_func` on AIX. This PR turns on the check by default. (cherry picked from commit b933517)
…ng EEW (llvm#101152) As noted in https://github.com/llvm/llvm-project/pull/100367/files#r1695448771, we currently fold in vmerge.vvms and vmv.v.vs into their ops even if the EEW is different which leads to an incorrect transform. This checks the op's EEW via its simple value type for now since there doesn't seem to be any existing information about the EEW size of instructions. We'll probably need to encode this at some point if we want to be able to access it at the MachineInstr level in llvm#100367
Before commit 705788c the checker alpha.unix.BlockInCriticalSection "recognized" the methods `std::mutex::lock` and `std::mutex::unlock` with an extremely trivial check that accepted any function (or method) named lock/unlock. To avoid matching unrelated user-defined function, this was refined to a check that also requires the presence of "std" and "mutex" as distinct parts of the qualified name. However, as llvm#99628 reported, there are standard library implementations where some methods of `std::mutex` are inherited from an implementation detail base class and the new code wasn't able to recognize these methods, which led to emitting false positive reports. As a workaround, this commit partially restores the old behavior by omitting the check for the class name. In the future, it would be good to replace this hack with a solution which ensures that `CallDescription` understands inherited methods. (cherry picked from commit 99ae2ed)
Following up on the RFC discussion, this is clarifying that the main purpose and effect of the -Ofast deprecation is to discourage its usage and that everything else is more or less open for discussion, e.g. there is no timeline yet for removal. --------- Co-authored-by: Aaron Ballman <[email protected]> (cherry picked from commit 48d4d4b)
This enables "-rc" suffix in release branches. (cherry picked from commit 25efb74)
) This patch refactors the handling of reduction to eliminate layering violations. * Introduced `getReductionIntrinsicID` in LoopUtils.h for mapping recurrence kinds to llvm.vector.reduce.* intrinsic IDs. * Updated `VectorBuilder::createSimpleTargetReduction` to accept llvm.vector.reduce.* intrinsic directly. * New function `VPIntrinsic::getForIntrinsic` for mapping intrinsic ID to the same functional VP intrinsic ID. (cherry picked from commit 6d12b3f)
Since llvm#99276 has been landed, the dependency has become redundant. This reverts commit aa94a43. (llvmorg-19-init-17718-gaa94a43178e1) (cherry picked from commit 5bf0859)
```
SanitizerCommon-ubsan-sparc-Linux :: Linux/signal_line.cpp
```
currently `FAIL`s on Linux/sparc64 (32 and 64-bit) for `n == 2`. Instead
of the expected `SIGSEGV`, the test dies with `SIGBUS`. `strace` reveals
that this is due to a unaligned access:
```
--- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRALN, si_addr=0x1} ---
```
which is to be expected on a strict-alignment target like SPARC. Fixed
by changing the invalid pointer to be better aligned.
Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
(cherry picked from commit 94394ca)
llvm#101011) …parc64 ``` SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerCommon/InternalMmapWithOffset ``` `FAIL`s on 32-bit Linux/sparc64: ``` projects/compiler-rt/lib/sanitizer_common/tests/./Sanitizer-sparc-Test --gtest_filter=SanitizerCommon.InternalMmapWithOffset -- compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cpp:335: Failure Expected equality of these values: 'A' Which is: 'A' (65, 0x41) p[0] Which is: '\0' ``` It turns out the `pgoffset` arg to `mmap2` is passed incorrectly in this case, unlike the 64-bit test. The caller, `MapWritableFileToMemory`, passes an `u64` arg, while `mmap2` expects an `off_t`. This patch casts the arg accordingly. Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`. (cherry picked from commit 1c25f2c)
…g SME attrs" (llvm#100991) (llvm#100996) Test `aarch64-sme-inline-streaming-attrs.c` caused some buildbot failures, because the test was missing a `REQUIRES: aarch64-registered target`. This was because we've demoted the error to a warning, which then resulted in a different error message, because Clang can't actually CodeGen the IR. (cherry picked from commit 389679d)
…lvm#92103) Also changes the behaviour of `__builtin_is_layout_compatible` None of the historic nor the current definition of layout-compatible classes mention anything about base classes (other than implicitly through being standard-layout) and are defined in terms of members, not direct members.
…gisters. (llvm#94628) On PowerPC there are 128 bit VSX registers. These registers are half overlapped with 64 bit floating point registers (FPR). The 64 bit half of the VXS register that does not overlap with the FPR does not overlap with any other register class. The FPR are the only subregisters of the VSX registers but they do not fully cover the 128 bit super register. This leads to incorrect lane masks being created. This patch adds phony registers for the other half of the VSX registers in order to fully cover them and to make sure that the lane masks are not the same for the VSX and the floating point register. (cherry picked from commit 53c37f3)
…script (llvm#101647) Current CSA logic does not expect `LazyCompoundValKind` as array index. This may happen if array is used as subscript to another, in case of bitcast to integer type. Catch such cases and return `UnknownVal`, since CSA cannot model array -> int casts. Closes llvm#94496 (cherry picked from commit d96569e)
In terms of bug catching capability, `_FORTIFY_SOURCE` does not perform as well as some dynamic instrumentation tools. When a sanitizer is used, generally `_FORTIFY_SOURCE` should be disabled since sanitizer runtime does not implement most `*_chk` functions. Using `_FORTIFY_SOURCE` will regress error checking (asan/hwasan/tsan) or cause false positives (msan). `*printf_chk` are the most pronounced `_chk` interceptors for uninstrumented DSOes (https://reviews.llvm.org/D40951). glibc 2.40 introduced `pass_object_info` style fortified source for some functions ([1]). `fprintf` will be mangled as `_ZL7fprintfP8_IO_FILEU17pass_object_size1PKcz`, which has no associated interceptor, leading to printf-fortify-5.c failure. Just disable the test. Fix llvm#100877 [1]: https://sourceware.org/pipermail/libc-alpha/2024-February/154531.html Pull Request: llvm#101566 (cherry picked from commit bbdccf4)
(cherry picked from commit 8f39502)
…1820) llvm#98489 resurrected an [old patch](https://reviews.llvm.org/D10833) that was adding new libclang functions. That PR got merged with old `LLVM_13` symbol versions for new functions. This patch fixes this oversight. (cherry picked from commit 2bae7ae)
```
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
llvm#1 0x7003a708 in f() compiler-rt/test/ubsan/TestCases/Misc/Linux/diag-stacktrace.cpp:14:35
llvm#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)
Crash seems to be caused by the check function not handling inline namespaces correctly for some instances. Changed how the Replacer is got from the MatchResult now which should alleviate any potential issues Fixes llvm#100406 (cherry picked from commit 0762db6)
This adds release binary builds for the 4 platforms currently supported by the free GitHub Action runners: * Linux x86_64 * Windows x86_64 * Mac x86_64 * Mac AArch64 The test stages for these are known to fail, but the creating and upoading of the release binaries should pass. (cherry picked from commit 247251a)
(cherry picked from commit 18dee70)
…ranch (llvm#100805) If we pull from the release tag, then if there is a bug in one of the actions on the release tag, then we can never do a build for that tag. Pulling from main will allows us to fix bugs in the actions we use to build the releases. (cherry picked from commit b0860b2)
…t workspace (llvm#100845) Otherwise, the checkout step will override them. (cherry picked from commit 41003ff)
…acos-14 (llvm#101774) python3 wasn't able to see modules installed by pip, so we need to use the setup-python action to ensure that the default pip and python3 both use the same prefix. See actions/runner-images#10385 (cherry picked from commit 59476c9)
…tion (llvm#101569) The old version in the llvm/actions repo stopped working after the version variables were moved out of llvm/CMakeLists.txt. Composite actions are more simple and don't require javascript, which is why I reimplemented it as a composite action. This will fix the failing abi checks on the release branch. (cherry picked from commit 14837af)
Fixes llvm#101859. If we have at least 2 ranges, we have to try to merge the last and first ones to handle the wrap range. (cherry picked from commit 4377656)
In ExpandFPLibCall, an assumption is made that all floating point libcalls that take integer arguments use unsigned integers. In the case of ldexp and frexp, this assumption is incorrect, leading to miscompilation and subsequent target-dependent incorrect operation. Indicate that ldexp and frexp utilize signed arguments in ExpandFPLibCall. Fixes llvm#108904 Signed-off-by: Timothy Pearson <[email protected]> (cherry picked from commit 90c1474)
…rbose_trap support (llvm#110161) We should have been checking against 1700, not 17000, which was a typo. (cherry picked from commit 1eba879)
Large scratch offset with one on highest bit selected as negative, negative offset has same binary representation in 16 bits as large unsigned offset. (cherry picked from commit e9d12a6)
…lvm#110256) Use i32 for offset instead of i16, this way it does not get interpreted as negative 16 bit offset. (cherry picked from commit 83fe851)
Until llvm#103056 lands or another more appropriate check can be found. This test fails on Ubuntu Focal where zdump is built with 32 bit time_t but passes on Ubuntu Jammy where zdump is built with 64 bit time_t. Marking it unsupported means Linaro can upgrade its bots to Ubuntu Jammy without getting an unexpected pass. (cherry picked from commit 6f6422f)
This fixes the test on Arm 32 bit Ubuntu Jammy where time_t is 32 bit. (cherry picked from commit cdd608b)
…lvm#90967) Multiple invocations of the pass could interfere with eachother, preventing some undefs being initialised. I found it very difficult to create a unit test for this due to it being dependent on particular allocations of a previous function. However, the bug can be observed here: https://godbolt.org/z/7xnMo41Gv with the creation of the illegal instruction `vnsrl.wi v9, v8, 0`
…ssing NoCD8 (llvm#109579) Promoted KMOV* was encoded with CD8 incorrectly, see https://godbolt.org/z/cax513hG1 (cherry picked from commit 0d334d8)
This was mistakely changed by llvm#109579, which doesn't match with other EVEX decoding. (cherry picked from commit 70529b2)
Fix counted_by attribute for cases where the flexible array member is
accessed through struct pointer inside another struct:
```
struct variable {
int a;
int b;
int length;
short array[] __attribute__((counted_by(length)));
};
struct bucket {
int a;
struct variable *growable;
int b;
};
```
__builtin_dynamic_object_size(p->growable->array, 0);
This commit makes sure that if the StructBase is both a MemberExpr and a
pointer, it is treated as a pointer. Otherwise clang will generate to
code to access the address of p->growable intead of loading the value of
p->growable->length.
Fixes llvm#110385
bwendling
requested review from
a team,
Endilll,
JDevlieghere,
aaupov,
ayermolo,
dcci,
keith,
maksfb,
nikic,
rafaelauler and
rupprecht
as code owners
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
124 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
/cherry-pick