[SyncBots] Integrate LLVM - #8
Closed
WuXintong123 wants to merge 3380 commits into
Closed
WuXintong123 wants to merge 3380 commits into
WuXintong123 wants to merge 3380 commits into
Conversation
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.
Fixes a few tests with the MSVC toolchain due to incompatibilities: 1. `asan_and_llvm_coverage_test.cpp`: Adds MSVC-specific linker flags (/link /NODEFAULTLIB:libcmt ...) alongside the existing clang-cl -Wl flags. It is probably better to convert these later to substitution changes in `lit.cfg.py`, but that will require upstreaming more test changes. 1. `debug_invalid_pointer_pair.cpp`: Marks the test `UNSUPPORTED: MSVC` because `-mllvm` and codegen isn't supported with MSVC. 1. `debug_memcpy_overlap.cpp` : Adds `/Oi` (enable intrinsics) when building with MSVC, so `memcpy` is emitted as a call that ASan can intercept.
…lvm#196218) Add a dedicated unit test for every standard DWARF 5 expression operator (plus the GNU extensions in use), so each opcode in the evaluator's switch has explicit coverage. Tests for opcodes that require execution context not available in a standalone evaluation (process, frame, compile unit, object address) assert that evaluation fails cleanly rather than crashing. This PR fixes one bug surfaced by the audit: DW_OP_deref_size only rejected sizes greater than 8, not sizes greater than the target's address size. The DWARF 5 spec requires the operand to be no larger than the generic type. The new check returns a clean diagnostic instead of silently dereferencing beyond the address-sized window on 32-bit targets. Assisted-by: Claude
Frontend inserted conversions may conflict with variable names. Avoid this for integer conversions by using `__builtin_int` instead of `int`. Fixes llvm#188879
Uses `CIRGenItaniumCXXABI` when generating IR for the ABI target. Co-authored-by: Justin A. Wilson <waj334@gmsil.com>
This patch adds: - a new kernel `void single_counter(int32_t init_loop, int32_t addend, uint32_t *init_val, uint32_t *out)` - a new test suite `olLaunchKernelSingleCounterSyncEventTest`, with two tests The test `SuccessSyncEvent` verifies whether `olSyncEvent(Event)` awaits the completion of `Event`. The test `SuccessTwoQueues` checks the correctness of the synchronization between queues using events. Enqueueing the kernel on the queue `Q1` should produce `Result1`, which is used as an initial value for the queue `Q2`. Therefore, before executing any future work, `Q2` should wait for the event `Event1`, which is created after submitting work on `Q1`. The required synchronization is ensured by `olWaitEvents(Q2, &Event1, 1)`. If `Q2` uses the value passed as `Result1` before the work on `Q1` has completed, the result of the kernel enqueued on `Q2` would be incorrect.
) Replace errorNYI stubs with actual cir::LLVMIntrinsicCallOp calls for: - __nvvm_fabs_f, __nvvm_fabs_d, __nvvm_fabs_ftz_f (+ f16/bf16 variants) - __nvvm_ex2_approx_f, __nvvm_ex2_approx_d, __nvvm_ex2_approx_ftz_f __nvvm_fabs_d maps to standard llvm.fabs (matching classic CodeGen), while the rest map to their respective nvvm.* intrinsics. Part of llvm#179278
…lvm#196362) `AddressSize` parameter is not used by `DataExtractor` and will be removed in the future. See llvm#190519 for more context.
Call `EnsureConnected` in the `PlatformWebInspectorWasm` ctor so the platform reports being connected after selecting in. The lazy approach resulted in confusion due to the "Connected: no" in the `platform select` output: ``` (lldb) platform select webinspector-wasm Platform: webinspector-wasm Connected: no ```
…m#190649) This makes infinities and NaNs return the new, more explicit formats added in 8d9299c and extends the base decimal output literal to support non-double types. In addition, the legacy hexadecimal floating-point literal format is no longer output in any circumstance. In general, this means that NaNs are reported as +/-qnan, +/-nan(payload), or +/-snan(payload), depending on their payload and infinities as +/-inf. The hexadecimal output generally changes to `f0x...` notation, and is used when 6 decimal digits are insufficient to accurately represent the number, or for noncanonical ppc_fp128 values. A script to change the output for most test files is available at https://gist.github.com/jcranmer-intel/d279296ad91884c98b77fb23a9112a5a. Full disclosure: the python portion of the script was written with the use of AI tools. The C++ portion was written entirely by hand, reusing LLVM's existing helpers for output. The test changes included in this commit are *only* those which do not work with that script, either because the script mangled the conversion (e.g., intentionally matching only a prefix to allow some imprecision) or because the tests were too unusual for the script to find the floating-point literals being compared against.
This preserves the existing behavior and makes the pass compliant with \llvm#192120, which is important as inheriting from the normal PassInfoMixin will be going away soonish.
Creating a feature branch. New Console Pane that - - captures stdout/stderr msgs from debugged process - displays output to console in real-time - provides scrolling and navigation features - manages 10K line circular buffer - auto-scroll on/off feature <img width="2940" height="1744" alt="image" src="https://github.com/user-attachments/assets/49e9dd3e-9f6f-4383-820b-ce365a46208f" /> Controls - enable / disable : F5 + o tab to switch to Console pane UP/ DOWN / PAGEUP/ PAGEDOWN for scrolling, HOME/ END for top or bottom c for clear output Tested on Mac
As part of the NonNarrowingCastsOptimization we were optimizing away some cases where the inner input was an integer and the outer output was a float. Not all of the resulting dtype combinations for these cases are supported by TOSA, so these scenarios are no longer optimized as part of canonicalizations. --------- Signed-off-by: Ian Tayler Lessa <ian.taylerlessa@arm.com>
…r `-gpu=mem:unified` (llvm#196228) Under `-gpu=mem:unified`, plain Fortran module-scope variables referenced directly from a `global` kernel previously produced wrong results. This adds a `cuda-unified` option to the CUF passes: - CUFDeviceGlobal: when set, plain (un-attributed, non-constant) module globals are mirrored into the GPU module as no-body declarations, so PTX emits `.extern .global ...`. - CUFAddConstructor: when set, emits a CUFRegisterExternalVariable call for each such global from `__cudaFortranConstructor`. - New runtime entry `CUFRegisterExternalVariable` wraps `__cudaRegisterHostVar` so the CUDA driver maps the device extern to the host pointer at module-load time. HMM/ATS handles migration from there.
-frepack-arrays (implied by -Ofast) was inserting fir.pack_array / fir.unpack_array for assumed-shape dummy arguments with CUDA data attributes (device, managed, etc.). The repacking allocates a host-side temporary and copies the descriptor, but the data lives in device memory. When the CUF kernel subsequently receives the host descriptor pointer, accessing it from the GPU triggers cudaErrorIllegalAddress. Skip repacking in needsRepack() for any symbol that carries a CUDA data attribute.
…etCallee (llvm#196204) IndirectCallEdge::GetCallee calculates the raw address of a function pointer and tries to resolve a load address for it. If the function pointer has metadata bits in it (e.g. a signed pointer in arm64e) then the resolution will fail. --------- Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
…symbolication.cpp (llvm#196380) Somehow, llvm#196152 fixed a bug where the x86_64h feature wasn't getting correctly set and so some tests that weren't running before started running. One such test is [AddressSanitizer-x86_64-darwin.TestCases/Darwin.haswell-symbolication.cpp](https://green.lab.llvm.org/job/llvm.org/job/clang-stage1-RA-cmake-incremental/job/main/872/testReport/AddressSanitizer-x86_64-darwin/TestCases_Darwin/haswell_symbolication_cpp/), which appears to have never been updated for the internal lit shell. The internal lit shell does not support sub-shells, so the typical pattern appears to be to write results to a file and use `%{readfile:%t.whatever}`. rdar://176390171
) On Windows, offload-arch fails to find or loads the wrong amdhip64 DLL when running from a source-built LLVM/Clang installation where the executable and HIP runtime are in different subdirectories. Three fixes: 1. getSearchPaths(): walk parent directories appending /bin to each, so layouts like <root>/lib/llvm/bin/offload-arch can discover <root>/bin/amdhip64_*.dll. Capped at 6 levels with root detection. Case-insensitive dedup for Windows paths. 2. findNewestHIPDLL(): use stable_sort to preserve search-path order on version ties, so a colocated build DLL wins over a system copy. 3. printGPUsByHIP(): prime the DLL load with LoadLibraryExW and LOAD_WITH_ALTERED_SEARCH_PATH so transitive dependencies resolve from the DLL own directory. Uses LLVM convertUTF8ToUTF16String for path conversion. Also fixes two pre-existing bugs: inverted current_path error check (line 138) and missing break in HipApiVersion switch (line 421). --------- Co-authored-by: Samiii777 <Samiii777@users.noreply.github.com>
This PR was started because I noticed bugs in the docs: - The interestingness test checked for an error, but did not redirect stderr to stdout to include it in the pipe. - The interestingness test pipe ended with grep, but then checked for an exit code of 1 to mark the input as interesting. However, a pipe's overall exit code is the exit code of the rightmost command, and grep's exit code is zero when it detects the query string, and 1 when it does not detect the query string. So the test was backwards. Then I wanted to test my fixes to be sure I got it right, and I realized that the doc has no properly runnable example. This PR adds a working example. h/t @aidint for fixing up the input.
…lvm#195348) When multiple prefetch hints target the same external symbol, only the first one should provide the weak fallback definition. This avoids multiple definitions of the same symbol in the generated assembly.
…structions (llvm#195266) The intra-block path previously gated on isCSINCInstruction, restricting optimization to CSINC. Replace the gate with findCondCodeUseOperandIdxForBranchOrSelect(), which covers the full select family: CSEL, CSINC, CSINV, CSNEG, and FCSEL.
Replace the CityHash-style mixer in hash_combine and (transitively) hash_value(std::basic_string), hash_value(StringRef), and therefore DenseMap<StringRef, X> lookups, with a flatten-and-call into xxh3_64bits, a modern hash superior to CityHash. hash_value(int) / hash_value(ptr) keep the existing Murmur-style hash_16_bytes mixer; those are the dominant DenseMap key paths and a fully-inline 16-byte mix beats inlining xxh3's larger 0..16-byte short path. To break dependency cycle: xxHash64, xxh3_64bits, and xxh3_128bits ArrayRef/StringRef overloads move from llvm/Support/xxhash.h to inline overloads in llvm/ADT/ArrayRef.h and llvm/ADT/StringRef.h, so xxhash.h has no ADT dependencies. A variant that inlined xxh3's 0..16-byte fast path at every combine_bytes call site (vs. always calling out-of-line xxh3_64bits) showed no measurable compile-time improvement on the tracker, so combine_bytes is a one-liner over the out-of-line entry point. llvm-compile-time-tracker.com (CTMark, instructions:u) ``` stage1-O0-g -1.76% (sqlite3 -3.78%) stage1-aarch64-O0-g -1.40% (sqlite3 -2.86%) stage1-ReleaseLTO-g -1.13% stage1-ReleaseThinLTO -0.45% stage1-O3 -0.43% stage1-aarch64-O3 -0.42% stage2-O0-g -0.42% stage2-O3 -0.15% clang build -0.71% (wall -0.42%) ``` DenseMap-of-pointer paths (dominant at -O3) are untouched, so higher- optimization configs see smaller wins as expected. opt's .text shrinks ~92 KB. Subsumes the StringRef-only carve-out proposed in llvm#191115. Notes on properties not introduced by this patch: - Endianness: hash_combine over native integers was already not cross-host stable. memcpy of a native integer into the buffer is host-encoded; fetch32 normalized the read but not the underlying bytes, so on LE vs BE the value fed to the mixer already differed. xxh3 inherits the same property: same byte stream, different mixer. - Process seed: combine_bytes XORs get_execution_seed into the result, which cancels under hash_combine(x) ^ hash_combine(y). The pre-patch short/state paths fed the seed through hash_16_bytes / shift_mix non-linearly, so this is a regression in seed effectiveness under that pattern. Default seed is constant, so this only matters under LLVM_ENABLE_ABI_BREAKING_CHECKS. Follow-up: add a seeded xxh3 entry point in libSupport. Aided by Claude opus 4.7
This has been deprecated for a while and was slated for removal after the branching of LLVM 22. Remove it since I'm on on the Google integrate rotation this week and can take care of any failures on our end.
Add a basic dl_iterate_phdr implementation so that we can get libunwind building. This implementation is bare and not fully compliant with the man page for fully static binaries (which are all that we support currently with the lack of a dynamic linker) due to the lack of TLS info, but that can be added at a future date if it is needed, as it is not needed by libunwind. Add some very basic smoke tests.
xxHash64 is a legacy, pre-XXH3 hash whose only non-test caller in the monorepo is llvm::getKCFITypeID. llvm#196774 accidentally exposed the API.
…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
May 21, 2026
) ``` Before: ext v1.16b, v0.16b, v0.16b, #8 zip1 v0.16b, v0.16b, v1.16b addv h0, v0.8h fmov w0, s0 After: addp v0.16b, v0.16b, v0.16b addp v0.16b, v0.16b, v0.16b addp v0.16b, v0.16b, v0.16b umov w0, v0.h[0] ``` The existing lowering in vectorToScalarBitmask for v16i8 used an EXT+ZIP1+ADDV sequence to pack the per-lane bits into an i16. The horizontal ADDV is expensive on some microarchitectures and forces an early SIMD-to-GPR domain crossing. Replace it with a three-level pairwise-add (ADDP) tree. After the AND with the powers-of-two constant, each byte lane holds at most one set bit within its 8-byte group, so pairwise addition cannot carry and is equivalent to OR at every level. Three ADDPs therefore losslessly pack the 16 per-lane bits into the low i16 of the result vector, from which we extract the bitmask with a single UMOV. This keeps all computation in the vector register file until the final extract and avoids the horizontal reduction. Partially addresses llvm#192749. Follow-up work can extend this transform to N=32 and N=64 by fusing across Q-registers in the first ADDP level.
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
Jun 12, 2026
…ructions (llvm#185170) We currently emit `movi`+`ext` instructions when generating code for shuffle slides of a 64-bit vector left/right and fill it with zeros. This patch optimizes these patterns to use a single `ushr`/`shl` instruction instead. Example: ```llvm define <8 x i8> @slide_left(<8 x i8> %v) { %r = shufflevector <8 x i8> %v, <8 x i8> zeroinitializer, <8 x i32> <i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7, i32 8> ret <8 x i8> %r } ``` Before, we generate: ``` movi v1.2d, #0 ext v0.8b, v0.8b, v1.8b, #1 ``` Now: ``` ushr d0, d0, #8 ``` Fixes: llvm#183398 Alive2 proof: https://alive2.llvm.org/ce/z/QaW5CQ --------- Signed-off-by: Dibri Nsofor <dibrinsofor@gmail.com>
WuXintong123
pushed a commit
that referenced
this pull request
Jun 24, 2026
…203854) ### Summary On ARM/Thumb2, a saturating clamp to a signed range that is not centered on zero is *not* matched to `ssat`, even though it can be potentially matched to `ssat`. The backend instead emits a long explicit compare/select clamp. This pattern is extremely common in quantized ML code: an int8 requantize is `clamp(accumulator + output_zero_point, -128, 127)`, and whenever the output zero_point != 0, the instruction count regress from one ssat to ~10 instructions. The root cause is that InstCombine canonically **sinks the constant out of the min/max** — `clamp(X + C, -128, 127)` becomes `clamp(X, -128-C, 127-C) + C` — and the backend's SSAT matcher (`PerformMinMaxToSatCombine`) only handles a clamp whose bounds already form a saturation range. The offset of the form (`[-128-C, 127-C]`, width 256 = 2⁸) falls through to a generic clamp. #### Reproducer ```c #include <stdint.h> int8_t requant_offset(int32_t acc) { // output zero-point = 96 int32_t v = (acc >> 8) + 96; if (v < -128) v = -128; if (v > 127) v = 127; return (int8_t)v; } int8_t requant_zero(int32_t acc) { // output zero-point = 0 (for contrast) int32_t v = (acc >> 8); if (v < -128) v = -128; if (v > 127) v = 127; return (int8_t)v; } ``` ``` clang -O2 --target=thumbv7em-none-eabihf -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -S issue.c ``` **Actual** `requant_offset` (zero-point 96): ```asm asrs r1, r0, #8 cmn.w r1, llvm#224 mvn r1, llvm#223 it gt asrgt r1, r0, #8 cmp r1, llvm#31 it ge movge r1, llvm#31 add.w r0, r1, llvm#96 sxtb r0, r0 ``` `requant_zero` (zero-point 0): ```asm ssat r0, #8, r0, asr #8 ``` #### Expected `requant_offset` should select `ssat`, e.g.: ```asm movs r1, llvm#96 add.w r0, r1, r0, asr #8 ssat r0, #8, r0 subs r0, llvm#96 ``` #### Why this is sound A clamp whose width (hi − lo + 1) is a power of two is just an `ssat` shifted off zero by constant C. ``` clamp(X, lo, hi) == ssat_k(X − C) + C, C = lo + 2^(k-1) ``` e.g. `clamp(X, −224, 31)` == `clamp(X+96, (-225+96), (31+96)) - 96` == `ssat8(X + 96) − 96` Assisted-by: Claude
WuXintong123
pushed a commit
that referenced
this pull request
Jun 29, 2026
`Evaluate_DW_OP_deref` validated that the dereference size was `<= 8` but not that it was non-zero. The DWARF expression evaluator parses untrusted operands, so a `DW_OP_deref_size` with size operand `0` is reachable (it is hit by the lldb-dwarf-expression-fuzzer). A zero dereference size flows into `DerefSizeExtractDataHelper`, which constructs a `DataExtractor` with `addr_size == 0` and aborts on its assertion. The unit test that feeds `DW_OP_lit0, DW_OP_deref_size, 0x00` shows the crash: ``` [ RUN ] DWARFExpressionMockProcessTest.DW_OP_deref_size_zero Assertion failed: (addr_size >= 1 && addr_size <= 8), function DataExtractor, file DataExtractor.cpp, line 134. #8 DataExtractor::DataExtractor(...) #11 DWARFExpression::Evaluate(...) ``` Reject a zero dereference size with an error, alongside the existing `size > 8` check. Adds `DWARFExpressionMockProcessTest.DW_OP_deref_size_zero`, which aborts on the assertion above without the fix.
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 3, 2026
… movemask (llvm#199081) The existing lowering in vectorToScalarBitmask() creates a 1 bit per lane movemask using a powers of 2 reduction (and+addv with a constant pool entry). This patch adds a DAG combine on ISD::CTTZ that recognizes cttz(bitcast <N x i1> to iN) and produces a compressed movemask with shrn (for i8 lanes) or xtn (for wider lanes) then runs scalar cttz on a 64- or 128-bit value. Dividing by bits per lane gives the lane index. Supports lane counts {2, 4, 8, 16, 32} (one or two NEON registers) For the example in the issue (`<16 x i8> -> i16`): Before: ```asm adrp x8, .LCPI0_0 cmlt v0.16b, v0.16b, #0 ldr q1, [x8, :lo12:.LCPI0_0] and v0.16b, v0.16b, v1.16b ext v1.16b, v0.16b, v0.16b, #8 zip1 v0.16b, v0.16b, v1.16b addv h0, v0.8h fmov w8, s0 orr w8, w8, #0x10000 rbit w8, w8 clz w0, w8 ret ``` After: ```asm cmlt v0.16b, v0.16b, #0 shrn v0.8b, v0.8h, #4 fmov x8, d0 rbit x8, x8 clz x8, x8 lsr x0, x8, #2 ret ``` Also created a new test file with 24 functions covering both endianness - 7 basic widths (`<16 x i8>` down through `<2 x i32>`) - 4 wider cases that span two NEON registers (`<32 x i8>` etc) - 2 narrow cases that get sext'd up to fit one register - 2 cases where the bitcast has two users - 4 alternative comparison operators (`eq`, `ne`, etc) - 1 `cttz` with `is_zero_undef=true` - 4 negative tests that bails for unsupported shapes Fixes llvm#186295
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 4, 2026
…10793) A shuffle mask that interleaves zeros between every other byte element is equivalent to a vector shift left on a wider element type. This avoids generating a `tbl` instruction with a constant mask loaded from memory, replacing it with a single `shl` instruction. Before: ```asm adrp x8, .LCPI0_0 ldr q1, [x8, :lo12:.LCPI0_0] tbl v0.16b, { v0.16b }, v1.16b ``` After: ```asm shl v0.8h, v0.8h, #8 ``` Both `<16 x i8>` and `<8 x i8>` vectors are handled. The canonicalized form where zeros appear in either the first or second shuffle operand is also handled. Fixes llvm#107287
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 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
Aug 28, 2026
Introduced by llvm#213356 ``` SanitizerError AddressSanitizer: 2760 byte(s) leaked in 15 allocation(s). Details ================================================================= ==6162==ERROR: LeakSanitizer: detected memory leaks Direct leak of 1472 byte(s) in 8 object(s) allocated from: ... #8 0x7f4d08980c00 in ObjectFileELF::CreateSections(lldb_private::SectionList&) lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2168:28 #9 0x7f4d085c5651 in lldb_private::Module::GetSectionList() lldb/source/Core/Module.cpp:1226:17 #10 0x7f4d08af4f6f in lldb_private::plugin::dwarf::SymbolFileDWARF::SymbolFileDWARF(std::__u::shared_ptr<lldb_private::ObjectFile>, lldb_private::SectionList*) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:490:44 #11 0x7f4d08af331e in lldb_private::plugin::dwarf::SymbolFileDWARF::CreateInstance(std::__u::shared_ptr<lldb_private::ObjectFile>) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:347:14 #12 0x7f4d08cc36af in lldb_private::SymbolFile::FindPlugin(std::__u::shared_ptr<lldb_private::ObjectFile>) lldb/source/Symbol/SymbolFile.cpp:64:51 #13 0x7f4d08cd2dc9 in lldb_private::SymbolVendor::AddSymbolFileRepresentation(std::__u::shared_ptr<lldb_private::ObjectFile> const&) lldb/source/Symbol/SymbolVendor.cpp:65:27 #14 0x7f4d08cd2ba0 in lldb_private::SymbolVendor::FindPlugin(std::__u::shared_ptr<lldb_private::Module> const&, lldb_private::Stream*) lldb/source/Symbol/SymbolVendor.cpp:51:16 #15 0x7f4d085c1d9f in lldb_private::Module::GetSymbolFile(bool, lldb_private::Stream*) lldb/source/Core/Module.cpp:991:13 #16 0x7f50eadaf896 in lldb_private::YAMLModuleTester::YAMLModuleTester(llvm::StringRef, unsigned long) lldb/unittests/TestingSupport/Symbol/YAMLModuleTester.cpp:24:61 #17 0x7f50eb471eea in DWARFASTParserClangYAMLTester lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp:53:9 #18 0x7f50eb471eea in DWARFASTParserClangTests_TestRustVariantMember_Test::TestBody() lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp:2128:33 ... Direct leak of 1288 byte(s) in 7 object(s) allocated from: ... #8 0x7f4d08980c00 in ObjectFileELF::CreateSections(lldb_private::SectionList&) lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp:2168:28 #9 0x7f4d085c5651 in lldb_private::Module::GetSectionList() lldb/source/Core/Module.cpp:1226:17 #10 0x7f4d08af4f6f in lldb_private::plugin::dwarf::SymbolFileDWARF::SymbolFileDWARF(std::__u::shared_ptr<lldb_private::ObjectFile>, lldb_private::SectionList*) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:490:44 #11 0x7f4d08af331e in lldb_private::plugin::dwarf::SymbolFileDWARF::CreateInstance(std::__u::shared_ptr<lldb_private::ObjectFile>) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:347:14 #12 0x7f4d08cc36af in lldb_private::SymbolFile::FindPlugin(std::__u::shared_ptr<lldb_private::ObjectFile>) lldb/source/Symbol/SymbolFile.cpp:64:51 #13 0x7f4d08cd2dc9 in lldb_private::SymbolVendor::AddSymbolFileRepresentation(std::__u::shared_ptr<lldb_private::ObjectFile> const&) lldb/source/Symbol/SymbolVendor.cpp:65:27 #14 0x7f4d08cd2ba0 in lldb_private::SymbolVendor::FindPlugin(std::__u::shared_ptr<lldb_private::Module> const&, lldb_private::Stream*) lldb/source/Symbol/SymbolVendor.cpp:51:16 #15 0x7f4d085c1d9f in lldb_private::Module::GetSymbolFile(bool, lldb_private::Stream*) lldb/source/Core/Module.cpp:991:13 #16 0x7f50eadaf896 in lldb_private::YAMLModuleTester::YAMLModuleTester(llvm::StringRef, unsigned long) lldb/unittests/TestingSupport/Symbol/YAMLModuleTester.cpp:24:61 #17 0x7f50eb461ba2 in DWARFASTParserClangYAMLTester lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp:53:9 #18 0x7f50eb461ba2 in DWARFASTParserClangTests_TestDefaultTemplateParamParsing_Test::TestBody() lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp:587:33 ... ```
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
WuXintong123
pushed a commit
that referenced
this pull request
Sep 13, 2026
Opening a Mach-O file whose LC_SYMTAB claims far more symbols than the
file could possibly hold makes lldb ask for hundreds of gigabytes. A
128-byte file with LC_SYMTAB.nsyms = 0x80000000 (the new unit test's
input, built with yaml2obj) reproduces it through `lldb-target-fuzzer`,
the harness that found this bug:
```
==45515== ERROR: libFuzzer: out-of-memory (malloc(171798691840))
#8 std::__1::__split_buffer<lldb_private::Symbol,...>::__split_buffer(...)
#9 std::__1::vector<lldb_private::Symbol,...>::resize(unsigned long)
#10 lldb_private::Symtab::Resize(unsigned long)
#11 ObjectFileMachO::ParseSymtab(lldb_private::Symtab&)
```
`ParseSymtab()` sizes the destination `Symtab`'s `vector<Symbol>`
directly
from `nsyms` and `nindirectsyms`, two counts read from the file's
`LC_SYMTAB` and `LC_DYSYMTAB` commands. `nlist_data`, the view already
built earlier in the function from the bytes the file actually has at
`symoff`, is far smaller than what those counts claim; the guard gating
this code only checks that it is non-empty, not how many nlist records
it can back.
Bound both counts by what `nlist_data` and `indirect_symbol_index_data`
(already clipped to the available bytes) can hold, instead of trusting
the file's counts outright.
Add a unit test whose LC_SYMTAB claims about two billion symbols in a
128-byte file; completing quickly instead of reserving that much space
is the regression check.
Assited-by: claude
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.