[MemCpyOpt] Remove libcall availability checks for memory intrinsics - #11
Open
addmisol wants to merge 349 commits into
Open
[MemCpyOpt] Remove libcall availability checks for memory intrinsics#11addmisol wants to merge 349 commits into
addmisol wants to merge 349 commits into
Conversation
addmisol
pushed a commit
that referenced
this pull request
Jul 2, 2026
`Evaluate_DW_OP_deref` validated that the dereference size was `<= 8` but not that it was non-zero. The DWARF expression evaluator parses untrusted operands, so a `DW_OP_deref_size` with size operand `0` is reachable (it is hit by the lldb-dwarf-expression-fuzzer). A zero dereference size flows into `DerefSizeExtractDataHelper`, which constructs a `DataExtractor` with `addr_size == 0` and aborts on its assertion. The unit test that feeds `DW_OP_lit0, DW_OP_deref_size, 0x00` shows the crash: ``` [ RUN ] DWARFExpressionMockProcessTest.DW_OP_deref_size_zero Assertion failed: (addr_size >= 1 && addr_size <= 8), function DataExtractor, file DataExtractor.cpp, line 134. #8 DataExtractor::DataExtractor(...) #11 DWARFExpression::Evaluate(...) ``` Reject a zero dereference size with an error, alongside the existing `size > 8` check. Adds `DWARFExpressionMockProcessTest.DW_OP_deref_size_zero`, which aborts on the assertion above without the fix.
addmisol
pushed a commit
that referenced
this pull request
Jul 2, 2026
…lvm#191275)" (llvm#206816) This reverts commit 0f51760. A test fails with the commit (llvm#191275 (comment)): ``` Traceback (most recent call last): File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 596, in test_python_source_frames self.assertNotIn("0xffffffffffffffff", output.lower()) AssertionError: '0xffffffffffffffff' unexpectedly found in "* thread #2, name = 'a.out', stop reason = breakpoint 1.1\n * frame #0: compute_fibonacci at python_helper.py:7 [synthetic]\n frame #1: process_data at python_helper.py:16 [synthetic]\n frame #2: main at python_helper.py:27 [synthetic]\n frame #3: 0x0000badc2de81358 a.out`thread_func(thread_num=0) at main.cpp:44:13\n frame #4: 0x0000badc2de81f9c a.out`void std::__invoke_impl<void, void (*)(int), int>((null)=__invoke_other @ 0x0000f1555ebae74f, __f=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:61:14\n frame #5: 0x0000badc2de81f18 a.out`std::__invoke_result<void (*)(int), int>::type std::__invoke<void (*)(int), int>(__fn=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:96:14\n frame #6: 0x0000badc2de81ee4 a.out`void std::thread::_invoker<std::tuple<void (*)(int), int>>::_m_invoke<0ul, 1ul>(this=0x0000badc66845eb8, (null)=_index_tuple<0ul, 1ul> @ 0x0000f1555ebae7af) at std_thread.h:259:13\n frame #7: 0x0000badc2de81e98 a.out`std::thread::_invoker<std::tuple<void (*)(int), int>>::operator()(this=0x0000badc66845eb8) at std_thread.h:266:11\n frame #8: 0x0000badc2de81d70 a.out`std::thread::_state_impl<std::thread::_invoker<std::tuple<void (*)(int), int>>>::_m_run(this=0xffffffffffffffff) at std_thread.h:211:13\n frame #9: 0x0000f1555ef029cc libstdc++.so.6`___lldb_unnamed_symbol_d29b0 + 28\n frame #10: 0x0000f1555ec30398 libc.so.6`___lldb_unnamed_symbol_800c0 + 728\n frame #11: 0x0000f1555ec99e9c libc.so.6`___lldb_unnamed_symbol_e9e90 + 12\n" ``` I don't know why this test fails with the PR, but I don't have time to fix it now, so revert it to unblock CI. The backtrace was ``` frame #0: compute_fibonacci at python_helper.py:7 [synthetic] frame #1: process_data at python_helper.py:16 [synthetic] frame #2: main at python_helper.py:27 [synthetic] frame #3: 0x0000badc2de81358 a.out`thread_func(thread_num=0) at main.cpp:44:13 frame #4: 0x0000badc2de81f9c a.out`void std::__invoke_impl<void, void (*)(int), int>((null)=__invoke_other @ 0x0000f1555ebae74f, __f=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:61:14 frame #5: 0x0000badc2de81f18 a.out`std::__invoke_result<void (*)(int), int>::type std::__invoke<void (*)(int), int>(__fn=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:96:14 frame #6: 0x0000badc2de81ee4 a.out`void std::thread::_invoker<std::tuple<void (*)(int), int>>::_m_invoke<0ul, 1ul>(this=0x0000badc66845eb8, (null)=_index_tuple<0ul, 1ul> @ 0x0000f1555ebae7af) at std_thread.h:259:13 frame #7: 0x0000badc2de81e98 a.out`std::thread::_invoker<std::tuple<void (*)(int), int>>::operator()(this=0x0000badc66845eb8) at std_thread.h:266:11 frame #8: 0x0000badc2de81d70 a.out`std::thread::_state_impl<std::thread::_invoker<std::tuple<void (*)(int), int>>>::_m_run(this=0xffffffffffffffff) at std_thread.h:211:13 frame #9: 0x0000f1555ef029cc libstdc++.so.6`___lldb_unnamed_symbol_d29b0 + 28 frame #10: 0x0000f1555ec30398 libc.so.6`___lldb_unnamed_symbol_800c0 + 728 frame #11: 0x0000f1555ec99e9c libc.so.6`___lldb_unnamed_symbol_e9e90 + 12 ``` This contains 0xffffffffffffffff in frame 8.
addmisol
pushed a commit
that referenced
this pull request
Aug 19, 2026
I see the following
```
anutosh491@Anutoshs-MacBook-Air llvm-project % cat /private/tmp/wasm-f16-select.ll
define <8 x half> @select_v8f16(i1 %cond, <8 x half> %a, <8 x half> %b) {
%result = select i1 %cond, <8 x half> %a, <8 x half> %b
ret <8 x half> %result
}
```
```
anutosh491@Anutoshs-MacBook-Air llvm-project % build-assert/bin/llc \
-mtriple=wasm32-unknown-unknown \
-mattr=+simd128,+fp16 \
-o /dev/null \
/private/tmp/wasm-f16-select.ll
LLVM ERROR: Cannot select: t8: v8f16 = select t12, t4, t6
t12: i32 = and t2, Constant:i32<1>
t2: i32 = WebAssemblyISD::ARGUMENT TargetConstant:i32<0>
t4: v8f16 = WebAssemblyISD::ARGUMENT TargetConstant:i32<1>
t6: v8f16 = WebAssemblyISD::ARGUMENT TargetConstant:i32<2>
In function: select_v8f16
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug.
Stack dump:
0. Program arguments: build-assert/bin/llc -mtriple=wasm32-unknown-unknown -mattr=+simd128,+fp16 -o /dev/null /private/tmp/wasm-f16-select.ll
1. Running pass 'Function Pass Manager' on module '/private/tmp/wasm-f16-select.ll'.
2. Running pass 'WebAssembly Instruction Selection' on function '@select_v8f16'
#0 0x0000000103c6852c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1030e852c)
#1 0x0000000103c66208 llvm::sys::RunSignalHandlers() (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1030e6208)
#2 0x0000000103c69130 SignalHandler(int, __siginfo*, void*) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1030e9130)
#3 0x000000018b5f7744 (/usr/lib/system/libsystem_platform.dylib+0x1804fb744)
#4 0x000000018b5ed8d8 (/usr/lib/system/libsystem_pthread.dylib+0x1804f18d8)
#5 0x000000018b4f4644 (/usr/lib/system/libsystem_c.dylib+0x1803f8644)
#6 0x0000000103bbc0b4 llvm::report_fatal_error(llvm::Twine const&, bool) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x10303c0b4)
#7 0x0000000103af91b8 llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f791b8)
#8 0x0000000103af813c llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int, unsigned char const*) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f7813c)
#9 0x0000000101f66b78 (anonymous namespace)::WebAssemblyDAGToDAGISel::Select(llvm::SDNode*) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1013e6b78)
#10 0x0000000103aee46c llvm::SelectionDAGISel::DoInstructionSelection() (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f6e46c)
#11 0x0000000103aed400 llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f6d400)
#12 0x0000000103aeb4b4 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f6b4b4)
llvm#13 0x0000000103ae8ba8 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f68ba8)
llvm#14 0x0000000103ae6cd8 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f66cd8)
llvm#15 0x0000000102b71d28 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x101ff1d28)
llvm#16 0x0000000103096900 llvm::FPPassManager::runOnFunction(llvm::Function&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102516900)
llvm#17 0x000000010309cc00 llvm::FPPassManager::runOnModule(llvm::Module&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x10251cc00)
llvm#18 0x0000000103097174 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102517174)
llvm#19 0x0000000100b880a4 main (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1000080a4)
llvm#20 0x000000018b22fe00
zsh: abort build-assert/bin/llc -mtriple=wasm32-unknown-unknown -mattr=+simd128,+fp16 -o
```
addmisol
pushed a commit
that referenced
this pull request
Aug 25, 2026
`Scalar::operator>>=` and `Scalar::ExtractBitfield` pass their shift
amount straight to `APSInt::operator>>=(unsigned)`, which asserts when
the
amount exceeds the operand's bit width:
```
Assertion failed: (ShiftAmt <= BitWidth && "Invalid shift amount"),
function ashrInPlace, file APInt.h, line 842.
#7 llvm::APInt::ashrInPlace(unsigned int)
#8 lldb_private::Scalar::ExtractBitfield(unsigned int, unsigned int)
#9 lldb_private::DWARFExpression::Evaluate(...)
#11 LLVMFuzzerTestOneInput
```
The DWARF expression evaluator reaches both from untrusted operands
(`DW_OP_shra` shift counts and `DW_OP_bit_piece` bit offsets), so
`lldb-dwarf-expression-fuzzer` aborts the process on a shift wider than
the
value. A shift amount at or beyond the width is well-defined as a sign
or
zero fill, so clamp it rather than reject it. `operator>>=` uses
`getLimitedValue`, which also avoids the `getZExtValue` assertion when
the
amount itself needs more than 64 bits.
`operator<<=` and `ShiftRightLogical` (`DW_OP_shl` and `DW_OP_shr`)
already
pass an `APInt` amount, and those `APInt` overloads clamp internally the
same
way, so they need no change.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
addmisol
pushed a commit
that referenced
this pull request
Aug 28, 2026
Introduced by llvm#213356 ``` SanitizerError AddressSanitizer: 2760 byte(s) leaked in 15 allocation(s). Details ================================================================= ==6162==ERROR: LeakSanitizer: detected memory leaks Direct leak of 1472 byte(s) in 8 object(s) allocated from: ... #8 0x7f4d08980c00 in ObjectFileELF::CreateSections(lldb_private::SectionList&) lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2168:28 #9 0x7f4d085c5651 in lldb_private::Module::GetSectionList() lldb/source/Core/Module.cpp:1226:17 #10 0x7f4d08af4f6f in lldb_private::plugin::dwarf::SymbolFileDWARF::SymbolFileDWARF(std::__u::shared_ptr<lldb_private::ObjectFile>, lldb_private::SectionList*) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:490:44 #11 0x7f4d08af331e in lldb_private::plugin::dwarf::SymbolFileDWARF::CreateInstance(std::__u::shared_ptr<lldb_private::ObjectFile>) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:347:14 #12 0x7f4d08cc36af in lldb_private::SymbolFile::FindPlugin(std::__u::shared_ptr<lldb_private::ObjectFile>) lldb/source/Symbol/SymbolFile.cpp:64:51 llvm#13 0x7f4d08cd2dc9 in lldb_private::SymbolVendor::AddSymbolFileRepresentation(std::__u::shared_ptr<lldb_private::ObjectFile> const&) lldb/source/Symbol/SymbolVendor.cpp:65:27 llvm#14 0x7f4d08cd2ba0 in lldb_private::SymbolVendor::FindPlugin(std::__u::shared_ptr<lldb_private::Module> const&, lldb_private::Stream*) lldb/source/Symbol/SymbolVendor.cpp:51:16 llvm#15 0x7f4d085c1d9f in lldb_private::Module::GetSymbolFile(bool, lldb_private::Stream*) lldb/source/Core/Module.cpp:991:13 llvm#16 0x7f50eadaf896 in lldb_private::YAMLModuleTester::YAMLModuleTester(llvm::StringRef, unsigned long) lldb/unittests/TestingSupport/Symbol/YAMLModuleTester.cpp:24:61 llvm#17 0x7f50eb471eea in DWARFASTParserClangYAMLTester lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp:53:9 llvm#18 0x7f50eb471eea in DWARFASTParserClangTests_TestRustVariantMember_Test::TestBody() lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp:2128:33 ... Direct leak of 1288 byte(s) in 7 object(s) allocated from: ... #8 0x7f4d08980c00 in ObjectFileELF::CreateSections(lldb_private::SectionList&) lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2168:28 #9 0x7f4d085c5651 in lldb_private::Module::GetSectionList() lldb/source/Core/Module.cpp:1226:17 #10 0x7f4d08af4f6f in lldb_private::plugin::dwarf::SymbolFileDWARF::SymbolFileDWARF(std::__u::shared_ptr<lldb_private::ObjectFile>, lldb_private::SectionList*) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:490:44 #11 0x7f4d08af331e in lldb_private::plugin::dwarf::SymbolFileDWARF::CreateInstance(std::__u::shared_ptr<lldb_private::ObjectFile>) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:347:14 #12 0x7f4d08cc36af in lldb_private::SymbolFile::FindPlugin(std::__u::shared_ptr<lldb_private::ObjectFile>) lldb/source/Symbol/SymbolFile.cpp:64:51 llvm#13 0x7f4d08cd2dc9 in lldb_private::SymbolVendor::AddSymbolFileRepresentation(std::__u::shared_ptr<lldb_private::ObjectFile> const&) lldb/source/Symbol/SymbolVendor.cpp:65:27 llvm#14 0x7f4d08cd2ba0 in lldb_private::SymbolVendor::FindPlugin(std::__u::shared_ptr<lldb_private::Module> const&, lldb_private::Stream*) lldb/source/Symbol/SymbolVendor.cpp:51:16 llvm#15 0x7f4d085c1d9f in lldb_private::Module::GetSymbolFile(bool, lldb_private::Stream*) lldb/source/Core/Module.cpp:991:13 llvm#16 0x7f50eadaf896 in lldb_private::YAMLModuleTester::YAMLModuleTester(llvm::StringRef, unsigned long) lldb/unittests/TestingSupport/Symbol/YAMLModuleTester.cpp:24:61 llvm#17 0x7f50eb461ba2 in DWARFASTParserClangYAMLTester lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp:53:9 llvm#18 0x7f50eb461ba2 in DWARFASTParserClangTests_TestDefaultTemplateParamParsing_Test::TestBody() lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp:587:33 ... ```
addmisol
force-pushed
the
users/addmisol/remove_libcall_avaibility_checks
branch
from
September 2, 2026 12:33
d4ca47c to
e0052fd
Compare
Reviewers: Pull Request: llvm#222141
…2135) * Add support for POSIX-specified `_SC_GETGR_R_SIZE_MAX` and `_SC_GETPW_R_SIZE_MAX` constants used as arguments to `sysconf` function; * Return -1 for these values - they provide "initial size" for user-supplied buffers passed to `getgr*` and `getpw*` functions, but there's no real maximum limit imposed by the LLVM-libc implementation, and user might provide a size they can, and rely on `ERANGE` return values if the chosen size ended up being too small for pwd/group entries. * Add unit test coverage, and update the unit test to use proxy headers instead of system-provided `<unistd.h>`. Also, properly test errno values returned by `sysconf`. This fixes one of the remaining blockers for building Clang against LLVM-libc (llvm#97191)
The backend:NVPTX labeler rules are anchored to the llvm/ subtree (every glob starts with llvm/**), so NVPTX/NVVM-related files elsewhere in the tree never get the label. In particular, ClangIR's lowering under clang/ touches NVPTX code but the PR is not tagged backend:NVPTX. This drops the llvm/ prefix so the patterns match anywhere in the tree.
…vm#220165) This optimizes MachineInstr::insert by copying trailing operands first and then removing them from the end. This avoids repeatedly shifting the remaining operands, reducing the operation from quadratic to linear time without changing behavior.
…per, NFC (llvm#221987) Extract the "keep the most specific match status" comparison in matchAndEmitInstruction into an atLeastAsSpecific() lambda ranking Match_MnemonicFail < Match_InvalidOperand < Match_MissingFeature. No functional change.
…ective to use new value which is created. (llvm#212361) Limitation: Right now, added a TODO warning about lowering of variable with SAVE attribute or named COMMON block are not completely supported end to end. So a warning is emitted.
Collect predecessors and successors up front in reassociateBlocks. Currently NFC, but makes it more robust in the future, because it also correctly handles self-edges.
…llvm#222149) Factor logic to helper function, so it can be re-used in follow-up changes.
Enable strict property assembly format mode for the Transform dialect and its extensions. Bind transform operation options directly in declarative assembly formats so strict parsing does not rely on fallback handling. Update transform dialect, extension, and transform-driven tests to use the direct property spelling. Assisted-by: Codex
…traction (llvm#217341) fixes llvm#216804 ## Summary This PR fixes pointer subtraction between pointers with different but overlapping address spaces (e.g., `private` and `generic` in OpenCL). Previously, when subtracting a private pointer from a generic pointer on AMDGPU: - The private pointer (AS5, 32-bit) was converted directly to i32 via `ptrtoaddr` - The generic pointer (AS0, 64-bit) was converted to i64 via `ptrtoaddr` - This resulted in incorrect comparison of 32-bit vs 64-bit values Now, pointers are first promoted to the composite (superset) address space using `addrspacecast` before the subtraction. This mirrors how the conditional operator (`?:`) already handles mixed address space pointers. ## Test plan - `clang/test/CodeGenOpenCL/size_t.cl` updated and passes - Verified generated IR shows correct `addrspacecast` before `ptrtoaddr` for AMDGCN and SPIR targets --------- Signed-off-by: addmisol <addmisol9@gmail.com>
…st (llvm#222054) Up until now if trySchedule() failed, the ready instructions would be removed from the ready list for no good reason. This patch fixes this and reinserts the deferred nodes to the ready list. This also helps reduce the scan for ready instructions in trySchedule().
This PR exposes a target `@linux_uapi//:linux_uapi_headers` that points to a local directory configured by the `LINUX_UAPI_INCLUDE_DIR` environment variable. Linux UAPI headers are required to support libc's `FULL_BUILD` configuration, which uses `-nostdlibinc` and thus requires a copy of linux kernel headers.
This PR defines a flag `--@llvm-project//libc:build_mode` that configures LLVM-libc to build with full-build flags. This is only compatible with clang at the moment, since it relies on the `-nostdlibinc` flag. This PR contains the logic for LLVM-libc full build in Bazel. A largely AI generated follow-on PR has `libc/BUILD.bazel` changes for building libc targets in full-build mode: llvm#218993.
…m#214868) This is a mechanical change generated by `utils/docs/remove_page_tocs.py`. In case of conflicts, which are likely, due to the ongoing markdown migration (llvm#201242), this script can be re-run to regenerate the change. I'm creating a separate PR for it to minimize the diff on the functional changes for the furo PR.
This change moves the static assets into utils/docs/llvm_sphinx, and centralizes some of the furo theme logic there. It then configures furo from clang/docs/conf.py and clang/analyzer/docs/conf.py. The temporary preview for the site is here: https://clangdocs.staging.reidkleckner.dev/after/clang/docs/ The RFC is here: https://discourse.llvm.org/t/rfc-use-furo-theme-for-clang-docs/91505/7 I plan to wait until at least Aug 13 before merging to gather more feedback.
* Provide the values for `AI_*` flags that are passed in `ai_flags` field of `addrinfo` structure to `getaddrinfo` calls. * Reference some of those constant in a placeholder unittest. Rename it to `getaddrinfo_test` to clarify its scope (we'll likely be using different test files for other netdb.h functions).
…llvm#221112) We falsely split CBB/CBH instructions by explicitly extending the second register operand instead of the first one, leading to the following, wrong codegen: cbh $wn, $wm, cc, trgt => sxth $wt, $wm cmp $wn, $wt, cc, sxth Correct is cbh $wn, $wm, cc, trgt => sxth $wt, $wn cmp $wt, $wm, cc, sxth since cmp with extended register extends it's second, not its first operand.
Internal communicating functions `optional::__get` can be superseded by either `value`, `operator*()`, or direct use of data member. Even though `value()` is checked, checks are already performed before internal calls to it, so compilers should be able to remove duplicated checks. It is intended to use `opt.value()` instead of `*opt` to avoid undesired argument-dependent lookup.
Enable strict property assembly format mode for the EmitC dialect. Spell call metadata directly in the affected declarative assembly formats and drop unneeded property dictionaries from formats that already cover their inherent attributes. Refresh EmitC tests and related C++ target checks so call properties use direct syntax while ordinary attributes remain in attr-dict. Assisted-by: Codex
The two tests libFuzzer-x86-64-default-Linux::fork_corpus_groups.test and libFuzzer-x86-64-default-Linux::fork.test have started being flaky again on two of my bots, so bumping up the rss limit in the test which temporarily solved the issue back in llvm#204701. See comment in llvm#222187 for links to the bots and recent failures.
Now that we're trying to build by default, we actually have to be able to build on other buildbots! But since we still don't have the ABI/target stuff for non linux, we need to make sure our tests don't hit that.
…lvm#220726) Fixes warnings: ``` SampleProfWriter.cpp:804:12: note: use reference type 'std::pair<llvm::sampleprof::FunctionId, unsigned long> const &' to prevent copying 804 | for (const auto [TypeName, Count] : *Map) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | & SampleProfWriter.cpp:829:12: note: use reference type 'std::pair<llvm::sampleprof::FunctionId, unsigned long> const &' to prevent copying 829 | for (const auto [TypeId, Count] : *Map) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ | & ```
…s` (llvm#221036) Fixes llvm#66331. Stop countring the verification run in TryDetectingAMemoryLeak() as part of TotalNumberOfRuns, as the number of executed units could exceed -runs=N.
Enable strict property assembly format mode for the LLVM dialect. Bind LLVM operation properties directly in declarative assembly formats so strict parsing does not rely on fallback handling. Update LLVM dialect, target, and conversion tests to use the direct property spelling. Assisted-by: Codex
Enable MLIR implicitly for ClangIR without attaching its unrelated tools and test suite to the aggregate build. An explicit MLIR selection retains its normal behavior. Add MLIR after all Clang consumers enable Clang, so CIR also works when Clang is enabled for LLDB. Package the required MLIR libraries through Clang's existing exports and LLVM's distribution policy. Register dependency library and header install components and honor toolchain-only installations. When Clang is itself an implicit Flang dependency, let Flang package the required targets. Keep MLIR test support available for CIR and retain the standalone ClangIR restriction. Leave MLIR disabled when CIR is disabled. Assisted-by: Codex
…ribute APIs (llvm#218913) Migrate the Affine, Arith, Arm vector, SCF, and Vector dialect families and related conversions to explicit discardable or typed attribute access. Assisted-by: Codex
Fixes llvm#194739 and fixes llvm#194743 This PR implements Texture3D and RWTexture3D and adds+modifies tests for the two types. Assisted by: Claude Opus 5 --------- Co-authored-by: Finn Plummer <mail@inbelic.dev>
These tests appear to be passing/deleted as of 9/9/26.
Follow the new amdgcn system so we don't have to carry 2 different forms of this infrastructure. Co-authored-by: Claude (Opus 4.8) <noreply@anthropic.com>
Tosa specification changes in arm/tosa-specification#78
Now that we're trying to build by default, we actually have to be able to build on other buildbots! But since we still don't have the ABI/target stuff for non linux, we need to make sure our tests don't hit that. Tests that execute 'clang' in some way are given a triple, ones that are on .cir files we just add a 'requires'. Some day we should be able to remove those, but it'll require us to add the cxxabi/etc for windows.
) **Problem** When an invalid 'gang dim' value is used in `CheckGangDimExpr`, the function prints the value into the diagnostic message by calling `getExtValue`. This function asserts on values that can't fit into a signed integer. **Solution** `APSInt` has a `<<` operator anyway so just use that. The fix causes the message to print with the following formatting: ``` test.cpp:5:40: error: argument to 'gang' clause dimension must be 1, 2, or 3: evaluated to 18'446'744'073'709'551'574 5 | #pragma acc routine(S::foo) gang(dim : S::foo()) | ^ 1 warning and 1 error generated. ``` Fixes llvm#221418
This resolves llvm#181730: fixes a missing `-Wconstant-conversion` diagnostic for `signed char` array initialization. Before this change, Clang warned for `signed char foo = 255;` but did not warn for `signed char bar[] = {255};`. The warning suppression helper did not distinguish between `char`, `unsigned char`, and `signed char` in brace-initialized arrays. Now it does.
…llvm#221646) The `llvm.spv.resource.handlefrombinding` intrinsic stores its binding operands in the order (DescriptorSet, BindingNo, ...). The `llvm.spv.resource.counterhandlefrombinding` intrinsic should use the same order. The `llvm.spv.resource.counterhandlefrombinding` intrinsic is currently emitted only by the `SPIRVLegalizeImplicitBinding` pass. The pass previously built its operands in the wrong order, and the instruction selector repeated the same inversion when emitting decorations. This change makes the operand order consistent with `llvm.spv.resource.handlefrombinding`. Test update closes a coverage gap - there were no tests for explicit `llvm.spv.resource.counterhandlefrombinding` calls. Assisted by GPT-5.6 Sol.
…m#221992) Add legalizer rules so llvm.lrint/llrint lower to fcvt.{w,l}.{h,s,d} with FRM_DYN, mirroring the existing G_LROUND/G_LLROUND handling.
Adds CoroResumeOp, CoroDestroyOp, and CoroDoneOp, representing llvm.coro.resume, llvm.coro.destroy, and llvm.coro.done respectively.
Add some i16 and i64 tests.
Fold the COFF layout pass into writeCOFF so the ContiguousBlobAccumulator tracks section offsets and sizes as data is written. Reserve and fill in the optional header and section table once the section layout is final. This is almost NFC, except when the output size exceeds the limit.
WASI defines `off_t` as 64-bit signed integers to support files larger than 2 GiB. https://github.com/WebAssembly/wasi-libc/blob/wasi-sdk-25/libc-bottom-half/headers/public/__typedef_off_t.h
Handles it the same way as EPOLL_CTL_ADD
…#221552) Fixes llvm#65312. Floating point rounding could push the result above `max`, or even overflow to infinity, so we clamp it instead. --------- Co-authored-by: Dan Blackwell <danblackwell95@gmail.com>
…lvm#222463) There is no opsel support for these instructions, and thus we do not have to manipulate opsel at MC layer. As a result, isPackedSingleSGPR64BitIns is currently only used before pseudo-expansion. So we remove MC instruction check inside.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 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.
No description provided.