Skip to content

[AMDGPU] Support atomic load for vector float types (v2f32, v4f32, v2f16, v4f16, v8f16) - #1

Closed
harrisonGPU wants to merge 1 commit into
mainfrom
amdgpu/atomic-load-select
Closed

[AMDGPU] Support atomic load for vector float types (v2f32, v4f32, v2f16, v4f16, v8f16)#1
harrisonGPU wants to merge 1 commit into
mainfrom
amdgpu/atomic-load-select

Conversation

@harrisonGPU

@harrisonGPU harrisonGPU commented Apr 20, 2026

Copy link
Copy Markdown
Owner

Stack created with GitHub Stacks CLI • Give Feedback 💬

harrisonGPU pushed a commit that referenced this pull request Apr 20, 2026
@pfusik
[InstCombine] Generalize (A + 1) + ~B fold to any constant (llvm#18…
c0d4959 
…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
harrisonGPU pushed a commit that referenced this pull request Apr 20, 2026
@GeorgeHuyubo George Hu
[lldb] Fix stale Symbol pointer crash in statusline after 'target sym…
02fdc8f 
…bols add' (llvm#188377)

Context: 
lldb might crash when running to a debuggee crashing state and do a
target symbols add command.
Backtrace: 
```
 #0 0x000055ca6790dc65 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/hyubo/osmeta/external/llvm-project/llvm/lib/Support/Unix/Signals.inc:848:11
 #1 0x000055ca6790e434 PrintStackTraceSignalHandler(void*) /home/hyubo/osmeta/external/llvm-project/llvm/lib/Support/Unix/Signals.inc:931:1
 #2 0x000055ca6790b839 llvm::sys::RunSignalHandlers() /home/hyubo/osmeta/external/llvm-project/llvm/lib/Support/Signals.cpp:104:5
 llvm#3 0x000055ca6790ff6b SignalHandler(int, siginfo_t*, void*) /home/hyubo/osmeta/external/llvm-project/llvm/lib/Support/Unix/Signals.inc:430:38
 llvm#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
 llvm#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
 llvm#6 0x00007fe9ec649170 SignalHandler(int, siginfo_t*, void*) /home/hyubo/osmeta/external/llvm-project/llvm/lib/Support/Unix/Signals.inc:429:7
 llvm#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
 llvm#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
 llvm#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
llvm#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
llvm#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
llvm#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>
harrisonGPU pushed a commit that referenced this pull request May 6, 2026
@kastiglione
[lldb] Define breakpoint location "." to mean the location(s) at whic…
749af7f 
…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
harrisonGPU pushed a commit that referenced this pull request May 6, 2026
@vitalybuka
[LowerTypeTests] Add debug info to jump table entries (llvm#194493)
82bf5e8 
[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.
harrisonGPU pushed a commit that referenced this pull request May 6, 2026
@thurstond
Revert "[llvm-profgen] Support [buildid:]0xaddr format in perfscript …
1f83fdb 
…input" (llvm#195551)

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

```
Failed Tests (1):
  LLVM :: tools/llvm-profgen/filter-build-id.test
```
```
==llvm-profgen==3809550==ERROR: AddressSanitizer: container-overflow on address 0x6e80441e1762 at pc 0x6216c3f2cdce bp 0x7fff3c3ddf60 sp 0x7fff3c3dd710
READ of size 8 at 0x6e80441e1762 thread T0
    #0 0x6216c3f2cdcd in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long) /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:848:7
    #1 0x6216c3f2d25c in bcmp /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:894:10
    #2 0x6216c400b836 in operator== /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/include/llvm/ADT/StringRef.h:914:10
    llvm#3 0x6216c400b836 in operator!= /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/include/llvm/ADT/StringRef.h:917:69
    llvm#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
    llvm#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
    llvm#6 0x6216c40150d8 in parseSample /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/PerfReader.cpp:1118:3
    llvm#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
    llvm#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
    llvm#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
    llvm#10 0x6216c3ff2c7a in main /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/llvm/tools/llvm-profgen/llvm-profgen.cpp:229:19
    llvm#11 0x72404502a8c0  (/usr/lib/x86_64-linux-gnu/libc.so.6+0x2a8c0) (BuildId: ae327f26c123ea1374623c41e676a4bf00e5c1cb)
    llvm#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
    llvm#3 0x724045511c07 in allocate_at_least /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/libcxx/include/__memory/allocator.h:99:13
    llvm#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
    llvm#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
    llvm#6 0x724045511c07 in __allocate_long_buffer /home/b/sanitizer-x86_64-linux-bootstrap-asan/build/llvm-project/libcxx/include/string:2259:21
    llvm#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
    llvm#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
    llvm#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
    llvm#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
    llvm#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
    llvm#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)
```
harrisonGPU pushed a commit that referenced this pull request May 6, 2026
@mustartt
[SelectionDAG] Look through FREEZE in getCopyToRegs when checking isZ…
5399086 
…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.
harrisonGPU pushed a commit that referenced this pull request May 15, 2026
@thurstond
[AArch64][test] Fix use-after-scope in createInstrInfo (llvm#197622)
13a6287 
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
llvm#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
llvm#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
llvm#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
llvm#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
harrisonGPU pushed a commit that referenced this pull request Oct 6, 2026
@felipepiovezan
[lldb] Reject thread until targets outside of an inline frame's funct…
150f9dc 
…ion (llvm#227800)

`thread until -f N <line>` rejects a line outside of the function of
frame N.

Before this patch, for an inline frame, it checked the concrete
function, not the inlined function, so it accepted lines of other
inlined functions. The until plan then ignored a hit of such a target,
because it is not in the scope of frame N.

This commit changes GetStepUntilAddresses to only accepts an address if
its innermost inlined function is the one of frame N, as it does for a
regular frame.

As a before/after example, consider this backtrace:

```
  frame #0: 0x00000001000003c0 deep`sink(x=81) at deep.c:4:6 [opt]
  frame #1: 0x0000000100000418 deep`level3(a=48) at deep.c:11:3 [opt] [inlined]
  frame #2: 0x0000000100000404 deep`level2(b=37) at deep.c:20:3 [opt] [inlined]
  frame llvm#3: 0x00000001000003f0 deep`level1(c=42) at deep.c:28:3 [opt] [inlined]
  frame llvm#4: 0x00000001000003dc deep`main at deep.c:33:3 [opt]
```

This patch changes behavior as follows:

```
command                             gdb        lldb before    lldb after
until -f 1 <later line in frame 2>  that line  process exits  error
until -f 2 <later line in frame 1>  that line  process exits  error
harrisonGPU pushed a commit that referenced this pull request Oct 6, 2026
@felipepiovezan
[lldb] Step through inlined code when stepping out of inline frame N …
c834457 
…> 0 (llvm#226910)

To step out of an inline frame N > 0, ThreadPlanStepOut first steps out
to frame N, then queues a plan that steps through the inlined block. Due
to a bug, ShouldStop marks the plan complete right after it queues that
plan, so the thread stops as soon as it reaches frame N, with no stop
reason.

In fact, the comment next to that code describes the intended behavior
while implementing something different: only call the StepOut plan done
if the "step out from line" plan cannot be queued.

For example, consider this backtrace:
```
  frame #0: 0x00000001000003c0 deep`sink(x=81) at deep.c:4:6 [opt]
  frame #1: 0x0000000100000418 deep`level3(a=48) at deep.c:11:3 [opt] [inlined]
  frame #2: 0x0000000100000404 deep`level2(b=37) at deep.c:20:3 [opt] [inlined]
  frame llvm#3: 0x00000001000003f0 deep`level1(c=42) at deep.c:28:3 [opt] [inlined]
  frame llvm#4: 0x00000001000003dc deep`main at deep.c:33:3 [opt]
```

This patch changes behavior as follows:

```
command                  before                          after
frame select 1; finish   level3 line 12, no stop reason  level2 line 21, step out
frame select 2; finish   level3 line 12, no stop reason  level1 line 29, step out
```
harrisonGPU pushed a commit that referenced this pull request Oct 6, 2026
@felipepiovezan
[lldb] Step through inlined code when stepping out of inline frame N …
fb21c44 
…> 0 (llvm#226910)

To step out of an inline frame N > 0, ThreadPlanStepOut first steps out
to frame N, then queues a plan that steps through the inlined block. Due
to a bug, ShouldStop marks the plan complete right after it queues that
plan, so the thread stops as soon as it reaches frame N, with no stop
reason.

In fact, the comment next to that code describes the intended behavior
while implementing something different: only call the StepOut plan done
if the "step out from line" plan cannot be queued.

For example, consider this backtrace:
```
  frame #0: 0x00000001000003c0 deep`sink(x=81) at deep.c:4:6 [opt]
  frame #1: 0x0000000100000418 deep`level3(a=48) at deep.c:11:3 [opt] [inlined]
  frame #2: 0x0000000100000404 deep`level2(b=37) at deep.c:20:3 [opt] [inlined]
  frame llvm#3: 0x00000001000003f0 deep`level1(c=42) at deep.c:28:3 [opt] [inlined]
  frame llvm#4: 0x00000001000003dc deep`main at deep.c:33:3 [opt]
```

This patch changes behavior as follows:

```
command                  before                          after
frame select 1; finish   level3 line 12, no stop reason  level2 line 21, step out
frame select 2; finish   level3 line 12, no stop reason  level1 line 29, step out
```
harrisonGPU pushed a commit that referenced this pull request Oct 6, 2026
@riyaz86a @riyazahmad86
[compiler-rt][asan] Allow optional leading dot in function names in c…
4693dfb 
…omplete_stack_trace.c (llvm#227969)

On AIX/XCOFF, the symbolizer reports function names with a leading dot
('.') because each function's executable code is stored in a separate
`.<funcname>` csect (the text-section entry point symbol). For example,
`read_2` is reported as `.read_2`.

The existing CHECK patterns required an exact match on the bare name,
causing the test to fail on AIX:

```
  expected: {{ *#1 0x.* in read_2 .*complete_stack_trace.c}}
  actual:   #1 0x... in .read_2 complete_stack_trace.c:23
```

Use `\.?` inside the FileCheck regex blocks to make the leading dot
optional, matching both ELF (bare name) and XCOFF (dot-prefixed name)
symbolizer output.

Co-authored-by: Riyaz Ahmad <riyaz.ahmad@ibm.com>
harrisonGPU pushed a commit that referenced this pull request Oct 11, 2026
@denniwang
Fix SystemZ TableGen crashing when GlobalISel is enabled (llvm#228227)
352a92f 
## Description

When I enable GlobalISel for SystemZ by adding `tablegen(LLVM
SystemZGenGlobalISel.inc -gen-global-isel)` in `SystemZ/CMakeList`, it
crashes with this trace:

```

0.	Program arguments: /Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen -gen-global-isel -I/Users/dennis/Developer/llvm-project/llvm/lib/Target/SystemZ -I/Users/dennis/Developer/llvm-project/build/include -I/Users/dennis/Developer/llvm-project/llvm/include -I /Users/dennis/Developer/llvm-project/llvm/lib/Target /Users/dennis/Developer/llvm-project/llvm/lib/Target/SystemZ/SystemZ.td --write-if-changed -o SystemZGenGlobalISel.inc -d SystemZGenGlobalISel.inc.d
 #0 0x00000001004897ac llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x1002f17ac)
 #1 0x0000000100486ff0 llvm::sys::RunSignalHandlers() (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x1002eeff0)
 #2 0x000000010048a0cc SignalHandler(int, __siginfo*, void*) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x1002f20cc)
 llvm#3 0x0000000184d8c144 (/usr/lib/system/libsystem_platform.dylib+0x180898144)
 llvm#4 0x00000001003a1158 llvm::gi::CopyConstantAsImmRenderer& llvm::gi::BuildMIAction::addRenderer<llvm::gi::CopyConstantAsImmRenderer, llvm::gi::RuleMatcher&, llvm::StringRef&>(llvm::gi::RuleMatcher&, llvm::StringRef&) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x100209158)
 llvm#5 0x00000001003a1158 llvm::gi::CopyConstantAsImmRenderer& llvm::gi::BuildMIAction::addRenderer<llvm::gi::CopyConstantAsImmRenderer, llvm::gi::RuleMatcher&, llvm::StringRef&>(llvm::gi::RuleMatcher&, llvm::StringRef&) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x100209158)
 llvm#6 0x00000001003a0688 (anonymous namespace)::GlobalISelEmitter::importNodeRenderer(llvm::gi::RuleMatcher&, llvm::gi::BuildMIAction&, llvm::TreePatternNode const&, std::__1::__list_iterator<std::__1::unique_ptr<llvm::gi::MatchAction, std::__1::default_delete<llvm::gi::MatchAction>>, void*>&) const (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x100208688)
 llvm#7 0x000000010039f11c (anonymous namespace)::GlobalISelEmitter::importExplicitUseRenderers(std::__1::__list_iterator<std::__1::unique_ptr<llvm::gi::MatchAction, std::__1::default_delete<llvm::gi::MatchAction>>, void*>, llvm::gi::RuleMatcher&, llvm::gi::BuildMIAction&, llvm::TreePatternNode const&) const (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x10020711c)
 llvm#8 0x0000000100394a6c (anonymous namespace)::GlobalISelEmitter::run(llvm::raw_ostream&) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x1001fca6c)
 llvm#9 0x0000000100392f74 llvm::TableGen::Emitter::OptClass<(anonymous namespace)::GlobalISelEmitter>::run(llvm::StringRef, llvm::RecordKeeper const&) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x1001faf74)
llvm#10 0x00000001004aea9c llvm::TableGen::Emitter::ApplyCallback(llvm::RecordKeeper const&, llvm::TableGenOutputFiles&, llvm::StringRef) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x100316a9c)
llvm#11 0x000000010048e968 llvm::TableGenMain(char const*, llvm::function_ref<bool (llvm::TableGenOutputFiles&, llvm::RecordKeeper const&)>) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x1002f6968)
llvm#12 0x00000001001f76d4 tblgen_main(int, char**) (/Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen+0x10005f6d4)
llvm#13 0x00000001849abe80
/bin/sh: line 1: 45648 Segmentation fault: 11  /Users/dennis/Developer/llvm-project/build/bin/llvm-tblgen -gen-global-isel -I/Users/dennis/Developer/llvm-project/llvm/lib/Target/SystemZ -I/Users/dennis/Developer/llvm-project/build/include -I/Users/dennis/Developer/llvm-project/llvm/include -I /Users/dennis/Developer/llvm-project/llvm/lib/Target /Users/dennis/Developer/llvm-project/llvm/lib/Target/SystemZ/SystemZ.td --write-if-changed -o SystemZGenGlobalISel.inc -d SystemZGenGlobalISel.inc.d
ninja: build stopped: subcommand failed.
```

Note that it compiles with no issues when it doesn't have the GlobalISel
instruction on the CMakeList setting.

Turns out the pattern is using `imm` when it should be an `timm`,
causing the pattern to break. After applying my changes, I was able to
build the SystemZ compiler and also ran the entire LLVM test suite.

### AI usage
- AI was used to help me decipher the stack trace and find out which
pattern was causing the issue.
- AI was used to help explain the difference between `imm` and `timm`,
amongst other keywords.
- AI was used to tell me what commands to run to build, and test if my
changes worked.
harrisonGPU pushed a commit that referenced this pull request Oct 11, 2026
@qiyao
[lldb] Recognize flag forms in DWARFFormValue's constant accessors (l…
a99159a 
…lvm#229738)

LLDB crashes on parsing a `DW_TAG_LLVM_ptrauth_type` with
`DW_AT_LLVM_ptrauth_address_discriminated`, here is the crash
inside lldb,

```
thread #1, stop reason = libc++: .../usr/include/c++/v1/optional:1150:libc++ Hardening assertion this->has_value() failed: optional operator*
called on a disengaged value

frame #2: llvm::DWARFTypePrinter<...>::appendUnqualifiedNameAfter(...)::'lambda'(...)::operator()(Attr=DW_AT_LLVM_ptrauth_address_discriminated) const at DWARFTypePrinter.h:375
   374        if (auto Form = D.find(Attr))
-> 375          return *Form->getAsUnsignedConstant();

(lldb) frame variable Form
(std::optional<DWARFFormValue>) Form =  Has Value=true  {
  Value = { m_form = DW_FORM_flag_present, m_value = (uval = 1, ...) }
}
```

The dereference that actually traps is one level deeper:
`Form->getAsUnsignedConstant()` itself returns `std::nullopt`, because
`DWARFFormValue::getAsUnsignedConstant()` and `getAsSignedConstant()`
only accept forms where `IsDataForm()` is true, and `IsDataForm()`
lists `sdata`, `udata`, and `data1` through `data8`, but not
`DW_FORM_flag` or `DW_FORM_flag_present`.

DWARF form values are grouped into classes, and `constant` and `flag`
are two separate classes. LLVM's own `DWARFFormValue` (in
`llvm/lib/DebugInfo/DWARF`) keeps that distinction: its
`getAsUnsignedConstant()` and `getAsSignedConstant()` check
`isFormClass(FC_Constant) || isFormClass(FC_Flag)`. LLDB's
`DWARFFormValue`'s two accessors check only `IsDataForm()`,that is
the divergence this crash exposes.

Add a new `IsFlagForm()`, parallel to the existing `IsBlockForm()`, and
have `getAsUnsignedConstant()` and `getAsSignedConstant()` accept
either `IsDataForm()` or `IsFlagForm()`, matching LLVM's own
`FC_Constant`/`FC_Flag` check. `DWARFFormValue::ExtractValue()` already
stores a flag's 0/1 value in `m_value.uval` the same way it stores any
other data form's value, so there is nothing to lose by accepting it
here.

Add a regression test building a class template whose argument type is
an address-discriminated `DW_TAG_LLVM_ptrauth_type`, then calling
`GetDIEClassTemplateParams`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@harrisonGPU