Update LLVM to 19.1.4 #179
Merged
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
…lvm#115167) Since b4130be, we check for _LIBCPP_HAS_THREAD_API_PTHREAD to decide between using SetThreadDescription or pthread_setname_np for setting the thread name. c6f3b7b changed how libcxx defines their configuration macros - now they are always defined, but defined to 0 or 1, while they previously were either defined or undefined. As these libcxx defines used to be defined to an empty string (rather than expanding to 1) if enabled, we can't easily produce an expression that works both with older and newer libcxx. Additionally, these defines are libcxx internal config macros that aren't a detail that isn't supported and isn't meant to be relied upon. Simply skip trying to set thread name on MinGW as we can't easily know which kind of thread native handle we have. Setting the thread name is only a nice to have, quality of life improvement - things should work the same even without it. Additionally, libfuzzer isn't generally usable on MinGW targets yet (Clang doesn't include it in the getSupportedSanitizers() method for the MinGW target), so this shouldn't make any difference in practice anyway. (cherry picked from commit 87f4bc0)
…Br. (llvm#109513) The Fixups vector passed into this function may already have fixups in it from earlier instructions. We should not erase those. We just want to erase fixups added by this function. Fixes llvm#108612. (cherry picked from commit c3d3cef)
…configs (llvm#113491) The use of CLANG_NO_DEFAULT_CONFIG in the tests was added because some Linux distributions had a global default config file, that added flags relating to hardening, which interfere with the sanitizer tests. By setting CLANG_NO_DEFAULT_CONFIG, the global default config files that are found are ignored, and the sanitizers get the expected default compiler behaviour. (This was llvm#60394, which was fixed in 8ab7625.) However, some toolchains may rely on default config files for mandatory parts required for functioning at all - setting things like sysroots, -rtlib, -unwindlib, -stdlib, -fuse-ld etc. In such a case we can't forcibly disable any default config, because it will break the otherwise working toolchain. Add a test for whether the compiler works while passing --no-default-config to it. If the option is accepted and the toolchain still works while that is set, set CLANG_NO_DEFAULT_CONFIG while running tests. (This adds a little bit of inconsistency, as we're testing for the command line option, while using the environment variable. However doing compile testing with an environment variable isn't quite as easily doable, and passing an extra command line flag to all compile commands while testing, is a bit clumsy - therefore this inconsistency.) (cherry picked from commit a14a83d)
…vm#114506) Fixes llvm#114408. (cherry picked from commit 6ca816f)
…int normalization Backport 227afac
(cherry picked from commit 96d2196)
…s for LSX and LASX builtins (llvm#114510) `-flax-vector-conversions=none` does not allow an implicit conversion from `signed char` vector to `char` vector, and we cannot remove `signed` from `v16i8` or `v32i8` because doing so will break our expectation with `-fno-signed-char`. So to make lsxintrin.h and lasxintrin.h work fine with `-flax-vector-conversions=none`, we must use `signed char` instead of `char`. The change is just done via sed 's/V16c/V16Sc/g' -i BuiltinsLoongArchLSX.def sed 's/V32c/V32Sc/g' -i BuiltinsLoongArchLASX.def Depends on llvm#114509. Part of llvm#110834 fix. (cherry picked from commit b885054)
…b builtins `signed char` vector (llvm#114511) These builtins operate on int8 vectors, not int16 vectors. So the old definition does not make any sense. Depends on llvm#114510. Part of llvm#110834 fix. (cherry picked from commit 92daad2)
…b builtins `signed char` vectors (llvm#114512) The lsxintrin.h and and lasxintrin.h headers uses `signed char` vectors instead of `unsigned char` vectors. GCC also uses `signed char` for them, so align their definition with the headers and GCC. Depends on llvm#114511. Part of llvm#110834 fix. (cherry picked from commit 4006b28)
… builti ns `unsigned char` vectors (llvm#114513) The lsxintrin.h and and lasxintrin.h headers uses `unsigned char` vectors instead of `signed char` vectors. GCC also uses `unsigned char` for them, so align their definition with the headers and GCC. Fixes llvm#110834. Depends on llvm#114512. (cherry picked from commit 4f740f9)
Previously, building `multc3.c` on A64 with GCC 7 or up but 9 and lower
will attempt to reference `__builtin_copysignq`, an [x86-specific
intrinsic][1]:
```
$ gcc -c multc3.c
In file included from fp_lib.h:24,
from multc3.c:14:
multc3.c: In function '__multc3':
int_math.h:71:32: warning: implicit declaration of function '__builtin_copysignq'; did you mean '__builtin_copysign'? [-Wimplicit-function-declaration]
#define crt_copysignf128(x, y) __builtin_copysignq((x), (y))
^~~~~~~~~~~~~~~~~~~
```
This is because `__has_builtin` is from GCC 10, and defined to 0 at the
top of int_math.h for affected GCC versions, so the fallback definition
is used. But `__builtin_copysignq` is unavailable on A64.
Use version detection to find `__builtin_copysignf128` instead. It's
available since GCC 7 and [available][2] on both x86 and A64, given this
macro is only used when `CRT_HAS_IEEE_TF`.
---
I realize this is fixing a problem for an out-of-tree build
configuration, but help would be greatly appreciated. Rust
[builds](https://github.com/rust-lang/compiler-builtins) `multc3.c` with
GCC 8 and this mis-selection is causing [build
issues](rust-lang/rust#125619) way downstream.
ref: d2ce3e9
[1]: https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html
[2]: https://gcc.gnu.org/gcc-7/changes.html
(cherry picked from commit 8aa9d62)
…gInterpreter for wasm (llvm#113446) While building llvm (clang, lld) for wasm using emscripten (recipe hosted on emscripten-forge https://github.com/emscripten-forge/recipes/tree/main/recipes/recipes_emscripten/llvm) I ended up with this error ``` │ │ wasm-ld: error: ../../../../lib/libclangInterpreter.a(Wasm.cpp.o): undefined symbol: lld::wasm::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm: │ │ :raw_ostream&, bool, bool) ``` This is due to the link function here https://github.com/llvm/llvm-project/blob/a4819bd46d8baebc3aaa8b38f78065de33593199/clang/lib/Interpreter/Wasm.cpp#L25-L30 This was added through this PR (llvm#86402) as an attempt to support running clang-repl and executing C++ code interactively inside a Javascript engine using WebAssembly when built with Emscripten. The definition for link is present in lldwasm and when building for the emscripten platform we should be linking against it. (cherry picked from commit 075581f)
A miscompilation issue has been addressed with refined checking.
Arm64EC uses a special name mangling mode that adds `$$h` between the symbol name and its type. In MSVC's name mangling `@` is used to separate the name and type BUT it is also used for other purposes, such as the separator between paths in a fully qualified name. The original algorithm was quite fragile and made assumptions that didn't hold true for all MSVC mangled symbols, so instead of trying to improve this algorithm we are now using the demangler to indicate where the insertion point should be (i.e., to parse the fully-qualified name and return the current string offset). Also fixed `isArm64ECMangledFunctionName` to search for `@$$h` since the `$$h` must always be after a `@`. Fixes llvm#115231
Before using a constexpr variable that is not properly initialized check that it is valid. Fixes llvm#109095 Fixes llvm#112516
…#114193) Reproducer: ``` //--- a.cppm export module a; int func(); static int a = func(); //--- a.cpp import a; ``` The `func()` should only execute once. However, before this patch we will somehow import `static int a` from a.cppm incorrectly and initialize that again. This is super bad and can introduce serious runtime behaviors. And also surprisingly, it looks like the root cause of the problem is simply some oversight choosing APIs. (cherry picked from commit 259eaa6)
) On Apple platforms, using system-libcxxabi as an ABI library wouldn't work because we'd try to re-export symbols from libc++abi that the system libc++abi.dylib might not have. Instead, only re-export those symbols when we're using the in-tree libc++abi. This does mean that libc++.dylib won't re-export any libc++abi symbols when building against the system libc++abi, which could be fixed in various ways. However, the best solution really depends on the intended use case, so this patch doesn't try to solve that problem. As a drive-by, also improve the diagnostic message when the user forgets to set the LIBCXX_CXX_ABI_INCLUDE_PATHS variable, which would previously lead to a confusing error. Closes llvm#104672 (cherry picked from commit 21da4e7)
Closes llvm#112666 and llvm#114181. (cherry picked from commit ff07df6)
…act(). (llvm#100150) A test case showed up where the new vector type is v24i16, which is not a simple MVT. In order to get an extended value type for cases like this, EVT::getVectorVT() needs to be called instead of MVT::getVectorVT(), otherwise the following call to getVectorElementType() in combineExtract() will fail. (cherry picked from commit 22bc9db)
Manual cherry-pick of llvm#110986 to the LLVM 19 release branch.
…leting (llvm#113443)" for non-Android Linux only (llvm#115790) The original patch (25fd366) was reverted in 083a5cd because it broke some buildbots. This revised patch makes two changes: - Reverts to *pre-llvm#98200* behavior for Android. This avoids a build breakage on Android. - Only define KeepUnblocked if SANITIZER_LINUX: this avoids a build breakage on solaris, which does not support internal_sigdelset. N.B. Other buildbot failures were non-sanitizer tests and are therefore unrelated. Original commit message: My earlier patch llvm#98200 caused a regression because it unconditionally unblocked synchronous signals, even if the user program had deliberately blocked them. This patch fixes the issue by checking the current signal mask, as suggested by Vitaly. It also adds tests. Fixes llvm#113385 (cherry picked from commit 531acf9)
So far we have assumed that we only rethrow the exception caught in the innermost EH pad. This is true in code we directly generate, but after inlining this may not be the case. For example, consider this code: ```ll ehcleanup: %0 = cleanuppad ... call @Destructor cleanupret from %0 unwind label %catch.dispatch ``` If `destructor` gets inlined into this function, the code can be like ```ll ehcleanup: %0 = cleanuppad ... invoke @throwing_func to label %unreachale unwind label %catch.dispatch.i catch.dispatch.i: catchswitch ... [ label %catch.start.i ] catch.start.i: %1 = catchpad ... invoke @some_function to label %invoke.cont.i unwind label %terminate.i invoke.cont.i: catchret from %1 to label %destructor.exit destructor.exit: cleanupret from %0 unwind label %catch.dispatch ``` We lower a `cleanupret` into `rethrow`, which assumes it rethrows the exception caught by the nearest dominating EH pad. But after the inlining, the nearest dominating EH pad is not `ehcleanup` but `catch.start.i`. The problem exists in the same manner in the new (exnref) EH, because it assumes the exception comes from the nearest EH pad and saves an exnref from that EH pad and rethrows it (using `throw_ref`). This problem can be fixed easily if `cleanupret` has the basic block where its matching `cleanuppad` is. The bitcode instruction `cleanupret` kind of has that info (it has a token from the `cleanuppad`), but that info is lost when when we enter ISel, because `TargetSelectionDAG.td`'s `cleanupret` node does not have any arguments: https://github.com/llvm/llvm-project/blob/5091a359d9807db8f7d62375696f93fc34226969/llvm/include/llvm/Target/TargetSelectionDAG.td#L700 Note that `catchret` already has two basic block arguments, even though neither of them means `catchpad`'s BB. This PR adds the `cleanuppad`'s BB as an argument to `cleanupret` node in ISel and uses it in the Wasm backend. Because this node is also used in X86 backend we need to note its argument there too but nothing more needs to change there as long as X86 doesn't need it. --- - Details about changes in the Wasm backend: After this PR, our pseudo `RETHROW` instruction takes a BB, which means the EH pad whose exception it needs to rethrow. There are currently two ways to generate a `RETHROW`: one is from `llvm.wasm.rethrow` intrinsic and the other is from `CLEANUPRET` we discussed above. In case of `llvm.wasm.rethrow`, we add a '0' as a placeholder argument when it is lowered to a `RETHROW`, and change it to a BB in LateEHPrepare. As written in the comments, this PR doesn't change how this BB is computed. The BB argument will be converted to an immediate argument as with other control flow instructions in CFGStackify. In case of `CLEANUPRET`, it already has a BB argument pointing to an EH pad, so it is just converted to a `RETHROW` with the same BB argument in LateEHPrepare. This will also be lowered to an immediate in CFGStackify with other control flow instructions. --- Fixes llvm#114600.
|
Thanks! Could you merge |
LLVM Release 19.1.4
Earlopain
force-pushed
the
llvm-19.1.4
branch
from
f29fd94 to
b73591a
Compare
|
Yeah, sure. That does make it cleaner for next time around 👍 |
|
Hm, the rebase merge option here didn't do what I expected, I thought it was going to rebase only the merge commit... |
|
I have disabled "squash merging" and "rebase merging", but maybe a local fast-forward merge is the best option. |
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.
👋 First-time "contributor". I updated it following https://rustc-dev-guide.rust-lang.org/backend/updating-llvm.html#backports-upstream-supported
LLVM 19.1.4 contains llvm#93890 (backported in llvm#115006) which will fix rust-lang/rust#125619
I reverted 51dee6b because it already bumps the version number to 19.1.5. Probably, this is not the best place to choose as the first contribution point. If this doesn't look right, just see this as a notice that some rust issue will be fixed. I'm totally fine with the usual people doing the update like it usually happens