Conversation
trdthg
force-pushed
the
buddy-mlir-backend
branch
2 times, most recently
from
April 20, 2026 12:27
cae61e8 to
5faa117
Compare
yuzibo
force-pushed
the
main
branch
5 times, most recently
from
May 9, 2026 07:48
4ab1448 to
4851970
Compare
WuXintong123
force-pushed
the
main
branch
7 times, most recently
from
May 14, 2026 14:17
9f45e3c to
1e7ae41
Compare
WuXintong123
pushed a commit
that referenced
this pull request
May 14, 2026
llvm#183506 revealed a pre-existing use-after-scope in createInstrInfo (MSan bot: https://lab.llvm.org/buildbot/#/builders/164/builds/21562 [*]). This patch fixes the issue by changing the stack-allocated AArch64Subtarget (which goes out of scope once createInstrInfo() returns) into heap-allocated, allowing it to be safely stored in the returned AArch64InstrInfo. ----- [*] WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x55555666fabd in llvm::AArch64InstrInfo::getInstSizeInBytes(llvm::MachineInstr const&) const /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp:247:5 ... /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/unittests/Target/AArch64/InstSizes.cpp:85:3 #9 0x555556508559 in InstSizes_MOVaddrTagged_Test::TestBody() /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/unittests/Target/AArch64/InstSizes.cpp:301:3 ... Member fields were destroyed #0 0x555556498a1d in __sanitizer_dtor_callback_fields /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:1074:5 #1 0x5555564fbda6 in ~Triple /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/include/llvm/TargetParser/Triple.h:348:12 #2 0x5555564fbda6 in ~Triple /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/include/llvm/TargetParser/Triple.h:47:7 #3 0x5555564fbda6 in llvm::AArch64Subtarget::~AArch64Subtarget() /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/lib/Target/AArch64/AArch64Subtarget.h:38:7 #4 0x555556503396 in (anonymous namespace)::createInstrInfo(llvm::TargetMachine*) /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/unittests/Target/AArch64/InstSizes.cpp:38:1 #5 0x5555565084cb in InstSizes_MOVaddrTagged_Test::TestBody() /home/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/unittests/Target/AArch64/InstSizes.cpp:299:42
WuXintong123
force-pushed
the
main
branch
8 times, most recently
from
May 22, 2026 14:05
c50a52c to
98bad71
Compare
WuXintong123
force-pushed
the
main
branch
3 times, most recently
from
May 27, 2026 02:32
1dcaa37 to
1b19ecc
Compare
…opsrun test (llvm#4) Fix three issues found on RISC-V: 1. Fix use-after-free in block walk (Visitors.h) When walking blocks with ReverseDominanceIterator, the Traversal object returned by Iterator::makeIterable(region) was passed as a temporary directly to llvm::make_early_inc_range(). The temporary was destroyed at the end of the full expression while iterators from make_early_inc_range still referenced it. Store the result in a local variable with auto&& to extend the lifetime of the temporary and bind lvalue references for ForwardIterator. 2. Fix Shape dialect CstrBroadcastableOp fold and cast canonicalization Extend getShapeVec to look through tensor.cast operations so that folds can resolve shapes behind casts inserted by earlier canonicalization passes (e.g., ShapeOfOpToConstShapeOp). Add a new fold check in CstrBroadcastableOp::fold that recognizes broadcasting is trivially valid when at most one operand is non-scalar (resolved via getShapeVec). Rewrite CanonicalizeCastExtentTensorOperandsPattern to use modifyOpInPlace instead of replaceOpWithNewOp to avoid issues with op builder template instantiation. 3. Fix opsrun.py test invocation pattern for multithreaded_tests.py Convert direct test_foo() calls to run(test_foo) so that copy_and_update in multithreaded_tests.py properly strips them during import, preventing JIT execution at module load time which crashes on RISC-V due to R_RISCV_HI20 relocation range limits.
Co-authored-by: Cursor <cursoragent@cursor.com>
trdthg
force-pushed
the
buddy-mlir-backend
branch
from
June 2, 2026 06:54
5faa117 to
35c0800
Compare
trdthg
force-pushed
the
buddy-mlir-backend
branch
from
June 2, 2026 07:28
35c0800 to
63ed51e
Compare
WuXintong123
pushed a commit
that referenced
this pull request
Jun 5, 2026
Fix llvm#201615. Fix the issue that non atomic operations race in waiting queue, which causes missed futex wakeup signals. Confirmed by TSAN: ``` ================== WARNING: ThreadSanitizer: data race (pid=388518) Write of size 4 at 0x7ffd21cf98e4 by thread T23: #0 __llvm_libc_23_0_0_git::RawRwLock::notify_pending_threads() ./libc/src/__support/threads/raw_rwlock.h:443:44 #1 __llvm_libc_23_0_0_git::RawRwLock::unlock() ./libc/src/__support/threads/raw_rwlock.h:520:5 #2 randomized_thread_operation(SharedData*) ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:104:18 #3 thread_runner(void*) ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:148:5 Previous atomic read of size 4 at 0x7ffd21cf98e4 by thread T4: #0 __llvm_libc_23_0_0_git::cpp::Atomic<unsigned int>::load(...) ./libc/src/__support/CPP/atomic.h:115:5 #1 __llvm_libc_23_0_0_git::Futex::wait(...) ./libc/src/__support/threads/linux/futex_utils.h:43:17 #2 __llvm_libc_23_0_0_git::cpp::expected<int, int> __llvm_libc_23_0_0_git::rwlock::WaitingQueue::wait<Role::Reader>(...) ./libc/src/__support/threads/raw_rwlock.h:101:35 #3 __llvm_libc_23_0_0_git::rwlock::LockResult __llvm_libc_23_0_0_git::RawRwLock::lock_slow<Role::Reader>(...) ./libc/src/__support/threads/raw_rwlock.h:402:34 #4 __llvm_libc_23_0_0_git::RawRwLock::read_lock(...) ./libc/src/__support/threads/raw_rwlock.h:485:12 #5 randomized_thread_operation(SharedData*) ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:79:16 #6 thread_runner(void*) ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:148:5 Thread T23 (tid=388553, running) created by main thread at: #0 pthread_create ... #1 main ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:166:5 Thread T4 (tid=388533, running) created by main thread at: #0 pthread_create ... #1 main ./libc/test/integration/src/__support/threads/tsan_full_rwlock.cpp:166:5 SUMMARY: ThreadSanitizer: data race ./libc/src/__support/threads/raw_rwlock.h:443:44 in __llvm_libc_23_0_0_git::RawRwLock::notify_pending_threads() ================== ``` AI wrote the detection script. Manually fixed.
WuXintong123
pushed a commit
that referenced
this pull request
Jun 7, 2026
I recently noticed LLDB crash during execution of `script print(lldb.SBDebugger().GetBroadcaster().GetName())` command: ``` PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. Stack dump: 0. Program arguments: /home/sergei/llvm-project/build/bin/lldb-dap #0 0x000062735c3403d2 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/sergei/llvm-project/build/bin/lldb-dap+0x7c3d2) #1 0x000062735c33d7ec llvm::sys::RunSignalHandlers() (/home/sergei/llvm-project/build/bin/lldb-dap+0x797ec) #2 0x000062735c33d94c SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0 #3 0x00007eaa6aa45330 (/lib/x86_64-linux-gnu/libc.so.6+0x45330) #4 0x00007eaa6bb0c092 lldb::SBBroadcaster::GetName() const (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x90c092) #5 0x00007eaa6bcb9a5d _wrap_SBBroadcaster_GetName LLDBWrapPython.cpp:0:0 #6 0x00007eaa6a1df5f5 (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x1df5f5) #7 0x00007eaa6a182b2c PyObject_Vectorcall (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x182b2c) #8 0x00007eaa6a11d5ee _PyEval_EvalFrameDefault (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x11d5ee) #9 0x00007eaa6a2a091f PyEval_EvalCode (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x2a091f) #10 0x00007eaa6a29c8b0 (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x29c8b0) #11 0x00007eaa6a11fbd3 _PyEval_EvalFrameDefault (/lib/x86_64-linux-gnu/libpython3.12.so.1.0+0x11fbd3) #12 0x00007eaa6c4891b7 lldb_private::ScriptInterpreterPythonImpl::ExecuteOneLine(llvm::StringRef, lldb_private::CommandReturnObject*, lldb_private::ExecuteScriptOptions const&) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x12891b7) #13 0x00007eaa70326ff5 CommandObjectScriptingRun::DoExecute(llvm::StringRef, lldb_private::CommandReturnObject&) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x5126ff5) #14 0x00007eaa6bee3739 lldb_private::CommandObjectRaw::Execute(char const*, lldb_private::CommandReturnObject&) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0xce3739) #15 0x00007eaa6bede09a lldb_private::CommandInterpreter::HandleCommand(char const*, lldb_private::LazyBool, lldb_private::CommandReturnObject&, bool) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0xcde09a) #16 0x00007eaa6bb0f0f8 lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBExecutionContext&, lldb::SBCommandReturnObject&, bool) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x90f0f8) #17 0x00007eaa6bb0f265 lldb::SBCommandInterpreter::HandleCommand(char const*, lldb::SBCommandReturnObject&, bool) (/home/sergei/llvm-project/build/bin/../lib/liblldb.so.23.0git+0x90f265) #18 0x000062735c3707f3 lldb_dap::RunLLDBCommands[abi:cxx11](lldb::SBDebugger&, lldb::SBMutex, llvm::StringRef, llvm::ArrayRef<lldb_dap::protocol::String> const&, bool&, bool, bool) (/home/sergei/llvm-project/build/bin/lldb-dap+0xac7f3) #19 0x000062735c3a8019 lldb_dap::EvaluateRequestHandler::Run(lldb_dap::protocol::EvaluateArguments const&) const (/home/sergei/llvm-project/build/bin/lldb-dap+0xe4019) #20 0x000062735c3aba78 lldb_dap::RequestHandler<lldb_dap::protocol::EvaluateArguments, llvm::Expected<lldb_dap::protocol::EvaluateResponseBody>>::operator()(lldb_dap::protocol::Request const&) const (/home/sergei/llvm-project/build/bin/lldb-dap+0xe7a78) #21 0x000062735c3ce1bf lldb_dap::BaseRequestHandler::Run(lldb_dap::protocol::Request const&) (/home/sergei/llvm-project/build/bin/lldb-dap+0x10a1bf) #22 0x000062735c3577e7 lldb_dap::DAP::HandleObject(std::variant<lldb_dap::protocol::Request, lldb_dap::protocol::Response, lldb_dap::protocol::Event> const&) (/home/sergei/llvm-project/build/bin/lldb-dap+0x937e7) #23 0x000062735c358705 lldb_dap::DAP::Loop() (/home/sergei/llvm-project/build/bin/lldb-dap+0x94705) #24 0x000062735c2ed0c7 main (/home/sergei/llvm-project/build/bin/lldb-dap+0x290c7) #25 0x00007eaa6aa2a1ca __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3 ``` As far as I understand default constuctors should be covered by fuzzing tests, so I don't know how to write test for that patch.
WuXintong123
pushed a commit
that referenced
this pull request
Jul 1, 2026
…lvm#191275)" (llvm#206816) This reverts commit 0f51760. A test fails with the commit (llvm#191275 (comment)): ``` Traceback (most recent call last): File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 596, in test_python_source_frames self.assertNotIn("0xffffffffffffffff", output.lower()) AssertionError: '0xffffffffffffffff' unexpectedly found in "* thread #2, name = 'a.out', stop reason = breakpoint 1.1\n * frame #0: compute_fibonacci at python_helper.py:7 [synthetic]\n frame #1: process_data at python_helper.py:16 [synthetic]\n frame #2: main at python_helper.py:27 [synthetic]\n frame #3: 0x0000badc2de81358 a.out`thread_func(thread_num=0) at main.cpp:44:13\n frame #4: 0x0000badc2de81f9c a.out`void std::__invoke_impl<void, void (*)(int), int>((null)=__invoke_other @ 0x0000f1555ebae74f, __f=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:61:14\n frame #5: 0x0000badc2de81f18 a.out`std::__invoke_result<void (*)(int), int>::type std::__invoke<void (*)(int), int>(__fn=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:96:14\n frame #6: 0x0000badc2de81ee4 a.out`void std::thread::_invoker<std::tuple<void (*)(int), int>>::_m_invoke<0ul, 1ul>(this=0x0000badc66845eb8, (null)=_index_tuple<0ul, 1ul> @ 0x0000f1555ebae7af) at std_thread.h:259:13\n frame #7: 0x0000badc2de81e98 a.out`std::thread::_invoker<std::tuple<void (*)(int), int>>::operator()(this=0x0000badc66845eb8) at std_thread.h:266:11\n frame #8: 0x0000badc2de81d70 a.out`std::thread::_state_impl<std::thread::_invoker<std::tuple<void (*)(int), int>>>::_m_run(this=0xffffffffffffffff) at std_thread.h:211:13\n frame #9: 0x0000f1555ef029cc libstdc++.so.6`___lldb_unnamed_symbol_d29b0 + 28\n frame #10: 0x0000f1555ec30398 libc.so.6`___lldb_unnamed_symbol_800c0 + 728\n frame #11: 0x0000f1555ec99e9c libc.so.6`___lldb_unnamed_symbol_e9e90 + 12\n" ``` I don't know why this test fails with the PR, but I don't have time to fix it now, so revert it to unblock CI. The backtrace was ``` frame #0: compute_fibonacci at python_helper.py:7 [synthetic] frame #1: process_data at python_helper.py:16 [synthetic] frame #2: main at python_helper.py:27 [synthetic] frame #3: 0x0000badc2de81358 a.out`thread_func(thread_num=0) at main.cpp:44:13 frame #4: 0x0000badc2de81f9c a.out`void std::__invoke_impl<void, void (*)(int), int>((null)=__invoke_other @ 0x0000f1555ebae74f, __f=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:61:14 frame #5: 0x0000badc2de81f18 a.out`std::__invoke_result<void (*)(int), int>::type std::__invoke<void (*)(int), int>(__fn=0x0000badc66845ec0, __args=0x0000badc66845eb8) at invoke.h:96:14 frame #6: 0x0000badc2de81ee4 a.out`void std::thread::_invoker<std::tuple<void (*)(int), int>>::_m_invoke<0ul, 1ul>(this=0x0000badc66845eb8, (null)=_index_tuple<0ul, 1ul> @ 0x0000f1555ebae7af) at std_thread.h:259:13 frame #7: 0x0000badc2de81e98 a.out`std::thread::_invoker<std::tuple<void (*)(int), int>>::operator()(this=0x0000badc66845eb8) at std_thread.h:266:11 frame #8: 0x0000badc2de81d70 a.out`std::thread::_state_impl<std::thread::_invoker<std::tuple<void (*)(int), int>>>::_m_run(this=0xffffffffffffffff) at std_thread.h:211:13 frame #9: 0x0000f1555ef029cc libstdc++.so.6`___lldb_unnamed_symbol_d29b0 + 28 frame #10: 0x0000f1555ec30398 libc.so.6`___lldb_unnamed_symbol_800c0 + 728 frame #11: 0x0000f1555ec99e9c libc.so.6`___lldb_unnamed_symbol_e9e90 + 12 ``` This contains 0xffffffffffffffff in frame 8.
WuXintong123
pushed a commit
that referenced
this pull request
Jul 6, 2026
…lvm#207008) `Evaluate_DW_OP_convert` dereferenced `eval_ctx.dwarf_cu` (the `DWARFExpression` Delegate) whenever the operand DIE offset was non-zero, and unconditionally read `eval_ctx.stack.back()`. When a DWARF expression is evaluated without a DWARF unit (as the lldb-dwarf-expression-fuzzer does), two operand shapes crash: - `DW_OP_convert` with a non-zero offset calls `dwarf_cu->GetDIEBitSizeAndSign(...)` on a null Delegate. - `DW_OP_convert` with nothing on the stack reads the back of an empty vector. The unit test feeds both with `dwarf_cu == nullptr` and crashes: ``` [ RUN ] DWARFExpression.DW_OP_convert #2 SignalHandler(int, __siginfo*, void*) #4 DWARFExpression::Evaluate(...) #5 Evaluate(ArrayRef<unsigned char>, ...) ``` (SIGSEGV, the process aborts.) Bail out with an error when the stack is empty, and when a non-zero DIE offset is requested without a DWARF unit, instead of crashing. Extends `DWARFExpression.DW_OP_convert` with these two cases, which crash without the fix. --------- Co-authored-by: Michael Buch <michaelbuch12@gmail.com>
WuXintong123
pushed a commit
that referenced
this pull request
Jul 30, 2026
…lvm#212759) I see the following ``` anutosh491@Anutoshs-MacBook-Air llvm-project % cat /private/tmp/wasm-scalable-shift-cost.ll define <vscale x 4 x i32> @shift(<vscale x 4 x i32> %x, <vscale x 4 x i32> %amount) { %result = shl <vscale x 4 x i32> %x, %amount ret <vscale x 4 x i32> %result } anutosh491@Anutoshs-MacBook-Air llvm-project % build-assert/bin/opt \ -mtriple=wasm32-unknown-unknown \ -mattr=+simd128 \ -passes='print<cost-model>' \ -disable-output \ /private/tmp/wasm-scalable-shift-cost.ll Printing analysis 'Cost Model Analysis' for function 'shift': Cost Model: Assertion failed: (isa<To>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file Casting.h, line 572. 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/opt -mtriple=wasm32-unknown-unknown -mattr=+simd128 -passes=print<cost-model> -disable-output /private/tmp/wasm-scalable-shift-cost.ll 1. Running pass "function(print<cost-model>)" on module "/private/tmp/wasm-scalable-shift-cost.ll" 2. Running pass "print<cost-model>" on function "shift" #0 0x0000000105b7a56c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102f6256c) #1 0x0000000105b78248 llvm::sys::RunSignalHandlers() (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102f60248) #2 0x0000000105b7b170 SignalHandler(int, __siginfo*, void*) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102f63170) #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 0x000000018b4f38a0 (/usr/lib/system/libsystem_c.dylib+0x1803f78a0) #7 0x0000000104036ddc llvm::BasicTTIImplBase<llvm::WebAssemblyTTIImpl>::getArithmeticInstrCost(unsigned int, llvm::Type*, llvm::TargetTransformInfo::TargetCostKind, llvm::TargetTransformInfo::OperandValueInfo, llvm::TargetTransformInfo::OperandValueInfo, llvm::ArrayRef<llvm::Value const*>, llvm::Instruction const*) const (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x10141eddc) #8 0x000000010403b0ac llvm::TargetTransformInfoImplCRTPBase<llvm::WebAssemblyTTIImpl>::getInstructionCost(llvm::User const*, llvm::ArrayRef<llvm::Value const*>, llvm::TargetTransformInfo::TargetCostKind) const (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x1014230ac) #9 0x00000001049162c8 llvm::TargetTransformInfo::getInstructionCost(llvm::User const*, llvm::ArrayRef<llvm::Value const*>, llvm::TargetTransformInfo::TargetCostKind) const (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x101cfe2c8) #10 0x00000001058d90b4 llvm::TargetTransformInfo::getInstructionCost(llvm::User const*, llvm::TargetTransformInfo::TargetCostKind) const (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102cc10b4) #11 0x000000010468a368 getCost(llvm::Instruction&, llvm::TargetTransformInfo::TargetCostKind, llvm::TargetTransformInfo&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x101a72368) #12 0x0000000104689dd4 llvm::CostModelPrinterPass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x101a71dd4) #13 0x0000000105186554 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x10256e554) #14 0x000000010518a680 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x102572680) #15 0x0000000105185418 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x10256d418) #16 0x0000000106127cb0 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::__1::function<void (llvm::PassBuilder&)>>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool, bool) (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x10350fcb0) #17 0x0000000106131eac optMain (/Users/anutosh491/work/llvm-project/build-assert/bin/opt+0x103519eac) #18 0x000000018b22fe00 zsh: abort build-assert/bin/opt -mtriple=wasm32-unknown-unknown -mattr=+simd128 ```
WuXintong123
pushed a commit
that referenced
this pull request
Aug 18, 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)
#13 0x0000000103ae8ba8 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f68ba8)
#14 0x0000000103ae6cd8 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102f66cd8)
#15 0x0000000102b71d28 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x101ff1d28)
#16 0x0000000103096900 llvm::FPPassManager::runOnFunction(llvm::Function&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102516900)
#17 0x000000010309cc00 llvm::FPPassManager::runOnModule(llvm::Module&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x10251cc00)
#18 0x0000000103097174 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x102517174)
#19 0x0000000100b880a4 main (/Users/anutosh491/work/llvm-project/build-assert/bin/llc+0x1000080a4)
#20 0x000000018b22fe00
zsh: abort build-assert/bin/llc -mtriple=wasm32-unknown-unknown -mattr=+simd128,+fp16 -o
```
WuXintong123
pushed a commit
that referenced
this pull request
Sep 1, 2026
Make distributedBarrier::stillNeed atomic and use release/acquire
ordering for distributed barrier gather arrival flags.
The old volatile stillNeed flag did not synchronize an arriving thread's
pre-barrier writes with the thread that observed its arrival. On weakly
ordered architectures, a group leader could observe stillNeed == 0
before the arriving thread's pre-barrier writes were visible. This
allowed another thread to pass the barrier and read stale data written
before the barrier.
Use release stores when publishing stillNeed == 0. Keep the spin loops
on relaxed loads, then perform one acquire fence after all expected zero
values have been observed. This connects the arriving threads'
pre-barrier writes to the observer through the standard release/acquire
happens-before chain, without using acquire loads on every poll.
The same pattern is used when a group leader publishes its own stillNeed
== 0 after the in-group gather completes. The existing go-flag
release/acquire path then carries the ordering to threads leaving the
barrier.
Initialization and next-iteration reset stores remain relaxed because
they do not publish pre-barrier data.
On x86, this does not change the generated instruction sequence for the
affected stillNeed polling/arrival code, since TSO already provides the
needed ordering for ordinary loads and stores.
Reproducer:
I used the following stress test to reproduce the distributed-barrier
visibility issue on AArch64 (Grace).
`test.c`:
```c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <omp.h>
int main() {
int nt;
#pragma omp parallel
#pragma omp master
nt = omp_get_num_threads();
int n = 1024;
int *p = aligned_alloc(64, nt * n * sizeof(int));
memset(p, 0, nt * n * sizeof(int));
#pragma omp parallel
{
int t = omp_get_thread_num();
int *pt = p + t * n;
int *pt2 = p + ((t + 1) % nt) * n;
for (int it = 1; it <= 100000; it++) {
for (int i = 0; i < n; i++)
pt[i] = it;
#pragma omp barrier
for (int i = 0; i < n; i++) {
if (pt2[i] != it) {
printf("thread #%d observes pt2[%d] != %d\n", t, i, it);
abort();
}
}
#pragma omp barrier
}
}
printf("ok\n");
return 0;
}
```
`noise.c`:
```c
// background memory-bandwidth noise
#include <stdlib.h>
#include <omp.h>
int main() {
long N = 1024L*1024;
#pragma omp parallel
{
long *b = malloc(sizeof(long)*N);
for (long j=0; j<1000; j++)
for (long i = 0; i < N; i += 8)
b[i] += 1;
}
return 0;
}
```
Build and run:
```bash
clang test.c -O -fopenmp -o test
clang noise.c -O -fopenmp -o noise
./noise &
KMP_PLAIN_BARRIER_PATTERN=dist,dist \
KMP_FORKJOIN_BARRIER_PATTERN=dist,dist \
KMP_REDUCTION_BARRIER_PATTERN=dist,dist \
OMP_NUM_THREADS=10 \
./test
```
With the old runtime, this can fail as follows:
```text
thread #5 observes pt2[112] != 343
Aborted (core dumped)
```
The same test passes with the patched runtime.
WuXintong123
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.
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
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.