Build and push container to my local registry #2

Nerixyz · 2025-06-30T14:17:06Z

No description provided.

Fix unnecessary conversion of C-String to StringRef in the `Cmp` lambda inside `lookupLLVMIntrinsicByName`. This both fixes an ASAN error in the code that happens when the `Name` StringRef passed in is not a Null terminated StringRef, and additionally can potentially speed up the code as well by eliminating the unnecessary computation of string length every time a C String is converted to StringRef in this code (It seems practically this computation is eliminated in optimized builds, but this will avoid it in O0 builds as well). Added a unit test that demonstrates this issue by building LLVM with these options: ``` CMAKE_BUILD_TYPE=Debug LLVM_USE_SANITIZER=Address LLVM_OPTIMIZE_SANITIZED_BUILDS=OFF ``` The error reported is as follows: ``` ==462665==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5030000391a2 at pc 0x56525cc30bbf bp 0x7fff9e4ccc60 sp 0x7fff9e4cc428 READ of size 19 at 0x5030000391a2 thread T0 #0 0x56525cc30bbe in strlen (upstream-llvm-second/llvm-project/build/unittests/IR/IRTests+0x713bbe) (BuildId: 0651acf1e582a4d2) #1 0x7f8ff22ad334 in std::char_traits<char>::length(char const*) /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/char_traits.h:399:9 #2 0x7f8ff22a34a0 in llvm::StringRef::StringRef(char const*) /home/rjoshi/upstream-llvm-second/llvm-project/llvm/include/llvm/ADT/StringRef.h:96:33 #3 0x7f8ff28ca184 in _ZZL25lookupLLVMIntrinsicByNameN4llvm8ArrayRefIjEENS_9StringRefES2_ENK3$_0clIjPKcEEDaT_T0_ upstream-llvm-second/llvm-project/llvm/lib/IR/Intrinsics.cpp:673:18 ```

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.

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

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

…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 ... ```

## 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)

…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.

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>) ```

…build breakage from llvm#155943) (llvm#156103) ASan now detects dereferences of zero-sized allocations (llvm#155943; the corresponding MSan change is llvm#155944). This appears to have detected a bug in CrossOverTest.cpp, causing a buildbot breakage. This patch fixes the test. Buildbot report: https://lab.llvm.org/buildbot/#/builders/4/builds/8732 ``` 7: ==949882==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf169cfbe0010 at pc 0xb5f45efc6d1c bp 0xffffd933e460 sp 0xffffd933e458 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 8: READ of size 1 at 0xf169cfbe0010 thread T0 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 9: #0 0xb5f45efc6d18 in LLVMFuzzerTestOneInput /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/test/fuzzer/CrossOverTest.cpp:48:7 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ check:20'1 ? possible intended match 10: #1 0xb5f45eec7288 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 11: #2 0xb5f45eec85d4 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::vector<fuzzer::SizedFile, std::allocator<fuzzer::SizedFile>>&) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:812:3 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 12: #3 0xb5f45eec8c60 in fuzzer::Fuzzer::Loop(std::vector<fuzzer::SizedFile, std::allocator<fuzzer::SizedFile>>&) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:872:3 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13: llvm#4 0xb5f45eeb5c64 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:923:6 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 14: llvm#5 0xb5f45eee09d0 in main /home/tcwg-buildbot/worker/clang-aarch64-sve-vls-2stage/llvm/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10 check:20'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``` For context, FuzzerLoop.cpp:812 tries empty input: ``` 810 // Test the callback with empty input and never try it again. 811 uint8_t dummy = 0; 812 ExecuteCallback(&dummy, 0); ```

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 ... ```

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".

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 ```

