Merge tag llvmorg-17.0.0-rc4 into rustc/17.0-2023-07-29
#151
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
On FreeBSD and NetBSD we don't use .weak due to differing semantics. Currently we end up using no directive, which gives a local symbol, whereas the closer thing to a weak symbol would be a global one. In particular, both GNU and LLVM toolchains cannot handle a GOT-indirect reference to a local symbol at a non-zero offset within a section on AArch64 (see ARM-software/abi-aa#217), and so interceptors do not work on FreeBSD/arm64, failing to link with LLD. Switching to .globl both works around this bug and more closely aligns such non-weak platforms with weak ones. Fixes llvm#63418 Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D158552 (cherry picked from commit 7e1afab)
… and VectorType::RVVFixedLengthDataVector. This code was copied from SVE and modified for RVV. For SVE, there is only one size for builtin types so they didn't need to check the size. For RVV, due to LMUL there are 7 different sizes of builtin types so we do need to check the size. I'm not sure we should have lax vector conversions at all for RVV. That appears to be contributing to llvm#64404 This patch at least fixes the obvious correctness issue. This should be backported to LLVM 17. Reviewed By: jacquesguan Differential Revision: https://reviews.llvm.org/D157130 (cherry picked from commit 33af2f1)
This patch fixes: llvm#64671 DataOp EMI callbacks would not report the correct target pointer. This is now alleviated by passing a `void**` into the function which emits the actual callback, then evaluating that pointer. Note: Since this is only done after the pointer has been properly updated, only `endpoint=2` callbacks will show a non-null value. Reviewed By: dhruvachak, jdoerfert Differential Revision: https://reviews.llvm.org/D157996 (cherry picked from commit 41f3626)
…evice num This patch fixes: llvm#64738 We observed multiple issues, primarily that the `DeviceId` was reported as -1 in certain scenarios. The reason for this is simply that the device is not initialized at that point. Hence, we need to move the RAII object creation just after the `checkDeviceAndCtors`, closer to the actual call we want to observe. This also solves an odering issue where one `target enter data` callback would be executed before the `Init` callback. Additionally, this change will also fix that the callbacks corresponding to `enter / exit data` and `update` in conjunction with `nowait` would not result in the emission of an OMPT callback. Added a testcase to cover initialized device number and `omp target` constructs. Reviewed By: dhruvachak Differential Revision: https://reviews.llvm.org/D157605 (cherry picked from commit 57f0bdc)
This was an oversight in D146872, where function calls with tuple type was not covered. This commit fixes this. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D157953 (cherry picked from commit 39a41c8)
…k coro handle unconditionally any more Close llvm#59723. The fundamental cause of the above issue is that we assumed the memory of coroutine frame can be released by stack unwinding automatically if the allocation of the coroutine frame is elided. But we missed one point: the stack unwinding has different semantics with the explicit coroutine_handle<>::destroy(). Since the latter is explicit so it shows the intention of the user. So we can blame the user to destroy the coroutine frame incorrectly in case of use-after-free happens. But we can't do so with stack unwinding. So after this patch, we won't think the exceptional terminator don't leak the coroutine handle unconditionally. Instead, we think the exceptional terminator will leak the coroutine handle too if the coroutine is leaked somewhere along the search path. Concretely for C++, we can think the exceptional terminator is not special any more. Maybe this may cause some performance regressions. But I've tested the motivating example (std::generator). And on the other side, the coroutine elision is a middle end opitmization and not a language feature. So we don't think we should blame such regressions especially we are correcting the miscompilations. (cherry picked from commit 7037331)
When a binary is instrumented with --instrumentation-sleep-time and instrumentation-wait-forks options and lauched, the profile is periodically written until all the forks die. The problem is that we cannot wait for the whole process tree, and we have no way to tell when it's safe to read the profile. Hovewer, if we keep profile open throughout the life of the process tree, we can use fuser to determine when writing is finished. Reviewed By: rafauler Differential Revision: https://reviews.llvm.org/D154436 (cherry picked from commit a799298)
This fixes llvm#60766 With MSVC style exception-handling (funclets), no registers are alive when entering the funclet so they must be reloaded from the stack. MachineLICM can sometimes hoist such reloads out of the funclet which is not correct, the register will have been clobbered when entering the funclet. This can happen in any loop that contains a try-catch. This has been tested on x86_64-pc-window-msvc. I'm not sure if funclets work the same on the other windows archs. Reviewed By: rnk, arsenm Differential Revision: https://reviews.llvm.org/D153337 (cherry picked from commit 917574d)
On macOS, files are usually below `/Users/...` and clang-cl treats
that as the `/U` flag followed by something instead of as a path.
Put `--` in front of `%s` to make it treat it as a patch, like in
all other tests.
The failure without this change:
x86-no-gather-no-scatter.cpp:4:14: error: NOGATHER: expected string not found in input
// NOGATHER: "-target-feature" "+prefer-no-gather"
^
<stdin>:5:44: note: possible intended match here
clang: warning: 'x86-no-gather-no-scatter.cpp' treated as the '/U' option [-Wslash-u-filename]
^
(cherry picked from commit 547ee1c)
When an expression is instantiated, TreeTransform skips ImplicitCastExpr nodes, assuming they are recreated when the instantiated expression is built. It breaks functions that use non-default floating-point options, because they are kept in these ImplicitCastExprs. In this case the recreated ImplicitCastExpr takes FP options from the current Sema state and not from AST node. To fix this issue the FP options in Sema object are set when a compound statement is cloned in TreeTransform. This change fixes llvm#64605 ([Regression 16 -> 17] Template instantiation ignores FENV_ACCESS being ON for both definition and instantiation). Differential Revision: https://reviews.llvm.org/D158158 (cherry picked from commit 0baf85c)
The test clang/test/SemaCXX/template-64605.cpp uses pragma FENV_ACCESS, which is not supported on all targets. Restrict it to x86_64 only. (cherry picked from commit 73e5a70)
…es` to `operandSegmentSizes` This renaming started with the native ODS support for properties, this is completing it. A mass automated textual rename seems safe for most codebases. Drop also the ods prefix to keep the accessors the same as they were before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173
…ptionalParseResult' Fix llvm#63072
Using properties would break when a dialect isn't in the mlir namespace
…t when initialization is needed The current logic hashes the context to detect registration changes and re-run the pass initialization. However it wasn't checking for changes to the pipeline, so a pass that would get added after a first run would not be initialized during subsequent runs. Reviewed By: Mogball Differential Revision: https://reviews.llvm.org/D158377
…elected fields It is surprising for the user that only some fields were honored. Also make the FrozenRewritePatternSet a shared_ptr<const T>. Fixes llvm#64543 Differential Revision: https://reviews.llvm.org/D157469
Test cases in D157680 should be target specific, but miss some limit, add them back to make buildbot pass. Reviewed By: skan, Hahnfeld Differential Revision: https://reviews.llvm.org/D158252
Reviewed By: #libc, #libc_abi, Mordante Spies: arphaman, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D157060
I need to use header_information.py in a generator script that isn't for tests in an upcoming change. Move it up a level so that it's in utils/libcxx instead of utils/libcxx/tests. Differential Revision: https://reviews.llvm.org/D157639 # Conflicts: # libcxx/test/libcxx/system_reserved_names.gen.py
Top level modules don't need `requires` because they're only built when their headers are included. Reviewed By: ldionne, Mordante, #libc Differential Revision: https://reviews.llvm.org/D157363
Use header_information to generate the __std_clang_module header. Instead of using lit_header_restrictions like the manually written header did, make a new header_include_requirements to codify what can be included rather than what can be fully tested. Reviewed By: Mordante, #libc Differential Revision: https://reviews.llvm.org/D157364 # Conflicts: # libcxx/utils/libcxx/header_information.py
Post review feedback on D157364. Don't section the __std_clang_module header by macro, put the headers in alphabetical order and repeat the macro guards. Restore header_information.header_restrictions. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D158133 # Conflicts: # libcxx/utils/libcxx/header_information.py
- Make a test for an internal concept libc++-only; - Make sure that `size` and `capacity` in a test container return the same type on all platforms. (cherry picked from commit 8b9a986)
Prevent these tests from failing on some platforms (the number of constexpr steps increased by https://reviews.llvm.org/D154860). (cherry picked from commit 91876ea)
…BCPP_LOCALE__L_EXTENSIONS is undefined When `__locale_dir/locale_base_api/locale_guard.h is` compiled independently, as it is when it's in its own clang module, it fails to compile due to `locale_t` being undefined. It needs to include `__locale` to get that, instead of just `clocale`. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D158669 (cherry picked from commit 6021c78)
… not empty Close llvm#56301 Close llvm#64151 See the summary and the discussion of https://reviews.llvm.org/D157070 to get the full context. As @rjmccall pointed out, the key point of the root cause is that currently we didn't implement the semantics for '@llvm.coro.save' well ("after the await-ready returns false, the coroutine is considered to be suspended ") well. Since the semantics implies that we (the compiler) shouldn't write the spills into the coroutine frame in the await_suspend. But now it is possible due to some combinations of the optimizations so the semantics are broken. And the inlining is the root optimization of such optimizations. So in this patch, we tried to add the `noinline` attribute to the await_suspend call. Also as an optimization, we don't add the `noinline` attribute to the await_suspend call if the awaiter is an empty class. This should be correct since the programmers can't access the local variables in await_suspend if the awaiter is empty. I think this is necessary for the performance since it is pretty common. Another potential optimization is: call @llvm.coro.await_suspend(ptr %awaiter, ptr %handle, ptr @awaitSuspendFn) Then it is much easier to perform the safety analysis in the middle end. If it is safe to inline the call to awaitSuspend, we can replace it in the CoroEarly pass. Otherwise we could replace it in the CoroSplit pass. Reviewed By: rjmccall Differential Revision: https://reviews.llvm.org/D157833
… regressions The fix we sent for llvm#56301 may bring performance regressions. But we didn't mention it in the ReleaseNotes so that users may get confused. e.g, llvm#64933. So this patch mentions the possible side effect and the potential solutions in llvm#64945 to avoid misunderstandings.
Because indirect call tables use static addresses for call sites, but pc values recorded by runtime may be subject to ASLR in PIE, we couldn't find indirect call descriptions by their runtime address in PIE. It resulted in [unknown] entries in profile for all indirect calls. We need to substract base address of .text from runtime addresses to get the corresponding static addresses. Here we create a getter for base address of .text and substract it's return value from recorded PC values. It converts them to static addresses, which then may be used to find the corresponding indirect call descriptions. Reviewed By: rafauler Differential Revision: https://reviews.llvm.org/D154121 (cherry picked from commit a86dd9a)
Before accessing "getOpcode" thorugh machine instruction, check if the iterator has reached the end of Machine basic block otherwise we will crash at the assertion `!NodePtr->isKnownSentinel()`. The above assertion is hit in "Prologue/Epilogue Insertion & Frame Finalization pass". Reviewed By: craig.topper, wangpc Differential Revision: https://reviews.llvm.org/D158256 (cherry picked from commit fdef795)
… _S_IWRITE` When sending file from a Linux host to a Windows remote, Linux host will try to copy the source file's permission bits, which will contain `_S_I?GRP` and `_S_I?OTH` bits. Those bits are rejected by `_wsopen_s`, causing it to return EINVAL. This patch masks out the rejected bits. GitHub issue: llvm#64313 Reviewed By: jasonmolenda, DavidSpickett Differential Revision: https://reviews.llvm.org/D156817 (cherry picked from commit 9a4b3fd)
Fixes https://llvm.org/PR65011 Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D158940 (cherry picked from commit 8930d04)
The `STGloop` family of pseudo-instructions all expand to a loop which iterates over a region of memory setting all its MTE tags to a given value. The loop writes to the flags in order to check termination. But the unexpanded pseudo-instructions were not marked as modifying the flags. Therefore it was possible for one to end up in a location where the flags were live, and then the loop would corrupt them. We spotted the effect of this in a libc++ test involving a lot of complicated inlining, and haven't been able to construct a smaller test case that demonstrates actual incorrect output code. So my test here is just checking that `implicit-def $nzcv` shows up on the pseudo-instructions as they're output from isel. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D158262 (cherry picked from commit b09c575)
…/stores when relaxing initial-exec to local-exec D153645 added additional X-Form load/stores that can be generated for TLS accesses. However, these added instructions have not been accounted for in lld. As a result, lld does not know how to handle them and cannot relax initial-exec to local-exec when the initial-exec sequence contains these additional load/stores. This patch aims to resolve llvm#64424. Differential Revision: https://reviews.llvm.org/D158197 (cherry picked from commit 698b45a)
…as others users. This disables the transform if the branch does not have the kill flag set for the AND we want to delete. Ideally we'd be able to share the AND with the AND we create in the expansion, but that's a more complex transform. So this starts with the simple approach to fix miscompile. This should be backported to LLVM 17. Fixes PR65025.ll Reviewed By: asb Differential Revision: https://reviews.llvm.org/D158962 (cherry picked from commit ff6d333)
see the issue llvm#64191 Differential Revision: https://reviews.llvm.org/D156650 (cherry picked from commit dcb2824)
Split from D158952. (cherry picked from commit 30ec947)
Reviewed By: RKSimon Differential Revision: https://reviews.llvm.org/D158952 (cherry picked from commit b667e9c)
…arget. An execute-only target disallows data access to code sections. -fsanitize=function and -fsanitize=kcfi instrument indirect function calls to load a type hash before the function label. This results in a non-execute access to the code section and a runtime error. To solve the issue, -fsanitize=function should not be included in any check group (e.g. undefined) on an execute-only target. If a user passes -fsanitize=undefined, there is no error and no warning. However, if the user explicitly passes -fsanitize=function or -fsanitize=kcfi on an execute-only target, an error will be emitted. Fixes: llvm#64931. Reviewed By: MaskRay, probinson, simon_tatham Differential Revision: https://reviews.llvm.org/D158614
…58614 clangDriver depends on clangBasic, so clangBasic should not depend on clangDriver, even just its header. Also remove clangBasic's dependency on LLVMOption. The issue can be seen through the bazel commit d26dd68 which is reverted now. Add hasFlagNoClaim and use it as we don't want to suppress -Wunused-command-line-argument for -mexecute-only just because -fsanitize= is specified.
Adjust tests from dd230ef to use -std=c2x instead, as Clang in release/17.x doesn't support -std=c23.
Fixes llvm#64191 Differential Revision: https://reviews.llvm.org/D156648 (cherry picked from commit 171868d)
Whether a temp file or a pipe is used for preprocessing is an internal detail, this flag has a notable effect on the preprocessing in GNU windres. Without this flag, GNU windres passes command arguments as-is to popen(), which means they get evaluated by a shell without being re-escaped for this case. To mimic this, llvm-windres has manually tried to unescape arguments. When GNU windres is given the --use-temp-file flag, it uses a different API for invoking the preprocessor, and this API takes care of preserving special characters in the command line arguments. For users of GNU windres, this means that by using --use-temp-file, they don't need to do the (quite terrible) double escaping of quotes/spaces etc. The xz project uses the --use-temp-file flag when invoking GNU windres, see tukaani-project/xz@6b117d3. However as llvm-windres didn't implement this flag and just assumed the GNU windres popen() behaviour, they had to use a different codepath for llvm-windres. That separate codepath for llvm-windres broke later when llvm-windres got slightly more accurate unescaping of lone quotes in 0f4c6b1 / https://reviews.llvm.org/D146848 (fixing a discrepancy to GNU windres as found in llvm#57334), and this was reported in mstorsjo/llvm-mingw#363. Not touching the implementation of the --preprocessor option with respect to the --use-temp-file flag; that option is doubly tricky as GNU windres changed its behaviour in a backwards incompatible way recently (and llvm-windres currently matches the old behaviour). (See https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20, https://sourceware.org/bugzilla/show_bug.cgi?id=27594 and https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f;hp=3abbafc2aacc6706fea3e3e326e2f08d107c3672 for the behaviour change.) Differential Revision: https://reviews.llvm.org/D159223 (cherry picked from commit 2bcc0fd)
StN lane memory size set too big lead to alias analysis goes wrong. Fixes llvm#64696 Differential Revision: https://reviews.llvm.org/D158611 (cherry picked from commit db8f6c0)
…embler input This patch amends D151590 to not error for unlaimed TargetSpecific options for `-x assembler` input files. This input type causes Driver to construct tools::ClangAs (-fintegrated-as) or other assemblers (e.g. tools::gnutools::Assembler) Their ConstructJobs methods, unlike Clang::ConstructJobs, claim very few options. If an option is unclaimed, it either leads to a -Wunused-command-line-argument warning or an error (if `TargetSpecific` is set): ``` % clang '-###' --target=aarch64 -mbranch-protection=bti -c a.s clang: error: unsupported option '-mbranch-protection=' for target 'aarch64' ``` It seems that downgrading the diagnostic to warning is most useful as many users use CFLAGS even for `.s` files: ``` clang --target=aarch64 -mbranch-protection=bti -S a.c clang --target=aarch64 -mbranch-protection=bti -c a.s ``` I decide not to suppress the warning so that -Wunused-command-line-argument lovers still get a warning, and help projects use proper ASFLAGS/CFLAGS/etc. Note: `-mbranch-protection=bti a.S` currently has no warning as `-x assembler-with-cpp` instructs clangDriver to select tools::Clang and claim most options. Revert D159010 to demonstrate that we emit a warning for -mfpmath= for `-x assembler` input. Modify my AIX cleanup cd18efb to add an err_drv_unsupported_opt_for_target. Reviewed By: thesamesam Differential Revision: https://reviews.llvm.org/D159173 (cherry picked from commit e9d454d)
This patch fixes valgrind reports from downstream consumers about conditional jump over uninitialised memory. The original report: ```[ RUN ] ScopeReflectionTest.IsComplete ==987150== Conditional jump or move depends on uninitialised value(s) ==987150== at 0x1E1128F: clang::CodeGen::CodeGenModule::SetLLVMFunctionAttributesForDefinition(clang::Decl const*, llvm::Function*) (CodeGenModule.cpp:2391) ==987150== by 0x1E4F181: clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (CodeGenModule.cpp:5669) ==987150== by 0x1E4A194: clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (CodeGenModule.cpp:3909) ==987150== by 0x1E4A752: clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (CodeGenModule.cpp:3649) ==987150== by 0x1E532F5: clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) [clone .part.0] (CodeGenModule.cpp:6563) ==987150== by 0x1B0BEDD: (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) (ModuleBuilder.cpp:190) ==987150== by 0x1AEA47B: clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (CodeGenAction.cpp:235) ==987150== by 0x101B02F: clang::IncrementalASTConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (IncrementalParser.cpp:52) ==987150== by 0x101ED93: clang::IncrementalParser::ParseOrWrapTopLevelDecl() (IncrementalParser.cpp:276) ==987150== by 0x101FBBC: clang::IncrementalParser::Parse(llvm::StringRef) (IncrementalParser.cpp:342) ==987150== by 0x100E104: clang::Interpreter::Parse(llvm::StringRef) (Interpreter.cpp:360) ==987150== by 0xE734C0: Cpp::Interpreter::Parse(llvm::StringRef) (CppInterOpInterpreter.h:172) ==987150== Uninitialised value was created by a heap allocation ==987150== at 0x844BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==987150== by 0x1B0C882: StartModule (ModuleBuilder.cpp:139) ==987150== by 0x1B0C882: clang::CodeGenerator::StartModule(llvm::StringRef, llvm::LLVMContext&) (ModuleBuilder.cpp:360) ==987150== by 0x101C4AF: clang::IncrementalParser::GenModule() (IncrementalParser.cpp:372) ==987150== by 0x101FC0E: clang::IncrementalParser::Parse(llvm::StringRef) (IncrementalParser.cpp:362) ==987150== by 0x100E104: clang::Interpreter::Parse(llvm::StringRef) (Interpreter.cpp:360) ==987150== by 0x100E243: clang::Interpreter::create(std::unique_ptr<clang::CompilerInstance, std::default_delete<clang::CompilerInstance> >) (Interpreter.cpp:279) ==987150== by 0xF2131A: compat::createClangInterpreter(std::vector<char const*, std::allocator<char const*> >&) (Compatibility.h:123) ==987150== by 0xF22AB9: Cpp::Interpreter::Interpreter(int, char const* const*, char const*, std::vector<std::shared_ptr<clang::ModuleFileExtension>, std::allocator<std::shared_ptr<clang::ModuleFileExtension> > > const&, void*, bool) (CppInterOpInterpreter.h:146) ==987150== by 0xF1827A: CreateInterpreter (CppInterOp.cpp:2494) ==987150== by 0xECFA0E: TestUtils::GetAllTopLevelDecls(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<clang::Decl*, std::allocator<clang::Decl*> >&, bool) (Utils.cpp:23) ==987150== by 0xE9CB85: ScopeReflectionTest_IsComplete_Test::TestBody() (ScopeReflectionTest.cpp:71) ==987150== by 0xF0ED0C: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (in /home/vvassilev/workspace/builds/scratch/cppyy/InterOp/build-with-clang-repl-release/unittests/CppInterOp/CppInterOpTests) ==987150== ``` Differential revision: https://reviews.llvm.org/D159339 (cherry picked from commit 92246a9)
When the optional assignment-allocation character 'm' (Extension to the ISO C standard) is present, we currently use internal_strlen(buf)+1 for all of cCsS[ (D85350). Fix cCS to use the correct size. Fix llvm#61768 Reviewed By: #sanitizers, vitalybuka Differential Revision: https://reviews.llvm.org/D158485 (cherry picked from commit beeb37a)
…tFailure We're expecting a SubstitutionDiagnostic in diagnoseUnsatisfiedRequirement if the status of ExprRequirement is SubstFailure. Previously, the Requirement was created with Expr on SubstFailure by mistake, which could lead to the assertion failure in the subsequent diagnosis. Fixes clangd/clangd#1726 Fixes llvm#64723 Fixes llvm#64172 In addition, this patch also fixes an invalid test from D129499. Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D158061
`clang::runWithSufficientStackSpace` requires the address of the initial stack bottom to prevent potential stack overflows. In addition, add a fallback to ASTFrontendAction in case any client forgets to call it when not through CompilerInstance::ExecuteAction, which is rare. Fixes clangd/clangd#1745. Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D158967 (cherry picked from commit e257c0a)
(cherry picked from commit 5855a4b)
(cherry picked from commit 7ded71b)
This is probably a bad idea, but it's only become a problem with properties and is easy to fix. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D159185
…into rustc/17.0-2023-07-29 LLVM 17.0.0-rc4 Release
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 5, 2023
…uviper Update LLVM submodule to 17.0.0-rc4 Updates the in-tree LLVM submodule to the 17.0.0-rc4 branch from rust-lang/llvm-project#151.
vext01
added a commit
to vext01/llvm-project
that referenced
this pull request
May 9, 2024
Serialise indirect calls.
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.
This updates the version of LLVM 17 to the latest release candidate upstream (the branch is currently at
llvmorg-17.0.0-rc3). Motivated by this fix for this issue.