[SyncBots] Integrate LLVM#9
Closed
WuXintong123 wants to merge 8 commits into
Closed
Conversation
…opsrun test (#4) Fix three issues found on RISC-V: 1. Fix use-after-free in block walk (Visitors.h) When walking blocks with ReverseDominanceIterator, the Traversal object returned by Iterator::makeIterable(region) was passed as a temporary directly to llvm::make_early_inc_range(). The temporary was destroyed at the end of the full expression while iterators from make_early_inc_range still referenced it. Store the result in a local variable with auto&& to extend the lifetime of the temporary and bind lvalue references for ForwardIterator. 2. Fix Shape dialect CstrBroadcastableOp fold and cast canonicalization Extend getShapeVec to look through tensor.cast operations so that folds can resolve shapes behind casts inserted by earlier canonicalization passes (e.g., ShapeOfOpToConstShapeOp). Add a new fold check in CstrBroadcastableOp::fold that recognizes broadcasting is trivially valid when at most one operand is non-scalar (resolved via getShapeVec). Rewrite CanonicalizeCastExtentTensorOperandsPattern to use modifyOpInPlace instead of replaceOpWithNewOp to avoid issues with op builder template instantiation. 3. Fix opsrun.py test invocation pattern for multithreaded_tests.py Convert direct test_foo() calls to run(test_foo) so that copy_and_update in multithreaded_tests.py properly strips them during import, preventing JIT execution at module load time which crashes on RISC-V due to R_RISCV_HI20 relocation range limits.
WuXintong123
pushed a commit
that referenced
this pull request
May 14, 2026
llvm#183506 revealed a pre-existing use-after-scope in createInstrInfo (MSan bot: https://lab.llvm.org/buildbot/#/builders/164/builds/21562 [*]). This patch fixes the issue by changing the stack-allocated AArch64Subtarget (which goes out of scope once createInstrInfo() returns) into heap-allocated, allowing it to be safely stored in the returned AArch64InstrInfo. ----- [*] WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x55555666fabd in llvm::AArch64InstrInfo::getInstSizeInBytes(llvm::MachineInstr const&) const /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp:247:5 ... /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/unittests/Target/AArch64/InstSizes.cpp:85:3 #9 0x555556508559 in InstSizes_MOVaddrTagged_Test::TestBody() /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/unittests/Target/AArch64/InstSizes.cpp:301:3 ... Member fields were destroyed #0 0x555556498a1d in __sanitizer_dtor_callback_fields /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1074:5 #1 0x5555564fbda6 in ~Triple /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/include/llvm/TargetParser/Triple.h:348:12 #2 0x5555564fbda6 in ~Triple /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/include/llvm/TargetParser/Triple.h:47:7 #3 0x5555564fbda6 in llvm::AArch64Subtarget::~AArch64Subtarget() /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/lib/Target/AArch64/AArch64Subtarget.h:38:7 #4 0x555556503396 in (anonymous namespace)::createInstrInfo(llvm::TargetMachine*) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/unittests/Target/AArch64/InstSizes.cpp:38:1 #5 0x5555565084cb in InstSizes_MOVaddrTagged_Test::TestBody() /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/unittests/Target/AArch64/InstSizes.cpp:299:42
WuXintong123
pushed a commit
that referenced
this pull request
Jun 7, 2026
I recently noticed LLDB crash during execution of `script print(lldb.SBDebugger().GetBroadcaster().GetName())` command: ``` PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/sergei/llvm-project/build/bin/lldb-dap #0 0x000062735c3403d2 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/sergei/llvm-project/build/bin/lldb-dap+0x7c3d2) #1 0x000062735c33d7ec llvm::sys::RunSignalHandlers() (/home/sergei/llvm-project/build/bin/lldb-dap+0x797ec) #2 0x000062735c33d94c SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0 #3 0x00007eaa6aa45330 (/lib/x86_64-linux-gnu/libc.so.6+0x45330) #4 0x00007eaa6bb0c092 lldb::SBBroadcaster::GetName() const (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x90c092) #5 0x00007eaa6bcb9a5d _wrap_SBBroadcaster_GetName LLDBWrapPython.cpp:0:0 #6 0x00007eaa6a1df5f5 (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x1df5f5) #7 0x00007eaa6a182b2c PyObject_Vectorcall (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x182b2c) #8 0x00007eaa6a11d5ee _PyEval_EvalFrameDefault (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x11d5ee) #9 0x00007eaa6a2a091f PyEval_EvalCode (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x2a091f) #10 0x00007eaa6a29c8b0 (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x29c8b0) #11 0x00007eaa6a11fbd3 _PyEval_EvalFrameDefault (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x11fbd3) #12 0x00007eaa6c4891b7 lldb_private::ScriptInterpreterPythonImpl::ExecuteOneLine(llvm::StringRef, lldb_private::CommandReturnObject*, lldb_private::ExecuteScriptOptions const&) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x12891b7) #13 0x00007eaa70326ff5 CommandObjectScriptingRun::DoExecute(llvm::StringRef, lldb_private::CommandReturnObject&) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x5126ff5) #14 0x00007eaa6bee3739 lldb_private::CommandObjectRaw::Execute(char const*, lldb_private::CommandReturnObject&) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0xce3739) #15 0x00007eaa6bede09a lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, bool) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0xcde09a) #16 0x00007eaa6bb0f0f8 lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBExecutionContext&, lldb::SBCommandReturnObject&, bool) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x90f0f8) #17 0x00007eaa6bb0f265 lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBCommandReturnObject&, bool) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x90f265) #18 0x000062735c3707f3 lldb_dap::RunLLDBCommands[abi:cxx11](lldb::SBDebugger&, lldb::SBMutex, llvm::StringRef, llvm::ArrayRef<lldb_dap::protocol::String> const&, bool&, bool, bool) (/home/sergei/llvm-project/build/bin/lldb-dap+0xac7f3) #19 0x000062735c3a8019 lldb_dap::EvaluateRequestHandler::Run(lldb_dap::protocol::EvaluateArguments const&) const (/home/sergei/llvm-project/build/bin/lldb-dap+0xe4019) #20 0x000062735c3aba78 lldb_dap::RequestHandler<lldb_dap::protocol::EvaluateArguments, llvm::Expected<lldb_dap::protocol::EvaluateResponseBody>>::operator()(lldb_dap::protocol::Request const&) const (/home/sergei/llvm-project/build/bin/lldb-dap+0xe7a78) #21 0x000062735c3ce1bf lldb_dap::BaseRequestHandler::Run(lldb_dap::protocol::Request const&) (/home/sergei/llvm-project/build/bin/lldb-dap+0x10a1bf) #22 0x000062735c3577e7 lldb_dap::DAP::HandleObject(std::variant<lldb_dap::protocol::Request, lldb_dap::protocol::Response, lldb_dap::protocol::Event> const&) (/home/sergei/llvm-project/build/bin/lldb-dap+0x937e7) llvm#23 0x000062735c358705 lldb_dap::DAP::Loop() (/home/sergei/llvm-project/build/bin/lldb-dap+0x94705) llvm#24 0x000062735c2ed0c7 main (/home/sergei/llvm-project/build/bin/lldb-dap+0x290c7) llvm#25 0x00007eaa6aa2a1ca __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3 ``` As far as I understand default constuctors should be covered by fuzzing tests, so I don't know how to write test for that patch.
WuXintong123
pushed a commit
that referenced
this pull request
Jun 12, 2026
…2769) `KnownBits::add()` with `SelfAdd=true` lowers `X+X` to `shl(X, 1)` using a fixed 8-bit shift amount: ```cpp KnownBits Amt = KnownBits::makeConstant(APInt(8, 1)); return KnownBits::shl(LHS, Amt, NUW, NSW, /*ShAmtNonZero=*/true); ``` The comment there claims the shift-amount bitwidth is independent of the source bitwidth, but that is not true: `shl()`'s `getMaxShiftAmount()` extracts `Log2_32(BitWidth)` bits from the shift amount's max value when `BitWidth` is a power of two: ```cpp static unsigned getMaxShiftAmount(const APInt &MaxValue, unsigned BitWidth) { if (isPowerOf2_32(BitWidth)) return MaxValue.extractBitsAsZExtValue(Log2_32(BitWidth), 0); ... } ``` For source widths `>= 512`, `Log2_32(BitWidth) >= 9`, so extracting that many bits from the 8-bit shift amount trips the assertion in `APInt::extractBitsAsZExtValue`: ``` Assertion `bitPosition < BitWidth && (numBits + bitPosition) <= BitWidth && "Illegal bit extraction"' failed. #9 llvm::APInt::extractBitsAsZExtValue(unsigned int, unsigned int) const #10 llvm::KnownBits::shl(...) #11 llvm::KnownBits::add(...) ``` (256 is the boundary that still works: `Log2_32(256) == 8`, extracting exactly 8 bits from the 8-bit amount.) Fix: make the shift-amount bitwidth match the source bitwidth so the extraction is always in bounds. The `SelfAdd` path was introduced in llvm#188078. Found via fuzzing. Adds a `SelfAddWide` regression test covering widths 256/512/1024.
WuXintong123
pushed a commit
that referenced
this pull request
Jul 1, 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.
WuXintong123
pushed a commit
that referenced
this pull request
Jul 6, 2026
A `breakpoint set -P <class>` with an invalid-UTF-8 class name crashes lldb with `EXC_BAD_ACCESS`. The class name is passed through unmodified, so the byte sequence `\xd0p` (an incomplete two-byte UTF-8 sequence) reaches the Python layer: ``` ./bin/lldb -b -o $'breakpoint set -P \xd0p -f main.cpp' ./bin/lldb ... PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ Stack dump: #4 PythonDictionary::GetItem(PythonObject const&) const #6 PythonDictionary::GetItemForKey(PythonObject const&) const #7 PythonObject::ResolveNameWithDictionary(StringRef, PythonDictionary const&) #9 ScriptedPythonInterface::CreatePluginObject<...>(...) ``` `ResolveNameWithDictionary` builds a `PythonString` from the class name and looks it up in the module dictionary. When the name is not valid UTF-8, `PyUnicode_FromStringAndSize` returns `NULL`, so the `PythonString` is left with `m_py_obj == NULL`. `GetItemForKey` forwards that object to `GetItem`, which passed the `NULL` `PyObject *` straight to `PyDict_GetItemWithError`. Debugging the crashing lldb under lldb shows the `NULL` key arriving in `GetItem`: ``` (lldb) break set -n lldb_private::python::PythonDictionary::GetItem (lldb) run --no-use-colors -b -s /tmp/bp_cmds.txt * stop reason = breakpoint 1.1 (lldb) up (lldb) frame variable key.m_py_obj (PyObject *) key.m_py_obj = nullptr ``` Continuing lands on the dereference of that `NULL` inside CPython: ``` (lldb) continue * stop reason = EXC_BAD_ACCESS (code=1, address=0x8) frame #0: PyDict_GetItemWithError + 40 -> ldr x8, [x1, #0x8] ``` `x1` holds the key argument, which is `NULL`, so reading the type field at offset `0x8` faults at address `0x8`. `GetItem` already guards against an invalid dictionary (`!IsValid()`); extend that guard to reject an invalid key as well and return `nullDeref()`. `GetItemForKey` consumes the error and returns an empty `PythonObject`, so existing callers such as `ResolveNameWithDictionary` keep working and the breakpoint command now fails cleanly instead of crashing. This was found by `lldb-commandinterpreter-fuzzer`. Adds `PythonDataObjectsTest.TestPythonDictionaryGetItemWithInvalidKey`, which feeds an invalid-UTF-8 key to `GetItem`. Without the fix the test dereferences the `NULL` key and crashes (`SIGSEGV`).
WuXintong123
pushed a commit
that referenced
this pull request
Jul 8, 2026
…long encodings (llvm#205907) When a (signed or unsigned) LEB128 value is encoded with extra trailing bytes that only carry zero- or sign-extension, the decode loop could keep running with the shift amount at 64 or beyond and then evaluate `Slice << Shift`, which is undefined behavior for a 64-bit type. The DWARF expression parser feeds attacker-controlled LEB128 operands (such as `DW_OP_bregN` / `DW_OP_constu`) through `DataExtractor::getULEB128` / `getSLEB128`, so the `lldb-dwarf-expression-fuzzer` reaches this under UBSan. The unsigned case: ``` LEB128.h:152:20: runtime error: shift exponent 70 is too large for 64-bit type 'uint64_t' (aka 'unsigned long long') #0 llvm::decodeULEB128(...) LEB128.h:152 #1 getLEB128<unsigned long long>(...) DataExtractor.cpp:227 #2 llvm::DataExtractor::getULEB128(...) DataExtractor.cpp:241 #3 llvm::DWARFExpression::Operation::extract(...) DWARFExpression.cpp:218 #7 lldb_private::DWARFExpression::Evaluate(...) DWARFExpression.cpp:1333 #9 LLVMFuzzerTestOneInput lldb-dwarf-expression-fuzzer.cpp:83 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior LEB128.h:152:20 ``` and the signed case, reached the same way: ``` LEB128.h:190:20: runtime error: shift exponent 70 is too large for 64-bit type 'uint64_t' (aka 'unsigned long long') #0 llvm::decodeSLEB128(...) LEB128.h:190 #1 getLEB128<long long>(...) DataExtractor.cpp:227 #2 llvm::DataExtractor::getSLEB128(...) DataExtractor.cpp:245 #3 llvm::DWARFExpression::Operation::extract(...) DWARFExpression.cpp:216 #7 lldb_private::DWARFExpression::Evaluate(...) DWARFExpression.cpp:1333 ``` The existing range checks already guarantee that once `Shift` reaches 64 the remaining bytes are pure extension and contribute nothing to the result, so skip the accumulating shift in that case. Decoded values are unchanged for all well-formed inputs. Adds overlong-encoding regression cases to `LEB128Test`. Without the fix the signed case is the UBSan diagnostic above in a sanitizer build, and in a normal build the unsigned case also decodes to the wrong value (the overlong `1` decodes as `11`).
WuXintong123
pushed a commit
that referenced
this pull request
Jul 21, 2026
…builtin (llvm#210524) ## Summary Fix an assertion failure when Clang classifies a built-in call with type-dependent arguments before template instantiation, e.g., while deducing an `auto` non-type template parameter: For example: ```cpp template <auto> struct S {}; template <typename T> using Alias = S<__builtin_constant_p(T::x)>; ``` ``` Assertion failed: (isa<T>(CanonicalType)), function castAs, file TypeBase.h, line 9349. #9 clang::Type::castAs<clang::FunctionType>() const #10 clang::CallExpr::getCallReturnType(clang::ASTContext const&) const #11 ClassifyInternal(clang::ASTContext&, clang::Expr const*) #12 clang::Expr::ClassifyImpl(clang::ASTContext&, clang::SourceLocation*) const #13 clang::Sema::DeduceAutoType(...) #14 clang::Sema::CheckTemplateArgument(...) ``` ## Cause Built-in references initially have the BuiltinFn placeholder type. For a non-dependent call, `BuildResolvedCallExpr()` applies `CK_BuiltinFnToFnPtr`, converting the callee to its function-pointer type. When a call has type-dependent arguments, `BuildCallExpr()` postpones semantic analysis until instantiation. The callee, therefore, retains its BuiltinFn placeholder type. Deducing the auto non-type template parameter classifies the dependent call through `Expr::ClassifyImpl()`. This calls `CallExpr::getCallReturnType()`, which previously did not handle BuiltinFn and attempted to cast the placeholder to FunctionType, triggering an assertion. The issue also affects ordinary builtins such as `__builtin_ffs` and is not specific to` __builtin_constant_p`. ## Fix Handle `BuiltinFn` alongside the dependent and `Overload` callee cases in `CallExpr::getCallReturnType()` and return `DependentTy`. This matches the type `BuildCallExpr()` gives the `CallExpr` itself, so `getCallReturnType()` and `getType()` now agree on such calls. Built-in resolution and built-in-specific type checking still occur as usual during template instantiation. Added coverage for dependent calls and successful instantiation of `__builtin_constant_p` and `__builtin_ffs`, a non-dependent control case, and getCallReturnType() for a BuiltinFn callee.
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
3 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.