[AMDGPU] Implement getAddrSpaceCastPreservedPtrMask - #1
Closed
addmisol wants to merge 4 commits into
Closed
Conversation
addmisol
marked this pull request as draft
February 21, 2026 06:48
…m#181932)" (llvm#182657) This is causing some testing issue. Reverting for now.
addmisol
pushed a commit
that referenced
this pull request
Feb 27, 2026
Using code/ideas from the x86 backend to optimize a select on a bitcast integer. The previous aarch64 approach was to individually extract the bits from the mask, which is kind of terrible. https://rust.godbolt.org/z/576sndT66 ```llvm define void @if_then_else8(ptr %out, i8 %mask, ptr %if_true, ptr %if_false) { start: %t = load <8 x i32>, ptr %if_true, align 4 %f = load <8 x i32>, ptr %if_false, align 4 %m = bitcast i8 %mask to <8 x i1> %s = select <8 x i1> %m, <8 x i32> %t, <8 x i32> %f store <8 x i32> %s, ptr %out, align 4 ret void } ``` turned into ```asm if_then_else8: // @if_then_else8 sub sp, sp, llvm#16 ubfx w8, w1, #4, #1 and w11, w1, #0x1 ubfx w9, w1, #5, #1 fmov s1, w11 ubfx w10, w1, #1, #1 fmov s0, w8 ubfx w8, w1, #6, #1 ldp q5, q2, [x3] mov v1.h[1], w10 ldp q4, q3, [x2] mov v0.h[1], w9 ubfx w9, w1, #2, #1 mov v1.h[2], w9 ubfx w9, w1, #3, #1 mov v0.h[2], w8 ubfx w8, w1, #7, #1 mov v1.h[3], w9 mov v0.h[3], w8 ushll v1.4s, v1.4h, #0 ushll v0.4s, v0.4h, #0 shl v1.4s, v1.4s, llvm#31 shl v0.4s, v0.4s, llvm#31 cmlt v1.4s, v1.4s, #0 cmlt v0.4s, v0.4s, #0 bsl v1.16b, v4.16b, v5.16b bsl v0.16b, v3.16b, v2.16b stp q1, q0, [x0] add sp, sp, llvm#16 ret ``` With this PR that instead emits ```asm if_then_else8: adrp x8, .LCPI0_1 dup v0.4s, w1 ldr q1, [x8, :lo12:.LCPI0_1] adrp x8, .LCPI0_0 ldr q2, [x8, :lo12:.LCPI0_0] ldp q4, q3, [x2] and v1.16b, v0.16b, v1.16b and v0.16b, v0.16b, v2.16b ldp q5, q2, [x3] cmeq v1.4s, v1.4s, #0 cmeq v0.4s, v0.4s, #0 bsl v1.16b, v2.16b, v3.16b bsl v0.16b, v5.16b, v4.16b stp q0, q1, [x0] ret ``` So substantially shorter. Instead of building the mask element-by-element, this approach (by virtue of not splitting) instead splats the mask value into all vector lanes, performs a bitwise and with powers of 2, and compares with zero to construct the mask vector. cc rust-lang/rust#122376 cc llvm#175769
addmisol
pushed a commit
that referenced
this pull request
Mar 3, 2026
llvm#184186) …83889)" This reverts commit 2342db0. Revert "[CMake] Propagate dependencies to OBJECT libraries in `add_llvm_library` (llvm#183541)" This reverts commit e3c0454.
addmisol
pushed a commit
that referenced
this pull request
Mar 11, 2026
`SE.getUMaxExpr` causes assertion failure due to type mismatch here: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Analysis/LoopAccessAnalysis.cpp#L253 Running `opt -S -p loop-vectorize -debug-only=loop-vectorize llvm/test/Analysis/LoopAccessAnalysis/type-mismatch-in-scalar-evolution.ll ` without the changes made in LoopAccessAnalysis.cpp causes assertion failure. Attaching the stack dump for reference: ``` LV: Checking a loop in 'loop_contains_store_assumed_bounds' from input.ll LV: Loop hints: force=? width=4 interleave=0 LV: Found a loop: for.body LV: Found an induction variable. opt: /home/kshitij/llvm-project/llvm/lib/Analysis/ScalarEvolution.cpp:3918: const llvm::SCEV* llvm::ScalarEvolution::getMinMaxExpr(llvm::SCEVTypes, llvm::SmallVectorImpl<const llvm::SCEV*>&): Assertion `getEffectiveSCEVType(Ops[i]->getType()) == ETy && "Operand types don't match!"' failed. 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: opt -S -passes=loop-vectorize -debug-only=loop-vectorize -force-vector-width=4 -disable-output input.ll 1. Running pass "function(loop-vectorize<no-interleave-forced-only;no-vectorize-forced-only;>)" on module "input.ll" 2. Running pass "loop-vectorize<no-interleave-forced-only;no-vectorize-forced-only;>" on function "loop_contains_store_assumed_bounds" #0 0x000058ee97c5e652 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/bin/opt+0x4f44652) #1 0x000058ee97c5af0f llvm::sys::RunSignalHandlers() (/usr/local/bin/opt+0x4f40f0f) #2 0x000058ee97c5b05c SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0 #3 0x00007c49d4c45330 (/lib/x86_64-linux-gnu/libc.so.6+0x45330) #4 0x00007c49d4c9eb2c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 #5 0x00007c49d4c9eb2c __pthread_kill_internal ./nptl/pthread_kill.c:78:10 #6 0x00007c49d4c9eb2c pthread_kill ./nptl/pthread_kill.c:89:10 #7 0x00007c49d4c4527e raise ./signal/../sysdeps/posix/raise.c:27:6 #8 0x00007c49d4c288ff abort ./stdlib/abort.c:81:7 #9 0x00007c49d4c2881b _nl_load_domain ./intl/loadmsgcat.c:1177:9 #10 0x00007c49d4c3b517 (/lib/x86_64-linux-gnu/libc.so.6+0x3b517) #11 0x000058ee98003fdb llvm::ScalarEvolution::getMinMaxExpr(llvm::SCEVTypes, llvm::SmallVectorImpl<llvm::SCEV const*>&) (/usr/local/bin/opt+0x52e9fdb) #12 0x000058ee98004507 llvm::ScalarEvolution::getUMaxExpr(llvm::SCEV const*, llvm::SCEV const*) (/usr/local/bin/opt+0x52ea507) llvm#13 0x000058ee980dc728 llvm::getStartAndEndForAccess(llvm::Loop const*, llvm::SCEV const*, llvm::Type*, llvm::SCEV const*, llvm::SCEV const*, llvm::ScalarEvolution*, llvm::DenseMap<std::pair<llvm::SCEV const*, llvm::Type*>, std::pair<llvm::SCEV const*, llvm::SCEV const*>, llvm::DenseMapInfo<std::pair<llvm::SCEV const*, llvm::Type*>, void>, llvm::detail::DenseMapPair<std::pair<llvm::SCEV const*, llvm::Type*>, std::pair<llvm::SCEV const*, llvm::SCEV const*>>>*, llvm::DominatorTree*, llvm::AssumptionCache*, std::optional<llvm::ScalarEvolution::LoopGuards>&) (/usr/local/bin/opt+0x53c2728) llvm#14 0x000058ee9814008b llvm::isDereferenceableAndAlignedInLoop(llvm::LoadInst*, llvm::Loop*, llvm::ScalarEvolution&, llvm::DominatorTree&, llvm::AssumptionCache*, llvm::SmallVectorImpl<llvm::SCEVPredicate const*>*) (/usr/local/bin/opt+0x542608b) llvm#15 0x000058ee9a0fa1ca llvm::LoopVectorizationLegality::canUncountableExitConditionLoadBeMoved(llvm::BasicBlock*) (/usr/local/bin/opt+0x73e01ca) llvm#16 0x000058ee9a0faee0 llvm::LoopVectorizationLegality::isVectorizableEarlyExitLoop() (/usr/local/bin/opt+0x73e0ee0) llvm#17 0x000058ee9a104678 llvm::LoopVectorizationLegality::canVectorize(bool) (/usr/local/bin/opt+0x73ea678) llvm#18 0x000058ee9a08c953 llvm::LoopVectorizePass::processLoop(llvm::Loop*) (/usr/local/bin/opt+0x7372953) llvm#19 0x000058ee9a090e21 llvm::LoopVectorizePass::runImpl(llvm::Function&) (/usr/local/bin/opt+0x7376e21) llvm#20 0x000058ee9a0914e0 llvm::LoopVectorizePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/usr/local/bin/opt+0x73774e0) llvm#21 0x000058ee99e419a5 llvm::detail::PassModel<llvm::Function, llvm::LoopVectorizePass, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) PassBuilderPipelines.cpp:0:0 llvm#22 0x000058ee97f18905 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/usr/local/bin/opt+0x51fe905) llvm#23 0x000058ee995d70d5 llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) AMDGPUTargetMachine.cpp:0:0 llvm#24 0x000058ee97f17051 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/usr/local/bin/opt+0x51fd051) llvm#25 0x000058ee995d7775 llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) AMDGPUTargetMachine.cpp:0:0 llvm#26 0x000058ee97f1783d llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/usr/local/bin/opt+0x51fd83d) llvm#27 0x000058ee9c153909 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::PassPlugin>, llvm::ArrayRef<std::function<void (llvm::PassBuilder&)>>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool, bool) (/usr/local/bin/opt+0x9439909) llvm#28 0x000058ee97c3f380 optMain (/usr/local/bin/opt+0x4f25380) llvm#29 0x00007c49d4c2a1ca __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3 llvm#30 0x00007c49d4c2a28b call_init ./csu/../csu/libc-start.c:128:20 llvm#31 0x00007c49d4c2a28b __libc_start_main ./csu/../csu/libc-start.c:347:5 llvm#32 0x000058ee97c309a5 _start (/usr/local/bin/opt+0x4f169a5) ``` This is caused by a type mismatch between `SE.getSCEV(DerefRK.IRArgValue)` and `DerefBytesSCEV`. Fixing this by extending them to the wider type.
addmisol
pushed a commit
that referenced
this pull request
Mar 14, 2026
…#185473) This patch extracts the `msg` value of the `failwithmessage` error and uses it as the stop reason if the MSVC Runtime fails while debugging. # Before ``` lldb.exe C:\Users\charleszablit\Developer\testing\uninit.exe -b -o 'r' (lldb) target create "C:\\Users\\charleszablit\\Developer\\testing\\uninit.exe" Current executable set to 'C:\Users\charleszablit\Developer\testing\uninit.exe' (x86_64). (lldb) r Process 9400 launched: 'C:\Users\charleszablit\Developer\testing\uninit.exe' (x86_64) Process 9400 stopped * thread #1, stop reason = Exception 0x80000003 encountered at address 0x7ff96516c96a frame #0: 0x00007ff77efe20ba uninit.exe`failwithmessage(retaddr=0x00007ff77efe150f, crttype=1, errnum=3, msg="The variable 'x' is being used without being initialized.") at error.cpp:210 ``` # After ``` lldb.exe C:\Users\charleszablit\Developer\testing\uninit.exe -b -o 'r' (lldb) target create "C:\\Users\\charleszablit\\Developer\\testing\\uninit.exe" Current executable set to 'C:\Users\charleszablit\Developer\testing\uninit.exe' (x86_64). (lldb) r Process 9400 launched: 'C:\Users\charleszablit\Developer\testing\uninit.exe' (x86_64) Process 9400 stopped * thread #1, stop reason = Run-time check failure: The variable 'x' is being used without being initialized. frame #0: 0x00007ff77efe20ba uninit.exe`failwithmessage(retaddr=0x00007ff77efe150f, crttype=1, errnum=3, msg="The variable 'x' is being used without being initialized.") at error.cpp:210 ``` fix llvm#184990. rdar://172103284
addmisol
pushed a commit
that referenced
this pull request
Mar 27, 2026
…e edge case (llvm#188590) llvm#186966 was reverted because the test case triggered a use-of-uninitialized-memory (https://lab.llvm.org/buildbot/#/builders/94/builds/16379), due to the include directive omitting a trailing newline. This patch adds a minor fix to avoid the use-of-uninitialized-memory, and deliberately re-adds the test case sans trailing newline for regression testing. MSan report prior to this fix: ``` @@@BUILD_STEP sanitizer logs: stage2/msan_track_origins check@@@ ==clang-scan-deps==616960==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5555599c3300 in isAnnotation /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/Lex/Token.h:131:38 #1 0x5555599c3300 in setLength /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/Lex/Token.h:152:13 #2 0x5555599c3300 in clang::Lexer::FormTokenWithChars(clang::Token&, char const*, clang::tok::TokenKind) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/Lex/Lexer.h:644:12 #3 0x5555599cf895 in clang::Lexer::LexEndOfFile(clang::Token&, char const*) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/Lexer.cpp:3166:5 #4 0x555559bb229b in clang::Preprocessor::Lex(clang::Token&) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/Preprocessor.cpp:916:11 #5 0x555559aa5365 in __invoke<void (clang::Preprocessor::*&)(clang::Token &), clang::Preprocessor *, clang::Token &> /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/libcxx_install_msan_track_origins/include/c++/v1/__type_traits/invoke.h:90:27 #6 0x555559aa5365 in invoke<void (clang::Preprocessor::*&)(clang::Token &), clang::Preprocessor *, clang::Token &> /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/libcxx_install_msan_track_origins/include/c++/v1/__functional/invoke.h:29:10 #7 0x555559aa5365 in operator()<void (clang::Preprocessor::*)(clang::Token &)> /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/PPDirectives.cpp:470:5 #8 0x555559aa5365 in clang::Preprocessor::CheckEndOfDirective(llvm::StringRef, bool, llvm::SmallVectorImpl<clang::Token>*) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/PPDirectives.cpp:478:5 #9 0x555559ab96b5 in clang::Preprocessor::HandleIncludeDirective(clang::SourceLocation, clang::Token&, clang::detail::SearchDirIteratorImpl<true>, clang::FileEntry const*) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Lex/PPDirectives.cpp:2205:7 ... ```
addmisol
pushed a commit
that referenced
this pull request
Apr 12, 2026
Running gcc test c-c++-common/tsan/tls_race.c on s390 we get: ThreadSanitizer: CHECK failed: tsan_platform_linux.cpp:618 "((thr_beg)) >= ((tls_addr))" (0x3ffaa35e140, 0x3ffaa35e250) (tid=2419930) #0 __tsan::CheckUnwind() /devel/src/libsanitizer/tsan/tsan_rtl.cpp:696 (libtsan.so.2+0x91b57) #1 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /devel/src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:86 (libtsan.so.2+0xd211b) #2 __tsan::ImitateTlsWrite(__tsan::ThreadState*, unsigned long, unsigned long) /devel/src/libsanitizer/tsan/tsan_platform_linux.cpp:618 (libtsan.so.2+0x8faa3) #3 __tsan::ThreadStart(__tsan::ThreadState*, unsigned int, unsigned long long, __sanitizer::ThreadType) /devel/src/libsanitizer/tsan/tsan_rtl_thread.cpp:225 (libtsan.so.2+0xaadb5) #4 __tsan_thread_start_func /devel/src/libsanitizer/tsan/tsan_interceptors_posix.cpp:1065 (libtsan.so.2+0x3d34d) #5 start_thread <null> (libc.so.6+0xae70d) (BuildId: d3b08de1b543c2d15d419bf861b3c2e4c01ac75b) #6 thread_start <null> (libc.so.6+0x12d2ff) (BuildId: d3b08de1b543c2d15d419bf861b3c2e4c01ac75b) In order to determine the static TLS blocks in GetStaticTlsBoundary we iterate over the modules and try to find the largest range without a gap. Here we might have that modules are spaced exactly by the alignment. For example, for the failing test we have: (gdb) p/x ranges.data_[0] $1 = {begin = 0x3fff7f9e6b8, end = 0x3fff7f9e740, align = 0x8, tls_modid = 0x3} (gdb) p/x ranges.data_[1] $2 = {begin = 0x3fff7f9e740, end = 0x3fff7f9eed0, align = 0x40, tls_modid = 0x2} (gdb) p/x ranges.data_[2] $3 = {begin = 0x3fff7f9eed8, end = 0x3fff7f9eef8, align = 0x8, tls_modid = 0x4} (gdb) p/x ranges.data_[3] $4 = {begin = 0x3fff7f9eefc, end = 0x3fff7f9ef00, align = 0x4, tls_modid = 0x1} where ranges[3].begin == ranges[2].end + ranges[3].align holds. Since in the loop a strict inequality test is used we compute the wrong address (gdb) p/x *addr $5 = 0x3fff7f9eefc whereas 0x3fff7f9e6b8 is expected which is why we bail out in the subsequent.
addmisol
pushed a commit
that referenced
this pull request
Apr 12, 2026
…8271) Example: int foo(int a, int b) { return a - 1 + ~b; } Before, on AArch64: mvn w8, w1 add w8, w0, w8 sub w0, w8, #1 After (matches gcc): sub w0, w0, w1 sub w0, w0, #2 Proof: https://alive2.llvm.org/ce/z/g_bV01
addmisol
pushed a commit
that referenced
this pull request
Apr 17, 2026
…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 llvm#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 llvm#14 0x00007fe9ebb68441 lldb_private::StackFrameList::GetFrameWithStackID(lldb_private::StackID const&) /home/hyubo/osmeta/external/llvm-project/lldb/source/Target/StackFrameList.cpp:697:11 llvm#15 0x00007fe9ebbee395 lldb_private::Thread::GetFrameWithStackID(lldb_private::StackID const&) /home/hyubo/osmeta/external/llvm-project/lldb/include/lldb/Target/Thread.h:459:7 llvm#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>
addmisol
pushed a commit
that referenced
this pull request
Apr 25, 2026
When Control Flow Integrity (CFI) is enabled, jump tables are used to redirect indirect calls. Previously, these jump table entries lacked debug information, making it difficult for profilers and debuggers to attribute execution time correctly. Now stack trace, when stopped on jump table entry will looks like this: ``` #0: __ubsan_check_cfi_icall_jt at sanitizer/ubsan_interface.h:0 #1: c::c() (.cfi_jt) at sanitizer/ubsan_interface.h:0:0 #2: .cfi.jumptable.81 at sanitizer/ubsan_interface.h:0:0 ```
addmisol
pushed a commit
that referenced
this pull request
Apr 25, 2026
…93670) When Control Flow Integrity (CFI) is enabled, jump tables are used to redirect indirect calls. Previously, these jump table entries lacked debug information, making it difficult for profilers and debuggers to attribute execution time correctly. Now stack trace, when stopped on jump table entry will looks like this: ``` #0: __ubsan_check_cfi_icall_jt at sanitizer/ubsan_interface.h:0 #1: c::c() (.cfi_jt) at sanitizer/ubsan_interface.h:0:0 #2: .cfi.jumptable.81 at sanitizer/ubsan_interface.h:0:0 ``` This is reland of llvm#192736, reverted with llvm#193663. This version don't update debug info for "Cross-DSO CFI" mode.
addmisol
pushed a commit
that referenced
this pull request
Apr 25, 2026
llvm#184115) In this change I'm extending the "memory region" command to show users the overlay permissions that a protection key refers to, and the result of applying that overlay to the page table permissions. For example, protection key 0 refers to Perm0 in the por register. ``` (lldb) register read por Perm0 = Read, Write, Execute ``` This is the default key, so many regions use it. ``` (lldb) memory region --all <...> [0x000ffffff7db0000-0x000ffffff7f40000) r-x /usr/lib/aarch64-linux-gnu/libc.so.6 PT_LOAD[0] protection key: 0 (rwx, effective: r-x) ``` Protection keys can only change what was already enabled in the page table. So we start with read and execute. Then a read/write/execute overlay is applied. We cannot add write, so the result is read and execute. Here's an example of its use with a real crash (output edited): ``` (lldb) c * thread #1, name = 'test.o', stop reason = signal SIGSEGV: failed protection key checks (fault address=0xffffff7d60000) -> 106 read_only_page[0] = '?'; (lldb) memory region 0xffffff7d60000 [0x000ffffff7d60000-0x000ffffff7d70000) rw- protection key: 6 (r--, effective: r--) (lldb) register read por Perm6 = Read ``` The calculation of permissions is implemented by a new ABI method. It's in ABI for 2 reasons: * These overlays are usually in a register (X86 and AArch64 are) and that register name is architecture specific. * The way the overlay values apply may differ between architecture. AArch64 treats a set bit as adding a permission, but some may treat it as removing. Technically this is dependent on operating system and architecture. However, so are the methods for removing non-address bits, and those are in ABI too. To test this I have changed the allocations in the test program to use read+execute permissions by default. With read+write+execute I could not observe that the overlay only changes enabled permissions.
addmisol
pushed a commit
that referenced
this pull request
Apr 25, 2026
We did not initialize the out parameters in llvm#192347, causing the "sanitizer-x86_64-linux-fast" bot to complain with: ``` SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1525:63 in compileModuleImpl(clang::CompilerInstance&, clang::SourceLocation, clang::SourceLocation, clang::Module*, clang::ModuleFileName) Exiting ==clang==3084515==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x586360f7a604 in compileModuleImpl(clang::CompilerInstance&, clang::SourceLocation, clang::SourceLocation, clang::Module*, clang::ModuleFileName) /home/b/sanitizer-x86_64-linux-fast/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1525:63 #1 <...> ``` This PR should fix that.
addmisol
pushed a commit
that referenced
this pull request
May 1, 2026
…lvm#141480) When a vector integer-to-float conversion is followed by a multiply with a reciprocal power-of-two constant, we can fold both operations into a single SCVTF or UCVTF instruction with a fixed-point shift operand. For example, `fmul(sitofp(v2i32 x), <0.5, 0.5>)` becomes `scvtf.2s v0, v0, #1`. This is a reworked version with several improvements over the original submission: - Rewrite the C++ operand matcher to share implementation with the existing `SelectCVTFixedPointVec` (MOVIshift, FMOV, and DUP handling with correct truncation for f16) - Add `uitofp`/`ucvtf` patterns via a `CVTFRecipPat` multiclass - Add full GlobalISel support (`GIComplexOperandMatcher` + renderer) Supported vector types: `v2f32`, `v4f32`, `v2f64`, `v4f16`, `v8f16`. Fixes llvm#94909
addmisol
pushed a commit
that referenced
this pull request
May 1, 2026
…h the current thread is stopped (llvm#194272) Adds `.` as a new `breakpt-id` syntax. Users can specify `.` to mean the breakpoint location(s) that caused the current thread to stop. I selected `.` to mean the current breakpoint locations for two reasons. In a shells, period means <ins>current</ins> directory. In prose, a period is a <ins>stop</ins>. My workflow often starts with multiple breakpoint locations, such as with regex breakpoints, or basename breakpoints for overloaded/overridden names. As locations are hit, I realize which locations are no longer needed. This new syntax makes it quick and easy to disable the currently stopped location(s). Another use case for this is to quickly repeat commands for the current location: ``` break com add -o 'p someVar' . ``` Usage example: ``` (lldb) b main.c:2 Process 47071 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: ... main`main at main.c:2:3 1 int main() { -> 2 return 0; 3 } Target 0: (main) stopped. (lldb) breakpoint disable . 1 breakpoints disabled. (lldb) breakpoint list Current breakpoints: 1: file = 'main.c', line = 2, exact_match = 0, locations = 1 1.1: where = main`main + 12 at main.c:2:3, address = ..., hit count = 1 Options: disabled ``` rdar://73047170 Assisted-by: claude
addmisol
pushed a commit
that referenced
this pull request
May 2, 2026
[LowerTypeTests] Add debug info to jump table entries (llvm#192736) When Control Flow Integrity (CFI) is enabled, jump tables are used to redirect indirect calls. Previously, these jump table entries lacked debug information, making it difficult for profilers and debuggers to attribute execution time correctly. Now stack trace, when stopped on jump table entry will looks like this: ``` #0: c::c() (.cfi_jt) at sanitizer/ubsan_interface.h:0:0 #1: __ubsan_check_cfi_icall_jt at sanitizer/ubsan_interface.h:0 ``` Following up on previous attempts llvm#192736 and llvm#193670, this PR is essentially llvm#192736 but with the `(.cfi_jt)` and `__ubsan_check_cfi_icall_jt` frames swapped. While the specific order of `__ubsan_check_cfi_icall_jt` isn't strictly necessary, swapping them helps maintain existing diagnostics behavior. Additionally, the diagnostics must remove `ubsan_interface.h` to allow for a fallback to printing the module name. See "Commits" tab for details.
addmisol
pushed a commit
that referenced
this pull request
May 5, 2026
…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) llvm#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 llvm#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 llvm#14 0x6216c4015095 in parseSample /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:1116:20 llvm#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 llvm#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) ```
addmisol
pushed a commit
that referenced
this pull request
May 5, 2026
…ExtFree (llvm#195285) When a narrow load i8 or i16 is frozen and its value crosses a basic block, `getCopyToRegs` emits `any_extend` instead of `zero_extend` because `isZExtFree` can't see through the `ISD::FREEZE` node. Example: https://godbolt.org/z/MYvjq8vPM contains an redundant `and w11, w11, 0xff` ``` ldrb w11, [x10], #1 cmp w11, llvm#32 b.lo .LBB0_1 and w11, w11, #0xff ``` Fix this by passing the incoming node to the freeze to `isZExtFree` instead.
addmisol
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
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
Jul 2, 2026
Summary This builds on the accelerator plugin protocol (llvm#201489) by letting a plugin ask the client to create and connect a second target — the mechanism a real backend (e.g. a GPU debug stub) uses to surface the accelerator alongside the CPU process being debugged. ### What this adds **Protocol** — a new `AcceleratorConnectionInfo` describing how the client should bring up the accelerator target. **Client** — when an `AcceleratorActions` carries `connect_info`, `ProcessGDBRemote` creates a new (empty) target, reverse-connects it to the GDB server the plugin points. **Mock server (for testing)** — to exercise this end to end, the mock accelerator plugin stands up an in-process GDB server backed by a minimal fake process: `ProcessMockAccelerator`, `ThreadMockAccelerator` and `RegisterContextMockAccelerator`. ### Scope Intentionally minimal: the goal is to create and show the second (accelerator) target. There is no register/memory modeling beyond what a connection requires. Next set of PRs will build up on this. ### Testing Demo of how this looks with this PR. (explicitly asking the native process to stop at every breakpoint for testability) ``` satyajanga@devgpu011:toolchain $ ./bin/lldb (lldb) file /home/satyajanga/llvm-sand/build/Debug/fbcode-x86_64/toolchain/lldb-test-build.noindex/accelerator/mock/TestMockAcceleratorActions/a.out Current executable set to '/home/satyajanga/llvm-sand/build/Debug/fbcode-x86_64/toolchain/lldb-test-build.noindex/accelerator/mock/TestMockAcceleratorActions/a.out' (x86_64). (lldb) log enable -f /tmp/packets.log gdb-remote packets (lldb) r Process 1430531 launched: '/home/satyajanga/llvm-sand/build/Debug/fbcode-x86_64/toolchain/lldb-test-build.noindex/accelerator/mock/TestMockAcceleratorActions/a.out' (x86_64) Process 1430531 stopped (lldb) target list Current targets: * target #0: /home/satyajanga/llvm-sand/build/Debug/fbcode-x86_64/toolchain/lldb-test-build.noindex/accelerator/mock/TestMockAcceleratorActions/a.out ( arch=x86_64-unknown-linux-gnu, platform=host, pid=1430531, state=stopped ) (lldb) c Process 1430531 resuming Process 1 stopped * thread #1, name = 'Mock Accelerator Thread', stop reason = trace frame #0: 0x0000000000001004 error: memory read failed for 0x1000 Target 0: (a.out) stopped. (lldb) target list Current targets: target #0: /home/satyajanga/llvm-sand/build/Debug/fbcode-x86_64/toolchain/lldb-test-build.noindex/accelerator/mock/TestMockAcceleratorActions/a.out ( arch=x86_64-unknown-linux-gnu, platform=host, pid=1430531, state=stopped ) * target #1: <none> ( arch=x86_64-unknown-linux-gnu, platform=host, pid=1, state=stopped ) (lldb) c Process 1 resuming (lldb) target select 0 Current targets: * target #0: /home/satyajanga/llvm-sand/build/Debug/fbcode-x86_64/toolchain/lldb-test-build.noindex/accelerator/mock/TestMockAcceleratorActions/a.out ( arch=x86_64-unknown-linux-gnu, platform=host, pid=1430531, state=stopped ) target #1: <none> ( arch=x86_64-unknown-linux-gnu, platform=host, pid=1, state=running ) (lldb) c Process 1430531 resuming Process 1430531 stopped (lldb) target list Current targets: * target #0: /home/satyajanga/llvm-sand/build/Debug/fbcode-x86_64/toolchain/lldb-test-build.noindex/accelerator/mock/TestMockAcceleratorActions/a.out ( arch=x86_64-unknown-linux-gnu, platform=host, pid=1430531, state=stopped ) target #1: <none> ( arch=x86_64-unknown-linux-gnu, platform=host, pid=1, state=running ) (lldb) a.out │ internal accelerator-plugin (mock) breakpoint(-4). ``` Packet log, you can notice the actions set with breakpoint info and later responding with connection info. and you can also see the 5 GPRs ``` lldb < 104> send packet: $qSupported:xmlRegisters=i386,arm,mips,arc;multiprocess+;fork-events+;vfork-events+;swbreak+;hwbreak+#cd lldb < 299> read packet: $PacketSize=131072;QStartNoAckMode+;qEcho+;native-signals+;QThreadSuffixSupported+;QListThreadsInStopReply+;qXfer:features:read+;QNonStop+;jMultiBreakpoint+;QPassSignals+;qXfer:auxv:read+;qXfer:libraries-svr4:read+;qXfer:siginfo:read+;accelerator-plugins+;multiprocess+;fork-events+;vfork-events+llvm#86 .. lldb < 32> send packet: $jAcceleratorPluginInitialize#50 lldb < 238> read packet: $[{"breakpoints":[{"by_address":null,"by_name":{"function_name":"mock_gpu_accelerator_initialize","shlib":null}],"identifier":1,"symbol_names":["mock_gpu_accelerator_compute"]}]],"identifier":1,"plugin_name":"mock","session_name":""}]]#2f .. intern-state < 314> send packet: $jAcceleratorPluginBreakpointHit:{"breakpoint":{"by_address":null,"by_name":{"function_name":"mock_gpu_accelerator_initialize","shlib":null}],"identifier":1,"symbol_names":["mock_gpu_accelerator_compute"]}],"plugin_name":"mock","symbol_values":[{"name":"mock_gpu_accelerator_compute","value":93824992235840}]]}]#e7 intern-state < 487> read packet: ${"actions":{"breakpoints":[{"by_address":null,"by_name":{"function_name":"mock_gpu_accelerator_finish","shlib":"a.out"}],"identifier":3,"symbol_names":[]}],{"by_address":{"load_address":93824992235840}],"by_name":null,"identifier":2,"symbol_names":[]}],{"by_address":null,"by_name":{"function_name":"mock_gpu_accelerator_connect","shlib":null}],"identifier":4,"symbol_names":[]}]],"identifier":2,"plugin_name":"mock","session_name":""}],"auto_resume_native":false,"disable_bp":true}]#7d .. .. intern-state < 218> send packet: $jAcceleratorPluginBreakpointHit:{"breakpoint":{"by_address":null,"by_name":{"function_name":"mock_gpu_accelerator_connect","shlib":null}],"identifier":4,"symbol_names":[]}],"plugin_name":"mock","symbol_values":[]}]#d1 intern-state < 268> read packet: ${"actions":{"breakpoints":[],"connect_info":{"connect_url":"connect://localhost:32893","exe_path":null,"synchronous":true,"triple":null}],"identifier":4,"plugin_name":"mock","session_name":"Mock Accelerator Session"}],"auto_resume_native":false,"disable_bp":true}]#8e intern-state < 1> send packet: + intern-state history[1] tid=0x15d41f < 1> send packet: + intern-state < 19> send packet: $QStartNoAckMode#b0 intern-state < 1> read packet: + intern-state < 6> read packet: $OK#9a intern-state < 1> send packet: + intern-state < 104> send packet: $qSupported:xmlRegisters=i386,arm,mips,arc;multiprocess+;fork-events+;vfork-events+;swbreak+;hwbreak+#cd intern-state < 159> read packet: $PacketSize=131072;QStartNoAckMode+;qEcho+;native-signals+;QThreadSuffixSupported+;QListThreadsInStopReply+;qXfer:features:read+;QNonStop+;jMultiBreakpoint+#f3 intern-state < 26> send packet: $QThreadSuffixSupported#e4 intern-state < 6> read packet: $OK#9a intern-state < 27> send packet: $QListThreadsInStopReply#21 intern-state < 6> read packet: $OK#9a intern-state < 13> send packet: $qHostInfo#9b intern-state < 364> read packet: $triple:7838365f36342d2d6c696e75782d676e75;ptrsize:8;watchpoint_exceptions_received:after;endian:little;os_version:6.13.2;os_build:362e31332e322d305f66626b355f 68617264656e65645f7263325f305f67313733613962316463613431;os_kernel:233120534d5020576564204a756c2032332030393a32343a3330205044542032303235;hostname:6465766770753031312e656167322e66616365626f6f6b2e6 36f6d;#c4 intern-state < 10> send packet: $vCont?llvm#49 intern-state < 19> read packet: $vCont;c;C;s;S;t#11 intern-state < 27> send packet: $qVAttachOrWaitSupported#38 intern-state < 6> read packet: $OK#9a intern-state < 23> send packet: $QEnableErrorStrings#8c intern-state < 6> read packet: $OK#9a intern-state < 16> send packet: $qProcessInfo#dc intern-state < 7> read packet: $E01#a6 intern-state < 6> send packet: $qC#b4 intern-state < 7> read packet: $QC1#c5 intern-state < 5> send packet: $?#3f intern-state < 291> read packet: $T00thread:1;name:Mock Accelerator Thread;threads:1;thread-pcs:0000000000001004;00:0010000000000000;01:0110000000000000;02:0210000000000000;03:0310000000000000 ;04:0410000000000000;05:0510000000000000;reason:trace;description:6d6f636b20616363656c657261746f72207468726561642073746f70706564;llvm#83 intern-state < 16> send packet: $qProcessInfo#dc intern-state < 7> read packet: $E01#a6 intern-state < 16> send packet: $qProcessInfo#dc intern-state < 7> read packet: $E01#a6 intern-state < 43> send packet: $qXfer:features:read:target.xml:0,131071#78 intern-state < 889> read packet: $l<?xml version="1.0"?> <target version="1.0"> <architecture>x86_64</architecture> <feature> <reg name="r0" bitsize="64" regnum="0" offset="0" encoding="uint" format="hex" group="General Purpose Registers" /> <reg name="r1" bitsize="64" regnum="1" offset="8" encoding="uint" format="hex" group="General Purpose Registers" /> <reg name="sp" bitsize="64" regnum="2" offset="16" encoding="uint" format="hex" group="General Purpose Registers" generic="sp" /> <reg name="fp" bitsize="64" regnum="3" offset="24" encoding="uint" format="hex" group="General Purpose Registers" generic="fp" /> <reg name="pc" bitsize="64" regnum="4" offset="32" encoding="uint" format="hex" group="General Purpose Registers" generic="pc" /> <reg name="flags" bitsize="64" regnum="5" offset="40" encoding="uint" format="hex" group="General Purpose Registers" /> </feature> </target> llvm#82 intern-state < 19> send packet: $p0;thread:0001;llvm#89 intern-state < 20> read packet: $0010000000000000#01 intern-state < 16> send packet: $qProcessInfo#dc intern-state < 7> read packet: $E01#a6 intern-state < 19> send packet: $p0;thread:0001;llvm#89 intern-state < 20> read packet: $0010000000000000#01 intern-state < 16> send packet: $qProcessInfo#dc intern-state < 7> read packet: $E01#a6 intern-state < 16> send packet: $qProcessInfo#dc intern-state < 7> read packet: $E01#a6 intern-state < 16> send packet: $qProcessInfo#dc intern-state < 7> read packet: $E01#a6 intern-state < 26> send packet: $qStructuredDataPlugins#02 intern-state < 6> read packet: $[]#b8 intern-state < 26> send packet: $qMemoryRegionInfo:1004#d9 intern-state < 41> read packet: $error:6e6f7420696d706c656d656e746564;#f7 intern-state < 16> send packet: $jThreadsInfo#c1 intern-state < 198> read packet: $[{"description":"mock accelerator thread stopped","name":"Mock Accelerator Thread","reason":"trace","registers":{"2":"0210000000000000","3":"0310000000000000" ,"4":"0410000000000000"}],"tid":1}]]#4a ```
addmisol
pushed a commit
that referenced
this pull request
Aug 9, 2026
…ical blocks (llvm#215036) Merging identical blocks threads their differing values through the predecessors' terminators as new successor operands, but the only legality question asked of a predecessor was whether its terminator implements `BranchOpInterface` (`ableToUpdatePredOperands`). The transform's implicit assumption is that such a terminator can forward operands of **any** type — false for dialects whose branch ops constrain successor operand types. The LLVM dialect terminators declare theirs as `Variadic<LLVM_Type>`, so merging two blocks that differ in, say, an index-typed operand rewrote a verifying `llvm.cond_br` into one that no longer verifies. Reproducer (mixed-dialect IR of the kind a progressive lowering/raising pipeline carries), via `mlir-opt -pass-pipeline='builtin.module(func.func(canonicalize{region-simplify=aggressive}))'`: ```mlir func.func @f(%m: memref<4xf32>, %c: i1) { %f = arith.constant 1.0 : f32 %i0 = arith.constant 0 : index %i1 = arith.constant 1 : index llvm.cond_br %c, ^a, ^b ^a: memref.store %f, %m[%i0] : memref<4xf32> llvm.return ^b: memref.store %f, %m[%i1] : memref<4xf32> llvm.return } ``` previously produced ``` error: 'llvm.cond_br' op operand #1 must be variadic of LLVM dialect-compatible type, but got 'index' note: see current operation: "llvm.cond_br"(%arg1, %1, %2)[^bb1, ^bb1] ... ``` i.e. the transform manufactured IR that cannot verify. (Any greedy driver running at `GreedySimplifyRegionLevel::Aggressive` — the `applyPatternsGreedily` default — hits this; downstream we currently work around it by dropping to `Normal`.) This adds `mayForwardTypeToSuccessor(unsigned index, Type type)` to `BranchOpInterface`, default permissive, and makes block merging refuse a cluster when any predecessor terminator refuses any of the would-be block argument types. The LLVM dialect terminators (`br`, `cond_br`, `switch`, `invoke`, `indirectbr`) override it with `isCompatibleType`. The new test pins both directions: the index-typed merge is refused, an i32-typed merge through `llvm.cond_br` still happens. Assisted-by: Claude
addmisol
pushed a commit
that referenced
this pull request
Aug 14, 2026
…ction of a mask (llvm#215187) foldPartialReduceAdd synthesises the reduction's multiplier at the operand's type. At i1 a splat of 1 is all ones, which sign extends to -1, so the signed forms compute (-1) x (-1) = +1 per lane and sum to +n where sum(sext(mask)) must be -n. ```llvm %cmp = icmp eq <16 x i8> %a, %b %sext = sext <16 x i1> %cmp to <16 x i32> %r = call <4 x i32> @llvm.vector.partial.reduce.add(<4 x i32> %acc, <16 x i32> %sext) ``` -mattr=+neon sums to -n: ``` cmeq v1.16b, v1.16b, v2.16b sshll v2.8h, v1.8b, #0 sshll2 v1.8h, v1.16b, #0 saddw v0.4s, v0.4s, v2.4h saddw2 v0.4s, v0.4s, v2.8h saddw v0.4s, v0.4s, v1.4h saddw2 v0.4s, v0.4s, v1.8h ``` -mattr=+neon,+dotprod sums to +n: ``` movi v3.2d, #0xffffffffffffffff cmeq v1.16b, v1.16b, v2.16b sdot v0.4s, v1.16b, v3.16b ``` This patch extends i1 masks to the promoted type before the multiplier is built. That gives `movi v3.16b, #1` and the dot product path agrees with the expansion. Part of llvm#204897.
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 19, 2026
…list (llvm#216847) `Thread::ClearStackFrames` keeps the previous public frame list as the predecessor of the next unwinder list. When a scripted frame provider is registered, that public list is a `SyntheticStackFrameList` holding `BorrowedStackFrames`, and the unwinder list's merge step reuses a predecessor frame whenever the stack IDs match, so it adopted frames belonging to the provider's list. `UpdatePreviousFrameFromCurrentFrame` refreshes `StackFrame::m_frame_index`, but `BorrowedStackFrame::GetFrameIndex()` returns its own `m_new_frame_index`, which supersedes it. The adopted frame keeps reporting its index from the previous stop, so once the stack grows the backtrace stops counting up: ``` frame #1: middle frame #1: main frame #2: start ``` Such a frame also delegates its stack ID, register context and symbol context to a frame from the previous stop that the merge never refreshes, so it could report stale state as well. In the backtrace above, main also lost its source location. When the merge finds a matching predecessor frame that is a `BorrowedStackFrame`, keep the freshly unwound frame instead of adopting it. Only providers create BorrowedStackFrames, so this never drops a frame the unwinder built itself. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
addmisol
pushed a commit
that referenced
this pull request
Aug 21, 2026
…llvm#217377) Inline frames share the concrete frame's PC, so they share its address convention. Hardcoding false made GetFrameCodeAddressForSymbolication look up PC-1, resolving sc.symbol to the preceding symbol when the PC is a function's first instruction. StackFrameListTest checks that every frame sharing the concrete frame's PC reports the same address from GetFrameCodeAddressForSymbolication. Frame 1 reports PC-1 without this change. The yaml object file was written with help of Claude, and it creates a backtrace like this: ``` frame #0: 0x000000000000000d inner(x=<unavailable>) at inl.cpp:2:13 [inlined] frame #1: 0x000000000000000d outer(x=<unavailable>) at inl.cpp:6:27 ```
addmisol
pushed a commit
that referenced
this pull request
Aug 25, 2026
…vm#217659) Added in llvm#216840 / b0e9c53. This is failing on our downstream Arm 32-bit Linux bot: ``` * thread #1, name = 'a.out', stop reason = breakpoint 1.1 * frame #0: 0x013d0630 a.out`compute(a=<unavailable>, b=<unavailable>) at main.c:3:10 [synthetic] frame #1: 0x013d065c a.out`main at main.c:6:25 frame #2: 0xea2b739a libc.so.6` frame #3: 0xea2b743e libc.so.6`__libc_start_main + 94 frame #4: 0x013d0538 a.out`_start + 40 Expecting sub string: "compute(a=3, b=4)" (was not found) ``` I have not had time to reproduce it locally, but I did notice that the test packs a struct of registers using `Q` (8 bytes) regardless of register size. https://docs.python.org/3/library/struct.html#format-characters Which probably works because most targets have 64-bit GPRs and any non-64-bit registers don't take part in debug info lookups. By using the actual register sizes we can fix the test on 32-bit. I've tested this on x86_64, AArch64 and Arm-32-bit Linux.
addmisol
pushed a commit
that referenced
this pull request
Aug 25, 2026
…llvm#217525) Example: ```llvm loop.5: %iv.5 = phi i64 [ %next.5, %body.5 ], [ 0, %body.4 ] %value.5 = phi i32 [ %arg, %body.5 ], [ 0, %body.4 ] %cmp.5 = icmp slt i64 %iv.5, 10 br i1 %cmp.5, label %body.5, label %loop.4.latch body.5: %negative = icmp slt i32 %value.5, 0 call void @llvm.assume(i1 %negative) %next.5 = add i64 %iv.5, 1 br label %loop.5 ``` In this code, fully unrolling the enclosing nest clones the assumption once per iteration, and every clone constrains `%arg`, leaving 10,009 assumptions on one value. `registerAssumption()` rescans the whole cache on each registration, and `assumptionsFor()` returns every assumption affecting a value, all of which its callers inspect (`computeKnownBitsFromContext()` merges each fact). Registering n assumptions therefore costs O(n^2), and each of the 33,300 queries here costs O(n): `opt -O2` takes 59.6s on an asserts build, 99.5% of it in `LoopFullUnrollPass`, against 0.4s for the same IR without the assumption. The rescan is asserts-only; the query cost is in every build. Fix: bound both walks. `registerAssumption()` verifies only while the cache holds at most 64 assumptions, the case its own comment describes; larger caches are left to `AssumptionCacheTracker::verifyAnalysis()`, which now also rejects a cached assumption belonging to another function or not a call to `@llvm.assume`, and scopes its set of cached assumptions per function. `assumptionsFor()` returns only the first `-max-assumes-per-value` assumptions affecting a value, 1024 by default, so a query costs at most that many visits. Callers that must see every assumption use the new `allAssumptionsFor()`; the only one is the cache verification in `CodeExtractor`. The limit is a global written through `cl::location`, so `assumptionsFor()` stays inline in the header. The oldest are kept because an assumption is only usable at contexts below it, so those apply at the most program points, and rejecting one is dearer than using it: a hit is a `comesBefore()` check and ends the walk, while a miss scans up to 15 instructions for anything that could interrupt control flow. Keeping the newest inverts both. On a value with 8192 assumptions and 2,000 queries it costs 7.35s against 0.36s, and on 8 clones of one assumption a limit of 1 leaves 5 of them where keeping the oldest leaves 1, as no limit at all does. Deduplicating instead is not available here. The cache is an analysis and cannot erase the calls, and dropping entries for calls still in the IR would contradict its own verifier. Erasing them is what already happens, and it is the cost being bounded: assume k is known to be redundant only because `computeKnownBits()` merged the k-1 already cached, so removing n duplicates is itself O(n^2). No cheaper test is available, as the clones are distinct `icmp`s, and `early-cse` and `gvn` leave the calls alone because `@llvm.assume` writes inaccessible memory. Nor are duplicates the general case: the six assumptions in `Analysis/ScalarEvolution/avoid-assume-hang.ll` are all different. The cleanup outlives the limit, as the assumption which proves the copies redundant is the first one. The example takes 3.7s and its `-O2` output is unchanged. Normal code is unaffected: below the limit `assumptionsFor()` returns what it returned before, so no fact is lost, and real code stays far below it. Of the 45,340 `.ll` files under `llvm/test`, only the file above exceeds even a limit of 16, and it exists because of this same explosion; the C++ and Fortran translation units tested exceed none. `opt -O3` over pre-optimization IR from six LLVM translation units shows no difference beyond run-to-run noise. <details> <summary>Assumption-count scaling</summary> `opt -passes=instsimplify` over a function making 2,000 queries against a value affected by a varying number of assumptions: ``` assumptions unpatched patched 64 0.03s 0.03s 256 0.04s 0.04s 1024 0.21s 0.21s 2048 0.70s 0.23s 4096 2.55s 0.27s 8192 9.86s 0.36s ``` This bounds the constant, not the shape: a value with 1024 assumptions is still 1024 visits per query. </details> <details> <summary>Full reproducer</summary> ```llvm define void @nested(i32 %arg) { entry: br label %loop.1 loop.1: %iv.1 = phi i64 [ %next.1, %loop.1.latch ], [ 0, %entry ] %cmp.1 = icmp slt i64 %iv.1, 10 br i1 %cmp.1, label %loop.2, label %exit loop.2: %iv.2 = phi i64 [ %next.2, %loop.2.latch ], [ 0, %loop.1 ] %value.2 = phi i32 [ %next.value.2, %loop.2.latch ], [ 0, %loop.1 ] %cmp.2 = icmp slt i64 %iv.2, 10 br i1 %cmp.2, label %body.2, label %loop.1.latch body.2: %next.value.2 = add i32 %value.2, 1 %enter.3 = icmp slt i32 %value.2, 0 br i1 %enter.3, label %loop.3, label %loop.2.latch loop.3: %iv.3 = phi i64 [ %next.3, %loop.3.latch ], [ 0, %body.2 ] %cmp.3 = icmp slt i64 %iv.3, 10 br i1 %cmp.3, label %loop.4, label %loop.2.latch loop.4: %iv.4 = phi i64 [ %next.4, %loop.4.latch ], [ 0, %loop.3 ] %value.4 = phi i32 [ %next.value.4, %loop.4.latch ], [ 0, %loop.3 ] %cmp.4 = icmp slt i64 %iv.4, 10 br i1 %cmp.4, label %body.4, label %loop.3.latch body.4: %next.value.4 = add i32 %value.4, 1 %enter.5 = icmp slt i32 %value.4, 0 br i1 %enter.5, label %loop.5, label %loop.4.latch loop.5: %iv.5 = phi i64 [ %next.5, %body.5 ], [ 0, %body.4 ] %value.5 = phi i32 [ %arg, %body.5 ], [ 0, %body.4 ] %cmp.5 = icmp slt i64 %iv.5, 10 br i1 %cmp.5, label %body.5, label %loop.4.latch body.5: %negative = icmp slt i32 %value.5, 0 call void @llvm.assume(i1 %negative) call void @llvm.stackrestore.p0(ptr null) %next.5 = add i64 %iv.5, 1 br label %loop.5 loop.4.latch: %next.4 = add i64 %iv.4, 1 br label %loop.4 loop.3.latch: %next.3 = add i64 %iv.3, 1 br label %loop.3 loop.2.latch: %next.2 = add i64 %iv.2, 1 br label %loop.2 loop.1.latch: %next.1 = add i64 %iv.1, 1 br label %loop.1 exit: ret void } declare void @llvm.stackrestore.p0(ptr) #0 declare void @llvm.assume(i1 noundef) #1 attributes #0 = { nocallback nofree nosync nounwind willreturn } attributes #1 = { nocallback nofree nosync nounwind willreturn memory(inaccessiblemem: write) } ``` </details>
addmisol
pushed a commit
that referenced
this pull request
Aug 28, 2026
This PR optimizes the AArch64 backend for 128-bit integer squaring (`u128 x * x`). It updates the instruction selection logic to combine `(A + B) + B` into `A + (B << 1)`. This allows the compiler to emit a single, optimal `add ... lsl #1` instruction instead of multiple separate `add` instructions. A baseline test was added in the first commit, and the optimization is provided in the second commit to clearly highlight the codegen improvements. Fixes llvm#213775
addmisol
pushed a commit
that referenced
this pull request
Sep 1, 2026
This PR should fix ASAN errors from https://lab.llvm.org/buildbot/#/builders/52/builds/19811 There are three sources of leaks: 1. TargetPassConfig not being `PM.add()`ed ``` Direct leak of 136 byte(s) in 1 object(s) allocated from: #1 ...createPassConfig(...) DirectXTargetMachine.cpp:216:10 <- return new DirectXPassConfig(*this, PM); #2 ...addPassesToEmitFile(...) DirectXTargetMachine.cpp:177:34 <- TargetPassConfig *PassConfig = createPassConfig(PM); Indirect leak of 144 byte(s) in 1 object(s) allocated from: #1 llvm::TargetPassConfig::TargetPassConfig(...) TargetPassConfig.cpp:604:10 <- Impl = new PassConfigImpl(); #2 DirectXPassConfig DirectXTargetMachine.cpp:112:9 ``` 2. MachineModuleInfoWrapperPass not being `PM.add()`ed ``` Direct leak of 2624 byte(s) in 1 object(s) allocated from: #1 compileModule(...) llc.cpp:786:9 <- new MachineModuleInfoWrapperPass(Target.get()); ...passed in at llc.cpp:842:19, then dropped unless the obj+complete-pipeline branch ran ``` 3. Orphaned GlobalVariables that were detached from the module but got never deleted: - llvm/lib/Target/DirectX/DXILCBufferAccess.cpp:44: `Global->removeFromParent()`; - llvm/lib/Target/DirectX/DXILOpLowering.cpp:277: `NameGlobal->removeFromParent()`; ``` opt -S -dxil-cbuffer-access ... CBufferAccess/scalars.ll definitely lost: 57 bytes in 3 blocks (3 name entries) indirectly lost: 384 bytes in 3 blocks (3 × 128-byte GlobalVariable) ```
addmisol
pushed a commit
that referenced
this pull request
Sep 2, 2026
When flang is built with ASAN, one of the unit tests fails:
```
[ RUN ] FrontendActionTest.ParseSyntaxOnly
=================================================================
==94036==ERROR: AddressSanitizer: heap-use-after-free on address 0xef60299e1268 at pc 0xbf00842915d0 bp 0xffffcc819e50 sp 0xffffcc819e48
READ of size 2 at 0xef60299e1268 thread T0
#0 0xbf00842915cc in getShowColors /home/davspi01/llvm-project/llvm/../clang/include/clang/Basic/DiagnosticOptions.def:68:14
#1 0xbf00842915cc in showColors /home/davspi01/llvm-project/llvm/../clang/include/clang/Basic/DiagnosticOptions.h:159:13
#2 0xbf00842915cc in Fortran::frontend::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) /home/davspi01/llvm-project/flang/lib/Frontend/TextDiagnosticPrinter.cpp:116:27
#3 0xbf0088f08ef0 in clang::DiagnosticsEngine::Report(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) /home/davspi01/llvm-project/clang/lib/Basic/Diagnostic.cpp:625:11
#4 0xbf0088f09584 in clang::DiagnosticsEngine::ProcessDiag(clang::DiagnosticBuilder const&) /home/davspi01/llvm-project/clang/lib/Basic/Diagnostic.cpp:705:3
#5 0xbf0088f099ac in clang::DiagnosticsEngine::EmitDiagnostic(clang::DiagnosticBuilder const&, bool) /home/davspi01/llvm-project/clang/lib/Basic/Diagnostic.cpp:727:15
#6 0xbf0082d78778 in Emit /home/davspi01/llvm-project/llvm/../clang/include/clang/Basic/Diagnostic.h:1332:28
#7 0xbf0082d78778 in clang::DiagnosticBuilder::~DiagnosticBuilder() /home/davspi01/llvm-project/llvm/../clang/include/clang/Basic/Diagnostic.h:1367:26
#8 0xbf0083dacd7c in Fortran::frontend::FrontendAction::reportFatalSemanticErrors() /home/davspi01/llvm-project/flang/lib/Frontend/FrontendAction.cpp:310:5
<...>
```
* CompilerInstance is defaut constructed, which means it has a default
constructed CompilerInvocation.
* CompilerInstance::createDiagnostics is called.
* It makes a clang::DiagnosticsEngine and gives it a reference to
whatever getDiagnosticOpts() returns.
* That returns invocation->getDiagnosticOpts().
* CompilerInstance::setInvocation is called with a new invocation,
replacing the original invocation.
* The clang::DiagnosticsEngine now has a dangling reference to the
options in the original invocation.
To fix this, I have implemented the same thing that
b69dcb8 did for Clang.
Pass the invocation to the CompilerInstance constructor, and remove the
setInvocation method. So that you cannot mix up the order.
addmisol
pushed a commit
that referenced
this pull request
Sep 6, 2026
This PR should fix ASAN errors from https://lab.llvm.org/buildbot/#/builders/52/builds/19811 There are three sources of leaks: 1. TargetPassConfig not being `PM.add()`ed ``` Direct leak of 136 byte(s) in 1 object(s) allocated from: #1 ...createPassConfig(...) DirectXTargetMachine.cpp:216:10 <- return new DirectXPassConfig(*this, PM); #2 ...addPassesToEmitFile(...) DirectXTargetMachine.cpp:177:34 <- TargetPassConfig *PassConfig = createPassConfig(PM); Indirect leak of 144 byte(s) in 1 object(s) allocated from: #1 llvm::TargetPassConfig::TargetPassConfig(...) TargetPassConfig.cpp:604:10 <- Impl = new PassConfigImpl(); #2 DirectXPassConfig DirectXTargetMachine.cpp:112:9 ``` 2. MachineModuleInfoWrapperPass not being `PM.add()`ed ``` Direct leak of 2624 byte(s) in 1 object(s) allocated from: #1 compileModule(...) llc.cpp:786:9 <- new MachineModuleInfoWrapperPass(Target.get()); ...passed in at llc.cpp:842:19, then dropped unless the obj+complete-pipeline branch ran ``` 3. Orphaned GlobalVariables that were detached from the module but got never deleted: - llvm/lib/Target/DirectX/DXILCBufferAccess.cpp:44: `Global->removeFromParent()`; - llvm/lib/Target/DirectX/DXILOpLowering.cpp:277: `NameGlobal->removeFromParent()`; ``` opt -S -dxil-cbuffer-access ... CBufferAccess/scalars.ll definitely lost: 57 bytes in 3 blocks (3 name entries) indirectly lost: 384 bytes in 3 blocks (3 × 128-byte GlobalVariable) ```
addmisol
pushed a commit
that referenced
this pull request
Sep 6, 2026
When flang is built with ASAN, one of the unit tests fails:
```
[ RUN ] FrontendActionTest.ParseSyntaxOnly
=================================================================
==94036==ERROR: AddressSanitizer: heap-use-after-free on address 0xef60299e1268 at pc 0xbf00842915d0 bp 0xffffcc819e50 sp 0xffffcc819e48
READ of size 2 at 0xef60299e1268 thread T0
#0 0xbf00842915cc in getShowColors /home/davspi01/llvm-project/llvm/../clang/include/clang/Basic/DiagnosticOptions.def:68:14
#1 0xbf00842915cc in showColors /home/davspi01/llvm-project/llvm/../clang/include/clang/Basic/DiagnosticOptions.h:159:13
#2 0xbf00842915cc in Fortran::frontend::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) /home/davspi01/llvm-project/flang/lib/Frontend/TextDiagnosticPrinter.cpp:116:27
#3 0xbf0088f08ef0 in clang::DiagnosticsEngine::Report(clang::DiagnosticsEngine::Level, clang::Diagnostic const&) /home/davspi01/llvm-project/clang/lib/Basic/Diagnostic.cpp:625:11
#4 0xbf0088f09584 in clang::DiagnosticsEngine::ProcessDiag(clang::DiagnosticBuilder const&) /home/davspi01/llvm-project/clang/lib/Basic/Diagnostic.cpp:705:3
#5 0xbf0088f099ac in clang::DiagnosticsEngine::EmitDiagnostic(clang::DiagnosticBuilder const&, bool) /home/davspi01/llvm-project/clang/lib/Basic/Diagnostic.cpp:727:15
#6 0xbf0082d78778 in Emit /home/davspi01/llvm-project/llvm/../clang/include/clang/Basic/Diagnostic.h:1332:28
#7 0xbf0082d78778 in clang::DiagnosticBuilder::~DiagnosticBuilder() /home/davspi01/llvm-project/llvm/../clang/include/clang/Basic/Diagnostic.h:1367:26
#8 0xbf0083dacd7c in Fortran::frontend::FrontendAction::reportFatalSemanticErrors() /home/davspi01/llvm-project/flang/lib/Frontend/FrontendAction.cpp:310:5
<...>
```
* CompilerInstance is defaut constructed, which means it has a default
constructed CompilerInvocation.
* CompilerInstance::createDiagnostics is called.
* It makes a clang::DiagnosticsEngine and gives it a reference to
whatever getDiagnosticOpts() returns.
* That returns invocation->getDiagnosticOpts().
* CompilerInstance::setInvocation is called with a new invocation,
replacing the original invocation.
* The clang::DiagnosticsEngine now has a dangling reference to the
options in the original invocation.
To fix this, I have implemented the same thing that
b69dcb8 did for Clang.
Pass the invocation to the CompilerInstance constructor, and remove the
setInvocation method. So that you cannot mix up the order.
addmisol
pushed a commit
that referenced
this pull request
Sep 6, 2026
The test added by 076da86 / llvm#180605 fails when run with ASAN: ``` ==339162==ERROR: AddressSanitizer: global-buffer-overflow on address 0xc565e049c86e at pc 0xc565e0ee9268 bp 0xffffd5d7de20 sp 0xffffd5d7de18 READ of size 1 at 0xc565e049c86e thread T0 #0 0xc565e0ee9264 in Fortran::runtime::TrimTrailingSpaces(char const*, unsigned long) /home/davspi01/llvm-project/flang-rt/lib/runtime/tools.cpp:21:19 #1 0xc565e0e41d7c in Fortran::runtime::io::OpenStatementState::set_path(char const*, unsigned long) /home/davspi01/llvm-project/flang-rt/lib/runtime/io-stmt.cpp:291:17 #2 0xc565e0d56a84 in _FortranAioSetFile /home/davspi01/llvm-project/flang-rt/lib/runtime/io-api.cpp:1072:11 <...> 0xc565e049c86e is located 0 bytes after global variable '.str.263' defined in '/home/davspi01/llvm-project/flang-rt/unittests/Runtime/ExternalIOTest.cpp' (0xc565e049c860) of size 14 '.str.263' is ascii string 'opennewextant' ``` The test calls SetFile with "opennewextant" and a length of 15, but the length of that string is 13 (characters). TrimTrailingSpaces trusts that length and does `s[n - 1]`, which accesses out of bounds. Fix this by using the correct length of the string.
addmisol
pushed a commit
that referenced
this pull request
Sep 8, 2026
To match VirtualSize, and Microsoft's dumpbin which prints both as hex: SECTION HEADER #1 .text name 440B4 virtual size 1000 virtual address (0000000140001000 to 00000001400450B3) 44200 size of raw data llvm-readobj before this change: VirtualSize: 0x3478 VirtualAddress: 0x74000 RawDataSize: 3584 And after: VirtualSize: 0x3478 VirtualAddress: 0x74000 RawDataSize: 0xe00 This was pointed out on llvm#220618, where I was having to manually convert the numbers to compare them.
addmisol
pushed a commit
that referenced
this pull request
Sep 8, 2026
…m#205764 (llvm#221843) New LifetimeSafetyOpts fields were added in llvm#221610 but they are not initialized in clang/unittests/Analysis/LifetimeSafetyTest.cpp, leading to use-of-uninitialized-memory (https://lab.llvm.org/buildbot/#/builders/164/builds/25165): ``` WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x555571559cbc in clang::lifetimes::internal::(anonymous namespace)::LifetimeChecker::LifetimeChecker(clang::lifetimes::internal::LoanPropagationAnalysis const&, clang::lifetimes::internal::MovedLoansAnalysis const&, clang::lifetimes::internal::LiveOriginsAnalysis const&, clang::lifetimes::internal::FactManager&, clang::AnalysisDeclContext&, clang::lifetimes::LifetimeSafetySemaHelper*, clang::lifetimes::LifetimeSafetyOpts const&) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Analysis/LifetimeSafety/Checker.cpp:108:9 #1 0x5555715453cd in clang::lifetimes::internal::runLifetimeChecker(clang::lifetimes::internal::LoanPropagationAnalysis const&, clang::lifetimes::internal::MovedLoansAnalysis const&, clang::lifetimes::internal::LiveOriginsAnalysis const&, clang::lifetimes::internal::FactManager&, clang::AnalysisDeclContext&, clang::lifetimes::LifetimeSafetySemaHelper*, clang::lifetimes::LifetimeSafetyOpts const&) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Analysis/LifetimeSafety/Checker.cpp:575:19 #2 0x555571524c1e in clang::lifetimes::internal::LifetimeSafetyAnalysis::run() /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Analysis/LifetimeSafety/LifetimeSafety.cpp:98:3 #3 0x55555c3da25b in LifetimeTestRunner /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/unittests/Analysis/LifetimeSafetyTest.cpp:71:15 ... Uninitialized value was stored to memory at #0 0x55555bcd06c7 in __msan_memcpy /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1760:3 #1 0x5555715238ed in clang::lifetimes::internal::LifetimeSafetyAnalysis::LifetimeSafetyAnalysis(clang::AnalysisDeclContext&, clang::lifetimes::LifetimeSafetySemaHelper*, clang::lifetimes::LifetimeSafetyOpts const&) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Analysis/LifetimeSafety/LifetimeSafety.cpp:54:39 #2 0x55555c3da1b9 in make_unique<clang::lifetimes::internal::LifetimeSafetyAnalysis, clang::AnalysisDeclContext &, std::nullptr_t, clang::lifetimes::LifetimeSafetyOpts &, 0> /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/libcxx_install_msan_track_origins/include/c++/v1/__memory/unique_ptr.h:713:30 #3 0x55555c3da1b9 in LifetimeTestRunner /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/unittests/Analysis/LifetimeSafetyTest.cpp:70:9 ``` This patch fixes the issue by initializing the fields in the test to true, which maintains the behavior prior to the new fields being added. Additionally, this patch does a similar drive-by fix to the SuggestAnnotations field (added in llvm#205764). Although there has been no MSan report, that's likely either an MSan false negative or insufficient test coverage.
addmisol
pushed a commit
that referenced
this pull request
Sep 10, 2026
`target create` never returns for a little-endian 32-bit MIPS ELF file, on any host whose platform advertises `armv7m`/`armv7em` compatibility. On Darwin that is every platform, since `PlatformDarwin::GetCompatibleArchs()` lists both for every arm64/arm64e host and falls through to that same list for any other host core. It is found by `lldb-target-fuzzer`. Reproduce with a 52-byte ELF32 header (`ELFCLASS32`, `ELFDATA2LSB`, `e_machine = EM_MIPS`, `e_flags = EF_MIPS_ARCH_32`, everything else zero), saved as `mips32el.elf`: ``` (lldb) target create mips32el.elf ``` This never returns. Attaching a debugger to the hung process shows the same three frames looping forever, with the call stack never growing: ``` frame #1: cores_match(core1=eCore_arm_armv7m, core2=eCore_mips32el, try_inverse=false, ...) at ArchSpec.cpp:1575 [inlined] frame #2: ArchSpec::IsMatch(rhs=..., match=CompatibleMatch) at ArchSpec.cpp:1449 frame #3: Platform::IsCompatibleArchitecture(...) at Platform.cpp:1193 ``` `cores_match()` checks `core1` against `core2`. When nothing matches and the caller did not ask for an exact match, it sets `try_inverse` and retries once with the two cores swapped. It retries because the rule tables are not symmetric: a core lists only what it accepts, not everything that accepts it. Every case that reaches this fallback must leave `try_inverse` false on the way out, so the swap happens at most once. Three cases, `eCore_arm_armv7em`, `eCore_arm_armv7m`, and `eCore_mips32el`, instead set it back to true unconditionally. When both sides of a comparison are one of these three, the swapped call re-arms `try_inverse`, and the tail call back into `cores_match()` recurses forever. This is a tail call, so an optimizing compiler turns the recursion into a loop instead of a growing stack. That is why the process spins instead of crashing with a stack overflow. The three cases cannot simply leave `try_inverse` false like their siblings. `ArchSpec("mipsel").IsCompatibleMatch(ArchSpec("mips64el"))` is true today only because of this same swap: `eCore_mips32el`'s own rule says nothing about 64-bit MIPS, but `eCore_mips64el`'s rule accepts any 32-bit MIPS core with the same endianness, and only the inverted comparison reaches that rule. Instead, split the switch into a one-directional helper that never recurses, and try both directions from a plain, non-recursive wrapper: ``` cores_match(A, B) := cores_match_one_direction(A, B) || cores_match_one_direction(B, A) ``` This keeps every existing one-directional rule exactly as it was, including the mips32el/mips64el rule above, and makes a second retry impossible no matter what any case does. Adds two regression tests to ArchSpecTest.cpp. One asserts that the previously-hanging pairs now return false right away. The other locks in the two relationships that depend on checking both directions, so a future change cannot bring the recursion back by "fixing" the three cases the naive way. Assisted-by: claude
addmisol
pushed a commit
that referenced
this pull request
Sep 10, 2026
) BufferedStackTrace::UnwindFast walks the stack assuming frame[0] is the caller's frame pointer and frame[1] the return address. Alpha chains neither, so the walk yields a few garbage frames and then stops: ``` freed by thread T0 here: #0 0x020000971274 in free asan_malloc_linux.cpp:51 #1 0x0200007fa48c (<unknown module>) ``` Opt Alpha out of the fast unwinder the way Linux/MIPS already is. The _Unwind_Backtrace based unwinder gives complete traces; with it, GCC's g++.dg/asan/deep-stack-uaf-1.C passes on alpha-unknown-linux-gnu.
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
2 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.
Implement
getAddrSpaceCastPreservedPtrMaskfor AMDGPU to enable theInferAddressSpaces pass to recover address space information after
pointer arithmetic on flat pointers.
On AMDGPU, flat addresses use the high 32 bits to identify the memory
aperture (local, private, global) and the low 32 bits for the segment
address. This means any bit manipulation confined to the low 32 bits
preserves the address space.
This implementation returns a 32-bit mask for casts from flat address
space to local or global address spaces. Private address space is not
handled due to complications with the "globally addressable scratch"
feature.