[pull] main from llvm:main #5651
Open
+159,524
−61,215
Conversation
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
This is canonical in the rest of the repository and otherwise we can end up with warnings when compiling with clang-cl on Windows that look like the following: ``` 2025-11-06T17:55:25.2412502Z C:\_work\llvm-project\llvm-project\llvm\include\llvm/Support/thread.h(37,5): warning: 'LLVM_ON_UNIX' is not defined, evaluates to 0 [-Wundef] 2025-11-06T17:55:25.2413436Z 37 | #if LLVM_ON_UNIX || _WIN32 2025-11-06T17:55:25.2413791Z | ^ 2025-11-06T17:55:25.2414625Z C:\_work\llvm-project\llvm-project\llvm\include\llvm/Support/thread.h(52,5): warning: 'LLVM_ON_UNIX' is not defined, evaluates to 0 [-Wundef] 2025-11-06T17:55:25.2415585Z 52 | #if LLVM_ON_UNIX 2025-11-06T17:55:25.2415901Z | ^ 2025-11-06T17:55:25.2416169Z 2 warnings generated. ``` Reviewers: joker-eph, pcc, cachemeifyoucan Reviewed By: cachemeifyoucan Pull Request: #166827
We recently moved over to compiling with clang-cl on Windows. This ended up causing a large increase in warnings, particularly due to how warnings are handled in nanobind. cd91d0f initially set -Wall -Wextra and -Wpedantic while fixing another issue, which is probably not what we want to do on third-party code. We also need to disable -Wmissing-field-initializers to get things clean in this configuration. Reviewers: makslevental, jpienaar, rkayaith Reviewed By: makslevental Pull Request: #166828
We removed the limit a while back after moving to new infrastructure but never removed the comment. Do that now to prevent confusion.
…166005) This fixes two problems: - dyld itself resides within the shared cache. MemoryMappingLayout incorrectly computes the slide for dyld's segments, causing them to (appear to) overlap with other modules. This can cause symbolication issues. - The MemoryMappingLayout ranges on Darwin are not disjoint due to the fact that the LINKEDIT segments overlap for each module. We now ignore these segments to ensure the mapping is disjoint. This adds a check for disjointness, and a runtime warning if this is ever violated (as that suggests issues in the sanitizer memory mapping). There is now a test to ensure that these problems do not recur. rdar://163149325
…_v (#160607) Implemented [[*time.traits.is.clock*]](https://eel.is/c++draft/time.traits.is.clock) from [P0355R7](https://wg21.link/p0355r7). This patch implements the C++20 feature `is_clock` and `is_clock_v` based on the documentation [on cppreference](https://en.cppreference.com/w/cpp/chrono/is_clock.html) Fixes #166049.
This PR adds the necessary infrastructure to enable testing of the ACCImplicitData pass for FIR/HLFIR, along with comprehensive test coverage for implicit data clause generation in OpenACC constructs. New Infrastructure: - Add FIROpenACCSupport analysis providing FIR-specific implementations of OpenACCSupport interface methods for variable name extraction, recipe name generation, and NYI emission - Add FIROpenACCUtils with helper functions for: * Variable name extraction from FIR operations (getVariableName) * Recipe name generation with FIR type string representation * Bounds checking for constant array sections - Add ACCInitializeFIRAnalyses pass to pre-register FIR analyses (OpenACCSupport and AliasAnalysis) for use by subsequent OpenACC passes in the pipeline Refactoring in flang/lib/Lower/OpenACC.cpp: - Move bounds string generation and bounds checking to FIROpenACCUtils - Refactor recipe name generation to use fir::acc::getRecipeName Test Coverage: - acc-implicit-firstprivate.fir: Tests implicit firstprivate behavior for scalar types (i8, i16, i32, i64, f32, f64, logical, complex) in parallel/serial constructs with recipe generation verification - acc-implicit-data.fir: Tests implicit data clauses for scalars, arrays, derived types, and boxes in kernels/parallel/serial with default(none) and default(present) variations - acc-implicit-data-fortran.F90: Fortran tests verifying implicit data generation through bbc with both HLFIR and FIR - acc-implicit-data-derived-type-member.F90: Tests correct ordering of parent/child data clause operations for derived type members - acc-implicit-copy-reduction.fir: Tests enable-implicit-reduction-copy flag controlling whether reduction variables use copy or firstprivate This enables proper testing of implicit data clause generation through the flang optimizer pipeline for OpenACC directives.
Main executables were bypassing the locate module callback that shared libraries use, preventing custom symbol file location logic from working consistently. This PR fix this by * Adding target context to ModuleSpec * Leveraging that context to use target search path and platform's locate module callback in ModuleList::GetSharedModule This ensures both main executables and shared libraries get the same callback treatment for symbol file resolution. --------- Co-authored-by: George Hu <hyubo@meta.com> Co-authored-by: George Hu <georgehuyubo@gmail.com>
A global offset table is a section that holds the address of functions that are dynamically linked. The Swift plugin needs to know if sections are a global offset table or not.
Looks like #166517 is breaking libc-riscv32-qemu-yocto-fullbuild-dbg build due to failing overflow test for strfrom. https://lab.llvm.org/buildbot/#/changes/58668 ``` int result = func(buff, sizeof(buff), "%.2147483647f", 1.0f); EXPECT_LT(result, 0); ASSERT_ERRNO_FAILURE(); ``` ``` [ RUN ] LlvmLibcStrfromdTest.CharsWrittenOverflow /home/libcrv32buildbot/bbroot/libc-riscv32-qemu-yocto-fullbuild-dbg/llvm-project/libc/test/src/stdlib/StrfromTest.h:493: FAILURE Expected: result Which is: 0 To be less than: 0 Which is: 0 /home/libcrv32buildbot/bbroot/libc-riscv32-qemu-yocto-fullbuild-dbg/llvm-project/libc/test/src/stdlib/StrfromTest.h:494: FAILURE Expected: 0 Which is: 0 To be not equal to: static_cast<int>(libc_errno) Which is: 0 [ FAILED ] LlvmLibcStrfromdTest.CharsWrittenOverflow Ran 8 tests. PASS: 7 FAIL: 1 ``` At first glance it seem like there is some kind of overflow in internal::strfromfloat_convert on 32bit archs because the other overflow test case is passing for snprintf. Interestingly, it passes on all other buildbots, including libc-arm32-qemu-debian-dbg. This issue likely wasn't introduced by #166517 and was probably already present, so I'm not reverting the change just disabling the test case on riscv32 until I can debug properly.
…de braced initializers (#166180) Fixes #163498 --- This PR addresses the issue of confusing diagnostics for lambdas with init-captures appearing inside braced initializers. Cases such as: ```cpp S s{[a(42), &] {}}; ``` were misparsed as C99 array designators, producing unrelated diagnostics, such as `use of undeclared identifier 'a'`, and `expected ']'` --- https://github.com/llvm/llvm-project/blob/bb9bd5f263226840194b28457ddf9861986db51f/clang/lib/Parse/ParseInit.cpp#L470 https://github.com/llvm/llvm-project/blob/bb9bd5f263226840194b28457ddf9861986db51f/clang/lib/Parse/ParseInit.cpp#L74 https://github.com/llvm/llvm-project/blob/bb9bd5f263226840194b28457ddf9861986db51f/clang/include/clang/Parse/Parser.h#L4652-L4655 https://github.com/llvm/llvm-project/blob/24c22b7de620669aed9da28de323309c44a58244/clang/lib/Parse/ParseExprCXX.cpp#L871-L879 The tentative parser now returns `Incomplete` for partially valid lambda introducers, preserving the `lambda` interpretation and allowing the proper diagnostic to be issued later. --- Clang now correctly recognizes such constructs as malformed lambda introducers and emits the expected diagnostic — for example, “capture-default must be first” — consistent with direct initialization cases such as: ```cpp S s([a(42), &] {}); ```
The low hanging fruit that was causing the vast majority of these warnings has been fixed, so reenable them now. There are still a couple more warnings that could probably do with some cleanup, but those can be fixed in the future.
This allows SDNodes to be validated against their expected type profiles and reduces the number of changes required to add a new node. Fix BR_CC/MEMCPY descriptions to match C++ code that creates the nodes (an error detected by the enabled verification functionality). Also remove redundant `SDNPOutGlue` on `BPFISD::MEMCPY`. Part of #119709.
…162822) Check that all partial reductions in a chain are only used by other partial reductions with the same scale factor. Otherwise we end up creating users of scaled reductions where the types of the other operands don't match. A similar issue was addressed in #158603, but misses the chained cases. Fixes #162530. PR: #162822
…tions (#166776) Seeing warnings: llvm/include/llvm/CodeGen/LibcallLoweringInfo.h:15:46: error: 'visibility' attribute ignored [-Werror=attributes] 15 | LLVM_ABI const RTLIB::RuntimeLibcallsInfo &RTLCI; llvm/include/llvm/CodeGen/LibcallLoweringInfo.h:18:25: error: 'visibility' attribute ignored [-Werror=attributes] 18 | RTLIB::Unsupported};
Fix shared library linking failure for FIROpenACCTransforms
…#166674) Remove the unnecessary sleep in MachProcess::AttachForDebug. The preceding comment makes it seem like it's necessary for synchronization, though I don't believe that's the case (see below), and even if it were, sleeping is not a reliable way to achieve that. The reason I don't believe it's necessary is because after we return, we synchronize with the exception thread on a state change. The latter will call and update the process state, which is exactly what we synchronize on. I was able to verify that this is the first time we change the process state: i.e., `GetState` doesn't return a different value before and after the sleep. On top of that, there are 3 more places where we call ptrace attach (`PosixSpawnChildForPTraceDebugging`, `SBLaunchForDebug`, and `BoardServiceLaunchForDebug`) where we don't sleep. rdar://163952037
…153603) This enables printing, for example, the attribute value from a mismatched predicate. Example of resultant output (here made non-negative report value seen as sign-extended int): ``` PDL/ops.mlir:21:1: error: 'pdl.pattern' op attribute 'benefit' failed to satisfy constraint: 16-bit signless integer attribute whose value is non-negative (got -31) pdl.pattern @rewrite_with_args : benefit(-31) { ^ ``` This is primarily the mechanism and didn't change any existing constraints. I also attempted to keep the error format as close to the original as possible - but did notice 2 errors that were inconsistent with the rest and updated them to be consistent.
…166864) This allows for their reuse inside llvm-zorg. Otherwise we get an error that we cannot use reusable workflows inside job steps because Github thinks that they are reuseable workflows rather than composite actions. This should be NFC inside the monorepo.
This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [actions/attest-build-provenance](https://redirect.github.com/actions/attest-build-provenance) | action | major | `v1.4.4` -> `v3.0.0` | | [actions/checkout](https://redirect.github.com/actions/checkout) | action | major | `v4.3.0` -> `v5.0.0` | | [actions/github-script](https://redirect.github.com/actions/github-script) | action | major | `v7.1.0` -> `v8.0.0` | | [actions/github-script](https://redirect.github.com/actions/github-script) | action | major | `v6.4.1` -> `v8.0.0` | | [actions/labeler](https://redirect.github.com/actions/labeler) | action | major | `v4.3.0` -> `v6.0.1` | | [actions/setup-node](https://redirect.github.com/actions/setup-node) | action | major | `v4.4.0` -> `v6.0.0` | | [actions/setup-python](https://redirect.github.com/actions/setup-python) | action | major | `v5.6.0` -> `v6.0.0` | | [github/codeql-action](https://redirect.github.com/github/codeql-action) | action | major | `v2.28.1` -> `v4.31.2` | | [github/codeql-action](https://redirect.github.com/github/codeql-action) | action | major | `v3.31.2` -> `v4.31.2` | | [node](https://redirect.github.com/actions/node-versions) | uses-with | major | `18` -> `24` | | [tj-actions/changed-files](https://redirect.github.com/tj-actions/changed-files) | action | major | `v46.0.5` -> `v47.0.0` |
) Recently I've been deep diving ELF cores in LLDB, aspiring to move LLDB closer to GDB in capability. One issue I encountered was a system lib losing it's unwind plan when loading the debuginfo. The reason for this was the debuginfo has the eh_frame section stripped and the main executable did not. The root cause of this was this line in [ObjectFileElf](https://github.com/llvm/llvm-project/blob/163933e9e7099f352ff8df1973f9a9c3d7def6c5/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp#L1972) ``` // For eTypeDebugInfo files, the Symbol Vendor will take care of updating the // unified section list. if (GetType() != eTypeDebugInfo) unified_section_list = *m_sections_up; ``` This would always be executed because CalculateType can never return an eTypeDebugInfo ``` ObjectFile::Type ObjectFileELF::CalculateType() { switch (m_header.e_type) { case llvm::ELF::ET_NONE: // 0 - No file type return eTypeUnknown; case llvm::ELF::ET_REL: // 1 - Relocatable file return eTypeObjectFile; case llvm::ELF::ET_EXEC: // 2 - Executable file return eTypeExecutable; case llvm::ELF::ET_DYN: // 3 - Shared object file return eTypeSharedLibrary; case ET_CORE: // 4 - Core file return eTypeCoreFile; default: break; } return eTypeUnknown; } ``` This makes sense as there isn't a explicit sh_type to denote that this file is a debuginfo. After some discussion with @clayborg and @GeorgeHuyubo we settled on joining the exciting unified section list with whatever new sections were being added. Adding each new unique section, or taking the section with the maximum file size. We picked this strategy to pick the section with the most information. In most scenarios, LHS should be SHT_NOBITS and RHS would be SHT_PROGBITS. Here is a diagram documenting the existing vs proposed new way. <img width="1666" height="1093" alt="image" src="https://github.com/user-attachments/assets/73ba9620-c737-439e-9934-ac350d88a3b5" />
…#166494) `inttoptr` usage in global initialisers is valid, and rather common when it comes to the machinery around vtables (construction vtables are particularly fond). This was not handled by the BE, even though SPIR-V allows forming `SpecConstantOp`s with the `OpConvertUToPtr` opcode, which is what these would map to. We augment instruction selection to address this.
It is possible to run into situations where no mcpu is specified for an offload device side compilation. Currently, this'd lead to a rather uninformative blank being presented as the target for a failing compilation, when messaging the error count. This patch changes things so that if there is no `-mcpu` we print the triple, which is slightly more helpful, especially when there are multiple offload targets for a single compilation.
This was causing workflow failures when PRs were opened. Revert the upgrade for now so that this can be investigated and fixed before relanding.
This PR removes duplicated `SingleBlockImplicitTerminator<"YieldOp">` since `LinalgStructuredBase_Op` already defines it. and clean up formatting for other OpDefs.
Identified with readability-simplify-subscript-expr.
Addresses #93154 by ensuring the test RUN/FILECHECK prefixes across `mlir/test/Conversion/FuncToLLVM/` and related files match their expected outputs, and adds an `index-bitwidth=32` variant of `expand-then-convert-to-llvm.mlir` that exercises `@collapse_shape_dynamic_with_non_identity_layout` through the same MemRef-to-LLVM pipeline so the 32-bit layout descriptors are verified.
P0513R0 is essentially a collective resolution paper of LWG2543, LWG2791, LWG2809, and LWG2817. Among these LWG issues, LWG2543 (conditionally enabled `hash`) and LWG2817 (`hash<nullptr_t>`) affect pre-C++17 utilities. We generally backport changes from LWG issues, so this patch backports the relevant parts of P0513R0. Although we provide `hash<unique_ptr>` as an extension in C++03 mode, as C++03 mode isn't encouraged now, this patch leaves `hash<unique_ptr>` unchanged in C++03 mode.
Identified with readability-duplicate-include.
maskedBitSetCase takes StringRef, so we can "implicitly cast" std::string to StringRef. Identified with readability-redundant-string-cstr.
…card]]` (#166898) ...according to Coding Guidelines: *`[[nodiscard]]` should be applied to functions where discarding the return value is most likely a correctness issue.* # References - https://libcxx.llvm.org/CodingGuidelines.html#apply-nodiscard-where-relevant - #166524 (comment) Co-authored-by: Hristo Hristov <zingam@outlook.com>
This reverts commit 206a1d2. The issues that came up with the last landing have been fixed, so trying this again to see if it sticks this time.
EnableVPlanNativePath is declared in LoopVectorizationPlanner.h. Identified with readability-redundant-declaration.
Identified with readability-container-contains.
Identified with bugprone-unused-local-non-trivial-variable.
This reverts commit 4b6a597. This broke premerge and maybe one PPC bot: 1. https://lab.llvm.org/staging/#/builders/192/builds/10157 2. https://lab.llvm.org/buildbot/#/builders/95/builds/19044
This patch adds a Clang-compatible `--save-stats` option, to provide an easy to use way to save LLVM statistics files when working with llc on the backend. Like on Clang, one can specify `--save-stats`, `--save-stats=cwd`, and `--save-stats=obj` with the same semantics and JSON format. The implementation uses 2 methods `MaybeEnableStats` and `MaybeSaveStats` called before and after `compileModule` respectively that externally own the statistics related logic, while `compileModule` is now required to return the resolved output filename via an output param. Note: like on Clang, the pre-existing `--stats` option is not affected.
A quick fix for the CI failure introduced by #163967
Fix issue in readability-container-data-pointer when the container expression is a dereference (e.g., `&(*p)[0]`). The previous fix-it suggested `*p.data()`, which changes semantics because `.` binds tighter than `*`. The fix now correctly suggests `(*p).data()`. Closes [#164852](#164852) --------- Co-authored-by: Baranov Victor <bar.victor.2002@gmail.com>
…tomics` extension (#166257) This enables support for atomic RMW ops (add, sub, min and max to be precise) with `bfloat16` operands, via the [SPV_INTEL_16bit_atomics extension](intel/llvm#20009). It's logically a successor to #166031 (I should've used a stack), but I'm putting it up for early review. --------- Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
Identified with llvm-use-ranges.
Identified with readability-misleading-indentation.
Identified with readability-redundant-typename.
This patch consolidates two implementations of meet using "if constexpr", migrating away from the SFINAE-based approach.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
121 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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )