Skip to content

Test#7

Open
lukel97 wants to merge 1 commit into
mainfrom
test-suite-workflow-test-pr
Open

Test#7
lukel97 wants to merge 1 commit into
mainfrom
test-suite-workflow-test-pr

Conversation

@lukel97

@lukel97 lukel97 commented Apr 7, 2026

Copy link
Copy Markdown
Owner

No description provided.

@lukel97

lukel97 commented Apr 7, 2026

Copy link
Copy Markdown
Owner Author

/test-suite

@github-actions

github-actions Bot commented Apr 7, 2026

Copy link
Copy Markdown

Failed to get test-suite diff from ...: https://github.com/lukel97/llvm-project/actions/runs/24074778096

@lukel97

lukel97 commented Apr 7, 2026

Copy link
Copy Markdown
Owner Author

/test-suite

@github-actions

github-actions Bot commented Apr 7, 2026

Copy link
Copy Markdown

test-suite diff from 399653c...61b18e9: https://github.com/lukel97/llvm-project/actions/runs/24074885036/artifacts/6304114065

@lukel97

lukel97 commented Apr 7, 2026

Copy link
Copy Markdown
Owner Author

/test-suite

@github-actions

github-actions Bot commented Apr 7, 2026

Copy link
Copy Markdown

test-suite diff from 399653c...61b18e9: https://github.com/lukel97/llvm-project/actions/runs/24085284600/artifacts/6308848214

lukel97 pushed a commit that referenced this pull request Apr 16, 2026
@GeorgeHuyubo George Hu
[lldb] Fix stale Symbol pointer crash in statusline after 'target sym…
02fdc8f 
…bols add' (llvm#188377)

Context: 
lldb might crash when running to a debuggee crashing state and do a
target symbols add command.
Backtrace: 
```
 #0 0x000055ca6790dc65 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/hyubo/osmeta/external/llvm-project/llvm/lib/Support/Unix/Signals.inc:848:11
 #1 0x000055ca6790e434 PrintStackTraceSignalHandler(void*) /home/hyubo/osmeta/external/llvm-project/llvm/lib/Support/Unix/Signals.inc:931:1
 #2 0x000055ca6790b839 llvm::sys::RunSignalHandlers() /home/hyubo/osmeta/external/llvm-project/llvm/lib/Support/Signals.cpp:104:5
 #3 0x000055ca6790ff6b SignalHandler(int, siginfo_t*, void*) /home/hyubo/osmeta/external/llvm-project/llvm/lib/Support/Unix/Signals.inc:430:38
 #4 0x00007fe9e5e44560 __restore_rt /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/signal/../sysdeps/unix/sysv/linux/libc_sigaction.c:13:0
 #5 0x00007fe9e5f25649 syscall /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/misc/../sysdeps/unix/sysv/linux/x86_64/syscall.S:38:0
 #6 0x00007fe9ec649170 SignalHandler(int, siginfo_t*, void*) /home/hyubo/osmeta/external/llvm-project/llvm/lib/Support/Unix/Signals.inc:429:7
 #7 0x00007fe9e5e44560 __restore_rt /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/signal/../sysdeps/unix/sysv/linux/libc_sigaction.c:13:0
 #8 0x00007fe9ebb77bf0 lldb_private::operator<(lldb_private::StackID const&, lldb_private::StackID const&) /home/hyubo/osmeta/external/llvm-project/lldb/source/Target/StackID.cpp:99:16
 #9 0x00007fe9ebb6863d CompareStackID(std::shared_ptr<lldb_private::StackFrame> const&, lldb_private::StackID const&) /home/hyubo/osmeta/external/llvm-project/lldb/source/Target/StackFrameList.cpp:683:3
#10 0x00007fe9ebb6d049 bool __gnu_cxx::__ops::_Iter_comp_val<bool (*)(std::shared_ptr<lldb_private::StackFrame> const&, lldb_private::StackID const&)>::operator()<__gnu_cxx::__normal_iterator<std::shared_ptr<lldb_private::StackFrame>*, std::vector<std::shared_ptr<lldb_private::StackFrame>, std::allocator<std::shared_ptr<lldb_private::StackFrame>>>>, lldb_private::StackID const>(__gnu_cxx::__normal_iterator<std::shared_ptr<lldb_private::StackFrame>*, std::vector<std::shared_ptr<lldb_private::StackFrame>, std::allocator<std::shared_ptr<lldb_private::StackFrame>>>>, lldb_private::StackID const&) /mnt/gvfs/third-party2/libgcc/d1129753c8361ac8e9453c0f4291337a4507ebe6/11.x/platform010/5684a5a/include/c++/11.x/bits/predefined_ops.h:196:4
#11 0x00007fe9ebb6cefe __gnu_cxx::__normal_iterator<std::shared_ptr<lldb_private::StackFrame>*, std::vector<std::shared_ptr<lldb_private::StackFrame>, std::allocator<std::shared_ptr<lldb_private::StackFrame>>>> std::__lower_bound<__gnu_cxx::__normal_iterator<std::shared_ptr<lldb_private::StackFrame>*, std::vector<std::shared_ptr<lldb_private::StackFrame>, std::allocator<std::shared_ptr<lldb_private::StackFrame>>>>, lldb_private::StackID, __gnu_cxx::__ops::_Iter_comp_val<bool (*)(std::shared_ptr<lldb_private::StackFrame> const&, lldb_private::StackID const&)>>(__gnu_cxx::__normal_iterator<std::shared_ptr<lldb_private::StackFrame>*, std::vector<std::shared_ptr<lldb_private::StackFrame>, std::allocator<std::shared_ptr<lldb_private::StackFrame>>>>, __gnu_cxx::__normal_iterator<std::shared_ptr<lldb_private::StackFrame>*, std::vector<std::shared_ptr<lldb_private::StackFrame>, std::allocator<std::shared_ptr<lldb_private::StackFrame>>>>, lldb_private::StackID const&, __gnu_cxx::__ops::_Iter_comp_val<bool (*)(std::shared_ptr<lldb_private::StackFrame> const&, lldb_private::StackID const&)>) /mnt/gvfs/third-party2/libgcc/d1129753c8361ac8e9453c0f4291337a4507ebe6/11.x/platform010/5684a5a/include/c++/11.x/bits/stl_algobase.h:1464:8
#12 0x00007fe9ebb6cdfc __gnu_cxx::__normal_iterator<std::shared_ptr<lldb_private::StackFrame>*, std::vector<std::shared_ptr<lldb_private::StackFrame>, std::allocator<std::shared_ptr<lldb_private::StackFrame>>>> std::lower_bound<__gnu_cxx::__normal_iterator<std::shared_ptr<lldb_private::StackFrame>*, std::vector<std::shared_ptr<lldb_private::StackFrame>, std::allocator<std::shared_ptr<lldb_private::StackFrame>>>>, lldb_private::StackID, bool (*)(std::shared_ptr<lldb_private::StackFrame> const&, lldb_private::StackID const&)>(__gnu_cxx::__normal_iterator<std::shared_ptr<lldb_private::StackFrame>*, std::vector<std::shared_ptr<lldb_private::StackFrame>, std::allocator<std::shared_ptr<lldb_private::StackFrame>>>>, __gnu_cxx::__normal_iterator<std::shared_ptr<lldb_private::StackFrame>*, std::vector<std::shared_ptr<lldb_private::StackFrame>, std::allocator<std::shared_ptr<lldb_private::StackFrame>>>>, lldb_private::StackID const&, bool (*)(std::shared_ptr<lldb_private::StackFrame> const&, lldb_private::StackID const&)) /mnt/gvfs/third-party2/libgcc/d1129753c8361ac8e9453c0f4291337a4507ebe6/11.x/platform010/5684a5a/include/c++/11.x/bits/stl_algo.h:2062:14
#13 0x00007fe9ebb685fa auto llvm::lower_bound<std::vector<std::shared_ptr<lldb_private::StackFrame>, std::allocator<std::shared_ptr<lldb_private::StackFrame>>>&, lldb_private::StackID const&, bool (*)(std::shared_ptr<lldb_private::StackFrame> const&, lldb_private::StackID const&)>(std::vector<std::shared_ptr<lldb_private::StackFrame>, std::allocator<std::shared_ptr<lldb_private::StackFrame>>>&, lldb_private::StackID const&, bool (*)(std::shared_ptr<lldb_private::StackFrame> const&, lldb_private::StackID const&)) /home/hyubo/osmeta/external/llvm-project/llvm/include/llvm/ADT/STLExtras.h:2001:10
#14 0x00007fe9ebb68441 lldb_private::StackFrameList::GetFrameWithStackID(lldb_private::StackID const&) /home/hyubo/osmeta/external/llvm-project/lldb/source/Target/StackFrameList.cpp:697:11
#15 0x00007fe9ebbee395 lldb_private::Thread::GetFrameWithStackID(lldb_private::StackID const&) /home/hyubo/osmeta/external/llvm-project/lldb/include/lldb/Target/Thread.h:459:7
#16 0x00007fe9ebac7cf7 lldb_private::ExecutionContextRef::GetFrameSP() const /home/hyubo/osmeta/external/llvm-project/lldb/source/Target/ExecutionContext.cpp:643:25
llvm#17 0x00007fe9ebac80e1 lldb_private::GetStoppedExecutionContext(lldb_private::ExecutionContextRef const*) /home/hyubo/osmeta/external/llvm-project/lldb/source/Target/ExecutionContext.cpp:164:34
llvm#18 0x00007fe9eb8903fa lldb_private::Statusline::Redraw(std::optional<lldb_private::ExecutionContextRef>) /home/hyubo/osmeta/external/llvm-project/lldb/source/Core/Statusline.cpp:139:7
llvm#19 0x00007fe9eb7ac8be lldb_private::Debugger::RedrawStatusline(std::optional<lldb_private::ExecutionContextRef>) /home/hyubo/osmeta/external/llvm-project/lldb/source/Core/Debugger.cpp:1233:3
llvm#20 0x00007fe9eb804d1e lldb_private::IOHandlerEditline::RedrawCallback() /home/hyubo/osmeta/external/llvm-project/lldb/source/Core/IOHandler.cpp:446:3
llvm#21 0x00007fe9eb80aa81 lldb_private::IOHandlerEditline::IOHandlerEditline(lldb_private::Debugger&, lldb_private::IOHandler::Type, std::shared_ptr<lldb_private::File> const&, std::shared_ptr<lldb_private::LockableStreamFile> const&, std::shared_ptr<lldb_private::LockableStreamFile> const&, unsigned int, char const*, llvm::StringRef, llvm::StringRef, bool, bool, unsigned int, lldb_private::IOHandlerDelegate&)::$_2::operator()() const /home/hyubo/osmeta/external/llvm-project/lldb/source/Core/IOHandler.cpp:262:73
llvm#22 0x00007fe9eb80aa5d void llvm::detail::UniqueFunctionBase<void>::CallImpl<lldb_private::IOHandlerEditline::IOHandlerEditline(lldb_private::Debugger&, lldb_private::IOHandler::Type, std::shared_ptr<lldb_private::File> const&, std::shared_ptr<lldb_private::LockableStreamFile> const&, std::shared_ptr<lldb_private::LockableStreamFile> const&, unsigned int, char const*, llvm::StringRef, llvm::StringRef, bool, bool, unsigned int, lldb_private::IOHandlerDelegate&)::$_2>(void*) /home/hyubo/osmeta/external/llvm-project/llvm/include/llvm/ADT/FunctionExtras.h:213:5
llvm#23 0x00007fe9eb93bfbf llvm::unique_function<void ()>::operator()() /home/hyubo/osmeta/external/llvm-project/llvm/include/llvm/ADT/FunctionExtras.h:365:5
llvm#24 0x00007fe9eb93bb80 lldb_private::Editline::GetCharacter(wchar_t*) /home/hyubo/osmeta/external/llvm-project/lldb/source/Host/common/Editline.cpp:0:5
llvm#25 0x00007fe9eb941a18 lldb_private::Editline::ConfigureEditor(bool)::$_0::operator()(editline*, wchar_t*) const /home/hyubo/osmeta/external/llvm-project/lldb/source/Host/common/Editline.cpp:1287:5
llvm#26 0x00007fe9eb9419e2 lldb_private::Editline::ConfigureEditor(bool)::$_0::__invoke(editline*, wchar_t*) /home/hyubo/osmeta/external/llvm-project/lldb/source/Host/common/Editline.cpp:1286:27
llvm#27 0x00007fe9f3384e26 el_getc /home/engshare/third-party2/libedit/3.1/src/libedit/src/read.c:439:14
llvm#28 0x00007fe9f3384e26 el_getc /home/engshare/third-party2/libedit/3.1/src/libedit/src/read.c:400:1
llvm#29 0x00007fe9f3384f90 read_getcmd /home/engshare/third-party2/libedit/3.1/src/libedit/src/read.c:247:14
llvm#30 0x00007fe9f3384f90 el_gets /home/engshare/third-party2/libedit/3.1/src/libedit/src/read.c:586:14
llvm#31 0x00007fe9eb9409f3 lldb_private::Editline::GetLine(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>&, bool&) /home/hyubo/osmeta/external/llvm-project/lldb/source/Host/common/Editline.cpp:1636:16
llvm#32 0x00007fe9eb8044d7 lldb_private::IOHandlerEditline::GetLine(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>&, bool&) /home/hyubo/osmeta/external/llvm-project/lldb/source/Core/IOHandler.cpp:339:5
llvm#33 0x00007fe9eb805609 lldb_private::IOHandlerEditline::Run() /home/hyubo/osmeta/external/llvm-project/lldb/source/Core/IOHandler.cpp:600:11
llvm#34 0x00007fe9eb7b214c lldb_private::Debugger::RunIOHandlers() /home/hyubo/osmeta/external/llvm-project/lldb/source/Core/Debugger.cpp:1280:16
llvm#35 0x00007fe9eb98f00f lldb_private::CommandInterpreter::RunCommandInterpreter(lldb_private::CommandInterpreterRunOptions&) /home/hyubo/osmeta/external/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:3620:16
llvm#36 0x00007fe9eb4f0e09 lldb::SBDebugger::RunCommandInterpreter(bool, bool) /home/hyubo/osmeta/external/llvm-project/lldb/source/API/SBDebugger.cpp:1234:42
llvm#37 0x000055ca6788d6b0 Driver::MainLoop() /home/hyubo/osmeta/external/llvm-project/lldb/tools/driver/Driver.cpp:677:3
llvm#38 0x000055ca6788e226 main /home/hyubo/osmeta/external/llvm-project/lldb/tools/driver/Driver.cpp:887:17
llvm#39 0x00007fe9e5e2c657 __libc_start_call_main /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/csu/../sysdeps/nptl/libc_start_call_main.h:58:16
llvm#40 0x00007fe9e5e2c718 call_init /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/csu/../csu/libc-start.c:128:20
llvm#41 0x00007fe9e5e2c718 __libc_start_main@GLIBC_2.2.5 /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/csu/../csu/libc-start.c:379:5
llvm#42 0x000055ca67889a11 _start /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/csu/../sysdeps/x86_64/start.S:118:0
Segmentation fault (core dumped)
```

