test#2
Closed
adurang wants to merge 814 commits intoabhinavgaba:libomptarget-introduce-attach-supportfrom
Closed
Conversation
This was left during the upstream. Co-authored-by: Mekhanoshin, Stanislav <Stanislav.Mekhanoshin@amd.com>
Co-authored-by: Kosarev, Ivan <Ivan.Kosarev@amd.com>
…lvm#149631) This is a partial support because some other instructions have not been upstreamed yet.
…lvm#149812) We use this construct a lot. Use something similar to clang's UnsignedOrNone. This results in some slighy compile time improvements: https://llvm-compile-time-tracker.com/compare.php?from=17a4b0399d161a3b89d8f0ce82add1638f23f5d4&to=a251d81ecd0ed45dd190462663155fdb303ef04d&stat=instructions:u
Add the syntax `-fintrinsic-modules-path=<dir>` as an alias to the existing option `-fintrinsic-modules-path <dir>`. gfortran also supports both alternatives. This is particularly useful with CMake which de-duplicates command-line options. For instance, `-fintrinsic-modules-path /path/A -fintrinsic-modules-path /path/B` is de-duplicated to `-fintrinsic-modules-path /path/A /path/B` since it conisiders the second `-fintrinsic-modules-path` "redundant". This can be avoided using the syntax `-fintrinsic-modules-path=/path/A -fintrinsic-modules-path=/path/B`.
When reviewing llvm#147156, the reviewers pointed out that we didn't need to support the trigraph. The code never handled it right. In the debug build, this kind of input caused the assertion in the function `countLeadingWhitespace` to fail. The release build without assertions outputted `?` `?` `/` separated by spaces. ```C #define A ??/ int i; ``` This is because the code in `countLeadingWhitespace` assumed that the underlying lexer recognized the entire `??/` sequence as a single token. In fact, the lexer recognized it as 3 separate tokens. The flag to make the lexer recognize trigraphs was never enabled. This patch enables the flag in the underlying lexer. This way, the program now either turns the trigraph into a single `\` or removes it altogether if the line is short enough. There are operators like the `??=` in C#. So the flag is not enabled for all input languages. Instead the check for the token size is moved from the assert line into the if line. The problem was introduced by my own patch 370bee4 from about 3 years ago. I added code to count the number of characters in the escape sequence probably just because the block of code used to have a comment saying someone should add the feature. Maybe I forgot to enable assertions when I ran the code. I found the problem because reviewing pull request 145243 made me look at the code again.
A follow up patch from llvm#140736. Set default true16 mode from gfx110x to all gfx11 devices. Tests has been address in preivous patches.
OpenMP 6.0 has changed the modifiers on the MAP clause: - map-type-modifier has been split into individual modifiers, - map-type "delete" has become a modifier, - new modifiers have been added. This patch adds parsing support for all of the OpenMP 6.0 modifiers. The old "map-type-modifier" is retained, but is no longer created in parsing. It will remain to take advantage of the preexisting modifier validation for older versions: when the OpenMP version is < 6.0, the modifiers will be rewritten back as map-type-modifiers (or map- type in case of "delete"). In this patch the modifiers will always be rewritten in the older format to isolate these changes to parsing as much as possible.
Now that readMemProf calls two helper functions handleAllocSite and handleCallSite, we can simplify the control flow. We don't need to use "continue" anymore.
…perations (llvm#148350) This patch generalizes the existing foldBitOpOfBitcasts optimization in the VectorCombine pass to handle additional cast operations beyond just bitcast. Fixes: [llvm#146037](llvm#146037) Summary The optimization now supports folding bitwise operations (AND/OR/XOR) with the following cast operations: - bitcast (original functionality) - trunc (truncate) - sext (sign extend) - zext (zero extend) The transformation pattern is: bitop(castop(x), castop(y)) -> castop(bitop(x, y)) This reduces the number of cast instructions from 2 to 1, improving performance on targets where cast operations are expensive or where performing bitwise operations on narrower types is beneficial. Implementation Details - Renamed foldBitOpOfBitcasts to foldBitOpOfCastops to reflect broader functionality - Extended pattern matching to handle any CastInst operation - Added validation for each cast type's constraints (e.g., trunc requires source > dest) - Updated cost model to use the actual cast opcode - Preserves IR flags from original instructions - Handles multi-use scenarios appropriately Testing - Added comprehensive tests in test/Transforms/VectorCombine/bitop-of-castops.ll - Tests cover all supported cast types with all bitwise operations - Includes negative tests for unsupported patterns - All existing VectorCombine tests pass
Fixes llvm#149669; the old check compared with the end of the literal, but we can just check that after parsing digits, we're pointing to one character past the token start.
convert_iKxN_s is canonicalized into convert_iKxN_u when the argument is known to have sign bit 0. This results in emitting Wasm opcodes that, on some targets (like x86_64), are dramatically slower than signed versions on major engines. Similarly to X86, we now fix this up in isel when the instruction has nonneg flag from canonicalization or if we know the source has zero sign bit. Fixes llvm#149457.
Mips was the only architecture having PtrDiffType = SignedInt and
IntPtrType = SignedLong
This fixes a problem on mipsel-windows-gnu triple, where uintptr_t was
wrongly defined as unsigned long instead of unsigned int, leading to
problems in compiler-rt.
compiler-rt/lib/interception/interception_type_test.cpp:24:17: error:
static assertion failed due to requirement
'__sanitizer::is_same<unsigned long, unsigned int>::value':
24 | COMPILER_CHECK((__sanitizer::is_same<__sanitizer::uptr,
::uintptr_t>::value));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler-rt/lib/interception/../sanitizer_common/sanitizer_internal_defs.h:369:44:
note: expanded from macro 'COMPILER_CHECK'
369 | #define COMPILER_CHECK(pred) static_assert(pred, "")
| ^~~~
compiler-rt/lib/interception/interception_type_test.cpp:25:17: error:
static assertion failed due to requirement '__sanitizer::is_same<long,
int>::value':
25 | COMPILER_CHECK((__sanitizer::is_same<__sanitizer::sptr,
::intptr_t>::value));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler-rt/lib/interception/../sanitizer_common/sanitizer_internal_defs.h:369:44:
note: expanded from macro 'COMPILER_CHECK'
369 | #define COMPILER_CHECK(pred) static_assert(pred, "")
| ^~~~
compiler-rt/lib/interception/interception_type_test.cpp:27:17: error:
static assertion failed due to requirement '__sanitizer::is_same<long,
int>::value':
27 | COMPILER_CHECK((__sanitizer::is_same<::PTRDIFF_T,
::ptrdiff_t>::value));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compiler-rt/lib/interception/../sanitizer_common/sanitizer_internal_defs.h:369:44:
note: expanded from macro 'COMPILER_CHECK'
369 | #define COMPILER_CHECK(pred) static_assert(pred, "")
…#149845) Reverts llvm#140091 due to crash (see comments for reproducer)
…m#143845) llvm#92066 will be dependent on this change
Performance testing shows no significant gains or losses on graphics workloads, so this is mostly to make the behavior consistent across all supported OSes instead of special-casing HSA.
"to make the add's lexically identical" -> "to make the adds lexically identical"
Clang 19 has been the oldest supported version of Clang since the LLVM 20 release, but we had not cleaned up the test suite yet.
Fix a failing test for constant-folding the nvvm_round intrinsic. The original implementation added in llvm#141233 used a native libm call to the "round" function, but on PPC this produces +0.0 if the input is -0.0, which caused a test failure. This patch updates it to use APFloat functions instead of native libm calls to ensure cross-platform consistency.
This is one of the final remaining debug-intrinsic specific codepaths out there, and pieces of cross-LLVM infrastructure to do with debug intrinsics.
…r-noalias-addrspace.ll` (llvm#149826) The callee and caller signature doesn't match
…49849) string_utils.h uses uintptr_t, and there seems to be no tracking of this dependency. It seems upstream builds are unaffected but downstream this is causing a lot of flaky builds.
…vm#149178) Cleans up debt from llvm#147849 and llvm#147860 I had originally duplicated this test since the WinEH directory wasn't enabled for AArch64, but now that we can run AArch64 tests in that directory, I've unified the tests.
Co-authored-by: Stanislav Mekhanoshin <Stanislav.Mekhanoshin@amd.com>
…#149775) Addresses llvm#112164. minimumnum and maximumnum intrinsics were added in 5bf81e5. The new built-ins can be used for implementing OpenCL math function fmax and fmin in llvm#128506.
…lvm#150132) LanguageType has two kinds of enumerators in it. The first is DWARF-assigned enumerators which must be consecutive and match DW_LANG values. The second is the vendor-assigned enumerators which must be unique and must follow on from the DWARF-assigned values (i.e. the first one is currently eLanguageTypeMojo + 1) even if that collides with DWARF-assigned values that lldb is not yet aware of Only the DWARF-assigned enumerators may be static_cast from DW_LANG since their values match. The vendor-assigned enumerators must be explicitly converted since their values do not match. This needs to handle new languages added to DWARF and not yet implemented in lldb. This fixes a crash when encountering a DW_LANG value >= eNumLanguageTypes and wrong behaviour when encountering DW_LANG values that have not yet been added to LanguageType but happen to coincide with a vendor-assigned enumerator due to the consecutive values requirement described above. Another way to fix the crash is to add the language to LanguageType (and fill any preceeding gaps in the number space) so that the DW_LANG being encountered is correctly handled but this just moves the problem to a new subset of DW_LANG values. Also fix an unnecessary static-cast from LanguageType to LanguageType.
abhinavgaba
pushed a commit
that referenced
this pull request
Aug 11, 2025
Tracked at llvm#112294 This patch implements from [basic.link]p14 to [basic.link]p18 partially. The explicitly missing parts are: - Anything related to specializations. - Decide if a pointer is associated with a TU-local value at compile time. - [basic.link]p15.1.2 to decide if a type is TU-local. - Diagnose if TU-local functions from other TU are collected to the overload set. See [basic.link]p19, the call to 'h(N::A{});' in translation unit #2 There should be other implicitly missing parts as the wording uses "names" briefly several times. But to implement this precisely, we have to visit the whole AST, including Decls, Expression and Types, which may be harder to implement and be more time-consuming for compilation time. So I choose to implement the common parts. It won't be too bad to miss some cases since we DIDN'T do any such checks in the past 3 years. Any new check is an improvement. Given modules have been basically available since clang15 without such checks, it will be user unfriendly if we give a hard error now. And there are a lot of cases which violating the rule actually just fine. So I decide to emit it as warnings instead of hard errors.
abhinavgaba
pushed a commit
that referenced
this pull request
Aug 11, 2025
Extend support in LLDB for WebAssembly. This PR adds a new Process plugin (ProcessWasm) that extends ProcessGDBRemote for WebAssembly targets. It adds support for WebAssembly's memory model with separate address spaces, and the ability to fetch the call stack from the WebAssembly runtime. I have tested this change with the WebAssembly Micro Runtime (WAMR, https://github.com/bytecodealliance/wasm-micro-runtime) which implements a GDB debug stub and supports the qWasmCallStack packet. ``` (lldb) process connect --plugin wasm connect://localhost:4567 Process 1 stopped * thread #1, name = 'nobody', stop reason = trace frame #0: 0x40000000000001ad wasm32_args.wasm`main: -> 0x40000000000001ad <+3>: global.get 0 0x40000000000001b3 <+9>: i32.const 16 0x40000000000001b5 <+11>: i32.sub 0x40000000000001b6 <+12>: local.set 0 (lldb) b add Breakpoint 1: where = wasm32_args.wasm`add + 28 at test.c:4:12, address = 0x400000000000019c (lldb) c Process 1 resuming Process 1 stopped * thread #1, name = 'nobody', stop reason = breakpoint 1.1 frame #0: 0x400000000000019c wasm32_args.wasm`add(a=<unavailable>, b=<unavailable>) at test.c:4:12 1 int 2 add(int a, int b) 3 { -> 4 return a + b; 5 } 6 7 int (lldb) bt * thread #1, name = 'nobody', stop reason = breakpoint 1.1 * frame #0: 0x400000000000019c wasm32_args.wasm`add(a=<unavailable>, b=<unavailable>) at test.c:4:12 frame #1: 0x40000000000001e5 wasm32_args.wasm`main at test.c:12:12 frame #2: 0x40000000000001fe wasm32_args.wasm ``` This PR is based on an unmerged patch from Paolo Severini: https://reviews.llvm.org/D78801. I intentionally stuck to the foundations to keep this PR small. I have more PRs in the pipeline to support the other features/packets. My motivation for supporting Wasm is to support debugging Swift compiled to WebAssembly: https://www.swift.org/documentation/articles/wasm-getting-started.html
abhinavgaba
pushed a commit
that referenced
this pull request
Aug 11, 2025
Pointers and GEP are untyped. SPIR-V required structured OpAccessChain. This means the backend will have to determine a good way to retrieve the structured access from an untyped GEP. This is not a trivial problem, and needs to be addressed to have a robust compiler. The issue is other workstreams relies on the access chain deduction to work. So we have 2 options: - pause all dependent work until we have a good chain deduction. - submit this limited fix to we can work on both this and other features in parallel. Choice we want to make is #2: submitting this **knowing this is not a good** fix. It only increase the number of patterns we can work with, thus allowing others to continue working on other parts of the backend. This patch as-is has many limitations: - If cannot robustly determine the depth of the structured access from a GEP. Fixing this would require looking ahead at the full GEP chain. - It cannot always figure out the correct access indices, especially with dynamic indices. This will require frontend collaboration. Because we know this is a temporary hack, this patch only impacts the logical SPIR-V target. Physical SPIR-V, which can rely on pointer cast remains on the old method. Related to llvm#145002
abhinavgaba
pushed a commit
that referenced
this pull request
Aug 11, 2025
…lvm#152156) With this new A320 in-order core, we follow adding the FeatureUseFixedOverScalableIfEqualCost feature to A510 and A520 (llvm#132246), which reaps the same code generation benefits of preferring fixed over scalable when the cost is equal. So when we have: ``` void foo(float* a, float* b, float* dst, unsigned n) { for (unsigned i = 0; i < n; ++i) dst[i] = a[i] + b[i]; } ``` When compiling without the feature enabled, we get: ``` ... ld1b { z0.b }, p0/z, [x0, x10] ld1b { z2.b }, p0/z, [x1, x10] add x12, x0, x10 ldr z1, [x12, #1, mul vl] add x12, x1, x10 ldr z3, [x12, #1, mul vl] fadd z0.s, z2.s, z0.s add x12, x2, x10 fadd z1.s, z3.s, z1.s dech x11 st1b { z0.b }, p0, [x2, x10] incb x10, all, mul #2 str z1, [x12, #1, mul vl] ... ``` When compiling with, we get: ``` ... ldp q0, q1, [x12, #-16] ldp q2, q3, [x11, #-16] subs x13, x13, llvm#8 fadd v0.4s, v2.4s, v0.4s fadd v1.4s, v3.4s, v1.4s add x11, x11, llvm#32 add x12, x12, llvm#32 stp q0, q1, [x10, #-16] add x10, x10, llvm#32 ... ```
abhinavgaba
pushed a commit
that referenced
this pull request
Aug 14, 2025
## Problem When the new setting ``` set target.parallel-module-load true ``` was added, lldb began fetching modules from the devices from multiple threads simultaneously. This caused crashes of lldb when debugging on android devices. The top of the stack in the crash look something like this: ``` #0 0x0000555aaf2b27fe llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/llvm/bin/lldb-dap+0xb87fe) #1 0x0000555aaf2b0a99 llvm::sys::RunSignalHandlers() (/opt/llvm/bin/lldb-dap+0xb6a99) #2 0x0000555aaf2b2fda SignalHandler(int, siginfo_t*, void*) (/opt/llvm/bin/lldb-dap+0xb8fda) #3 0x00007f9c02444560 __restore_rt /home/engshare/third-party2/glibc/2.34/src/glibc-2.34/signal/../sysdeps/unix/sysv/linux/libc_sigaction.c:13:0 llvm#4 0x00007f9c04ea7707 lldb_private::ConnectionFileDescriptor::Disconnect(lldb_private::Status*) (usr/bin/../lib/liblldb.so.15+0x22a7707) llvm#5 0x00007f9c04ea5b41 lldb_private::ConnectionFileDescriptor::~ConnectionFileDescriptor() (usr/bin/../lib/liblldb.so.15+0x22a5b41) llvm#6 0x00007f9c04ea5c1e lldb_private::ConnectionFileDescriptor::~ConnectionFileDescriptor() (usr/bin/../lib/liblldb.so.15+0x22a5c1e) llvm#7 0x00007f9c052916ff lldb_private::platform_android::AdbClient::SyncService::Stat(lldb_private::FileSpec const&, unsigned int&, unsigned int&, unsigned int&) (usr/bin/../lib/liblldb.so.15+0x26916ff) llvm#8 0x00007f9c0528b9dc lldb_private::platform_android::PlatformAndroid::GetFile(lldb_private::FileSpec const&, lldb_private::FileSpec const&) (usr/bin/../lib/liblldb.so.15+0x268b9dc) ``` Our workaround was to set `set target.parallel-module-load ` to `false` to avoid the crash. ## Background PlatformAndroid creates two different classes with one stateful adb connection shared between the two -- one through AdbClient and another through AdbClient::SyncService. The connection management and state is complex, and seems to be responsible for the segfault we are seeing. The AdbClient code resets these connections at times, and re-establishes connections if they are not active. Similarly, PlatformAndroid caches its SyncService, which uses an AdbClient class, but the SyncService puts its connection into a different 'sync' state that is incompatible with a standard connection. ## Changes in this diff * This diff refactors the code to (hopefully) have clearer ownership of the connection, clearer separation of AdbClient and SyncService by making a new class for clearer separations of concerns, called AdbSyncService. * New unit tests are added * Additional logs were added (see llvm#145382 (comment) for details)
abhinavgaba
pushed a commit
that referenced
this pull request
Aug 14, 2025
…namic (llvm#153420) Canonicalizing the following IR: ``` func.func @mul_zero_dynamic_nofold(%arg0: tensor<?x17xf32>) -> tensor<?x17xf32> { %0 = "tosa.const"() <{values = dense<0.000000e+00> : tensor<1x1xf32>}> : () -> tensor<1x1xf32> %1 = "tosa.const"() <{values = dense<0> : tensor<1xi8>}> : () -> tensor<1xi8> %2 = tosa.mul %arg0, %0, %1 : (tensor<?x17xf32>, tensor<1x1xf32>, tensor<1xi8>) -> tensor<?x17xf32> return %2 : tensor<?x17xf32> } ``` resulted in a crash ``` #0 0x000056513187e8db backtrace (./build-release/bin/mlir-opt+0x9d698db) #1 0x0000565131b17737 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/llvm/lib/Support/Unix/Signals.inc:838:8 #2 0x0000565131b187f3 PrintStackTraceSignalHandler(void*) /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/llvm/lib/Support/Unix/Signals.inc:918:1 #3 0x0000565131b18c30 llvm::sys::RunSignalHandlers() /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/llvm/lib/Support/Signals.cpp:105:18 llvm#4 0x0000565131b18c30 SignalHandler(int, siginfo_t*, void*) /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/llvm/lib/Support/Unix/Signals.inc:409:3 llvm#5 0x00007f2e4165b050 (/lib/x86_64-linux-gnu/libc.so.6+0x3c050) llvm#6 0x00007f2e416a9eec __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 llvm#7 0x00007f2e4165afb2 raise ./signal/../sysdeps/posix/raise.c:27:6 llvm#8 0x00007f2e41645472 abort ./stdlib/abort.c:81:7 llvm#9 0x00007f2e41645395 _nl_load_domain ./intl/loadmsgcat.c:1177:9 llvm#10 0x00007f2e41653ec2 (/lib/x86_64-linux-gnu/libc.so.6+0x34ec2) llvm#11 0x00005651443ec4ba mlir::DenseIntOrFPElementsAttr::getRaw(mlir::ShapedType, llvm::ArrayRef<char>) /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/mlir/lib/IR/BuiltinAttributes.cpp:1361:3 llvm#12 0x00005651443f1209 mlir::DenseElementsAttr::resizeSplat(mlir::ShapedType) /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/mlir/lib/IR/BuiltinAttributes.cpp:0:10 llvm#13 0x000056513f76f2b6 mlir::tosa::MulOp::fold(mlir::tosa::MulOpGenericAdaptor<llvm::ArrayRef<mlir::Attribute>>) /local-ssd/sayans/Softwares/llvm-repo/llvm-project-latest/mlir/lib/Dialect/Tosa/IR/TosaCanonicalizations.cpp:0:0 ``` from the folder for `tosa::mul` since the zero value was being reshaped to `?x17` size which isn't supported. AFAIK, `tosa.const` requires all dimensions to be static. So in this case, the fix is to not to fold the op.
abhinavgaba
pushed a commit
that referenced
this pull request
Aug 25, 2025
This can happen when JIT code is run, and we can't symbolize those
frames, but they should remain numbered in the stack. An example
spidermonkey trace:
```
#0 0x564ac90fb80f (/builds/worker/dist/bin/js+0x240e80f) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#1 0x564ac9223a64 (/builds/worker/dist/bin/js+0x2536a64) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#2 0x564ac922316f (/builds/worker/dist/bin/js+0x253616f) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
#3 0x564ac9eac032 (/builds/worker/dist/bin/js+0x31bf032) (BuildId: 5d053c76aad4cfbd08259f8832e7ac78bbeeab58)
llvm#4 0x0dec477ca22e (<unknown module>)
```
Without this change, the following symbolization is output:
```
#0 0x55a6d72f980f in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:248:3
#1 0x55a6d72f980f in Crash(JSContext*, unsigned int, JS::Value*) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:4223:5
#2 0x55a6d7421a64 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:501:13
#3 0x55a6d742116f in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:597:12
llvm#4 0x55a6d80aa032 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/jit/BaselineIC.cpp:1705:10
llvm#4 0x2c803bd8f22e (<unknown module>)
```
The last frame has a duplicate number. With this change the numbering is
correct:
```
#0 0x5620c58ec80f in MOZ_CrashSequence /builds/worker/workspace/obj-build/dist/include/mozilla/Assertions.h:248:3
#1 0x5620c58ec80f in Crash(JSContext*, unsigned int, JS::Value*) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:4223:5
#2 0x5620c5a14a64 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:501:13
#3 0x5620c5a1416f in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:597:12
llvm#4 0x5620c669d032 in js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/jit/BaselineIC.cpp:1705:10
llvm#5 0x349f24c7022e (<unknown module>)
```
abhinavgaba
pushed a commit
that referenced
this pull request
Sep 8, 2025
Reverts llvm#154949 due to suspected buildbot breakage (https://lab.llvm.org/buildbot/#/builders/55/builds/16630/steps/11/logs/stdio). Previously commented on the original pull request: llvm#154949 (comment) ``` ******************** TEST 'MLIR :: Dialect/XeGPU/subgroup-distribute.mlir' FAILED ******************** ... # | PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace. # | Stack dump: # | 0. Program arguments: /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm_build_hwasan/bin/mlir-opt -xegpu-subgroup-distribute -allow-unregistered-dialect -canonicalize -cse -split-input-file /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/test/Dialect/XeGPU/subgroup-distribute.mlir # | #0 0x0000c0af4b066df0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/lib/Support/Unix/Signals.inc:834:13 # | #1 0x0000c0af4b060e20 llvm::sys::RunSignalHandlers() /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/lib/Support/Signals.cpp:105:18 # | #2 0x0000c0af4b0691b4 SignalHandler(int, siginfo_t*, void*) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/llvm/lib/Support/Unix/Signals.inc:426:38 # | #3 0x0000ee25a3dcb8f8 (linux-vdso.so.1+0x8f8) # | llvm#4 0x0000ee25a36c7608 (/lib/aarch64-linux-gnu/libc.so.6+0x87608) # | llvm#5 0x0000ee25a367cb3c raise (/lib/aarch64-linux-gnu/libc.so.6+0x3cb3c) # | llvm#6 0x0000ee25a3667e00 abort (/lib/aarch64-linux-gnu/libc.so.6+0x27e00) # | llvm#7 0x0000c0af4ae7e4b0 __sanitizer::Atexit(void (*)()) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_posix_libcdep.cpp:168:10 # | llvm#8 0x0000c0af4ae7c354 __sanitizer::Die() /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:52:5 # | llvm#9 0x0000c0af4ae66a30 Unlock /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/../sanitizer_common/sanitizer_mutex.h:250:16 # | llvm#10 0x0000c0af4ae66a30 ~GenericScopedLock /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/../sanitizer_common/sanitizer_mutex.h:386:51 # | llvm#11 0x0000c0af4ae66a30 __hwasan::ScopedReport::~ScopedReport() /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/hwasan_report.cpp:54:5 # | llvm#12 0x0000c0af4ae661b8 __hwasan::(anonymous namespace)::BaseReport::~BaseReport() /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/hwasan_report.cpp:477:7 # | llvm#13 0x0000c0af4ae63f5c __hwasan::ReportTagMismatch(__sanitizer::StackTrace*, unsigned long, unsigned long, bool, bool, unsigned long*) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/hwasan_report.cpp:1094:1 # | llvm#14 0x0000c0af4ae4f8e0 Destroy /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/../sanitizer_common/sanitizer_common.h:532:31 # | llvm#15 0x0000c0af4ae4f8e0 ~InternalMmapVector /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/../sanitizer_common/sanitizer_common.h:642:56 # | llvm#16 0x0000c0af4ae4f8e0 __hwasan::HandleTagMismatch(__hwasan::AccessInfo, unsigned long, unsigned long, void*, unsigned long*) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/hwasan.cpp:245:1 # | llvm#17 0x0000c0af4ae51e8c __hwasan_tag_mismatch4 /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/hwasan/hwasan.cpp:764:1 # | llvm#18 0x0000c0af4ae67b30 __interception::InterceptFunction(char const*, unsigned long*, unsigned long, unsigned long) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/compiler-rt/lib/interception/interception_linux.cpp:60:0 # | llvm#19 0x0000c0af5641cd24 getNumResults /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/include/mlir/IR/Operation.h:404:37 # | llvm#20 0x0000c0af5641cd24 getOpResultImpl /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/include/mlir/IR/Operation.h:1010:5 # | llvm#21 0x0000c0af5641cd24 getResult /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/include/mlir/IR/Operation.h:407:54 # | llvm#22 0x0000c0af5641cd24 mlir::OpTrait::detail::MultiResultTraitBase<mlir::gpu::WarpExecuteOnLane0Op, mlir::OpTrait::VariadicResults>::getResult(unsigned int) /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/include/mlir/IR/OpDefinition.h:638:62 # | llvm#23 0x0000c0af56426b60 getType /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/include/mlir/IR/Value.h:63:33 # | llvm#24 0x0000c0af56426b60 getType /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/include/mlir/IR/Value.h:105:39 # | llvm#25 0x0000c0af56426b60 (anonymous namespace)::LoadDistribution::matchAndRewrite(mlir::gpu::WarpExecuteOnLane0Op, mlir::PatternRewriter&) const /home/b/sanitizer-aarch64-linux-bootstrap-hwasan/build/llvm-project/mlir/lib/Dialect/XeGPU/Transforms/XeGPUSubgroupDistribute.cpp:991:55 ... ```
abhinavgaba
pushed a commit
that referenced
this pull request
Sep 25, 2025
A few improvements to logging when lldb-dap is started in **Server Mode** AND when the **`lldb-dap.logFolder`** setting is used (not `lldb-dap.log-path`). ### Improvement #1 **Avoid the prompt of restarting the server when starting each debug session.** That prompt is caused by the combination of the following facts: 1. The log filename changes every time a new debug session is starting (see [here](https://github.com/llvm/llvm-project/blob/9d6062c490548a5e6fea103e010ab3c9bc73a86d/lldb/tools/lldb-dap/src-ts/logging.ts#L47)) 2. The log filename is passed to the server via an environment variable called "LLDBDAP_LOG" (see [here](https://github.com/llvm/llvm-project/blob/9d6062c490548a5e6fea103e010ab3c9bc73a86d/lldb/tools/lldb-dap/src-ts/debug-adapter-factory.ts#L263-L269)) 3. All environment variables are put into the "spawn info" variable (see [here](https://github.com/llvm/llvm-project/blob/9d6062c490548a5e6fea103e010ab3c9bc73a86d/lldb/tools/lldb-dap/src-ts/lldb-dap-server.ts#L170-L172)). 4. The old and new "spawn info" are compared to decide if a prompt should show (see [here](https://github.com/llvm/llvm-project/blob/9d6062c490548a5e6fea103e010ab3c9bc73a86d/lldb/tools/lldb-dap/src-ts/lldb-dap-server.ts#L107-L110)). The fix is to remove the "LLDBDAP_LOG" from the "spawn info" variable, so that the same server can be reused if the log path is the only thing that has changed. ### Improvement #2 **Avoid log file conflict when multiple users share a machine and start server in the same second.** The problem: If two users start lldb-dap server in the same second, they will share the same log path. The first user will create the log file. The second user will find that they cannot access the same file, so their server will fail to start. The fix is to add a part of the VS Code session ID to the log filename. ### Improvement #3 **Avoid restarting the server when the order of environment variables changed.** This is done by sorting the environment variables before putting them into the "spawn info".
abhinavgaba
pushed a commit
that referenced
this pull request
Sep 25, 2025
Need this as `mlir/dialects/transform/smt.py` imports it: ```py from .._transform_smt_extension_ops_gen import * from .._transform_smt_extension_ops_gen import _Dialect ```
abhinavgaba
pushed a commit
that referenced
this pull request
Oct 20, 2025
**Mitigation for:** google/sanitizers#749 **Disclosure:** I'm not an ASan compiler expert yet (I'm trying to learn!), I primarily work in the runtime. Some of this PR was developed with the help of AI tools (primarily as a "fuzzy `grep` engine"), but I've manually refined and tested the output, and can speak for every line. In general, I used it only to orient myself and for "rubberducking". **Context:** The msvc ASan team (👋 ) has received an internal request to improve clang's exception handling under ASan for Windows. Namely, we're interested in **mitigating** this bug: google/sanitizers#749 To summarize, today, clang + ASan produces a false-positive error for this program: ```C++ #include <cstdio> #include <exception> int main() { try { throw std::exception("test"); }catch (const std::exception& ex){ puts(ex.what()); } return 0; } ``` The error reads as such: ``` C:\Users\dajusto\source\repros\upstream>type main.cpp #include <cstdio> #include <exception> int main() { try { throw std::exception("test"); }catch (const std::exception& ex){ puts(ex.what()); } return 0; } C:\Users\dajusto\source\repros\upstream>"C:\Users\dajusto\source\repos\llvm-project\build.runtimes\bin\clang.exe" -fsanitize=address -g -O0 main.cpp C:\Users\dajusto\source\repros\upstream>a.exe ================================================================= ==19112==ERROR: AddressSanitizer: access-violation on unknown address 0x000000000000 (pc 0x7ff72c7c11d9 bp 0x0080000ff960 sp 0x0080000fcf50 T0) ==19112==The signal is caused by a READ memory access. ==19112==Hint: address points to the zero page. #0 0x7ff72c7c11d8 in main C:\Users\dajusto\source\repros\upstream\main.cpp:8 #1 0x7ff72c7d479f in _CallSettingFrame C:\repos\msvc\src\vctools\crt\vcruntime\src\eh\amd64\handlers.asm:49 #2 0x7ff72c7c8944 in __FrameHandler3::CxxCallCatchBlock(struct _EXCEPTION_RECORD *) C:\repos\msvc\src\vctools\crt\vcruntime\src\eh\frame.cpp:1567 #3 0x7ffb4a90e3e5 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x18012e3e5) llvm#4 0x7ff72c7c1128 in main C:\Users\dajusto\source\repros\upstream\main.cpp:6 llvm#5 0x7ff72c7c33db in invoke_main C:\repos\msvc\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78 llvm#6 0x7ff72c7c33db in __scrt_common_main_seh C:\repos\msvc\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 llvm#7 0x7ffb49b05c06 (C:\WINDOWS\System32\KERNEL32.DLL+0x180035c06) llvm#8 0x7ffb4a8455ef (C:\WINDOWS\SYSTEM32\ntdll.dll+0x1800655ef) ==19112==Register values: rax = 0 rbx = 80000ff8e0 rcx = 27d76d00000 rdx = 80000ff8e0 rdi = 80000fdd50 rsi = 80000ff6a0 rbp = 80000ff960 rsp = 80000fcf50 r8 = 100 r9 = 19930520 r10 = 8000503a90 r11 = 80000fd540 r12 = 80000fd020 r13 = 0 r14 = 80000fdeb8 r15 = 0 AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: access-violation C:\Users\dajusto\source\repros\upstream\main.cpp:8 in main ==19112==ABORTING ``` The root of the issue _appears to be_ that ASan's instrumentation is incompatible with Window's assumptions for instantiating `catch`-block's parameters (`ex` in the snippet above). The nitty gritty details are lost on me, but I understand that to make this work without loss of ASan coverage, a "serious" refactoring is needed. In the meantime, users risk false positive errors when pairing ASan + catch-block parameters on Windows. **To mitigate this** I think we should avoid instrumenting catch-block parameters on Windows. It appears to me this is as "simple" as marking catch block parameters as "uninteresting" in `AddressSanitizer::isInterestingAlloca`. My manual tests seem to confirm this. I believe this is strictly better than today's status quo, where the runtime generates false positives. Although we're now explicitly choosing to instrument less, the benefit is that now more programs can run with ASan without _funky_ macros that disable ASan on exception blocks. **This PR:** implements the mitigation above, and creates a simple new test for it. _Thanks!_ --------- Co-authored-by: Antonio Frighetto <me@antoniofrighetto.com>
abhinavgaba
pushed a commit
that referenced
this pull request
Dec 15, 2025
… errors (llvm#169989) We can see the following while running clang-repl in C mode ``` anutosh491@vv-nuc:/build/anutosh491/llvm-project/build/bin$ ./clang-repl --Xcc=-x --Xcc=c --Xcc=-std=c23 clang-repl> printf("hi\n"); In file included from <<< inputs >>>:1: input_line_1:1:1: error: call to undeclared library function 'printf' with type 'int (const char *, ...)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 1 | printf("hi\n"); | ^ input_line_1:1:1: note: include the header <stdio.h> or explicitly provide a declaration for 'printf' error: Parsing failed. clang-repl> #include <stdio.h> hi ``` In debug mode while dumping the generated Module, i see this ``` clang-repl> printf("hi\n"); In file included from <<< inputs >>>:1: input_line_1:1:1: error: call to undeclared library function 'printf' with type 'int (const char *, ...)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] 1 | printf("hi\n"); | ^ input_line_1:1:1: note: include the header <stdio.h> or explicitly provide a declaration for 'printf' error: Parsing failed. clang-repl> #include <stdio.h> === compile-ptu 1 === [TU=0x55556cfbf830, M=0x55556cfc13a0 (incr_module_1)] [LLVM IR] ; ModuleID = 'incr_module_1' source_filename = "incr_module_1" target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" @.str = private unnamed_addr constant [4 x i8] c"hi\0A\00", align 1 @llvm.global_ctors = appending global [1 x { i32, ptr, ptr }] [{ i32, ptr, ptr } { i32 65535, ptr @_GLOBAL__sub_I_incr_module_1, ptr null }] define internal void @__stmts__0() #0 { entry: %call = call i32 (ptr, ...) @printf(ptr noundef @.str) ret void } declare i32 @printf(ptr noundef, ...) #1 ; Function Attrs: noinline nounwind uwtable define internal void @_GLOBAL__sub_I_incr_module_1() #2 section ".text.startup" { entry: call void @__stmts__0() ret void } attributes #0 = { "min-legal-vector-width"="0" } attributes #1 = { "frame-pointer"="all" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" } attributes #2 = { noinline nounwind uwtable "frame-pointer"="all" "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cmov,+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" } !llvm.module.flags = !{!0, !1, !2, !3, !4} !llvm.ident = !{!5} !0 = !{i32 1, !"wchar_size", i32 4} !1 = !{i32 8, !"PIC Level", i32 2} !2 = !{i32 7, !"PIE Level", i32 2} !3 = !{i32 7, !"uwtable", i32 2} !4 = !{i32 7, !"frame-pointer", i32 2} !5 = !{!"clang version 22.0.0git (https://github.com/anutosh491/llvm-project.git 81ad8fb)"} === end compile-ptu === execute-ptu 1: [TU=0x55556cfbf830, M=0x55556cfc13a0 (incr_module_1)] hi ``` Basically I see that CodeGen emits IR for a cell before we know whether DiagnosticsEngine has an error. For C code like `printf("hi\n");` without <stdio.h>, Sema emits a diagnostic but still produces a "codegen-able" `TopLevelStmt`, so the `printf` call is IR-generated into the current module. Previously, when `Diags.hasErrorOccurred()` was true, we only cleaned up the PTU AST and left the CodeGen module untouched. The next successful cell then called `GenModule()`, which returned that same module (now also containing the next cell’s IR), causing side effects from the failed cell (e.g. printf)
abhinavgaba
pushed a commit
that referenced
this pull request
Dec 23, 2025
…lvm#159480) When building rustc std for arm64e, core fails to compile successfully with the error: ``` Constant ValueID not recognized. UNREACHABLE executed at rust/src/llvm-project/llvm/lib/Transforms/Utils/FunctionComparator.cpp:523! ``` This is a result of function merging so I modified FunctionComparator.cpp as the ConstantPtrAuth value would go unchecked in the switch statement. The test case is a reduction from the failure in core and fails on main with: ``` ******************** FAIL: LLVM :: Transforms/MergeFunc/ptrauth-const-compare.ll (59809 of 59995) ******************** TEST 'LLVM :: Transforms/MergeFunc/ptrauth-const-compare.ll' FAILED ******************** Exit Code: 2 Command Output (stdout): -- # RUN: at line 3 /Users/oskarwirga/llvm-project/build/bin/opt -S -passes=mergefunc < /Users/oskarwirga/llvm-project/llvm/test/Transforms/MergeFunc/ptrauth-const-compare.ll | /Users/oskarwirga/llvm-project/build/bin/FileCheck /Users/oskarwirga/llvm-project/llvm/test/Transforms/MergeFunc/ptrauth-const-compare.ll # executed command: /Users/oskarwirga/llvm-project/build/bin/opt -S -passes=mergefunc # .---command stderr------------ # | Constant ValueID not recognized. # | UNREACHABLE executed at /Users/oskarwirga/llvm-project/llvm/lib/Transforms/Utils/FunctionComparator.cpp:523! # | 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: /Users/oskarwirga/llvm-project/build/bin/opt -S -passes=mergefunc # | 1. Running pass "mergefunc" on module "<stdin>" # | #0 0x0000000103335770 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/oskarwirga/llvm-project/build/bin/opt+0x102651770) # | #1 0x00000001033336bc llvm::sys::RunSignalHandlers() (/Users/oskarwirga/llvm-project/build/bin/opt+0x10264f6bc) # | #2 0x0000000103336218 SignalHandler(int, __siginfo*, void*) (/Users/oskarwirga/llvm-project/build/bin/opt+0x102652218) # | #3 0x000000018e6c16a4 (/usr/lib/system/libsystem_platform.dylib+0x1804ad6a4) # | llvm#4 0x000000018e68788c (/usr/lib/system/libsystem_pthread.dylib+0x18047388c) # | llvm#5 0x000000018e590a3c (/usr/lib/system/libsystem_c.dylib+0x18037ca3c) # | llvm#6 0x00000001032a84bc llvm::install_out_of_memory_new_handler() (/Users/oskarwirga/llvm-project/build/bin/opt+0x1025c44bc) # | llvm#7 0x00000001033b37c0 llvm::FunctionComparator::cmpMDNode(llvm::MDNode const*, llvm::MDNode const*) const (/Users/oskarwirga/llvm-project/build/bin/opt+0x1026cf7c0) # | llvm#8 0x00000001033b4d90 llvm::FunctionComparator::cmpBasicBlocks(llvm::BasicBlock const*, llvm::BasicBlock const*) const (/Users/oskarwirga/llvm-project/build/bin/opt+0x1026d0d90) # | llvm#9 0x00000001033b5234 llvm::FunctionComparator::compare() (/Users/oskarwirga/llvm-project/build/bin/opt+0x1026d1234) # | llvm#10 0x0000000102d6d868 (anonymous namespace)::MergeFunctions::insert(llvm::Function*) (/Users/oskarwirga/llvm-project/build/bin/opt+0x102089868) # | llvm#11 0x0000000102d6bc0c llvm::MergeFunctionsPass::runOnModule(llvm::Module&) (/Users/oskarwirga/llvm-project/build/bin/opt+0x102087c0c) # | llvm#12 0x0000000102d6b430 llvm::MergeFunctionsPass::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/Users/oskarwirga/llvm-project/build/bin/opt+0x102087430) # | llvm#13 0x0000000102b90558 llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/Users/oskarwirga/llvm-project/build/bin/opt+0x101eac558) # | llvm#14 0x0000000103734bc4 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/oskarwirga/llvm-project/build/bin/opt+0x102a50bc4) # | llvm#15 0x000000010373cc28 optMain (/Users/oskarwirga/llvm-project/build/bin/opt+0x102a58c28) # | llvm#16 0x000000018e2e6b98 # `----------------------------- # error: command failed with exit status: -6 # executed command: /Users/oskarwirga/llvm-project/build/bin/FileCheck /Users/oskarwirga/llvm-project/llvm/test/Transforms/MergeFunc/ptrauth-const-compare.ll # .---command stderr------------ # | FileCheck error: '<stdin>' is empty. # | FileCheck command line: /Users/oskarwirga/llvm-project/build/bin/FileCheck /Users/oskarwirga/llvm-project/llvm/test/Transforms/MergeFunc/ptrauth-const-compare.ll # `----------------------------- # error: command failed with exit status: 2 ```
abhinavgaba
pushed a commit
that referenced
this pull request
Jan 14, 2026
…lvm#175807) A buildbot was failing with a use-after-poison (https://lab.llvm.org/buildbot/#/builders/24/builds/16530) after llvm#175050: ``` ==llc==1532559==ERROR: AddressSanitizer: use-after-poison on address 0xe26e74e12368 at pc 0xb36d41bd74dc bp 0xffffed72a450 sp 0xffffed72a448 READ of size 8 at 0xe26e74e12368 thread T0 #0 0xb36d41bd74d8 in llvm::MachineInstr::print(llvm::raw_ostream&, bool, bool, bool, bool, llvm::TargetInstrInfo const*) const /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/lib/CodeGen/MachineInstr.cpp:1796:35 #1 0xb36d3e221b08 in operator<< /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/include/llvm/CodeGen/MachineInstr.h:2150:6 #2 0xb36d3e221b08 in llvm::PreRARematStage::rollback(llvm::PreRARematStage::RollbackInfo const&, llvm::BitVector&) const /home/b/sanitizer-aarch64-linux-bootstrap-asan/build/llvm-project/llvm/lib/Target/AMDGPU/GCNSchedStrategy.cpp:2363:57 ... ``` This is because it was printing an instruction that had already been deleted. This patch fixes this by reversing the order.
abhinavgaba
pushed a commit
that referenced
this pull request
Jan 21, 2026
**This patch adds a marker to make hidden frames more explicit.** --- Hidden frames can be confusing for some users, who see that the indexes of the frames in a backtrace are not contiguous. This patch aims to lessen the confusion by adding a delimiter for the first and last non hidden frame, i.e the boundaries. IDE's like Xcode and VSCode represent those in the UI by having the hidden frames either greyed out or collapsed. It's not possible to do this in the CLI, therefore, this patch makes use of 2 unicode characters to mark the beginning and end of the hidden frames range. This patch depends on: - llvm#168603 # Examples In the example below, frame `#2` to `llvm#7` are is hidden, and therefore, frame `#1` is the first non hidden frame of the range while frame `llvm#8` is the last non hidden frame: <img width="488" height="112" alt="Screenshot 2025-11-18 at 18 41 11" src="https://github.com/user-attachments/assets/a21431da-9729-4cf0-a6bc-024aa306fc45" /> If the selected frame is one of the 2 boundary frames, we replace the delimiter character with the select character (`*`). <img width="487" height="111" alt="Screenshot 2025-11-18 at 18 41 03" src="https://github.com/user-attachments/assets/5616fa81-6db6-457d-9d1e-bbe46e710c26" /> <img width="488" height="111" alt="Screenshot 2025-11-18 at 18 40 55" src="https://github.com/user-attachments/assets/93dfa6cf-0956-4718-b31c-f965ec72b56d" />
abhinavgaba
pushed a commit
that referenced
this pull request
Jan 21, 2026
… all redeclarations (llvm#176188) Fix handling of `lifetimebound` attributes on implicit `this` parameters across function redeclarations. Previously, the lifetime analysis would miss `lifetimebound` attributes on implicit `this` parameters if they were only present on certain redeclarations of a method. This could lead to false negatives in the lifetime safety analysis. This change ensures that if any redeclaration of a method has the attribute, it will be properly detected and used in the analysis. I can't seem to work around the crash in the earlier attempt llvm#172146. Reproducer of the original crash: ```cpp struct a { a &b() [[_Clang::__lifetimebound__]]; }; a &a::b() {} ``` This only crashes with `-target i686-w64-mingw32`. `bin/clang++ -c a.cpp` works fine. Problematic merging logic: ```cpp // If Old has lifetimebound but New doesn't, add it to New. if (OldLBAttr && !NewLBAttr) { QualType NewMethodType = New->getType(); QualType AttributedType = S.Context.getAttributedType(OldLBAttr, NewMethodType, NewMethodType); TypeLocBuilder TLB; TLB.pushFullCopy(NewTSI->getTypeLoc()); AttributedTypeLoc TyLoc = TLB.push<AttributedTypeLoc>(AttributedType); // Crashes. TyLoc.setAttr(OldLBAttr); New->setType(AttributedType); New->setTypeSourceInfo(TLB.getTypeSourceInfo(S.Context, AttributedType)); } ``` <details> <summary>Crash</summary> ``` clang++: /REDACTED//llvm-project/clang/lib/Sema/TypeLocBuilder.cpp:89: TypeLoc clang::TypeLocBuilder::pushImpl(QualType, size_t, unsigned int): Assertion `TLast == LastTy && "mismatch between last type and new type's inner type"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script. Stack dump: 0. Program arguments: bin/clang++ -target i686-w64-mingw32 -c /REDACTED//a.cpp 1. /REDACTED//a.cpp:4:11: current parser token '{' #0 0x000055971cfcb838 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) /REDACTED//llvm-project/llvm/lib/Support/Unix/Signals.inc:842:13 #1 0x000055971cfc9374 llvm::sys::RunSignalHandlers() /REDACTED//llvm-project/llvm/lib/Support/Signals.cpp:109:18 #2 0x000055971cfcaf0c llvm::sys::CleanupOnSignal(unsigned long) /REDACTED//llvm-project/llvm/lib/Support/Unix/Signals.inc:0:3 #3 0x000055971cf38116 (anonymous namespace)::CrashRecoveryContextImpl::HandleCrash(int, unsigned long) /REDACTED//llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:73:5 llvm#4 0x000055971cf38116 CrashRecoverySignalHandler(int) /REDACTED//llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:390:51 llvm#5 0x00007fe9ebe49df0 (/lib/x86_64-linux-gnu/libc.so.6+0x3fdf0) llvm#6 0x00007fe9ebe9e95c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 llvm#7 0x00007fe9ebe49cc2 raise ./signal/../sysdeps/posix/raise.c:27:6 llvm#8 0x00007fe9ebe324ac abort ./stdlib/abort.c:81:3 llvm#9 0x00007fe9ebe32420 __assert_perror_fail ./assert/assert-perr.c:31:1 llvm#10 0x000055971f969ade clang::TypeLocBuilder::pushImpl(clang::QualType, unsigned long, unsigned int) /REDACTED//llvm-project/clang/lib/Sema/TypeLocBuilder.cpp:93:3 llvm#11 0x000055971f237255 clang::QualType::hasLocalQualifiers() const /REDACTED//llvm-project/clang/include/clang/AST/TypeBase.h:1065:37 llvm#12 0x000055971f237255 clang::ConcreteTypeLoc<clang::UnqualTypeLoc, clang::AttributedTypeLoc, clang::AttributedType, clang::AttributedLocInfo>::isKind(clang::TypeLoc const&) /REDACTED//llvm-project/clang/include/clang/AST/TypeLoc.h:392:26 llvm#13 0x000055971f237255 clang::AttributedTypeLoc clang::TypeLoc::castAs<clang::AttributedTypeLoc>() const /REDACTED//llvm-project/clang/include/clang/AST/TypeLoc.h:79:5 llvm#14 0x000055971f237255 clang::AttributedTypeLoc clang::TypeLocBuilder::push<clang::AttributedTypeLoc>(clang::QualType) /REDACTED//llvm-project/clang/lib/Sema/TypeLocBuilder.h:106:47 llvm#15 0x000055971f280cc8 clang::AttributedTypeLoc::setAttr(clang::Attr const*) /REDACTED//llvm-project/clang/include/clang/AST/TypeLoc.h:1035:30 llvm#16 0x000055971f280cc8 mergeLifetimeBoundAttrOnMethod(clang::Sema&, clang::CXXMethodDecl*, clang::CXXMethodDecl const*) /REDACTED//llvm-project/clang/lib/Sema/SemaDecl.cpp:4497:11 llvm#17 0x000055971f280cc8 clang::Sema::MergeCompatibleFunctionDecls(clang::FunctionDecl*, clang::FunctionDecl*, clang::Scope*, bool) /REDACTED//llvm-project/clang/lib/Sema/SemaDecl.cpp:4528:5 llvm#18 0x000055971f27eb1f clang::Sema::MergeFunctionDecl(clang::FunctionDecl*, clang::NamedDecl*&, clang::Scope*, bool, bool) /REDACTED//llvm-project/clang/lib/Sema/SemaDecl.cpp:0:0 llvm#19 0x000055971f29c256 clang::Sema::CheckFunctionDeclaration(clang::Scope*, clang::FunctionDecl*, clang::LookupResult&, bool, bool) /REDACTED//llvm-project/clang/lib/Sema/SemaDecl.cpp:12371:9 llvm#20 0x000055971f28dab0 clang::Declarator::setRedeclaration(bool) /REDACTED//llvm-project/clang/include/clang/Sema/DeclSpec.h:2738:51 llvm#21 0x000055971f28dab0 clang::Sema::ActOnFunctionDeclarator(clang::Scope*, clang::Declarator&, clang::DeclContext*, clang::TypeSourceInfo*, clang::LookupResult&, llvm::MutableArrayRef<clang::TemplateParameterList*>, bool&) /REDACTED//llvm-project/clang/lib/Sema/SemaDecl.cpp:10877:9 llvm#22 0x000055971f2890fc clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&, llvm::MutableArrayRef<clang::TemplateParameterList*>) /REDACTED//llvm-project/clang/lib/Sema/SemaDecl.cpp:0:11 llvm#23 0x000055971f2aab99 clang::Sema::ActOnStartOfFunctionDef(clang::Scope*, clang::Declarator&, llvm::MutableArrayRef<clang::TemplateParameterList*>, clang::SkipBodyInfo*, clang::Sema::FnBodyKind) /REDACTED//llvm-project/clang/lib/Sema/SemaDecl.cpp:15904:15 llvm#24 0x000055971efab286 clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&, clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) /REDACTED//llvm-project/clang/lib/Parse/Parser.cpp:1364:23 llvm#25 0x000055971f013b40 clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, clang::DeclaratorContext, clang::ParsedAttributes&, clang::Parser::ParsedTemplateInfo&, clang::SourceLocation*, clang::Parser::ForRangeInit*) /REDACTED//llvm-project/clang/lib/Parse/ParseDecl.cpp:2268:18 llvm#26 0x000055971efaa54f clang::Parser::ParseDeclOrFunctionDefInternal(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec&, clang::AccessSpecifier) /REDACTED//llvm-project/clang/lib/Parse/Parser.cpp:0:10 llvm#27 0x000055971efa9e36 clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*, clang::AccessSpecifier) /REDACTED//llvm-project/clang/lib/Parse/Parser.cpp:1202:12 llvm#28 0x000055971efa8df8 clang::Parser::ParseExternalDeclaration(clang::ParsedAttributes&, clang::ParsedAttributes&, clang::ParsingDeclSpec*) /REDACTED//llvm-project/clang/lib/Parse/Parser.cpp:0:14 llvm#29 0x000055971efa7574 clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&, clang::Sema::ModuleImportState&) /REDACTED//llvm-project/clang/lib/Parse/Parser.cpp:743:10 llvm#30 0x000055971ef9c0ee clang::ParseAST(clang::Sema&, bool, bool) /REDACTED//llvm-project/clang/lib/Parse/ParseAST.cpp:169:5 llvm#31 0x000055971dbcdad6 clang::FrontendAction::Execute() /REDACTED//llvm-project/clang/lib/Frontend/FrontendAction.cpp:1317:10 llvm#32 0x000055971db3c5fd llvm::Error::getPtr() const /REDACTED//llvm-project/llvm/include/llvm/Support/Error.h:278:42 llvm#33 0x000055971db3c5fd llvm::Error::operator bool() /REDACTED//llvm-project/llvm/include/llvm/Support/Error.h:241:16 llvm#34 0x000055971db3c5fd clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /REDACTED//llvm-project/clang/lib/Frontend/CompilerInstance.cpp:1006:23 llvm#35 0x000055971dcb4f9c clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /REDACTED//llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:310:25 llvm#36 0x000055971a5e655e cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /REDACTED//llvm-project/clang/tools/driver/cc1_main.cpp:304:15 llvm#37 0x000055971a5e29cb ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&, llvm::ToolContext const&, llvm::IntrusiveRefCntPtr<llvm::vfs::FileSystem>) /REDACTED//llvm-project/clang/tools/driver/driver.cpp:226:12 llvm#38 0x000055971a5e4c1d clang_main(int, char**, llvm::ToolContext const&)::$_0::operator()(llvm::SmallVectorImpl<char const*>&) const /REDACTED//llvm-project/clang/tools/driver/driver.cpp:0:12 llvm#39 0x000055971a5e4c1d int llvm::function_ref<int (llvm::SmallVectorImpl<char const*>&)>::callback_fn<clang_main(int, char**, llvm::ToolContext const&)::$_0>(long, llvm::SmallVectorImpl<char const*>&) /REDACTED//llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:46:12 llvm#40 0x000055971d9bfe79 clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const::$_0::operator()() const /REDACTED//llvm-project/clang/lib/Driver/Job.cpp:442:30 llvm#41 0x000055971d9bfe79 void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const::$_0>(long) /REDACTED//llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:46:12 llvm#42 0x000055971cf37dbe llvm::function_ref<void ()>::operator()() const /REDACTED//llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:0:12 llvm#43 0x000055971cf37dbe llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) /REDACTED//llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:426:3 llvm#44 0x000055971d9bf5ac clang::driver::CC1Command::Execute(llvm::ArrayRef<std::optional<llvm::StringRef>>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>*, bool*) const /REDACTED//llvm-project/clang/lib/Driver/Job.cpp:442:7 llvm#45 0x000055971d98422c clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&, bool) const /REDACTED//llvm-project/clang/lib/Driver/Compilation.cpp:196:15 llvm#46 0x000055971d984447 clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&, bool) const /REDACTED//llvm-project/clang/lib/Driver/Compilation.cpp:246:13 llvm#47 0x000055971d99ee08 llvm::SmallVectorBase<unsigned int>::empty() const /REDACTED//llvm-project/llvm/include/llvm/ADT/SmallVector.h:83:46 llvm#48 0x000055971d99ee08 clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::pair<int, clang::driver::Command const*>>&) /REDACTED//llvm-project/clang/lib/Driver/Driver.cpp:2265:23 llvm#49 0x000055971a5e2303 clang_main(int, char**, llvm::ToolContext const&) /REDACTED//llvm-project/clang/tools/driver/driver.cpp:414:21 llvm#50 0x000055971a5f2527 main /usr/local/google/home/usx/build/tools/clang/tools/driver/clang-driver.cpp:17:10 llvm#51 0x00007fe9ebe33ca8 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3 llvm#52 0x00007fe9ebe33d65 call_init ./csu/../csu/libc-start.c:128:20 llvm#53 0x00007fe9ebe33d65 __libc_start_main ./csu/../csu/libc-start.c:347:5 llvm#54 0x000055971a5e0361 _start (bin/clang+++0x6636361) clang++: error: clang frontend command failed with exit code 134 (use -v to see invocation) clang version 23.0.0git (https://github.com/llvm/llvm-project.git 282a065) Target: i686-w64-windows-gnu Thread model: posix InstalledDir: /usr/local/google/home/usx/build/bin Build config: +assertions clang++: note: diagnostic msg: ******************** ``` </details>
abhinavgaba
pushed a commit
that referenced
this pull request
Jan 22, 2026
abhinavgaba
pushed a commit
that referenced
this pull request
Jan 29, 2026
This reverts commit 99fab01. llc was crashing in kernel-args.ll after this patch: ``` .---command stderr------------ | LLVM ERROR: Cannot select: t3: f32,ch = load<(non-temporal dereferenceable invariant load (s16), align 4, addrspace 7), sext from f16> t0, Constant:i32<36>, undef:i32 | In function: f16_arg | 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: /b/ml-opt-devrel-x86-64-b1/build/bin/llc -mtriple=r600 -mcpu=redwood | 1. Running pass 'Function Pass Manager' on module '<stdin>'. | 2. Running pass 'Unnamed pass: implement Pass::getPassName()' on function '@f16_arg' | #0 0x0000561402607438 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x81a7438) | #1 0x0000561402604b75 llvm::sys::RunSignalHandlers() (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x81a4b75) | #2 0x00005614026081b1 SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0 | #3 0x00007f55eb45a050 (/lib/x86_64-linux-gnu/libc.so.6+0x3c050) | llvm#4 0x00007f55eb4a8eec (/lib/x86_64-linux-gnu/libc.so.6+0x8aeec) | llvm#5 0x00007f55eb459fb2 raise (/lib/x86_64-linux-gnu/libc.so.6+0x3bfb2) | llvm#6 0x00007f55eb444472 abort (/lib/x86_64-linux-gnu/libc.so.6+0x26472) | llvm#7 0x0000561402567005 llvm::report_fatal_error(llvm::Twine const&, bool) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x8107005) | llvm#8 0x00005614023e7ba7 llvm::SelectionDAGISel::CannotYetSelect(llvm::SDNode*) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f87ba7) | llvm#9 0x00005614023e6a7d llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f86a7d) | llvm#10 0x00005614023dae94 llvm::SelectionDAGISel::DoInstructionSelection() (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f7ae94) | llvm#11 0x00005614023d9e6a llvm::SelectionDAGISel::CodeGenAndEmitDAG() (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f79e6a) | llvm#12 0x00005614023d7b5e llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f77b5e) | llvm#13 0x00005614023d4c30 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f74c30) | llvm#14 0x00005614023d22e0 llvm::SelectionDAGISelLegacy::runOnMachineFunction(llvm::MachineFunction&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7f722e0) | llvm#15 0x0000561401611793 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x71b1793) | llvm#16 0x0000561401b790e5 llvm::FPPassManager::runOnFunction(llvm::Function&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x77190e5) | llvm#17 0x0000561401b80f72 llvm::FPPassManager::runOnModule(llvm::Module&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7720f72) | llvm#18 0x0000561401b79b56 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x7719b56) | llvm#19 0x00005613ff4858f4 compileModule(char**, llvm::SmallVectorImpl<llvm::PassPlugin>&, llvm::LLVMContext&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>&) llc.cpp:0:0 | llvm#20 0x00005613ff482ed3 main (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x5022ed3) | llvm#21 0x00007f55eb44524a (/lib/x86_64-linux-gnu/libc.so.6+0x2724a) | llvm#22 0x00007f55eb445305 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x27305) | llvm#23 0x00005613ff47ea21 _start (/b/ml-opt-devrel-x86-64-b1/build/bin/llc+0x501ea21) `----------------------------- ```
abhinavgaba
pushed a commit
that referenced
this pull request
Feb 5, 2026
…lvm#178069) Kernel panic is a special case, and there is no signal or exception for that so we need to rely on special workaround called `dumptid`. FreeBSDKernel plugin is supposed to find this thread and set it manually through `SetStopInfo()` in `CalculateStopInfo()` like Mach core plugin does. Before (We had to find and select crashed thread list otherwise thread 1 was selected by default): ``` ➜ sudo lldb /boot/panic/kernel -c /var/crash/vmcore.last (lldb) target create "/boot/panic/kernel" --core "/var/crash/vmcore.last" Core file '/var/crash/vmcore.last' (x86_64) was loaded. (lldb) bt * thread #1, name = '(pid 12991) dtrace' * frame #0: 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff8015882f780, flags=259) at sched_ule.c:2448:26 frame #1: 0xffffffff80bd38d2 kernel`mi_switch(flags=259) at kern_synch.c:530:2 frame #2: 0xffffffff80c29799 kernel`sleepq_switch(wchan=0xfffff8014edff300, pri=0) at subr_sleepqueue.c:608:2 frame #3: 0xffffffff80c29b76 kernel`sleepq_catch_signals(wchan=0xfffff8014edff300, pri=0) at subr_sleepqueue.c:523:3 frame llvm#4: 0xffffffff80c29d32 kernel`sleepq_timedwait_sig(wchan=<unavailable>, pri=<unavailable>) at subr_sleepqueue.c:704:11 frame llvm#5: 0xffffffff80bd2e2d kernel`_sleep(ident=0xfffff8014edff300, lock=0xffffffff81df2880, priority=768, wmesg="uwait", sbt=2573804118162, pr=0, flags=512) at kern_synch.c:215:10 frame llvm#6: 0xffffffff80be8622 kernel`umtxq_sleep(uq=0xfffff8014edff300, wmesg="uwait", timo=0xfffffe0279cb3d20) at kern_umtx.c:843:11 frame llvm#7: 0xffffffff80bef87a kernel`do_wait(td=0xfffff8015882f780, addr=<unavailable>, id=0, timeout=0xfffffe0279cb3d90, compat32=1, is_private=1) at kern_umtx.c:1316:12 frame llvm#8: 0xffffffff80bed264 kernel`__umtx_op_wait_uint_private(td=0xfffff8015882f780, uap=0xfffffe0279cb3dd8, ops=<unavailable>) at kern_umtx.c:3990:10 frame llvm#9: 0xffffffff80beaabe kernel`sys__umtx_op [inlined] kern__umtx_op(td=<unavailable>, obj=<unavailable>, op=<unavailable>, val=<unavailable>, uaddr1=<unavailable>, uaddr2=<unavailable>, ops=<unavailable>) at kern_umtx.c:4999:10 frame llvm#10: 0xffffffff80beaa89 kernel`sys__umtx_op(td=<unavailable>, uap=<unavailable>) at kern_umtx.c:5024:10 frame llvm#11: 0xffffffff81122cd1 kernel`amd64_syscall [inlined] syscallenter(td=0xfffff8015882f780) at subr_syscall.c:165:11 frame llvm#12: 0xffffffff81122c19 kernel`amd64_syscall(td=0xfffff8015882f780, traced=0) at trap.c:1208:2 frame llvm#13: 0xffffffff810f1dbb kernel`fast_syscall_common at exception.S:570 ``` After: ``` ➜ sudo ./build/bin/lldb /boot/panic/kernel -c /var/crash/vmcore.last (lldb) target create "/boot/panic/kernel" --core "/var/crash/vmcore.last" Core file '/var/crash/vmcore.last' (x86_64) was loaded. (lldb) bt * thread llvm#18, name = '(pid 5409) powerd (crashed)', stop reason = kernel panic * frame #0: 0xffffffff80bc6c91 kernel`__curthread at pcpu_aux.h:57:2 [inlined] frame #1: 0xffffffff80bc6c91 kernel`doadump(textdump=0) at kern_shutdown.c:399:2 frame #2: 0xffffffff804b3b7a kernel`db_dump(dummy=<unavailable>, dummy2=<unavailable>, dummy3=<unavailable>, dummy4=<unavailable>) at db_command.c:596:10 frame #3: 0xffffffff804b396d kernel`db_command(last_cmdp=<unavailable>, cmd_table=<unavailable>, dopager=true) at db_command.c:508:3 frame llvm#4: 0xffffffff804b362d kernel`db_command_loop at db_command.c:555:3 frame llvm#5: 0xffffffff804b7026 kernel`db_trap(type=<unavailable>, code=<unavailable>) at db_main.c:267:3 frame llvm#6: 0xffffffff80c16aaf kernel`kdb_trap(type=3, code=0, tf=0xfffffe01b605b930) at subr_kdb.c:790:13 frame llvm#7: 0xffffffff8112154e kernel`trap(frame=<unavailable>) at trap.c:614:8 frame llvm#8: 0xffffffff810f14c8 kernel`calltrap at exception.S:285 frame llvm#9: 0xffffffff81da2290 kernel`cn_devtab + 64 frame llvm#10: 0xfffffe01b605b8b0 frame llvm#11: 0xffffffff84001c43 dtrace.ko`dtrace_panic(format=<unavailable>) at dtrace.c:652:2 frame llvm#12: 0xffffffff84005524 dtrace.ko`dtrace_action_panic(ecb=0xfffff80539cad580) at dtrace.c:7022:2 [inlined] frame llvm#13: 0xffffffff840054de dtrace.ko`dtrace_probe(id=88998, arg0=14343377283488, arg1=<unavailable>, arg2=<unavailable>, arg3=<unavailable>, arg4=<unavailable>) at dtrace.c:7665:6 frame llvm#14: 0xffffffff83e5213d systrace.ko`systrace_probe(sa=<unavailable>, type=<unavailable>, retval=<unavailable>) at systrace.c:226:2 frame llvm#15: 0xffffffff8112318d kernel`syscallenter(td=0xfffff801318d5780) at subr_syscall.c:160:4 [inlined] frame llvm#16: 0xffffffff81123112 kernel`amd64_syscall(td=0xfffff801318d5780, traced=0) at trap.c:1208:2 frame llvm#17: 0xffffffff810f1dbb kernel`fast_syscall_common at exception.S:570 ```
abhinavgaba
pushed a commit
that referenced
this pull request
Feb 5, 2026
…8306) In FreeBSD, allproc is a prepend list and new processes are appended at head. This results in reverse pid order, so we first need to order pid incrementally then print threads according to the correct order. Before: ``` Process 0 stopped * thread #1: tid = 101866, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff8015882f780, flags=259) at sched_ule.c:2448:26, name = '(pid 12991) dtrace' thread #2: tid = 101915, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff80158825780, flags=259) at sched_ule.c:2448:26, name = '(pid 11509) zsh' thread #3: tid = 101942, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff80142599000, flags=259) at sched_ule.c:2448:26, name = '(pid 11504) ftcleanup' thread llvm#4: tid = 101545, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff80131898000, flags=259) at sched_ule.c:2448:26, name = '(pid 5599) zsh' thread llvm#5: tid = 100905, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff80131899000, flags=259) at sched_ule.c:2448:26, name = '(pid 5598) sshd-session' thread llvm#6: tid = 101693, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff8015886e780, flags=259) at sched_ule.c:2448:26, name = '(pid 5595) sshd-session' thread llvm#7: tid = 101626, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801588be000, flags=259) at sched_ule.c:2448:26, name = '(pid 5592) sh' ... ``` After: ``` (lldb) thread list Process 0 stopped * thread #1: tid = 100000, 0xffffffff80bf9322 kernel`sched_switch(td=0xffffffff81abe840, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel' thread #2: tid = 100035, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d9780, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_0' thread #3: tid = 100036, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d9000, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_1' thread llvm#4: tid = 100037, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d8780, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_2' thread llvm#5: tid = 100038, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d8000, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_3' thread llvm#6: tid = 100039, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d7780, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_4' thread llvm#7: tid = 100040, 0xffffffff80bf9322 kernel`sched_switch(td=0xfffff801052d7000, flags=259) at sched_ule.c:2448:26, name = '(pid 0) kernel/softirq_5' ... ``` Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
abhinavgaba
pushed a commit
that referenced
this pull request
Mar 2, 2026
Using code/ideas from the x86 backend to optimize a select on a bitcast integer. The previous aarch64 approach was to individually extract the bits from the mask, which is kind of terrible. https://rust.godbolt.org/z/576sndT66 ```llvm define void @if_then_else8(ptr %out, i8 %mask, ptr %if_true, ptr %if_false) { start: %t = load <8 x i32>, ptr %if_true, align 4 %f = load <8 x i32>, ptr %if_false, align 4 %m = bitcast i8 %mask to <8 x i1> %s = select <8 x i1> %m, <8 x i32> %t, <8 x i32> %f store <8 x i32> %s, ptr %out, align 4 ret void } ``` turned into ```asm if_then_else8: // @if_then_else8 sub sp, sp, llvm#16 ubfx w8, w1, llvm#4, #1 and w11, w1, #0x1 ubfx w9, w1, llvm#5, #1 fmov s1, w11 ubfx w10, w1, #1, #1 fmov s0, w8 ubfx w8, w1, llvm#6, #1 ldp q5, q2, [x3] mov v1.h[1], w10 ldp q4, q3, [x2] mov v0.h[1], w9 ubfx w9, w1, #2, #1 mov v1.h[2], w9 ubfx w9, w1, #3, #1 mov v0.h[2], w8 ubfx w8, w1, llvm#7, #1 mov v1.h[3], w9 mov v0.h[3], w8 ushll v1.4s, v1.4h, #0 ushll v0.4s, v0.4h, #0 shl v1.4s, v1.4s, llvm#31 shl v0.4s, v0.4s, llvm#31 cmlt v1.4s, v1.4s, #0 cmlt v0.4s, v0.4s, #0 bsl v1.16b, v4.16b, v5.16b bsl v0.16b, v3.16b, v2.16b stp q1, q0, [x0] add sp, sp, llvm#16 ret ``` With this PR that instead emits ```asm if_then_else8: adrp x8, .LCPI0_1 dup v0.4s, w1 ldr q1, [x8, :lo12:.LCPI0_1] adrp x8, .LCPI0_0 ldr q2, [x8, :lo12:.LCPI0_0] ldp q4, q3, [x2] and v1.16b, v0.16b, v1.16b and v0.16b, v0.16b, v2.16b ldp q5, q2, [x3] cmeq v1.4s, v1.4s, #0 cmeq v0.4s, v0.4s, #0 bsl v1.16b, v2.16b, v3.16b bsl v0.16b, v5.16b, v4.16b stp q0, q1, [x0] ret ``` So substantially shorter. Instead of building the mask element-by-element, this approach (by virtue of not splitting) instead splats the mask value into all vector lanes, performs a bitwise and with powers of 2, and compares with zero to construct the mask vector. cc rust-lang/rust#122376 cc llvm#175769
abhinavgaba
pushed a commit
that referenced
this pull request
Mar 17, 2026
`SE.getUMaxExpr` causes assertion failure due to type mismatch here: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Analysis/LoopAccessAnalysis.cpp#L253 Running `opt -S -p loop-vectorize -debug-only=loop-vectorize llvm/test/Analysis/LoopAccessAnalysis/type-mismatch-in-scalar-evolution.ll ` without the changes made in LoopAccessAnalysis.cpp causes assertion failure. Attaching the stack dump for reference: ``` LV: Checking a loop in 'loop_contains_store_assumed_bounds' from input.ll LV: Loop hints: force=? width=4 interleave=0 LV: Found a loop: for.body LV: Found an induction variable. opt: /home/kshitij/llvm-project/llvm/lib/Analysis/ScalarEvolution.cpp:3918: const llvm::SCEV* llvm::ScalarEvolution::getMinMaxExpr(llvm::SCEVTypes, llvm::SmallVectorImpl<const llvm::SCEV*>&): Assertion `getEffectiveSCEVType(Ops[i]->getType()) == ETy && "Operand types don't match!"' failed. PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace and instructions to reproduce the bug. Stack dump: 0. Program arguments: opt -S -passes=loop-vectorize -debug-only=loop-vectorize -force-vector-width=4 -disable-output input.ll 1. Running pass "function(loop-vectorize<no-interleave-forced-only;no-vectorize-forced-only;>)" on module "input.ll" 2. Running pass "loop-vectorize<no-interleave-forced-only;no-vectorize-forced-only;>" on function "loop_contains_store_assumed_bounds" #0 0x000058ee97c5e652 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/bin/opt+0x4f44652) #1 0x000058ee97c5af0f llvm::sys::RunSignalHandlers() (/usr/local/bin/opt+0x4f40f0f) #2 0x000058ee97c5b05c SignalHandler(int, siginfo_t*, void*) Signals.cpp:0:0 #3 0x00007c49d4c45330 (/lib/x86_64-linux-gnu/libc.so.6+0x45330) llvm#4 0x00007c49d4c9eb2c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 llvm#5 0x00007c49d4c9eb2c __pthread_kill_internal ./nptl/pthread_kill.c:78:10 llvm#6 0x00007c49d4c9eb2c pthread_kill ./nptl/pthread_kill.c:89:10 llvm#7 0x00007c49d4c4527e raise ./signal/../sysdeps/posix/raise.c:27:6 llvm#8 0x00007c49d4c288ff abort ./stdlib/abort.c:81:7 llvm#9 0x00007c49d4c2881b _nl_load_domain ./intl/loadmsgcat.c:1177:9 llvm#10 0x00007c49d4c3b517 (/lib/x86_64-linux-gnu/libc.so.6+0x3b517) llvm#11 0x000058ee98003fdb llvm::ScalarEvolution::getMinMaxExpr(llvm::SCEVTypes, llvm::SmallVectorImpl<llvm::SCEV const*>&) (/usr/local/bin/opt+0x52e9fdb) llvm#12 0x000058ee98004507 llvm::ScalarEvolution::getUMaxExpr(llvm::SCEV const*, llvm::SCEV const*) (/usr/local/bin/opt+0x52ea507) llvm#13 0x000058ee980dc728 llvm::getStartAndEndForAccess(llvm::Loop const*, llvm::SCEV const*, llvm::Type*, llvm::SCEV const*, llvm::SCEV const*, llvm::ScalarEvolution*, llvm::DenseMap<std::pair<llvm::SCEV const*, llvm::Type*>, std::pair<llvm::SCEV const*, llvm::SCEV const*>, llvm::DenseMapInfo<std::pair<llvm::SCEV const*, llvm::Type*>, void>, llvm::detail::DenseMapPair<std::pair<llvm::SCEV const*, llvm::Type*>, std::pair<llvm::SCEV const*, llvm::SCEV const*>>>*, llvm::DominatorTree*, llvm::AssumptionCache*, std::optional<llvm::ScalarEvolution::LoopGuards>&) (/usr/local/bin/opt+0x53c2728) llvm#14 0x000058ee9814008b llvm::isDereferenceableAndAlignedInLoop(llvm::LoadInst*, llvm::Loop*, llvm::ScalarEvolution&, llvm::DominatorTree&, llvm::AssumptionCache*, llvm::SmallVectorImpl<llvm::SCEVPredicate const*>*) (/usr/local/bin/opt+0x542608b) llvm#15 0x000058ee9a0fa1ca llvm::LoopVectorizationLegality::canUncountableExitConditionLoadBeMoved(llvm::BasicBlock*) (/usr/local/bin/opt+0x73e01ca) llvm#16 0x000058ee9a0faee0 llvm::LoopVectorizationLegality::isVectorizableEarlyExitLoop() (/usr/local/bin/opt+0x73e0ee0) llvm#17 0x000058ee9a104678 llvm::LoopVectorizationLegality::canVectorize(bool) (/usr/local/bin/opt+0x73ea678) llvm#18 0x000058ee9a08c953 llvm::LoopVectorizePass::processLoop(llvm::Loop*) (/usr/local/bin/opt+0x7372953) llvm#19 0x000058ee9a090e21 llvm::LoopVectorizePass::runImpl(llvm::Function&) (/usr/local/bin/opt+0x7376e21) llvm#20 0x000058ee9a0914e0 llvm::LoopVectorizePass::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/usr/local/bin/opt+0x73774e0) llvm#21 0x000058ee99e419a5 llvm::detail::PassModel<llvm::Function, llvm::LoopVectorizePass, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) PassBuilderPipelines.cpp:0:0 llvm#22 0x000058ee97f18905 llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) (/usr/local/bin/opt+0x51fe905) llvm#23 0x000058ee995d70d5 llvm::detail::PassModel<llvm::Function, llvm::PassManager<llvm::Function, llvm::AnalysisManager<llvm::Function>>, llvm::AnalysisManager<llvm::Function>>::run(llvm::Function&, llvm::AnalysisManager<llvm::Function>&) AMDGPUTargetMachine.cpp:0:0 llvm#24 0x000058ee97f17051 llvm::ModuleToFunctionPassAdaptor::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/usr/local/bin/opt+0x51fd051) llvm#25 0x000058ee995d7775 llvm::detail::PassModel<llvm::Module, llvm::ModuleToFunctionPassAdaptor, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) AMDGPUTargetMachine.cpp:0:0 llvm#26 0x000058ee97f1783d llvm::PassManager<llvm::Module, llvm::AnalysisManager<llvm::Module>>::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&) (/usr/local/bin/opt+0x51fd83d) llvm#27 0x000058ee9c153909 llvm::runPassPipeline(llvm::StringRef, llvm::Module&, llvm::TargetMachine*, llvm::TargetLibraryInfoImpl*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::ToolOutputFile*, llvm::StringRef, llvm::ArrayRef<llvm::PassPlugin>, llvm::ArrayRef<std::function<void (llvm::PassBuilder&)>>, llvm::opt_tool::OutputKind, llvm::opt_tool::VerifierKind, bool, bool, bool, bool, bool, bool, bool, bool) (/usr/local/bin/opt+0x9439909) llvm#28 0x000058ee97c3f380 optMain (/usr/local/bin/opt+0x4f25380) llvm#29 0x00007c49d4c2a1ca __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3 llvm#30 0x00007c49d4c2a28b call_init ./csu/../csu/libc-start.c:128:20 llvm#31 0x00007c49d4c2a28b __libc_start_main ./csu/../csu/libc-start.c:347:5 llvm#32 0x000058ee97c309a5 _start (/usr/local/bin/opt+0x4f169a5) ``` This is caused by a type mismatch between `SE.getSCEV(DerefRK.IRArgValue)` and `DerefBytesSCEV`. Fixing this by extending them to the wider type.
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.
memcpycode" (Revert "[libc][NFC] refactor Cortexmemcpycode" llvm/llvm-project#149035)forinmatchAssociativeReduction([SLP][NFC] Use range-basedforinmatchAssociativeReductionllvm/llvm-project#149029)count_iftocount([SLP][NFC] Simplifycount_iftocountllvm/llvm-project#149072)ExceptionHandlingfromLangOptionstoCodeGenOptions([clang] MoveExceptionHandlingfromLangOptionstoCodeGenOptionsllvm/llvm-project#148982)<abi>and<pref>([LangRef] Document the difference between<abi>and<pref>llvm/llvm-project#147929)refractintrinsic ([HLSL][DXIL] Implementrefractintrinsic llvm/llvm-project#147342)v_rsq_bf16on gfx1250 ([AMDGPU] Add support forv_rsq_bf16on gfx1250 llvm/llvm-project#149194)v_log_bf16on gfx1250 ([AMDGPU] Add support forv_log_bf16on gfx1250 llvm/llvm-project#149201)(lldb) b([lldb] [cosmetic] Update help message of(lldb) bllvm/llvm-project#149114)range_formatandformat_kinddeclarations ([libc++] Granularizerange_formatandformat_kinddeclarations llvm/llvm-project#148876)memsetandmemcpyfunctions ([libc] Improve Cortexmemsetandmemcpyfunctions llvm/llvm-project#149044)v_exp_bf16on gfx1250 ([AMDGPU] Add support forv_exp_bf16on gfx1250 llvm/llvm-project#149229)v_sin_bf16on gfx1250 ([AMDGPU] Add support forv_sin_bf16on gfx1250 llvm/llvm-project#149241)umin([DAGCombiner] Fold vector subtraction if above threshold touminllvm/llvm-project#148834){i64,i64}for SysV-like ABIs ([Clang][CodeGen][X86] don't coerce int128 into{i64,i64}for SysV-like ABIs llvm/llvm-project#135230)alignmentattribute to memory access ops ([mlir][vector][memref] Addalignmentattribute to memory access ops llvm/llvm-project#144344)v_cos_bf16on gfx1250 ([AMDGPU] Add support forv_cos_bf16on gfx1250 llvm/llvm-project#149355)v_tanh_f32on gfx1250 ([AMDGPU] Add support forv_tanh_f32on gfx1250 llvm/llvm-project#149360)amdgpu.gather_to_lds([mlir][amdgpu] Properly handle mismatching memref ranks inamdgpu.gather_to_ldsllvm/llvm-project#149407)clang fp reciprocalin clc_native_divide/recip/rsqrt/tan ([libclc] Enableclang fp reciprocalin clc_native_divide/recip/rsqrt/tan llvm/llvm-project#149269)icmp gte->icmp sge([LangRef] fix non-existanticmp gte->icmp sgellvm/llvm-project#149420)COSPI([flang] ImplementCOSPIllvm/llvm-project#149343)NamespaceBaseDecl([Clang][AST][NFC] IntroduceNamespaceBaseDeclllvm/llvm-project#149123)v_tanh_f16on gfx1250 ([AMDGPU] Add support forv_tanh_f16on gfx1250 llvm/llvm-project#149439)simplifyDuplicateSwitchArmsuninitializedfromallockindwhen creating dummy zeroed variant function ([DSE] Removeuninitializedfromallockindwhen creating dummy zeroed variant function llvm/llvm-project#149336)MachineBlockFrequencyInfo's constructor arguments const (NFC) ([LLVM] MakeMachineBlockFrequencyInfo's constructor arguments const (NFC) llvm/llvm-project#149279)dead_on_returnwhen passing arguments indirectly__builtin_amdgcn_sqrt_bf16([Clang][AMDGPU] Add the missing builtin__builtin_amdgcn_sqrt_bf16llvm/llvm-project#149447)v_prng_b32on gfx1250 ([AMDGPU] Add support forv_prng_b32on gfx1250 llvm/llvm-project#149450)getName()to error messages for better debugging ([TableGen] AddgetName()to error messages for better debugging llvm/llvm-project#149531)v_permlane16_swap_b32on gfx1250 ([AMDGPU] Add support forv_permlane16_swap_b32on gfx1250 llvm/llvm-project#149518)v_sat_pk4_i4_[i8,u8]on gfx1250 ([AMDGPU] Add support forv_sat_pk4_i4_[i8,u8]on gfx1250 llvm/llvm-project#149528)vector.insertelement/extractelement([mlir][Flang][NFC] Replace use ofvector.insertelement/extractelementllvm/llvm-project#143272)REQUIRES: assertsfor --debug-only flag ([mlir][test] Add missingREQUIRES: assertsfor --debug-only flag llvm/llvm-project#149634)prepare_builtins_*variables in top-level CMakeLists ([libclc] Exposeprepare_builtins_*variables in top-level CMakeLists llvm/llvm-project#149657)std::ranges::zip_transform_view([libc++][ranges] implementstd::ranges::zip_transform_viewllvm/llvm-project#79605)isaCopyOpInterface([mlir][linalg] Add missing check forisaCopyOpInterfacellvm/llvm-project#149313)BreakBeforeBinaryOperators: All([clang-format] Fix a bug inBreakBeforeBinaryOperators: Allllvm/llvm-project#149695)[X]VMSK{LT,GE,NE}Z([LoongArch] Fix failure to widen operand for[X]VMSK{LT,GE,NE}Zllvm/llvm-project#149442)tosa.cond_if([mlir][tosa] Fix check for isolated regions intosa.cond_ifllvm/llvm-project#143772)v_sqrt_bf16([NFC][AMDGPU] Add an IR test forv_sqrt_bf16llvm/llvm-project#149629)v_cvt_f16_bf8([NFC][AMDGPU] Add an IR test forv_cvt_f16_bf8llvm/llvm-project#149627)llvm.[sin/cos].bf16([AMDGPU] Add the code generation support forllvm.[sin/cos].bf16llvm/llvm-project#149631)llvm/test/CodeGen/AMDGPU/attributor-noalias-addrspace.ll(#149826)llvm.lifetime.*intrinsics to stores when DXIL version is lower than 1.6 (#147432)" (#149874)includecreate APIs (3/n) (#149687)llvm.lifetime.*intrinsics to stores when DXIL version is lower than 1.6 (#147432)"" (#149882)flang/Optimizer/Transformscreate APIs (11/n) (#149915)flang/Lowercreate APIs (8/n) (#149912)flang/Optimizer/Builder/Runtimecreate APIs (10/n) (#149916)flang/Optimizer/Buildercreate APIs (9/n) (#149917)mlir/Dialectcreate APIs (16/n) (#149922)mlir/Dialectcreate APIs (22/n) (#149929)mlir/Dialectcreate APIs (25/n) (#149932)android(#149899)-Xflag in baremetal toolchain (#148855)vector.contractto SVE FEAT_BF16 operations (#147052)-Osand-Ozas multilib flags (#149819)VectorLoadOpConverter(#149964)mlir/Dialectcreate APIs (21/n) (#149928)mlir/Dialectcreate APIs (24/n) (#149931)Conversioncreate APIs (6/n) (#149888)mlir/libcreate APIs (26/n) (#149933)tosa.while_loop(#144865)bugprone-infinite-loopcheck by adding handing for structured bindings (#144213)mlir/Dialectcreate APIs (19/n) (#149926)Conversioncreate APIs (5/n) (#149887)Conversioncreate APIs (7/n) (#149889)#pragma push_macro("")or#pragma pop_macro("")(#149982)tooling::ToolAction(#149904)rocdl.s.waitcntwrapper (#149670)DwarfFDECache::findFDE()in definition (#146308)v_cvt_pk_bf16_f32on gfx1250 (#150053)amdgcn_tanhas canonicalized (#150059)llvm.lifetime.*intrinsics in EmbedDXILPass (#150100)clang-scan-deps. (#149857)sinpi(#149525)