A recent change adding a new sanitizer kind (via Sanitizers.def) was reverted in c74fa20 ("Revert "[Clang][CodeGen] Introduce the AllocToken SanitizerKind" (llvm#162413)"). The reason was this ASan report, when running the test cases in clang/test/Preprocessor/print-header-json.c: ``` ==clang==483265==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7d82b97e8b58 at pc 0x562cd432231f bp 0x7fff3fad0850 sp 0x7fff3fad0848 READ of size 16 at 0x7d82b97e8b58 thread T0 #0 0x562cd432231e in __copy_non_overlapping_range<const unsigned long *, const unsigned long *> zorg-test/libcxx_install_asan_ubsan/include/c++/v1/string:2144:38 #1 0x562cd432231e in void std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>::__init_with_size[abi:nn220000]<unsigned long const*, unsigned long const*>(unsigned long const*, unsigned long const*, unsigned long) zorg-test/libcxx_install_asan_ubsan/include/c++/v1/string:2685:18 #2 0x562cd41e2797 in __init<const unsigned long *, 0> zorg-test/libcxx_install_asan_ubsan/include/c++/v1/string:2673:3 #3 0x562cd41e2797 in basic_string<const unsigned long *, 0> zorg-test/libcxx_install_asan_ubsan/include/c++/v1/string:1174:5 llvm#4 0x562cd41e2797 in clang::ASTReader::ReadString(llvm::SmallVectorImpl<unsigned long> const&, unsigned int&) clang/lib/Serialization/ASTReader.cpp:10171:15 llvm#5 0x562cd41fd89a in clang::ASTReader::ParseLanguageOptions(llvm::SmallVector<unsigned long, 64u> const&, llvm::StringRef, bool, clang::ASTReaderListener&, bool) clang/lib/Serialization/ASTReader.cpp:6475:28 llvm#6 0x562cd41eea53 in clang::ASTReader::ReadOptionsBlock(llvm::BitstreamCursor&, llvm::StringRef, unsigned int, bool, clang::ASTReaderListener&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&) clang/lib/Serialization/ASTReader.cpp:3069:11 llvm#7 0x562cd4204ab8 in clang::ASTReader::ReadControlBlock(clang::serialization::ModuleFile&, llvm::SmallVectorImpl<clang::ASTReader::ImportedModule>&, clang::serialization::ModuleFile const*, unsigned int) clang/lib/Serialization/ASTReader.cpp:3249:15 llvm#8 0x562cd42097d2 in clang::ASTReader::ReadASTCore(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, clang::serialization::ModuleFile*, llvm::SmallVectorImpl<clang::ASTReader::ImportedModule>&, long, long, clang::ASTFileSignature, unsigned int) clang/lib/Serialization/ASTReader.cpp:5182:15 llvm#9 0x562cd421ec77 in clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, clang::serialization::ModuleFile**) clang/lib/Serialization/ASTReader.cpp:4828:11 llvm#10 0x562cd3d07b74 in clang::CompilerInstance::findOrCompileModuleAndReadAST(llvm::StringRef, clang::SourceLocation, clang::SourceLocation, bool) clang/lib/Frontend/CompilerInstance.cpp:1805:27 llvm#11 0x562cd3d0b2ef in clang::CompilerInstance::loadModule(clang::SourceLocation, llvm::ArrayRef<clang::IdentifierLoc>, clang::Module::NameVisibilityKind, bool) clang/lib/Frontend/CompilerInstance.cpp:1956:31 llvm#12 0x562cdb04eb1c in clang::Preprocessor::HandleHeaderIncludeOrImport(clang::SourceLocation, clang::Token&, clang::Token&, clang::SourceLocation, clang::detail::SearchDirIteratorImpl<true>, clang::FileEntry const*) clang/lib/Lex/PPDirectives.cpp:2423:49 llvm#13 0x562cdb042222 in clang::Preprocessor::HandleIncludeDirective(clang::SourceLocation, clang::Token&, clang::detail::SearchDirIteratorImpl<true>, clang::FileEntry const*) clang/lib/Lex/PPDirectives.cpp:2101:17 llvm#14 0x562cdb043366 in clang::Preprocessor::HandleDirective(clang::Token&) clang/lib/Lex/PPDirectives.cpp:1338:14 llvm#15 0x562cdafa84bc in clang::Lexer::LexTokenInternal(clang::Token&, bool) clang/lib/Lex/Lexer.cpp:4512:7 llvm#16 0x562cdaf9f20b in clang::Lexer::Lex(clang::Token&) clang/lib/Lex/Lexer.cpp:3729:24 llvm#17 0x562cdb0d4ffa in clang::Preprocessor::Lex(clang::Token&) clang/lib/Lex/Preprocessor.cpp:896:11 llvm#18 0x562cd77da950 in clang::ParseAST(clang::Sema&, bool, bool) clang/lib/Parse/ParseAST.cpp:163:7 [...] 0x7d82b97e8b58 is located 0 bytes after 3288-byte region [0x7d82b97e7e80,0x7d82b97e8b58) allocated by thread T0 here: #0 0x562cca76f604 in malloc zorg-test/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:67:3 #1 0x562cd1cce452 in safe_malloc llvm/include/llvm/Support/MemAlloc.h:26:18 #2 0x562cd1cce452 in llvm::SmallVectorBase<unsigned int>::grow_pod(void*, unsigned long, unsigned long) llvm/lib/Support/SmallVector.cpp:151:15 #3 0x562cdbe1768b in grow_pod llvm/include/llvm/ADT/SmallVector.h:139:11 llvm#4 0x562cdbe1768b in grow llvm/include/llvm/ADT/SmallVector.h:525:41 llvm#5 0x562cdbe1768b in reserve llvm/include/llvm/ADT/SmallVector.h:665:13 llvm#6 0x562cdbe1768b in llvm::BitstreamCursor::readRecord(unsigned int, llvm::SmallVectorImpl<unsigned long>&, llvm::StringRef*) llvm/lib/Bitstream/Reader/BitstreamReader.cpp:230:10 llvm#7 0x562cd41ee8ab in clang::ASTReader::ReadOptionsBlock(llvm::BitstreamCursor&, llvm::StringRef, unsigned int, bool, clang::ASTReaderListener&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>&) clang/lib/Serialization/ASTReader.cpp:3060:49 llvm#8 0x562cd4204ab8 in clang::ASTReader::ReadControlBlock(clang::serialization::ModuleFile&, llvm::SmallVectorImpl<clang::ASTReader::ImportedModule>&, clang::serialization::ModuleFile const*, unsigned int) clang/lib/Serialization/ASTReader.cpp:3249:15 llvm#9 0x562cd42097d2 in clang::ASTReader::ReadASTCore(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, clang::serialization::ModuleFile*, llvm::SmallVectorImpl<clang::ASTReader::ImportedModule>&, long, long, clang::ASTFileSignature, unsigned int) clang/lib/Serialization/ASTReader.cpp:5182:15 llvm#10 0x562cd421ec77 in clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, clang::serialization::ModuleFile**) clang/lib/Serialization/ASTReader.cpp:4828:11 llvm#11 0x562cd3d07b74 in clang::CompilerInstance::findOrCompileModuleAndReadAST(llvm::StringRef, clang::SourceLocation, clang::SourceLocation, bool) clang/lib/Frontend/CompilerInstance.cpp:1805:27 llvm#12 0x562cd3d0b2ef in clang::CompilerInstance::loadModule(clang::SourceLocation, llvm::ArrayRef<clang::IdentifierLoc>, clang::Module::NameVisibilityKind, bool) clang/lib/Frontend/CompilerInstance.cpp:1956:31 llvm#13 0x562cdb04eb1c in clang::Preprocessor::HandleHeaderIncludeOrImport(clang::SourceLocation, clang::Token&, clang::Token&, clang::SourceLocation, clang::detail::SearchDirIteratorImpl<true>, clang::FileEntry const*) clang/lib/Lex/PPDirectives.cpp:2423:49 llvm#14 0x562cdb042222 in clang::Preprocessor::HandleIncludeDirective(clang::SourceLocation, clang::Token&, clang::detail::SearchDirIteratorImpl<true>, clang::FileEntry const*) clang/lib/Lex/PPDirectives.cpp:2101:17 llvm#15 0x562cdb043366 in clang::Preprocessor::HandleDirective(clang::Token&) clang/lib/Lex/PPDirectives.cpp:1338:14 llvm#16 0x562cdafa84bc in clang::Lexer::LexTokenInternal(clang::Token&, bool) clang/lib/Lex/Lexer.cpp:4512:7 llvm#17 0x562cdaf9f20b in clang::Lexer::Lex(clang::Token&) clang/lib/Lex/Lexer.cpp:3729:24 llvm#18 0x562cdb0d4ffa in clang::Preprocessor::Lex(clang::Token&) clang/lib/Lex/Preprocessor.cpp:896:11 llvm#19 0x562cd77da950 in clang::ParseAST(clang::Sema&, bool, bool) clang/lib/Parse/ParseAST.cpp:163:7 [...] SUMMARY: AddressSanitizer: heap-buffer-overflow clang/lib/Serialization/ASTReader.cpp:10171:15 in clang::ASTReader::ReadString(llvm::SmallVectorImpl<unsigned long> const&, unsigned int&) ``` The reason is this particular RUN line: ``` // RUN: env CC_PRINT_HEADERS_FORMAT=json CC_PRINT_HEADERS_FILTERING=direct-per-file CC_PRINT_HEADERS_FILE=%t.txt %clang -fsyntax-only -I %S/Inputs/print-header-json -isystem %S/Inputs/print-header-json/system -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -o /dev/null ``` which was added in 8df194f ("[Clang] Support includes translated to module imports in -header-include-filtering=direct-per-file (llvm#156756)"). The problem is caused by an incremental build reusing stale cached module files (.pcm) that are no longer binary-compatible with the updated compiler. Adding a new sanitizer option altered the implicit binary layout of the serialized LangOptions data structure. The build + test system is oblivious to such changes. When the new compiler attempted to read the old module file (from the previous test invocation), it misinterpreted the data due to the layout mismatch, resulting in a heap-buffer-overflow. Unfortunately Clang's PCM format does not encode nor detect version mismatches here; a more graceful failure mode would be preferable. For now, fix the test to be more robust with incremental build + test.