When `target symbols add` is run, `Symtab::AddSymbol()` can reallocate
the underlying `std::vector<Symbol>` and resize it, invalidating all
existing Symbol* pointers. While `Process::Flush()` clears stale stack
frames, the statusline caches its own `ExecutionContextRef` containing a
`StackID` with a `SymbolContextScope*` (which can be a `Symbol*`). This
cached reference is not cleared by `Process::Flush()`, so the next
statusline redraw accesses a dangling pointer and crashes.

Fix this by adding `Statusline::Flush()` which clears the cached frame,
`Debugger::Flush()` which forwards to it under the statusline mutex, and
calling `Debugger::Flush()` from `Process::Flush()` so that all flush
paths (symbol add, exec, module load) also invalidate the statusline's
stale state.

After this fix, lldb is not crashing anymore, new symbols from a symbol
file are correctly loaded

---------

Co-authored-by: George Hu <georgehuyubo@gmail.com>
@lukel97
lukel97 force-pushed the test-suite-workflow-test-pr branch 2 times, most recently from e77209e to c949e0d Compare April 20, 2026 16:39
@lukel97

lukel97 commented Apr 20, 2026

Copy link
Copy Markdown
Owner Author

/test-suite

@github-actions

github-actions Bot commented Apr 20, 2026

Copy link
Copy Markdown

test-suite diff from 6c900b6...1821523: https://github.com/lukel97/llvm-project/actions/runs/24678527828/artifacts/6538931771

@lukel97 lukel97 mentioned this pull request Apr 20, 2026
Merged
lukel97 pushed a commit that referenced this pull request May 11, 2026
@thurstond
Revert "[llvm-profgen] Support [buildid:]0xaddr format in perfscript …
1f83fdb 
…input" (llvm#195551)

Reverts llvm#190863 due to buildbot breakage e.g.,
https://lab.llvm.org/buildbot/#/builders/52/builds/16951

```
Failed Tests (1):
  LLVM :: tools/llvm-profgen/filter-build-id.test
```
```
==llvm-profgen==3809550==ERROR: AddressSanitizer: container-overflow on address 0x6e80441e1762 at pc 0x6216c3f2cdce bp 0x7fff3c3ddf60 sp 0x7fff3c3dd710
READ of size 8 at 0x6e80441e1762 thread T0
    #0 0x6216c3f2cdcd in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long) /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:848:7
    #1 0x6216c3f2d25c in bcmp /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:894:10
    #2 0x6216c400b836 in operator== /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/include/llvm/ADT/StringRef.h:914:10
    #3 0x6216c400b836 in operator!= /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/include/llvm/ADT/StringRef.h:917:69
    #4 0x6216c400b836 in llvm::sampleprof::PerfScriptReader::extractCallstack(llvm::sampleprof::TraceStream&, llvm::SmallVectorImpl<unsigned long>&) /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:801:36
    #5 0x6216c400d37a in llvm::sampleprof::HybridPerfReader::parseSample(llvm::sampleprof::TraceStream&, unsigned long) /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:881:8
    #6 0x6216c40150d8 in parseSample /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:1118:3
    #7 0x6216c40150d8 in llvm::sampleprof::PerfScriptReader::parseEventOrSample(llvm::sampleprof::TraceStream&) /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:1201:5
    #8 0x6216c401539a in llvm::sampleprof::PerfScriptReader::parseAndAggregateTrace() /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:1210:5
    #9 0x6216c4018c88 in llvm::sampleprof::PerfScriptReader::parsePerfTraces() /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:1457:3
    #10 0x6216c3ff2c7a in main /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/llvm-profgen.cpp:229:19
    #11 0x72404502a8c0  (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a8c0) (BuildId: ae327f26c123ea1374623c41e676a4bf00e5c1cb)
    #12 0x72404502a9d7 in __libc_start_main (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a9d7) (BuildId: ae327f26c123ea1374623c41e676a4bf00e5c1cb)
    #13 0x6216c3f0f3d4 in _start (/home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/llvm-profgen+0x2f083d4)
0x6e80441e1762 is located 18 bytes inside of 48-byte region [0x6e80441e1750,0x6e80441e1780)
allocated by thread T0 here:
    #0 0x6216c3feab0d in operator new(unsigned long) /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/asan_new_delete.cpp:109:35
    #1 0x724045511c07 in __libcpp_allocate<char> /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/libcxx/include/__new/allocate.h:42:28
    #2 0x724045511c07 in allocate /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/libcxx/include/__memory/allocator.h:92:14
    #3 0x724045511c07 in allocate_at_least /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/libcxx/include/__memory/allocator.h:99:13
    #4 0x724045511c07 in allocate_at_least<std::__1::allocator<char> > /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/libcxx/include/__memory/allocator_traits.h:340:22
    #5 0x724045511c07 in __allocate_at_least<std::__1::allocator<char> > /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/libcxx/include/__memory/allocate_at_least.h:36:16
    #6 0x724045511c07 in __allocate_long_buffer /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/libcxx/include/string:2259:21
    #7 0x724045511c07 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::__grow_by(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long) /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/libcxx/include/string:2769:25
    #8 0x6216c401d90a in __grow_by_without_replace /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/libcxx_install_asan/include/c++/v1/string:2795:3
    #9 0x6216c401d90a in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>& std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::append[abi:sqn230000]<char const*, 0>(char const*, char const*) /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/libcxx_install_asan/include/c++/v1/string:1431:9
    #10 0x6216c401d1a6 in std::__1::basic_istream<char, std::__1::char_traits<char>>& std::__1::getline[abi:sqn230000]<char, std::__1::char_traits<char>, std::__1::allocator<char>>(std::__1::basic_istream<char, std::__1::char_traits<char>>&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&, char) /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/libcxx_install_asan/include/c++/v1/istream:1309:15
    #11 0x6216c4014a76 in getline<char, std::__1::char_traits<char>, std::__1::allocator<char> > /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/libcxx_install_asan/include/c++/v1/istream:1343:10
    #12 0x6216c4014a76 in advance /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.h:52:10
    #13 0x6216c4014a76 in llvm::sampleprof::PerfScriptReader::parseAggregatedCount(llvm::sampleprof::TraceStream&) /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:1110:13
    #14 0x6216c4015095 in parseSample /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:1116:20
    #15 0x6216c4015095 in llvm::sampleprof::PerfScriptReader::parseEventOrSample(llvm::sampleprof::TraceStream&) /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:1201:5
    #16 0x6216c401539a in llvm::sampleprof::PerfScriptReader::parseAndAggregateTrace() /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:1210:5
    llvm#17 0x6216c4018c88 in llvm::sampleprof::PerfScriptReader::parsePerfTraces() /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:1457:3
    llvm#18 0x6216c3ff2c7a in main /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/llvm-profgen.cpp:229:19
    llvm#19 0x72404502a8c0  (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a8c0) (BuildId: ae327f26c123ea1374623c41e676a4bf00e5c1cb)
    llvm#20 0x72404502a9d7 in __libc_start_main (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a9d7) (BuildId: ae327f26c123ea1374623c41e676a4bf00e5c1cb)
    llvm#21 0x6216c3f0f3d4 in _start (/home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm_build_asan/bin/llvm-profgen+0x2f083d4)
```
@lukel97
lukel97 force-pushed the main branch 4 times, most recently from f3b6bfd to cb91542 Compare May 28, 2026 08:31
lukel97 pushed a commit that referenced this pull request Jun 9, 2026
@DrSergei
[lldb] Add nullptr check in GetBroadcaster (llvm#201769)
731dd05 
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)
llvm#17 0x00007eaa6bb0f265 lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBCommandReturnObject&, bool) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x90f265)
llvm#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)
llvm#19 0x000062735c3a8019 lldb_dap::EvaluateRequestHandler::Run(lldb_dap::protocol::EvaluateArguments const&) const (/home/sergei/llvm-project/build/bin/lldb-dap+0xe4019)
llvm#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)
llvm#21 0x000062735c3ce1bf lldb_dap::BaseRequestHandler::Run(lldb_dap::protocol::Request const&) (/home/sergei/llvm-project/build/bin/lldb-dap+0x10a1bf)
llvm#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.
lukel97 added a commit to llvm/llvm-project that referenced this pull request Jun 10, 2026
@lukel97
[Github][RFC] Add workflow to diff codegen on llvm-test-suite (#190010)
dcf9add 
A common task when reviewing PRs in the LLVM subproject is checking out
the PR locally, building it, running it on some benchmarks e.g.
llvm-test-suite, and comparing the codegen against some known version.

The process is fairly laborious so this PR adds a GitHub workflow to
automate it. It's triggered by commenting "/test-suite" on a PR. The
workflow will kick off, build clang with the head and base of the PR,
build the benchmarks in llvm-test-suite for several configurations with
each version of clang, compute the diff in the output assembly via the
[tdiff.py
script](https://github.com/llvm/llvm-test-suite/blob/main/utils/tdiff.py),
and then report back with the diffs in a comment.

Here's an example on my fork where you can see the diff of a codegen
change in the RISC-V backend:
lukel97#7 (comment)

At the moment it's very simple but could be fleshed out later. Currently
it builds llvm-test-suite for handful of common configurations, some
cross-compiled:

- `-target aarch64-linux-gnu -march=armv9-a -O3`
- `-target riscv64-linux-gnu -march=rva23u64 -O3`
- `-target x86_64-linux-gnu -O3`

We could eventually extend this to accept arbitrary targets and flags in
the comment. It would also be nice to support LTO diffs in future but we
will need to add some extra support in llvm-test-suite to extract the
asm during the link step.

It also just comments a link to download the codegen diffs, but could
eventually also include some output from the ./utils/compare.py script
about e.g. changes in code size or statistics. For now, those results
are just uploaded as an artifact.

In terms of worker resources, running it on the free GitHub hosted
workers is good enough. Building Clang takes a while, over an hour, but
building the test-suite only takes around 10 minutes. But we could stick
it on something beefier if we wanted the feedback to be faster.

This workflow requires the PR to be mergeable, as it wants to get the
diff of the "mergeability" commit that GitHub generates for each PR.
That way the diff is always between the latest version of the base
branch and the PR, not the base branch at the time the PR was created.
llvm-sync Bot pushed a commit to arm/arm-toolchain that referenced this pull request Jun 10, 2026
@lukel97 @github-actions
Automerge: [Github][RFC] Add workflow to diff codegen on llvm-test-su…
e497444 
…ite (#190010)

A common task when reviewing PRs in the LLVM subproject is checking out
the PR locally, building it, running it on some benchmarks e.g.
llvm-test-suite, and comparing the codegen against some known version.

The process is fairly laborious so this PR adds a GitHub workflow to
automate it. It's triggered by commenting "/test-suite" on a PR. The
workflow will kick off, build clang with the head and base of the PR,
build the benchmarks in llvm-test-suite for several configurations with
each version of clang, compute the diff in the output assembly via the
[tdiff.py
script](https://github.com/llvm/llvm-test-suite/blob/main/utils/tdiff.py),
and then report back with the diffs in a comment.

Here's an example on my fork where you can see the diff of a codegen
change in the RISC-V backend:
lukel97/llvm-project#7 (comment)

At the moment it's very simple but could be fleshed out later. Currently
it builds llvm-test-suite for handful of common configurations, some
cross-compiled:

- `-target aarch64-linux-gnu -march=armv9-a -O3`
- `-target riscv64-linux-gnu -march=rva23u64 -O3`
- `-target x86_64-linux-gnu -O3`

We could eventually extend this to accept arbitrary targets and flags in
the comment. It would also be nice to support LTO diffs in future but we
will need to add some extra support in llvm-test-suite to extract the
asm during the link step.

It also just comments a link to download the codegen diffs, but could
eventually also include some output from the ./utils/compare.py script
about e.g. changes in code size or statistics. For now, those results
are just uploaded as an artifact.

In terms of worker resources, running it on the free GitHub hosted
workers is good enough. Building Clang takes a while, over an hour, but
building the test-suite only takes around 10 minutes. But we could stick
it on something beefier if we wanted the feedback to be faster.

This workflow requires the PR to be mergeable, as it wants to get the
diff of the "mergeability" commit that GitHub generates for each PR.
That way the diff is always between the latest version of the base
branch and the PR, not the base branch at the time the PR was created.
llvm-upstreamsync Bot pushed a commit to qualcomm/cpullvm-toolchain that referenced this pull request Jun 10, 2026
@lukel97 @github-actions
Automerge: [Github][RFC] Add workflow to diff codegen on llvm-test-su…
5ac62df 
…ite (#190010)

A common task when reviewing PRs in the LLVM subproject is checking out
the PR locally, building it, running it on some benchmarks e.g.
llvm-test-suite, and comparing the codegen against some known version.

The process is fairly laborious so this PR adds a GitHub workflow to
automate it. It's triggered by commenting "/test-suite" on a PR. The
workflow will kick off, build clang with the head and base of the PR,
build the benchmarks in llvm-test-suite for several configurations with
each version of clang, compute the diff in the output assembly via the
[tdiff.py
script](https://github.com/llvm/llvm-test-suite/blob/main/utils/tdiff.py),
and then report back with the diffs in a comment.

Here's an example on my fork where you can see the diff of a codegen
change in the RISC-V backend:
lukel97/llvm-project#7 (comment)

At the moment it's very simple but could be fleshed out later. Currently
it builds llvm-test-suite for handful of common configurations, some
cross-compiled:

- `-target aarch64-linux-gnu -march=armv9-a -O3`
- `-target riscv64-linux-gnu -march=rva23u64 -O3`
- `-target x86_64-linux-gnu -O3`

We could eventually extend this to accept arbitrary targets and flags in
the comment. It would also be nice to support LTO diffs in future but we
will need to add some extra support in llvm-test-suite to extract the
asm during the link step.

It also just comments a link to download the codegen diffs, but could
eventually also include some output from the ./utils/compare.py script
about e.g. changes in code size or statistics. For now, those results
are just uploaded as an artifact.

In terms of worker resources, running it on the free GitHub hosted
workers is good enough. Building Clang takes a while, over an hour, but
building the test-suite only takes around 10 minutes. But we could stick
it on something beefier if we wanted the feedback to be faster.

This workflow requires the PR to be mergeable, as it wants to get the
diff of the "mergeability" commit that GitHub generates for each PR.
That way the diff is always between the latest version of the base
branch and the PR, not the base branch at the time the PR was created.
Jianhui-Li pushed a commit to Jianhui-Li/llvm-project that referenced this pull request Jun 11, 2026
@lukel97 @Jianhui-Li
[Github][RFC] Add workflow to diff codegen on llvm-test-suite (llvm#1…
9b2e4e4 
…90010)

A common task when reviewing PRs in the LLVM subproject is checking out
the PR locally, building it, running it on some benchmarks e.g.
llvm-test-suite, and comparing the codegen against some known version.

The process is fairly laborious so this PR adds a GitHub workflow to
automate it. It's triggered by commenting "/test-suite" on a PR. The
workflow will kick off, build clang with the head and base of the PR,
build the benchmarks in llvm-test-suite for several configurations with
each version of clang, compute the diff in the output assembly via the
[tdiff.py
script](https://github.com/llvm/llvm-test-suite/blob/main/utils/tdiff.py),
and then report back with the diffs in a comment.

Here's an example on my fork where you can see the diff of a codegen
change in the RISC-V backend:
lukel97#7 (comment)

At the moment it's very simple but could be fleshed out later. Currently
it builds llvm-test-suite for handful of common configurations, some
cross-compiled:

- `-target aarch64-linux-gnu -march=armv9-a -O3`
- `-target riscv64-linux-gnu -march=rva23u64 -O3`
- `-target x86_64-linux-gnu -O3`

We could eventually extend this to accept arbitrary targets and flags in
the comment. It would also be nice to support LTO diffs in future but we
will need to add some extra support in llvm-test-suite to extract the
asm during the link step.

It also just comments a link to download the codegen diffs, but could
eventually also include some output from the ./utils/compare.py script
about e.g. changes in code size or statistics. For now, those results
are just uploaded as an artifact.

In terms of worker resources, running it on the free GitHub hosted
workers is good enough. Building Clang takes a while, over an hour, but
building the test-suite only takes around 10 minutes. But we could stick
it on something beefier if we wanted the feedback to be faster.

This workflow requires the PR to be mergeable, as it wants to get the
diff of the "mergeability" commit that GitHub generates for each PR.
That way the diff is always between the latest version of the base
branch and the PR, not the base branch at the time the PR was created.
@lukel97

lukel97 commented Jun 11, 2026

Copy link
Copy Markdown
Owner Author

/test-suite

@github-actions

github-actions Bot commented Jun 11, 2026

Copy link
Copy Markdown

test-suite diff from ce4e708...5d2b156: https://github.com/lukel97/llvm-project/actions/runs/27319463065/artifacts/7554414768

@github-actions

github-actions Bot commented Jun 11, 2026

Copy link
Copy Markdown

test-suite diff from ce4e708...5d2b156: https://github.com/lukel97/llvm-project/actions/runs/27319371830/artifacts/7554420914

carlobertolli pushed a commit to carlobertolli/llvm-project that referenced this pull request Jun 11, 2026
@lukel97 @carlobertolli
[Github][RFC] Add workflow to diff codegen on llvm-test-suite (llvm#1…
42047b8 
…90010)

A common task when reviewing PRs in the LLVM subproject is checking out
the PR locally, building it, running it on some benchmarks e.g.
llvm-test-suite, and comparing the codegen against some known version.

The process is fairly laborious so this PR adds a GitHub workflow to
automate it. It's triggered by commenting "/test-suite" on a PR. The
workflow will kick off, build clang with the head and base of the PR,
build the benchmarks in llvm-test-suite for several configurations with
each version of clang, compute the diff in the output assembly via the
[tdiff.py
script](https://github.com/llvm/llvm-test-suite/blob/main/utils/tdiff.py),
and then report back with the diffs in a comment.

Here's an example on my fork where you can see the diff of a codegen
change in the RISC-V backend:
lukel97#7 (comment)

At the moment it's very simple but could be fleshed out later. Currently
it builds llvm-test-suite for handful of common configurations, some
cross-compiled:

- `-target aarch64-linux-gnu -march=armv9-a -O3`
- `-target riscv64-linux-gnu -march=rva23u64 -O3`
- `-target x86_64-linux-gnu -O3`

We could eventually extend this to accept arbitrary targets and flags in
the comment. It would also be nice to support LTO diffs in future but we
will need to add some extra support in llvm-test-suite to extract the
asm during the link step.

It also just comments a link to download the codegen diffs, but could
eventually also include some output from the ./utils/compare.py script
about e.g. changes in code size or statistics. For now, those results
are just uploaded as an artifact.

In terms of worker resources, running it on the free GitHub hosted
workers is good enough. Building Clang takes a while, over an hour, but
building the test-suite only takes around 10 minutes. But we could stick
it on something beefier if we wanted the feedback to be faster.

This workflow requires the PR to be mergeable, as it wants to get the
diff of the "mergeability" commit that GitHub generates for each PR.
That way the diff is always between the latest version of the base
branch and the PR, not the base branch at the time the PR was created.
@lukel97 lukel97 closed this Jun 26, 2026
lukel97 pushed a commit that referenced this pull request Jul 6, 2026
@qiyao
[lldb] Reject NULL key in PythonDictionary::GetItem (llvm#205753)
4ffcfdf 
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`).
lukel97 pushed a commit that referenced this pull request Jul 7, 2026
@qiyao
[Support] Fix undefined shift in decodeULEB128/decodeSLEB128 for over…
8014a1d 
…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`).
@lukel97 lukel97 reopened this Jul 7, 2026
@lukel97

lukel97 commented Jul 7, 2026

Copy link
Copy Markdown
Owner Author

/test-suite

@lukel97
lukel97 force-pushed the main branch 2 times, most recently from 3dd856d to 483e0b7 Compare July 7, 2026 07:15
@lukel97
lukel97 force-pushed the test-suite-workflow-test-pr branch from c949e0d to 9907eeb Compare July 7, 2026 07:17
@lukel97

lukel97 commented Jul 7, 2026

Copy link
Copy Markdown
Owner Author

/test-suite

1 similar comment
@lukel97

lukel97 commented Jul 7, 2026

Copy link
Copy Markdown
Owner Author

/test-suite

@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown

test-suite diff from 483e0b7...b751034: https://github.com/lukel97/llvm-project/actions/runs/28848838705/artifacts/8132668756

Statistics: https://github.com/lukel97/llvm-project/actions/runs/28848838705/artifacts/8132669323

rva23u64

armv9-a

x86_64

@lukel97

lukel97 commented Jul 7, 2026

Copy link
Copy Markdown
Owner Author

/test-suite

@lukel97

lukel97 commented Jul 7, 2026

Copy link
Copy Markdown
Owner Author

/test-suite

@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown

Failed to get test-suite diff from ...: https://github.com/lukel97/llvm-project/actions/runs/28878337037

@lukel97
lukel97 force-pushed the test-suite-workflow-test-pr branch from 9907eeb to 030629e Compare July 7, 2026 15:31
@lukel97

lukel97 commented Jul 7, 2026

Copy link
Copy Markdown
Owner Author

/test-suite

@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown

Failed to get test-suite diff from 1992981...b5598ee: https://github.com/lukel97/llvm-project/actions/runs/28878094734

@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown

test-suite diff from a19d70a...588b27b: https://github.com/lukel97/llvm-project/actions/runs/28878436402/artifacts/8145442396

Statistics: https://github.com/lukel97/llvm-project/actions/runs/28878436402/artifacts/8145443034

riscv64-linux-gnu

('Program', '') ('size..text', 'base') ('size..text', 'head') ('size..text', 'diff')
Geomean difference nan nan -2.09634e-05

aarch64-linux-gnu

('Program', '') ('size..text', 'base') ('size..text', 'head') ('size..text', 'diff')
Geomean difference nan nan 0

x86_64-linux-gnu

('Program', '') ('size..text', 'base') ('size..text', 'head') ('size..text', 'diff')
Geomean difference nan nan 0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@lukel97