LLVM 19.1.2 bump #129
Merged
LLVM 19.1.2 bump #129
Conversation
This file contains 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 4377656f2419a8eb18c01e86929b689dcf22b5d6)
…(#101877) (cherry picked from commit 3c483b887e5a32a0ddc0a52a467b31f74aad25bb)
…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 8dd065d5bc81b0c8ab57f365bb169a5d92928f25)
… system. (#101392) Fixes build errors on some SDKs. rdar://132607572 (cherry picked from commit 3a4c7cc56c07b2db9010c2228fc7cb2a43dd9b2d)
…… (#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 9eefe065bb2752b0db9ed553d2406e9a15ce349e)
…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 1c53b907bd6348138a59da270836fc9b4c161a07)
``` 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 7cecbdfe4eac3fd7268532426fb6b13e51b8720d)
```
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 fcd6bd5587cc376cd8f43b60d1c7d61fdfe0f535)
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 7e44305041d96b064c197216b931ae3917a34ac1)
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 fb470db7b3a8ce6853e8bf17d235617a2fa79434)
…(#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 12937b1bfb23cca4731fa274f3358f7286cc6784)
…(#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 d6649f2d4871c4535ae0519920e36100748890c4)
…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 7775a4882d7105fde7f7a81f3c72567d39afce45)
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 e60ee1f2d70bdb0ac87b09ae685d669d8543b7bd)
…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 da380b26e4748ade5a8dba85b7df5e1c4eded8bc)
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 dc349a3f47882cdac7112c763d2964b59e77356a)
…(#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 3c8dadda3aa20b89fb5ad29ae31380d9594c3430)
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 3a226dbe27ac7c7d935bc0968e84e31798a01207)
(cherry picked from commit bb59f04e7e75dcbe39f1bf952304a157f0035314)
…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 c80c09f3e380a0a2b00b36bebf72f43271a564c1)
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 734c0488b6e69300adaf568f880f40b113ae02ca)
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 a1c6467bd90905d52cf8f6162b60907f8e98a704)
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 6c8933e1a095028d648a5a26aecee0f569304dd0)
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 beb37e2e22b549b361be7269a52a3715649e956a)
…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 961639962251de7428c3fe93fa17cfa6ab3c561a)
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 acf92a47c0ece8562fd745215c478fe2d4ab5896)
…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 8c1547055eaf65003f3e6fd024195f4926ff2356)
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 baf9b7da81025c1e3b0704d7ecf667e06f95642b)
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 677e8cd6ff51e178bcb4669104763f71a2de106c)
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 81ba95cefe1b5a12f0a7d8e6a383bcce9e95b785)
…nt, ensure we're only accepting ConstantInt splat scalars. Fixes #111170 (cherry picked from commit 9459d729d22b7bfedad9d3a4237162077c6984a4)
`__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 c136d3237a3c6230cfe1ab3f0f6790f903c54a27)
To Fix #110215 Interceptors introduced with 18a7ebd (cherry picked from commit d0b9c2c5647656738cda3fb670aa5d3b3a69d784)
Fixes #110968. (cherry picked from commit e5b05a51b8151cc7788bbdea4d491e5ccfceedea)
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 77aa8257acbd773c0c430cd962da1bcfbd5ee94b)
…rective (#112066) Fixes llvm/llvm-project#87717. (cherry picked from commit 9bf68c2400e8966511332dfbf5c0f05e8a3300fa)
…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 6c62ad446b2441b78ae524d9e700e351d5a76394)
Update LLVM to 19.0.0 version
Update LLVM to 19.1.2 version
|
LGTM |
kv-sc
pushed a commit
that referenced
this pull request
Dec 5, 2024
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.
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