**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 <[email protected]>

…64224) When originally introduced to libunwind as part of llvm#112171, FEAT_PAuthLR had its Call Frame Instruction's (CFI's) in a different location to other Signing Authentication methods. To incorporate this in libunwind, a 4 byte offset was introduced to work with this. However, this design was reversed in llvm#121551 so the CFI's are emitted in the same location as other methods. When making this change, the offset in libunwind was not removed, so libunwind's PC value would be incorrect. As the 4 byte offset is no longer needed, that adjustment can be removed. results->ptrAuthDiversifier will still be set.

…-info (llvm#165373) The IR->DWARF pipeline was not properly tested before. This patch adds a test to generate DWARF for various `DIObjCProperty` constructions. This caught a couple of bugs: 1. The `DW_AT_APPLE_property_getter` and `DW_AT_APPLE_property_setter` properties were emitted the wrong way around. 2. The `DW_TAG_member` ivars were not linking back to the property that they back. These will be fixed in follow-up patches.

This patch adds small workaround for [issue](llvm#152504). It looks like code compiled with gcc has lack of some important debug information (e.g. DW_TAG_template_type_parameter for allocator). Example code: ```cpp #include <unordered_map> int main() { std::unordered_map<int, int> map = { {1, 2} }; return 0; } ``` Output from `llvm-dwarfdump` for code compiled by GCC or Clang. I used system GCC (13.3.0) and Clang (18.1.3) on Ubuntu 24.04 (WSL). GCC: ``` 0x00001fcd: DW_TAG_class_type DW_AT_name ("allocator<std::pair<int const, int> >") DW_AT_byte_size (0x01) DW_AT_decl_file ("/usr/include/c++/13/bits/allocator.h") DW_AT_decl_line (130) DW_AT_decl_column (11) DW_AT_sibling (0x0000207c) 0x00001fda: DW_TAG_inheritance DW_AT_type (0x00001d0a "std::__new_allocator<std::pair<int const, int> >") DW_AT_data_member_location (0) DW_AT_accessibility (DW_ACCESS_public) 0x00001fe0: DW_TAG_subprogram DW_AT_external (true) DW_AT_name ("allocator") DW_AT_decl_file ("/usr/include/c++/13/bits/allocator.h") DW_AT_decl_line (163) DW_AT_decl_column (7) DW_AT_linkage_name ("_ZNSaISt4pairIKiiEEC4Ev") DW_AT_accessibility (DW_ACCESS_public) DW_AT_declaration (true) DW_AT_object_pointer (0x00001ff4) DW_AT_sibling (0x00001ffa) 0x00001ff4: DW_TAG_formal_parameter DW_AT_type (0x00004eb9 "std::allocator<std::pair<int const, int> > *") DW_AT_artificial (true) 0x00001ff9: NULL 0x00001ffa: DW_TAG_subprogram DW_AT_external (true) DW_AT_name ("allocator") DW_AT_decl_file ("/usr/include/c++/13/bits/allocator.h") DW_AT_decl_line (167) DW_AT_decl_column (7) DW_AT_linkage_name ("_ZNSaISt4pairIKiiEEC4ERKS2_") DW_AT_accessibility (DW_ACCESS_public) DW_AT_declaration (true) DW_AT_object_pointer (0x0000200e) DW_AT_sibling (0x00002019) 0x0000200e: DW_TAG_formal_parameter DW_AT_type (0x00004eb9 "std::allocator<std::pair<int const, int> > *") DW_AT_artificial (true) 0x00002013: DW_TAG_formal_parameter DW_AT_type (0x00004ec3 "const std::allocator<std::pair<int const, int> > &") 0x00002018: NULL 0x00002019: DW_TAG_subprogram DW_AT_external (true) DW_AT_name ("operator=") DW_AT_decl_file ("/usr/include/c++/13/bits/allocator.h") DW_AT_decl_line (172) DW_AT_decl_column (18) DW_AT_linkage_name ("_ZNSaISt4pairIKiiEEaSERKS2_") DW_AT_type (0x00004ec8 "std::allocator<std::pair<int const, int> > &") DW_AT_accessibility (DW_ACCESS_public) DW_AT_declaration (true) DW_AT_defaulted (DW_DEFAULTED_in_class) DW_AT_object_pointer (0x00002031) DW_AT_sibling (0x0000203c) 0x00002031: DW_TAG_formal_parameter DW_AT_type (0x00004eb9 "std::allocator<std::pair<int const, int> > *") DW_AT_artificial (true) 0x00002036: DW_TAG_formal_parameter DW_AT_type (0x00004ec3 "const std::allocator<std::pair<int const, int> > &") 0x0000203b: NULL 0x0000203c: DW_TAG_subprogram DW_AT_external (true) DW_AT_name ("~allocator") DW_AT_decl_file ("/usr/include/c++/13/bits/allocator.h") DW_AT_decl_line (184) DW_AT_decl_column (7) DW_AT_linkage_name ("_ZNSaISt4pairIKiiEED4Ev") DW_AT_accessibility (DW_ACCESS_public) DW_AT_declaration (true) DW_AT_object_pointer (0x00002050) DW_AT_sibling (0x0000205b) 0x00002050: DW_TAG_formal_parameter DW_AT_type (0x00004eb9 "std::allocator<std::pair<int const, int> > *") DW_AT_artificial (true) 0x00002055: DW_TAG_formal_parameter DW_AT_type (0x00004cab "int") DW_AT_artificial (true) 0x0000205a: NULL ``` Clang: ``` 0x00001a6e: DW_TAG_class_type DW_AT_calling_convention (DW_CC_pass_by_reference) DW_AT_name ("allocator<std::pair<const int, int> >") DW_AT_byte_size (0x01) DW_AT_decl_file ("/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/allocator.h") DW_AT_decl_line (130) 0x00001a74: DW_TAG_template_type_parameter DW_AT_type (0x00000dec "std::pair<const int, int>") DW_AT_name ("_Tp") 0x00001a7a: DW_TAG_inheritance DW_AT_type (0x00001ad5 "std::__allocator_base<std::pair<const int, int> >") DW_AT_data_member_location (0x00) DW_AT_accessibility (DW_ACCESS_public) 0x00001a81: DW_TAG_subprogram DW_AT_name ("allocator") DW_AT_decl_file ("/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/allocator.h") DW_AT_decl_line (163) DW_AT_declaration (true) DW_AT_external (true) DW_AT_accessibility (DW_ACCESS_public) 0x00001a86: DW_TAG_formal_parameter DW_AT_type (0x00002dd1 "std::allocator<std::pair<const int, int> > *") DW_AT_artificial (true) 0x00001a8b: NULL 0x00001a8c: DW_TAG_subprogram DW_AT_name ("allocator") DW_AT_decl_file ("/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/allocator.h") DW_AT_decl_line (167) DW_AT_declaration (true) DW_AT_external (true) DW_AT_accessibility (DW_ACCESS_public) 0x00001a91: DW_TAG_formal_parameter DW_AT_type (0x00002dd1 "std::allocator<std::pair<const int, int> > *") DW_AT_artificial (true) 0x00001a96: DW_TAG_formal_parameter DW_AT_type (0x00002dd6 "const std::allocator<std::pair<const int, int> > &") 0x00001a9b: NULL 0x00001a9c: DW_TAG_subprogram DW_AT_linkage_name ("_ZNSaISt4pairIKiiEEaSERKS2_") DW_AT_name ("operator=") DW_AT_decl_file ("/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/allocator.h") DW_AT_decl_line (172) DW_AT_type (0x00002de0 "std::allocator<std::pair<const int, int> > &") DW_AT_declaration (true) DW_AT_external (true) DW_AT_accessibility (DW_ACCESS_public) 0x00001aa6: DW_TAG_formal_parameter DW_AT_type (0x00002dd1 "std::allocator<std::pair<const int, int> > *") DW_AT_artificial (true) 0x00001aab: DW_TAG_formal_parameter DW_AT_type (0x00002dd6 "const std::allocator<std::pair<const int, int> > &") 0x00001ab0: NULL 0x00001ab1: DW_TAG_subprogram DW_AT_name ("~allocator") DW_AT_decl_file ("/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/allocator.h") DW_AT_decl_line (184) DW_AT_declaration (true) DW_AT_external (true) DW_AT_accessibility (DW_ACCESS_public) 0x00001ab6: DW_TAG_formal_parameter DW_AT_type (0x00002dd1 "std::allocator<std::pair<const int, int> > *") DW_AT_artificial (true) 0x00001abb: NULL ``` I propose to add fallback implementation based on type of `_M_h`.

…s.py (llvm#165448) It appears that we forgot to update user-facing docs for God know how long.

…Property constructor (llvm#165401) Depends on: * llvm#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR.

Fix manifest `trustInfo` to use the `urn:schemas-microsoft-com:asm.v3` namespace. Fixes llvm#120394.

Occasionally this test fails in CI. There are two possible races that can occur, one of which is rare. Both are supposed to be handled, but because the test matches "read-only" and the runtime outputs "Read-only" (note the capital letter), the FileCheck fails. This patch fixes the miscapitalisation of the FileCheck string in the test. rdar://163398219

…ported (llvm#165410) This test is currently failing on some macOS CI nodes due to an issue with the system symbolizer. This patch marks this test unsupported while we wait for all CI nodes to be updated to a newer OS. rdar://160409885

…htest ABI (llvm#113152) Most ptrauth flags are ABI-affecting, so usually we do not want them to be exposed to end users. Allow them only in the following cases: - ARM64 Darwin (under certain conditions, some ptrauth driver flags are intended to be used in this case); - pauthtest ABI (it's intended to be used for experimenting with signing schema and the signing schema is explicitly encoded in the pauth elf marking). Leave `-faarch64-jump-table-hardening` available for all AArch64 targets since it's not ABI-affecting.

) This commit adds support for the OCP-MX INT8 type. This includes the following operations: MATMUL_T_BLOCK_SCALED, CAST_FROM_BLOCK_SCALED, CAST_TO_BLOCK_SCALED and CONST. The support is added via a custom TOSA type "!tosa.mxint8" due to the fact it is not yet a builtin type in mlir. This may change in the future, depending on how this type is used by other frameworks/dialects. Conversions to/from this type have not yet been implemented for the same reasoning. Co-authored-by: Tat Wai Chong <[email protected]>

…lvm#165256) Flang also uses non-gtest based unittests, which don't go through the usual add_unittest() helper. These currently do not use the usual linker flags for unit tests. This means that in LTO builds, they do not disable LTO when building unit tests, which increases the build time.

…#165538) I added some logs to see the difference between C++ mode and C mode and I see this In C++ mode ``` clang-repl> struct S1{} s1; s1 [convertExprToValue] original Expr: DeclRefExpr | type: struct S1 [convertExprToValue] Ty: struct S1 [convertExprToValue] DesugaredTy: struct S1 [convertExprToValue] Treating lvalue record as reference (enters block 540) [convertExprToValue] Ty: struct S1 & (after block 540) [convertExprToValue] DesugaredTy: struct S1 & (after block 540) [computeInterfaceKind] Expr class: DeclRefExpr | isLValue: 1 (S1 &) @0x10c9ac058 ``` in C mode ``` (base) anutosh491@Anutoshs-MacBook-Air bin % ./clang-repl --Xcc=-xc --Xcc=-std=c23 clang-repl> struct S1{} s1; s1 [convertExprToValue] original Expr: ImplicitCastExpr | type: struct S1 [convertExprToValue] Ty: struct S1 [convertExprToValue] DesugaredTy: struct S1 [convertExprToValue] Ty: struct S1 (after block 540) [convertExprToValue] DesugaredTy: struct S1 (after block 540) [computeInterfaceKind] Expr class: ImplicitCastExpr | isLValue: 0 Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it): s0 clang-repl 0x0000000103cca03c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 88 1 clang-repl 0x0000000103cca61c PrintStackTraceSignalHandler(void*) + 28 2 clang-repl 0x0000000103cc7ee8 llvm::sys::RunSignalHandlers() + 152 3 clang-repl 0x0000000103ccbb54 SignalHandler(int, __siginfo*, void*) + 284 4 libsystem_platform.dylib 0x00000001887f4624 _sigtramp + 56 5 clang-repl 0x00000001079bee18 clang::Sema::CheckArgsForPlaceholders(llvm::MutableArrayRef<clang::Expr*>) + 120 6 clang-repl 0x00000001079bee18 clang::Sema::CheckArgsForPlaceholders(llvm::MutableArrayRef<clang::Expr*>) + 120 7 clang-repl 0x0000000107b823dc clang::Sema::BuildCXXNew(clang::SourceRange, bool, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>, clang::SourceLocation, clang::SourceRange, clang::QualType, clang::TypeSourceInfo*, std::__1::optional<clang::Expr*>, clang::SourceRange, clang::Expr*) + 5672 8 clang-repl 0x000000010538c560 clang::Interpreter::convertExprToValue(clang::Expr*) + 2580 9 clang-repl 0x0000000105360774 clang::InProcessPrintingASTConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 252 10 clang-repl 0x000000010536a82c clang::IncrementalParser::ParseOrWrapTopLevelDecl() + 676 11 clang-repl 0x000000010536b554 clang::IncrementalParser::Parse(llvm::StringRef) + 712 12 clang-repl 0x000000010537e6b4 clang::Interpreter::Parse(llvm::StringRef) + 588 13 clang-repl 0x000000010537d73c clang::Interpreter::ParseAndExecute(llvm::StringRef, clang::Value*) + 72 14 clang-repl 0x000000010022db38 main + 3660 15 dyld 0x000000018841ab98 start + 6076 ``` So basically C mode wasn't entering block 540 as expressions like `s1` (where `s1` is a struct variable) are wrapped in an `ImplicitCastExpr`, which masks the underlying `DeclRefExpr` that is actually an `lvalue`.This patch unwraps the implicit cast with E->IgnoreImpCasts() before checking isLValue(), restoring correct detection of lvalue structs.

See llvm#165419 (comment) for details. The extra annotation `"; Has predicate info"` does not provide any extra information and might poison the UTC-generated checks introduced by llvm#165419.

Fails with: ``` ******************** TEST 'LLVM :: DebugInfo/Generic/objc-property.ll' FAILED ******************** Exit Code: 2 Command Output (stdout): -- RUN: at line 1 ome/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/build/bin/llc -filetype=obj -o - /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/test/DebugInfo/Generic/objc-property.ll | /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/build/bin/llvm-dwarfdump --debug-info - | /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/build/bin/FileCheck /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/test/DebugInfo/Generic/objc-property.ll executed command: /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/build/bin/llc -filetype=obj -o - /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/test/DebugInfo/Generic/objc-property.ll .---command stderr------------ | Assertion failed: Section && "Cannot switch to a null section!", file /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/lib/MC/MCStreamer.cpp, line 1364, virtual void llvm::MCStreamer::switchSection(MCSection *, uint32_t)() | 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: /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/build/bin/llc -filetype=obj -o - /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/test/DebugInfo/Generic/objc-property.ll `----------------------------- error: command failed with exit status: -6 executed command: /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/build/bin/llvm-dwarfdump --debug-info - .---command stderr------------ | error: -: The file was not recognized as a valid object file `----------------------------- error: command failed with exit status: 1 executed command: /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/build/bin/FileCheck /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/test/DebugInfo/Generic/objc-property.ll .---command stderr------------ | FileCheck error: '<stdin>' is empty. | FileCheck command line: /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/build/bin/FileCheck /home/llvm/llvm-external-buildbots/workers/aix-ppc64/clang-ppc64-aix/llvm-project/llvm/test/DebugInfo/Generic/objc-property.ll `----------------------------- error: command failed with exit status: 2 ``` Presumably due to unsupported debug-info section (see llvm#71814)

…tence (llvm#154123) [lldb][DWARFASTParserClang] Added a check for the specialization existence While debugging an application with incorrect dwarf information, where DW_TAG_template_value_parameter was lost, I found that lldb does not check that the corresponding specialization exists. As a result, at the stage when ASTImporter works, the type is completed in such a way that it inherits from itself. And during the calculation of layout, an infinite recursion occurs. To catch this error, I added a corresponding check at the stage of restoring the type from dwarf information. I also added a trivial assert in clang to check that the class does not inherit from itself.

This PR preserves the InBounds flag (llvm#162477) where possible in PTRADD-related DAGCombines. We can't preserve them in all the cases that we could in the analogous GISel change (llvm#152495) because SDAG usually represents pointers as integers, which means that pointer provenance is not preserved between PTRADD operations (see the discussion at PR llvm#162477 for more details). This PR marks the places in the DAGCombiner where this is relevant explicitly. For SWDEV-516125.

Prior to this change, the data layout calculation would not account for explicitly set `-mabi=elfv2` on `powerpc64-unknown-linux-gnu`, a target that defaults to `elfv1`. This is loosely inspired by the equivalent ARM / RISC-V code. `make check-llvm` passes fine for me, though AFAICT all the tests specify the data layout manually so there isn't really a test for this and I am not really sure what the best way to go about adding one would be. Signed-off-by: Jens Reidel <[email protected]>

If an instruction at the high end of the 32-bit address space branches to one at the low end, then the branch can be within range for a B or BL instruction, and doesn't need a veneer. `ARM::inBranchRange` was failing to detect this because it calculated the offset as an int64_t, so that the offset was a small value ± 2^32 instead of just the small value. Fixes llvm#165211.

In llvm#165604, a test was skipped on Windows, because the native PDB plugin didn't set sizes on symbols. While the test isn't compiled with debug info, it's linked with `-gdwarf`, causing a PDB to be created on Windows. This PDB will only contain the public symbols (written by the linker) and section information. The symbols themselves don't have a size, however the DIA SDK sets a size for them. It seems like, for these data symbols, the size given from DIA is the distance to the next symbol (or the section end). This PR implements the naive approach for the native plugin. The main difference is in function/code symbols. There, DIA searches for a corresponding `S_GPROC32` which have a "code size" that is sometimes slightly smaller than the difference to the next symbol.

…#165537) This patch makes `dwarfdump` show the `DW_AT_APPLE_property_name` of a referenced `DW_TAG_APPLE_property` (similar to how we show the name of a referenced `DW_AT_type`). Eventually we'll extend this to the DWARFv6 property tags too. Before: ``` 0x00000013: DW_TAG_APPLE_property DW_AT_APPLE_property_name ("propertyName") 0x0000001b: DW_TAG_member DW_AT_name ("_ivar") DW_AT_APPLE_property (0x00000013) ``` After: ``` 0x00000013: DW_TAG_APPLE_property DW_AT_APPLE_property_name ("propertyName") 0x0000001b: DW_TAG_member DW_AT_name ("_ivar") DW_AT_APPLE_property (0x00000013 "propertyName") ```

…vm#163727) LLVM now requires Python >= 3.8, and ConfigParser was renamed to configparser in 3.0: https://docs.python.org/3/whatsnew/3.0.html#library-changes A few places imported it under the Python2 name even for Python3, I have swapped those to the Python3 name. This was reported by https://pypi.org/project/vermin/ as the file having incompatible versions. Since once import is 2.x and one is 3.x.

…#165837) We were setting these bits inverted. Not sure how this bug actually manifests, I just noticed when working on llvm#165707. I suspect these types just aren't very frequently used.

…lvm#163730) LLVM requires Python >=3.8 and in Python 3.0 urllib2 was renamed to urllib. https://docs.python.org/3/whatsnew/3.0.html#library-changes

The majority of this is running 2to3 on it: * print is a function in 3.x * next(it) instead of it.next() Then there was a use of "map(None, iterables..)" which in Python 2 was a way of saying "combine these iterables, and if one is shorter, pad with None". This no longer works in Python3, the equivalent is zip_longest: https://docs.python.org/3/library/itertools.html#itertools.zip_longest fillvalue defaults to None but I made it explicit since it may help someone debugging this script in future. (I doubt it has been used for a very long time)

…ord.py (llvm#163744) LLVM requires Python >= 3.8. itervalues was unused so I have removed it.

Fixes 35e1a2f itervalues is in fact used in opt-viewer.py.

…PointType (llvm#165707) Similar motivation to llvm#165702. It was unused in all callsites and inconsistent with other APIs like `IsIntegerType` (which doesn't take a `count` parameter). If we ever need a "how many elements does this type represent", we can implement one with a new TypeSystem API that does exactly that. Some callsites checked for `count == 1` previously, but I suspect what they intended to do is check for whether it's a vector type or complex type, before reading the FP register. I'm somewhat confident that's the case because the `TypeSystemClang::GetTypeInfo` currently incorrectly sets the integer and floating point bits for complex and vector types (will fix separately). But some architectures might choose to pass single-element vectors in scalar registers. I should probably changes these to check the vector element size. All the `count == 2 && is_complex` were redundant because `count == 2` iff `is_complex == true`. So I just removed the count check there.

…ew.py (llvm#163747) All these modules got new names or were moved around in Python 3.0: https://docs.python.org/3/whatsnew/3.0.html#library-changes LLVM requires Python >= 3.8 so we don't need to try Python2 naming.

…AG_APPLE_property (llvm#165409) Depends on: * llvm#165373 When an Objective-C property has a backing ivar, we would previously not add a `DW_AT_APPLE_property` to the ivar's `DW_TAG_member`. This is what was intended based on the [Objective-C DebugInfo docs](https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#proposal) but is not what LLVM currently generates. LLDB currently doesn't ever try linking the `ObjCPropertyDecl`s to their `ObjCIvarDecl`s, but if we wanted to, this debug-info patch is a pre-requisite.

…lvm#165425) When a load or store accesses N bytes starting from a pointer P, and we want to compute an offset pointer within these N bytes after P, we know that the arithmetic to add the offset must be inbounds. This is for example relevant when legalizing too-wide memory accesses, when lowering memcpy&Co., or when optimizing "vector-load -> extractelement" into an offset load. For SWDEV-516125.

…alable vectors. (llvm#165437)

…163407) This patch adds register bank legalization support for G_FADD opcodes in the AMDGPU GlobalISel pipeline. Added new reg bank type UniInVgprS64. This patch also adds a combine logic for ReadAnyLane + Trunc + AnyExt. --------- Co-authored-by: Abhinav Garg <[email protected]>

…5684)

…64395) "How To Release LLVM To The Public" [1] mentions to add the release:reviewed label once a bug has been reviewed, but looking at the label [2] it seems this hasn't been followed for quite a long time, so I propose we remove it. [1] https://llvm.org/docs/HowToReleaseLLVM.html#triaging-bug-reports-for-releases [2] https://github.com/llvm/llvm-project/issues?q=label%3Arelease%3Areviewed

…sure there isn't an interdependency between the load and amt (llvm#165850) Fixes llvm#165755

This test seems to have taken the lit documentation at its word: https://llvm.org/docs/CommandGuide/lit.html#substitutions "%t temporary file name unique to the test" %t is in fact the **path** of a file. As suggested by the line below that describing %basename_t. This test (I assume) assumed it was just the filename itself and so left a layout of: ``` $ tree tools/lld/test/ tools/lld/test/ ├── CMakeFiles ├── ELF │ └── Output │ ├── aarch64-build-attributes.s.tmp │ │ ├── pauth-bti-gcs.s │ │ └── pauth-bti-pac.s │ ├── aarch64-build-attributes.s.tmp.merged.o │ ├── aarch64-build-attributes.s.tmp1.o │ ├── aarch64-build-attributes.s.tmp2.o │ └── aarch64-build-attributes.s.tmp3.o ├── Unit │ └── lit.site.cfg.py ├── cmake_install.cmake └── lit.site.cfg.py ``` Note how the 2 .s files are in the temp dir but the .o files are not. This is fine, it works, but it's going to cost someone time to unpick when this test actually does fail. To fix this, remove %t from all the temp file names so they are created in the temp dir, which is cleaned before each run. New layout: ``` $ tree tools/lld/test/ tools/lld/test/ ├── CMakeFiles ├── ELF │ └── Output │ └── aarch64-build-attributes.s.tmp │ ├── 1.o │ ├── 2.o │ ├── 3.o │ ├── merged.o │ ├── pauth-bti-gcs.s │ └── pauth-bti-pac.s ├── Unit │ └── lit.site.cfg.py ├── cmake_install.cmake └── lit.site.cfg.py ```

Add support for multiple return statements in switch statements. Cases in switch statements don't have their own scopes but are distinct regions nonetheless. Insert multiple return blocks for each case and handle them in the cleanup code.

Per Intel Architecture Instruction Set Extensions Programming Reference rev. 59 (https://cdrdv2.intel.com/v1/dl/getContent/671368), Revision History entry for revision -59, AMX-TRANSPOSE was removed

…165558) This patch updates the mbarrier.init/inval Ops to use the AnyTypeOf[] construct for their `addr` argument. This enables us to have a single Op that can take a pointer in either generic or shared memory space and generate the right intrinsics during the lowering. * Updated existing tests accordingly. * Verified locally that there are no new regressions in `integration` tests. * TODO: Additional updates for the remaining mbarrier Ops are in progress. These will be refactored in subsequent patches. Signed-off-by: Durgadoss R <[email protected]>

.github/workflows/llvm-abi-tests.yml

+            repo: ${{ github.repository }}
+    steps:
+      - name: Install Ninja
+        uses: llvm/actions/install-ninja@main


.github/workflows/llvm-abi-tests.yml

+      - name: Download source code
+        uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
+        with:
+          ref: ${{ matrix.ref }}
+          repository: ${{ matrix.repo }}
+      - name: Configure


.github/workflows/release-binaries.yml

+    - name: Checkout LLVM
+      uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
      with:
-        ref: ${{ (github.event_name == 'pull_request' && github.sha) || 'main' }}
-        sparse-checkout: |
-          .github/workflows/
-        sparse-checkout-cone-mode: false
-        # Check out outside of working directory so the source checkout doesn't
-        # remove it.
-        path: workflows
+        ref: ${{ needs.prepare.outputs.ref }}

-    # actions/checkout does not support paths outside of the GITHUB_WORKSPACE.
-    # Also, anything that we put inside of GITHUB_WORKSPACE will be overwritten
-    # by future actions/checkout steps.  Therefore, in order to checkout the
-    # latest actions from main, we need to first checkout out the actions inside of
-    # GITHUB_WORKSPACE (see previous step), then use actions/checkout to checkout
-    # the code being built and the move the actions from main back into GITHUB_WORKSPACE,
-    # becasue the uses on composite actions only reads workflows from inside GITHUB_WORKSPACE.
-    - shell: bash
-      run: mv workflows  ../workflows-main
+    - name: Install Ninja


The best way to fix this problem is to ensure that code checked out in a privileged context (with access to secrets or write permissions) can only come from trusted sources—never directly from untrusted PRs, user-supplied refs, or forks. In practice:

For triggers that could be driven by untrusted users (such as workflow_call from a fork), do not allow arbitrary refs to be checked out. Restrict the ref so only trusted branches or tags are possible (e.g., only main, release branches, or tags).

If PRs must be processed, split the workflow: unprivileged workflow for building and artifact generation (using pull_request trigger), then a privileged workflow to post-process trusted artifacts (using the workflow_run trigger).

In this workflow, validate the value of ${{ needs.prepare.outputs.ref }} so it cannot reference an arbitrary, user-controlled SHA (block anything except trusted branches/tags).

To address this with minimal changes:

Add a step that validates the incoming ref against a whitelist of trusted refs before the checkout.

Block the workflow with exit 1 if the ref is untrusted.

E.g., allow only refs matching refs/heads/main, release branches (refs/heads/release/*), or tags like refs/tags/*.

Edit the build-release-package job:

Insert a shell validation step before the checkout.

Abort if the ref does not match a trusted pattern.

You may also annotate the workflow YAML with a comment explaining the implemented mitigation.

.github/workflows/release-binaries.yml

-      uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+    - name: Setup Windows
+      if: startsWith(runner.os, 'Windows')
+      uses: llvm/actions/setup-windows@main


Stylie777 and others added 16 commits October 29, 2025 08:20

[ASTMatchers][Docs] Regenerate MatchersReference via dump_ast_matcher…

7f1aef8

…s.py (llvm#165448) It appears that we forgot to update user-facing docs for God know how long.

[llvm][DebugInfo][ObjC] Fix argument order of setter/getter to DIObjC…

dda95d9

…Property constructor (llvm#165401) Depends on: * llvm#165373 This caused the `DW_AT_APPLE_property_(setter|getter)` to be inverted when compiling from LLVM IR.

[LLD][COFF] Fix manifest UAC trustInfo namespace (llvm#165285)

6ab8e8f

Fix manifest `trustInfo` to use the `urn:schemas-microsoft-com:asm.v3` namespace. Fixes llvm#120394.

[PredicateInfo] Drop redundant PredicateInfo annotation (llvm#165434)

356a811

See llvm#165419 (comment) for details. The extra annotation `"; Has predicate info"` does not provide any extra information and might poison the UTC-generated checks introduced by llvm#165419.

[MLIR] Remove unused include. NFC.

92b4e75

ritter-x2a and others added 27 commits October 31, 2025 10:25

[lldb][TypeSystem] Fix GetTypeInfo for vector and complex types (llvm…

e3299ab

…#165837) We were setting these bits inverted. Not sure how this bug actually manifests, I just noticed when working on llvm#165707. I suspect these types just aren't very frequently used.

[clang][docs] Remove Python2 import handler in dump_ast_matchers.py (l…

34decf3

…lvm#163730) LLVM requires Python >=3.8 and in Python 3.0 urllib2 was renamed to urllib. https://docs.python.org/3/whatsnew/3.0.html#library-changes

[llvm][tools][opt-viewer] Remove Python2 compatability code in optrec…

35e1a2f

…ord.py (llvm#163744) LLVM requires Python >= 3.8. itervalues was unused so I have removed it.

[llvm][tools][opt-viewer] Put back missing function

ef2a05d

Fixes 35e1a2f itervalues is in fact used in opt-viewer.py.

[NFCI] Address post-merge review of llvm#162503 (llvm#165582)

31a0ebb

[LLVM][ConstantFolding] Extend constantFoldVectorReduce to include sc…

96c6fd3

…alable vectors. (llvm#165437)

[libc++] Update our documentation on the supported compilers (llvm#16…

d1146b1

…5684)

[X86] combineTruncate - trunc(srl(load(p),amt)) -> load(p+amt/8) - en…

1d5580f

…sure there isn't an interdependency between the load and amt (llvm#165850) Fixes llvm#165755

[X86] Remove AMX-TRANSPOSE (llvm#165556)

5322fb6

Per Intel Architecture Instruction Set Extensions Programming Reference rev. 59 (https://cdrdv2.intel.com/v1/dl/getContent/671368), Revision History entry for revision -59, AMX-TRANSPOSE was removed

[libc++] Simplify the implementation of destroy_at a bit (llvm#165392)

9f9b8d5

[Github] Install make on Windows container

0d4c3f4

Nerixyz force-pushed the chore/push-container-local branch from 7bda0d4 to 0d4c3f4 Compare October 31, 2025 12:07

github-advanced-security bot found potential problems Oct 31, 2025

View reviewed changes

Nerixyz closed this Oct 31, 2025

@@ -167,6 +167,19 @@
                 runs-on: ${{ needs.prepare.outputs.build-runs-on }}
                 steps:
+                - name: Validate ref is trusted
+                  id: validate_ref
+                  shell: bash
+                  run: |
+                    # Only allow trusted refs: main branch, release branches, or tags.
+                    REF="${{ needs.prepare.outputs.ref }}"
+                    if [[ "$REF" =~ ^refs/heads/main$ ]] || [[ "$REF" =~ ^refs/heads/release/.*$ ]] || [[ "$REF" =~ ^refs/tags/.*$ ]]; then
+                      echo "Ref $REF is trusted – proceeding."
+                    else
+                      echo "ERROR: Untrusted ref $REF. Aborting!"
+                      exit 1
+                    fi
                 - name: Checkout LLVM
                   uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
                   with:

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Build and push container to my local registry #2

Build and push container to my local registry #2

Uh oh!

Nerixyz commented Jun 30, 2025

Uh oh!

Check warning

Check warning

Copilot Autofix

Check warning

Copilot Autofix

Check warning

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

131 participants

Build and push container to my local registry #2

Build and push container to my local registry #2

Uh oh!

Conversation

Nerixyz commented Jun 30, 2025

Uh oh!

Check warning

Uh oh!

Check warning

Copilot Autofix

Check warning

Copilot Autofix

Check warning

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

131 participants