LLVM 19.1.2 bump #129
Merged
LLVM 19.1.2 bump #129
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
Fixes #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)
…(#101877) (cherry picked from commit 3c483b8)
…1828) For functions with private linkage, pick IMAGE_SYM_CLASS_STATIC rather than IMAGE_SYM_CLASS_EXTERNAL; GlobalValue::isInternalLinkage() only checks for InternalLinkage, while GlobalValue::isLocalLinkage() checks for both InternalLinkage and PrivateLinkage. This matches what the AArch64 target does, since commit 3406934. This activates a preexisting fix for the AArch64 target from 1e7f592, for the ARM target as well. When a relocation points at a symbol, one usually can convey an offset to the symbol by encoding it as an immediate in the instruction. However, for the ARM and AArch64 branch instructions, the immediate stored in the instruction is ignored by MS link.exe (and lld-link matches this aspect). (It would be simple to extend lld-link to support it - but such object files would be incompatible with MS link.exe.) This was worked around by 1e7f592 by emitting symbols into the object file symbol table, for temporary symbols that otherwise would have been omitted, if they have the class IMAGE_SYM_CLASS_STATIC, in order to avoid needing an offset in the relocated instruction. This change gives the symbols generated from functions with the IR level "private" linkage the right class, to activate that workaround. This fixes llvm/llvm-project#100101, fixing code generation for coroutines for Windows on ARM. After the change in f786881, coroutines generate a function with private linkage, and calls to this function were previously broken for this target. (cherry picked from commit 8dd065d)
… system. (#101392) Fixes build errors on some SDKs. rdar://132607572 (cherry picked from commit 3a4c7cc)
…… (#100532)
…sparc64
Two ioctl tests `FAIL` on Linux/sparc64 (both 32 and 64-bit):
```
SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerIoctl/KVM_GET_LAPIC
SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerIoctl/KVM_GET_MP_STATE
```
like
```
compiler-rt/lib/sanitizer_common/tests/./Sanitizer-sparc-Test --gtest_filter=SanitizerIoctl.KVM_GET_LAPIC
--
compiler-rt/lib/sanitizer_common/tests/sanitizer_ioctl_test.cpp:91: Failure
Value of: res
Actual: false
Expected: true
compiler-rt/lib/sanitizer_common/tests/sanitizer_ioctl_test.cpp:92: Failure
Expected equality of these values:
ioctl_desc::WRITE
Which is: 2
desc.type
Which is: 1
```
The problem is that Linux/sparc64, like Linux/mips, uses a different
layout for the `ioctl` `request` arg than most other Linux targets as
can be seen in `sanitizer_platform_limits_posix.h` (`IOC_*`). Therefore,
this patch makes the tests use the correct one.
Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
(cherry picked from commit 9eefe06)
…0534) ``` SanitizerCommon-Unit :: ./Sanitizer-sparc-Test/SanitizerCommon/StartSubprocessTest ``` and every single test using the `llvm-symbolizer` `FAIL` on Linux/sparc64 in a very weird way: when using `StartSubprocess`, there's a call to `internal_fork`, but we never reach `internal_execve`. `internal_fork` is implemented using `syscall(SYS_clone)`. The calling convention of that syscall already varies considerably between targets, but as documented in `clone(2)`, SPARC again is widely different. Instead of trying to match `glibc` here, this patch just calls `__fork`. Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`. (cherry picked from commit 1c53b90)
``` SanitizerCommon-ubsan-sparc-Linux :: Linux/signal_send.cpp ``` currently `FAIL`s on Linux/sparc64 (32 and 64-bit). Instead of the expected values for `SIGUSR1` (`10`) and `SIGUSR1` (`12`), that target uses `30` and `31`. On Linux/x86_64, the signals get their values from `x86_64-linux-gnu/bits/signum-generic.h`, to be overridden in `x86_64-linux-gnu/bits/signum.h`. On Linux/sparc64 OTOH, the definitions are from `sparc64-linux-gnu/bits/signum-arch.h` and remain that way. There's no `signum.h` at all. The patch allows for both values. Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`. (cherry picked from commit 7cecbdf)
```
SanitizerCommon-Unit :: ./Sanitizer-sparcv9-Test/SanitizerCommon/FileOps
```
`FAIL`s on 64-bit Linux/sparc64:
```
projects/compiler-rt/lib/sanitizer_common/tests/./Sanitizer-sparcv9-Test --gtest_filter=SanitizerCommon.FileOps
--
compiler-rt/lib/sanitizer_common/tests/sanitizer_libc_test.cpp:144: Failure
Expected equality of these values:
len1 + len2
Which is: 10
fsize
Which is: 1721875535
```
The issue is similar to the mips64 case: the Linux/sparc64 `*stat`
syscalls take a `struct kernel_stat64 *` arg. Also the syscalls actually
used differ.
This patch handles this, adopting the mips64 code to avoid too much
duplication.
Tested on `sparc64-unknown-linux-gnu` and `x86_64-pc-linux-gnu`.
(cherry picked from commit fcd6bd5)
SmallVector uses `uint32_t`, `uint64_t` without including `<cstdint>` which fails to build w/ GCC 15 after a change in libstdc++ [0] [0] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3a817a4a5a6d94da9127af3be9f84a74e3076ee2 (cherry picked from commit 7e44305)
Investigating #96612 shows our implementation was different from the Standard and could cause UB. Testing the codegen showed quite a bit of assembly generated for these functions. The functions have been written differently which allows Clang to optimize the code to use simple CPU rotate instructions. Fixes: llvm/llvm-project#96612
Inlining may result in different behaviour when the callee clobbers ZT0, because normally the call-site will have code to preserve ZT0. When inlining the function this code to preserve ZT0 will no longer be emitted, and so the resulting behaviour of the program is changed. (cherry picked from commit fb470db)
…(#101677) The NEON dot product is not valid in streaming mode. A follow-up patch will improve codegen for these operations. (cherry picked from commit 12937b1)
…(#101522) The implementation of __arm_sc_memset in compiler-rt contains a Neon dup instruction which is not valid in streaming mode. This patch rewrites the function, using an SVE mov instruction if available. (cherry picked from commit d6649f2)
…tions. (#101679) The command line option enable-scalable-autovec-in-streaming-mode is used to enable scalable vectors but the same check is missing from enableScalableVectorization, which is blocking auto-vectorisation. (cherry picked from commit 7775a48)
The discussion about this in Flang (https://discourse.llvm.org/t/rfc-deprecate-ofast-in-flang/80243) has not concluded hence restricting the deprecation only to Clang. (cherry picked from commit e60ee1f)
…ion checking (#101879) If a fold expanded constraint would expand packs of different size, it is not a valid pack expansion and it is not satisfied. This should not produce an error. Fixes #99430 (cherry picked from commit da380b2)
As the comment explains, `*Triples[]` lists are discouraged and not
comprehensive anyway (e.g.
aarch64-unknown-linux-gnu/aarch64-unknown-linux-musl/aarch64-amazon-linux
do not work).
Boost incorrectly specifies --target=arm64-pc-linux ("arm64" should not
be used for Linux) and expects to probe "aarch64-linux-gnu". Add this
temporary workaround for the 19.x releases.
… (#102023) Now that the release binaries create artifact attestations, we need to ensure that we call the workflow with the correct permissions. (cherry picked from commit dc349a3)
…(#102041) We need a different attestation for each supported architecture, so there artifacts all need to have a different name. The upload step is run on a Linux runner, so no matter which architecture's binary is being uploaded the runner.os and runner.arch variables would always be 'Linux' and 'X64' and so we can't use them for naming the artifact. (cherry picked from commit 3c8dadd)
As discussed in Issue #86793, the `MachOTest.UnalignedLC` test dies with `SIGBUS` on SPARC, a strict-alignment target. It simply cannot work there. Besides, the test invokes undefined behaviour on big-endian targets, so this patch disables it on all of those. Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`. (cherry picked from commit 3a226db)
(cherry picked from commit bb59f04)
…577) Update getDependenceDistanceStrideAndSize to reason about different combinations of strides directly and explicitly. Update getPtrStride to return 0 for invariant pointers. Then proceed by checking the strides. If either source or sink are not strided by a constant (i.e. not a non-wrapping AddRec) or invariant, the accesses may overlap with earlier or later iterations and we cannot generate runtime checks to disambiguate them. Otherwise they are either loop invariant or strided. In that case, we can generate a runtime check to disambiguate them. If both are strided by constants, we proceed as previously. This is an alternative to llvm/llvm-project#99239 and also replaces additional checks if the underlying object is loop-invariant. Fixes llvm/llvm-project#87189. PR: llvm/llvm-project#99577
Fixes #99396 The result of `VirtRegAuxInfo::weightCalcHelper` can be influenced by x87 excess precision, which can result in slightly different register choices when the compiler is hosted on x86_64 or i386. This leads to different object file output when cross-compiling to i386, or native. Similar to 7af3432, we need to add a `volatile` qualifier to the local `Weight` variable to force it onto the stack, and avoid the excess precision. Define `stack_float_t` in `MathExtras.h` for this purpose, and use it. (cherry picked from commit c80c09f)
Allow BOLT to map the old address to a new binary address if the old address is the entry of the function. (cherry picked from commit 734c048)
Previously, we selected the Thumb2 PLT sequences if any input object is marked as not supporting the ARM ISA, which then causes assertion failures when calls from ARM code in other objects are seen. I think the intention here was to only use Thumb PLTs when the target does not have the ARM ISA available, signalled by no objects being marked as having it available. To do that we need to track which ISAs we have seen as we parse the build attributes, and defer the decision about PLTs until all input objects have been parsed. This bug was triggered by real code in picolibc, which have some versions of string.h functions built with Thumb2-only build attributes, so that they are compatible with v7-A, v7-R and v7-M. Fixes #99008. (cherry picked from commit a1c6467)
Take a common weak reference pattern for example
```
__attribute__((weak)) void undef_weak_fun();
if (&undef_weak_fun)
undef_weak_fun();
```
In this case, an undefined weak symbol `undef_weak_fun` has an address
of zero, and Bolt incorrectly changes the relocation for the
corresponding symbol to symbol@PLT, leading to incorrect runtime
behavior.
(cherry picked from commit 6c8933e)
This change updates the AArch64DeadRegisterDefinition pass to ensure it does not replace the destination register of a SWP instruction with the zero register when its value is unused. This is necessary to ensure that the ordering of such instructions in relation to DMB.LD barries adheres to the definitions of the AArch64 Memory Model. The memory model states the following (ARMARM version DDI 0487K.a §B2.3.7): ``` Barrier-ordered-before An effect E1 is Barrier-ordered-before an effect E2 if one of the following applies: [...] * All of the following apply: - E1 is a Memory Read effect. - E1 is generated by an instruction whose destination register is not WZR or XZR. - E1 appears in program order before E3. - E3 is either a DMB LD effect or a DSB LD effect. - E3 appears in program order before E2. ``` Prior to this change, by replacing the destination register of such SWP instruction with WZR/XZR, the ordering relation described above was incorrectly removed from the generated code. The new behaviour is ensured in this patch by adding the relevant `SWP[L](B|H|W|X)` instructions to list in the `atomicReadDroppedOnZero` predicate, which already covered the `LD<Op>` instructions that are subject to the same effect. Fixes #68428. (cherry picked from commit beb37e2)
…ses (#102239) The upcoming Apple SDK releases will support the clang built-in headers being in the clang built-in modules: stop passing -fbuiltin-headers-in-system-modules for those SDK versions. (cherry picked from commit 9616399)
Windows does not support float C89 math functions like: - acosf - asinf - atanf - coshf - sinhf - tanhf These 6 libfuncs need to be type promoted. This PR fixes the bug introduced by llvm/llvm-project#98949
…110408) Fixes #109925.
…seRangesCheck (#111282) Fixes llvm/llvm-project#109367 (cherry picked from commit acf92a4)
…solvedCallExpr() after fd87d76 (#111277) The special-casing for RequiresExprBodyDecl caused a regression, as reported in #110785. The original fix for #84020 has been superseded by fd87d76, which establishes a `DependentScopeDeclRefExpr` instead of a `CXXDependentScopeMemberExpr` for the case in issue. So the spurious diagnostic in #84020 would no longer occur. This also merges the test for #84020 together with that for #110785 into clang/test/SemaTemplate/instantiate-requires-expr.cpp. No release note because I think this merits a backport. Fixes #110785 (cherry picked from commit 8c15470)
PR #74625 introduced a regression in the code generated for the following set of intrinsic: vec_add_u128, vec_addc_u128, vec_adde_u128, vec_addec_u128 vec_sub_u128, vec_subc_u128, vec_sube_u128, vec_subec_u128 vec_sum_u128, vec_msum_u128 vec_gfmsum_128, vec_gfmsum_accum_128 This is because the new code incorrectly assumed that a cast from "unsigned __int128" to "vector unsigned char" would simply be a bitcast re-interpretation; instead, this cast actually truncates the __int128 to char and splats the result. Fixed by adding an intermediate cast via a single-element 128-bit integer vector. Fixes: llvm/llvm-project#109113 (cherry picked from commit baf9b7d)
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 #110385
Ensure we have the correct RecordDecl before returning the Expr we're looking for.
This is a (very partial) cherry-pick of #101715 to fix this oversight in the LLVM 19 release.
…09054) In 6a884a9, I synchronized the export list of libc++abi to the export list of libc++. From the linker's perspective, this caused these symbols to be taken from libc++.dylib instead of libc++abi.dylib. However, that can be problematic when back-deploying. Indeed, this means that the linker will encode an undefined reference to be fullfilled by libc++.dylib, but when backdeploying against an older system, that symbol might only be available in libc++abi.dylib. Most of the symbols that started being re-exported after 6a884a9 turn out to be implementation details of libc++abi, so nobody really depends on them and this back-deployment issue is inconsequential. However, we ran into issues with a few of these symbols while testing LLVM 19, which led to this patch. This slipped between the cracks and that is why the patch is coming so long after the original patch landed. In the future, a follow-up cleanup would be to stop exporting most of the _cxxabiv1_foo_type_infoE symbols from both libc++abi and libc++ since they are implementation details that nobody should be relying on. rdar://131984512 (cherry picked from commit 677e8cd)
This was using the default address space instead of the correct one. Fixes #56055 Keep old method around for ABI compatibility on the release branch. (cherry picked from commit 81ba95c)
…nt, ensure we're only accepting ConstantInt splat scalars. Fixes #111170 (cherry picked from commit 9459d72)
`__has_builtin` was relying on reversible identifiers and string matching to recognize builtin-type traits, leading to some newer type traits not being recognized. Fixes #111477
This bails out if we see an intrinsic with an operand bundle on it, to make sure we don't process the bundles incorrectly. Fixes #110382. (cherry picked from commit c136d32)
Fixes #110968. (cherry picked from commit e5b05a5)
When encountering an instruction like `if (p0) r0 = add(r0,##bar@GOT)`, lld would fail with: ``` ld.lld: error: unrecognized instruction for 16_X type: 0x7400C000 ``` This issue was encountered while building libreadline with clang 19.1.0. Fixes: #111876 (cherry picked from commit 77aa825)
…rective (#112066) Fixes llvm/llvm-project#87717. (cherry picked from commit 9bf68c2)
…lation. (#98138) In incremental compilation clang works with multiple `llvm::Module`s. Our current approach is to create a CodeGenModule entity for every new module request (via StartModule). However, some of the state such as the mangle context needs to be preserved to keep the original semantics in the ever-growing TU. Fixes: llvm/llvm-project#95581. cc: @jeaye (cherry picked from commit 6c62ad4)
Update LLVM to 19.0.0 version
Update LLVM to 19.1.2 version
|
LGTM |
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.
Contains three commits:
Tests status matches the state before LLVM bump (see #128):
Failed Tests (7):
LLVM :: tools/llvm-snippy/float-nan-propagation-error.yaml
LLVM :: tools/llvm-snippy/float-nan-propagation-warning.yaml
LLVM :: tools/llvm-snippy/gen-plan-verification-warn.yaml
LLVM :: tools/llvm-snippy/redefine-sp-ext-funcs-warn.yaml
LLVM :: tools/llvm-snippy/reserved-reg-fail.yaml
LLVM :: tools/llvm-snippy/stack-all-reserved.yaml
LLVM :: tools/llvm-snippy/stack-pointer-reg-warn.yaml