Integrate LLVM - #7
Closed
WuXintong123 wants to merge 3354 commits into
Closed
WuXintong123 wants to merge 3354 commits into
WuXintong123 wants to merge 3354 commits into
Conversation
Update hanging reference of ParseBinaryExpression to ParseRHSOfBinaryExpression Fixes llvm#195747
The SPIR-V target support for UBSan Minimal Runtime is added to provide basic undefined behavior detection capabilities for SPIR-V based devices. Currently, only the `spirv64` target is supported.
) Reverts llvm#194304, as it caused failed asserts - see that PR for reproducers.
These are suspected to have caused instability in CI testing llvm#191372. This reverts commits 4c22591 and d7fac0f (llvm#179470 and llvm#177572). The second change could technically stay in, but it was using the first change to fix a bug in lldb-server. So I think it's better to revert both so we don't mistakenly think the bug is still fixed.
This was only necessary for ASan container annotations for short strings. Remove it now that we do not support ASan container annotations on short strings to: 1. Not suppress Asan on other violations, e.g. std::string::size() on dead object. 2. Make the code a bit more clean. Short string annotations were removed in llvm#194208.
…#196307) This reverts commit a4ddeba, which raised concerns, see: llvm#193800
) shouldRunCompletion() checked the Expected<> from positionToOffset() via operator!() but never consumed the error with takeError(). This caused an assertion failure when a TriggerCharacter completion request had a position beyond the document bounds. LLM was used to generate the unit test. Fixes: llvm#196072
These functions are only used inside assert statements, so mark them [[maybe_unused]] to prevent -Wunused-function when they are used in a non-asserts build.
…6278) Added the Linux byteswap.h header providing bswap_16, bswap_32, and bswap_64 as macros expanding to __builtin_bswap{16,32,64}. These are always inlined by the compiler to single instructions. Follows the existing endian.h / endian-macros.h pattern. Assisted-by: Automated tooling, human reviewed.
…lvm#196101) Summary: This is currently rejected in two places, the toolchain creation and the target itself. For the target we just permit it in the same way we alloe things like 'amdhsa'. For the driver, the current handling just assumed everything with 'vulkan' was HLSL. This shouldn't be true so we check the source file type, and only push through actual HLSL files. This is intended to more canonically support the 'CLSPV' target that google has.
…vm#195150) `isDefinedAsZero` was vulnerable to a classic "passing an unchecked `Operation *` to `TypeSwitch`".
The hardware allows this.
…bank-select. (llvm#194778) This removes the fconstant_to_constant post-legalizer lowering combine, moving it to where it belongs in reg bank select. The result should be mostly be no change in generated code.
Summary: Adds a macro like for `__LINUX__` or `__WIN32`. The intention here is to let code differentiate between vulkan variants or not.
…mpoundLiteralExpr`s (llvm#195675) Like the current interpreter does.
Fixes the failure on `lldb-aarch64-ubuntu` (https://lab.llvm.org/buildbot/#/builders/59/builds/34161) after llvm#195514.
Should fix memory leaks introduced in llvm#138958
…e" (llvm#196328) Reverts llvm#194368 due to breaking tests on z/OS
…vm#195857) Currently PointerMayBeCaptured/FindEarliestEscape accept a ReturnCaptures argument to determine whether returning the pointer should be considered a capture. If you want to do a capture check for both cases, you have to invoke the capture tracking API twice. This PR instead changes the low level APIs to return a pair of capture components, one where returns are considered non-capturing, and one where they are considered capturing. This is for use by llvm#193939, where AA wants both our usual captures-before (ignoring returns) reasoning, and captures-anywhere (including returns). This will allow us to do this in one (cached) query.
Reverts llvm#194577 due to breaking tests on z/OS
This was added by llvm#190806 but it isn't used.
…vm#196301) `LD64B` and `ST64B` are defined as follows[1]: ``` LD64B <Xt>, [<Xn|SP> {,#0}] ``` but they're missing the form that allows a zero immediate offset, for example: ``` ld64b x2, [x13, #0] st64b x16, [x13, #0] ``` Add support for zero immediate offsets for these instructions. [1] https://developer.arm.com/documentation/ddi0602/2022-09/Base-Instructions/LD64B--Single-copy-Atomic-64-byte-Load-
This was phabricator specific which has not been around for a while now.
…vm#182501) The LLVM build documentation says that setting CMAKE_OSX_SYSROOT should be sufficient to correctly configure the sysroot, however this flag was not forwarded to the build of runtimes: leading to failures in flang-rt tests. https://llvm.org/docs/CMake.html#apple-osx It is not safe to forward this flag in general because the runtime might be cross-compiled. In this case I have tried to do this only for native builds. My intention here is not to make the build more complex than currently documented.
…#194991) Reduce the cost of i8 vector insert and extract elements to avoid scalarization in VectorCombine. It is impossible to know during VectorCombine if an extract element will require additional instructions or be free. There is a lot of additional context needed to make that assessment. For example, what instructions are using the extract elements or what other extract element index values occur. This patch chooses some cases that likely do not require instructions, which reduces the overall cost and avoids scalarization. Because of this chance, there are SLP vectorization opportunities that are missed. In general, those missed SLP vectorization cases require scalarization during code generation, and the compiler ends up generating the same code with and without SLP vectorization.
EmitCMP folds `c CMP rhs` into `rhs CMP' c+1` for four condition codes. The `c+1` must wrap modulo the i16 operand width, but the current code does `DAG.getConstant(C->getSExtValue() + 1, dl, MVT::i16)`: sign-extending to `int64_t`, adding there, then handing the result to the unsigned `getConstant(uint64_t, ..., MVT::i16)` overload. For constants with bit 15 set the negative `int64_t` is reinterpreted as a huge `uint64_t`, which trips the `isUIntN(16, val)` assertion in the APInt constructor under `LLVM_ENABLE_ASSERTIONS` and yields an APInt with non-zero bits past its declared width otherwise. Switching to `DAG.getSignedConstant(C->getSExtValue() + 1, ...)` routes through the signed `APInt` constructor, which checks `isIntN(16, val)` and accepts the negative `c+1` produced when the high bit is set. The four EmitCMP fold branches (SETUGE, SETULT, SETGE, SETLT) are updated identically.
) Summary: libclc needs to normalize triples, mostly on account of the fact that things like spv and clspv aren't real triples but are used anyway. That is, we convert the user-value to whatever is passed to `--target=`. The problem is that we were not using the normal triple for the installation directory, so something like `spirv64-mesa32-unknown` would be installed in `spirv64--`. This *might* have the side effect of putting these in `spirv64-unknown-unknown`. I actually do not know if that's a problem with the clang handling, I'll double check.
…m#196345) \llvm#192120 marked this as RequiredPassInfoMixin, deviating from previous behavior. This is probably fine for Function/Module analyses, but doesn't work well for loop analyses in the case that we have a loop in an optnone function that is not in LCSSA. The LCSSA pass will not run because it is optional, the analysis will get computed, and then we assert because the loop is out of LCSSA at the end of the LPM. Restore the old behavior of just not marking the pass as required as it seems reasonable enough.
Resolves llvm#128152. The old algorithm runs a backward DFS from `I` and marks `E` as ephemeral iff every user of `E` has already been visited. This fails when `E` has a user that the backward walk never reaches. Switch to a forward DFS from `E` so that ephemeral values are identified when the condition has other uses off the assume chain.
Updates from 2026-05-08 CWG telecon.
llvm#196661) Do not suggest adding `[[nodiscard]]` to functions returning a class template specialization whose primary template is already marked `[[nodiscard]]`. Class template specializations do not carry the `[[nodiscard]]` attribute on their own declarations, so `modernize-use-nodiscard` previously missed this case and emitted redundant diagnostics for return types such as: ```cpp template <class T> struct [[nodiscard]] Result; Result<int> f() const; ``` Fixes llvm#163425.
`TidyFastChecks.inc` is generated and its contents should not be checked by clang-format CI workflow. Add a local `.clang-format-ignore` entry so the PR formatting check does not report diffs for this file. Related run: llvm#194516 (comment)
…nd add relative aliases (llvm#194807) Fixes llvm#126032
This adds bf16 legalization for floating point compares.
Renames `RISCVInstrInfoZvvmm.td` to `RISCVInstrInfoZvvm.td` so `Zvvmm` and `Zvvfmm` share the same IME instruction file according to the spec. And all future instructions from the `Zvvm family` will be placed here too. This PR is required for reviewing llvm#196486 in order to make GitHub show the diff correcrly.
…opsrun test (#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.
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
A `breakpoint set -P <class>` with an invalid-UTF-8 class name crashes lldb with `EXC_BAD_ACCESS`. The class name is passed through unmodified, so the byte sequence `\xd0p` (an incomplete two-byte UTF-8 sequence) reaches the Python layer: ``` ./bin/lldb -b -o $'breakpoint set -P \xd0p -f main.cpp' ./bin/lldb ... PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ Stack dump: #4 PythonDictionary::GetItem(PythonObject const&) const #6 PythonDictionary::GetItemForKey(PythonObject const&) const #7 PythonObject::ResolveNameWithDictionary(StringRef, PythonDictionary const&) #9 ScriptedPythonInterface::CreatePluginObject<...>(...) ``` `ResolveNameWithDictionary` builds a `PythonString` from the class name and looks it up in the module dictionary. When the name is not valid UTF-8, `PyUnicode_FromStringAndSize` returns `NULL`, so the `PythonString` is left with `m_py_obj == NULL`. `GetItemForKey` forwards that object to `GetItem`, which passed the `NULL` `PyObject *` straight to `PyDict_GetItemWithError`. Debugging the crashing lldb under lldb shows the `NULL` key arriving in `GetItem`: ``` (lldb) break set -n lldb_private::python::PythonDictionary::GetItem (lldb) run --no-use-colors -b -s /tmp/bp_cmds.txt * stop reason = breakpoint 1.1 (lldb) up (lldb) frame variable key.m_py_obj (PyObject *) key.m_py_obj = nullptr ``` Continuing lands on the dereference of that `NULL` inside CPython: ``` (lldb) continue * stop reason = EXC_BAD_ACCESS (code=1, address=0x8) frame #0: PyDict_GetItemWithError + 40 -> ldr x8, [x1, #0x8] ``` `x1` holds the key argument, which is `NULL`, so reading the type field at offset `0x8` faults at address `0x8`. `GetItem` already guards against an invalid dictionary (`!IsValid()`); extend that guard to reject an invalid key as well and return `nullDeref()`. `GetItemForKey` consumes the error and returns an empty `PythonObject`, so existing callers such as `ResolveNameWithDictionary` keep working and the breakpoint command now fails cleanly instead of crashing. This was found by `lldb-commandinterpreter-fuzzer`. Adds `PythonDataObjectsTest.TestPythonDictionaryGetItemWithInvalidKey`, which feeds an invalid-UTF-8 key to `GetItem`. Without the fix the test dereferences the `NULL` key and crashes (`SIGSEGV`).
WuXintong123
pushed a commit
that referenced
this pull request
Jul 8, 2026
…long encodings (llvm#205907) When a (signed or unsigned) LEB128 value is encoded with extra trailing bytes that only carry zero- or sign-extension, the decode loop could keep running with the shift amount at 64 or beyond and then evaluate `Slice << Shift`, which is undefined behavior for a 64-bit type. The DWARF expression parser feeds attacker-controlled LEB128 operands (such as `DW_OP_bregN` / `DW_OP_constu`) through `DataExtractor::getULEB128` / `getSLEB128`, so the `lldb-dwarf-expression-fuzzer` reaches this under UBSan. The unsigned case: ``` LEB128.h:152:20: runtime error: shift exponent 70 is too large for 64-bit type 'uint64_t' (aka 'unsigned long long') #0 llvm::decodeULEB128(...) LEB128.h:152 #1 getLEB128<unsigned long long>(...) DataExtractor.cpp:227 #2 llvm::DataExtractor::getULEB128(...) DataExtractor.cpp:241 #3 llvm::DWARFExpression::Operation::extract(...) DWARFExpression.cpp:218 #7 lldb_private::DWARFExpression::Evaluate(...) DWARFExpression.cpp:1333 #9 LLVMFuzzerTestOneInput lldb-dwarf-expression-fuzzer.cpp:83 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior LEB128.h:152:20 ``` and the signed case, reached the same way: ``` LEB128.h:190:20: runtime error: shift exponent 70 is too large for 64-bit type 'uint64_t' (aka 'unsigned long long') #0 llvm::decodeSLEB128(...) LEB128.h:190 #1 getLEB128<long long>(...) DataExtractor.cpp:227 #2 llvm::DataExtractor::getSLEB128(...) DataExtractor.cpp:245 #3 llvm::DWARFExpression::Operation::extract(...) DWARFExpression.cpp:216 #7 lldb_private::DWARFExpression::Evaluate(...) DWARFExpression.cpp:1333 ``` The existing range checks already guarantee that once `Shift` reaches 64 the remaining bytes are pure extension and contribute nothing to the result, so skip the accumulating shift in that case. Decoded values are unchanged for all well-formed inputs. Adds overlong-encoding regression cases to `LEB128Test`. Without the fix the signed case is the UBSan diagnostic above in a sanitizer build, and in a normal build the unsigned case also decodes to the wrong value (the overlong `1` decodes as `11`).
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
Aug 20, 2026
This fixes operand validation for AArch64 EXT instructions. Symbolic operands such as f0, NaN, and Inf, as well as out-of-range byte-index immediates, could previously reach encoding paths that expect valid integer immediates. This could cause assertion failures in assertions-enabled builds or incorrect encodings when assertions were disabled. The patch uses the appropriate immediate operand ranges for the .8b and .16b forms so invalid operands are rejected during parsing. Regression tests cover symbolic operands, out-of-range immediates, and the valid boundary values #7 and #15. Testing: * llvm/test/MC/AArch64/neon-diagnostics.s * llvm/test/MC/AArch64/neon-extract.s Fixes llvm#185361 The SCVTF/UCVTF portion originally included in this PR is now covered by llvm#213490 and was removed after rebasing onto current main.
WuXintong123
pushed a commit
that referenced
this pull request
Aug 25, 2026
`Scalar::operator>>=` and `Scalar::ExtractBitfield` pass their shift
amount straight to `APSInt::operator>>=(unsigned)`, which asserts when
the
amount exceeds the operand's bit width:
```
Assertion failed: (ShiftAmt <= BitWidth && "Invalid shift amount"),
function ashrInPlace, file APInt.h, line 842.
#7 llvm::APInt::ashrInPlace(unsigned int)
#8 lldb_private::Scalar::ExtractBitfield(unsigned int, unsigned int)
#9 lldb_private::DWARFExpression::Evaluate(...)
#11 LLVMFuzzerTestOneInput
```
The DWARF expression evaluator reaches both from untrusted operands
(`DW_OP_shra` shift counts and `DW_OP_bit_piece` bit offsets), so
`lldb-dwarf-expression-fuzzer` aborts the process on a shift wider than
the
value. A shift amount at or beyond the width is well-defined as a sign
or
zero fill, so clamp it rather than reject it. `operator>>=` uses
`getLimitedValue`, which also avoids the `getZExtValue` assertion when
the
amount itself needs more than 64 bits.
`operator<<=` and `ShiftRightLogical` (`DW_OP_shl` and `DW_OP_shr`)
already
pass an `APInt` amount, and those `APInt` overloads clamp internally the
same
way, so they need no change.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
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.
WuXintong123
pushed a commit
that referenced
this pull request
Sep 11, 2026
…lvm#221872) - Moved the lit tests for `fadd`/`fsub` to their own dedicated file. - Updated the lit tests for `fadd`/`fsub` from version 2 to version 6. - `fadd_p0_ftz_daz #3` was actually testing `positivezero|positivezero`, so I fixed the name of the test to be `fadd_p0_ftpz_dapz #3`. Then added a separate `fadd_p0_ftz_daz #0` test. - `nofpclass-fadd-fsub.ll` uses attributes 1-9 except for 6, so I added `fadd_p0_dynamic_dynamic #6` so I wouldn't have to change the attributes for other tests (i.e. changing `test #7 --> test #6`, `test #8 --> test #7`, etc) The only tests for `fadd` that remain in `nofpclass.ll` are not related to testing `KnownFPClass::fadd`. I have split the PR into 3 commits to make it easier to review (4 commits due to the `undef` false positive). After this PR lands I plan to open this PR llvm#221876
Yranger
pushed a commit
to Yranger/llvm-project
that referenced
this pull request
Sep 15, 2026
…lls (llvm#221022) There are a number of places in codegen where we do this: ```c++ llvm::CallInst *TrapCall = EmitTrapCall(llvm::Intrinsic::trap); TrapCall->setDoesNotReturn(); TrapCall->setDoesNotThrow(); Builder.CreateUnreachable(); Builder.ClearInsertionPoint(); ``` This patch adds a helper that does this and updates `EmitTrapCall()` to no longer create a new block after emitting the trap call. One test had to be updated because an unnecessary block was dropped. Before, we were generating this: ```llvm dtor.call_delete_after_array_destroy: ; preds = %dtor.vector.cont call void @llvm.trap() RuyiAI-Stack#7 unreachable 6: ; No predecessors! unreachable ``` The second block here is now no longer present, which caused some instruction renumbering.
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
20 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.