[ci] Run ci job for riscv branch#11
Merged
Merged
Conversation
WuXintong123
pushed a commit
that referenced
this pull request
May 29, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 30, 2026
WuXintong123
pushed a commit
that referenced
this pull request
May 31, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 1, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 1, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 3, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 4, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 4, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 6, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 7, 2026
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 8, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 9, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 10, 2026
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
Jun 13, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 13, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 14, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 16, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 17, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 18, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 19, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 20, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 21, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 21, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 23, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 23, 2026
On targets where `size_t` is narrower than 64 bits (e.g. `i686`), CIR
codegen for `sizeof`/`alignof`/`__builtin_vectorelements` crashes with a
type/value bitwidth mismatch.
The result of these expressions is `size_t`, but the emitted integer
constant was built with a hardcoded 64-bit type. `EvaluateKnownConstInt`
returns an `APSInt` with the width of the AST result type (32 bits on
this target), so it no longer matches the `IntAttr`'s type and trips the
`IntAttr` verifier.
### How to Reproduce
```c++
using size_t = decltype(sizeof(int));
size_t size_of_int() { return sizeof(int); }
clang -cc1 -std=c++20 -triple i686-unknown-linux-gnu -fclangir \
-emit-cir test.cpp -o test.cir
error: type and value bitwidth mismatch: 64 != 32
clang: mlir/include/mlir/IR/StorageUniquerSupport.h:180:
... Assertion `succeeded(ConcreteT::verifyInvariants(...))' failed.
#11 cir::IntAttr::get(mlir::Type, llvm::APInt const&)
#12 ScalarExprEmitter::VisitUnaryExprOrTypeTraitExpr(...)
#13 CIRGenFunction::emitScalarExpr(...)
```
### Fix
Form the IntAttr using the converted AST result type (convertType(e->getType())) instead of a hardcoded 64-bit type, matching classic codegen. The same path covers the fixed-vector __builtin_vectorelements case.
WuXintong123
pushed a commit
that referenced
this pull request
Jun 24, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 25, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 26, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jun 29, 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.
WuXintong123
pushed a commit
that referenced
this pull request
Jun 30, 2026
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 1, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 1, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 2, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 3, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 4, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 5, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 6, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 8, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 8, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 13, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 13, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 14, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 16, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 17, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 18, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 19, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 20, 2026
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.
WuXintong123
pushed a commit
that referenced
this pull request
Jul 21, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 22, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 23, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 24, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 25, 2026
WuXintong123
pushed a commit
that referenced
this pull request
Jul 26, 2026
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
1 participant
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.