merge main into amd-staging#3322
Merged
rocm-cciapp[bot] merged 32 commits intoJul 11, 2026
Merged
Conversation
Whilst there is no data in theory to map with a zero sized array, the Fortran OpenMP specification considers the case of a zero sized array being mapped to device as the data being present on device. This includes both the data and the descriptor, and it should fundamentlaly work as a zero-sized array would on device with the respective Fortran functions for presence and size checking etc. We can't actually map a nullptr to device and expect it to be present in current OpenMP (for good reason), however, thankfully, a zero sized array isn't actually a nullptr, it is a descriptor contianing an allocated 1-byte of data. So, we can map this to device, alongside the descriptor and then the zero sized array is correctlly on device for all intents and purposes. This case is notably different from a non-allocated or non-zero sized array so we can do this without shooting ourselves in the foot.
) Previously, we were using a separate `bool` member in `Scope` for this because we ran out of bits in `ScopeFlags`. llvm#198436 recently freed up a bit for this, so switch to using it instead. Fixes llvm#207774.
…estructors instead of directly referencing `::operator delete` (llvm#188372) When Clang emits scalar/vector deleting destructors for classes with a class-level `operator delete`, it generates a conditional dispatch that can call either the class-level or global `::operator delete`. The global path directly referenced `::operator delete`, causing `LNK2001` linker errors in environments where no global `::operator delete` exists. MSVC handles this by calling `__global_delete` (and `__global_array_delete` for vector deletes) - this is a compiler generated function that is ONLY defined if there is a direct call to global `::operator delete` for type with non-trivial destructors. Additionally, it always emits an empty `__empty_global_delete` and uses `/ALTERNATIVENAME` linker arg to default `__global_delete` (and `__global_array_delete`) to `__empty_global_delete` if there is NEVER an delete operator call that would triffer the body to be emitted (thus the empty function should never be called). This change aligns Clang's behavior with MSVC when MSVC compatibility mode and non-LLVM 21 ABI is used, with one difference: the LLVM generated `__empty_global_delete` traps since it should never be called.
This PR adds an atomic line logger to `clang`. Situations have arisen where `clang` performs multi-threaded tasks (such as dependency scanning), and race conditions may happen. Such race conditions are difficult to debug using either `lldb` or with `llvm::errs()`. This logger provides atomic logging per line to a file on disk with time stamps at each line to facilitate such investigations. Specifically, the logger is designed with the following properties: 1. Each line is atomically written to the backing file. This avoids concurrent writes making the output text interleaving. 2. Each line is prefixed with a timestamp, a process ID and a thread ID. 3. `LogLine` implements a `<<` operator to allow arbitrary printable types to be piped into it. 4. The `LogLine`'s user does not need to check if it is setup or valid. A LogLine is always valid and can always accept input from `<<`. It becomes a no-op if the `LogLine` object is returned from a default constructed `AtomicLineLogger`. 5. The write happens when a `LogLine` object goes out of scope. The logger is inspired by the [OnDiskCASLogger](https://github.com/llvm/llvm-project/blob/09abee845d2136630fc3f50524148daa55a740a8/llvm/include/llvm/CAS/OnDiskCASLogger.h#L33). A followup PR llvm#195896 wires up this logger to clang's dependency scanning stack. Assisted-by: claude-opus-4.6 rdar://39907408
…lvm#208857) f9b5264 changed FileSpec::GetDirectory() to return llvm::StringRef instead of ConstString. ConstString had an operator bool, so the guard ``` if (left.GetDirectory() && right.GetDirectory()) ``` compiled. StringRef has neither a bool conversion nor operator&&, so the test no longer builds. Check for a non-empty directory instead, which preserves the original "if BOTH have a directory" intent.
LLDB builds with hidden visibility by default, so a function-local static in an inline function is not shared across shared library boundaries: each dylib that includes this header and calls an inline Get() gets its own private copy of the thread_local stack, silently splitting one logical per-thread stack into several. Declaring it out-of-line ensures every dylib resolves to the single instance defined in Policy.cpp. Nothing currently pushes a policy from outside liblldb, so this has no observable effect yet, but any future capability that needs to be set in one shared library and read in another depends on this. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
…8609) A Python command's print() writes to sys.stdout, which the interpreter session pointed at the debugger's raw terminal descriptor via PyFile_FromFd. Those writes bypass the debugger's output lock, so they can race with the statusline, resulting in truncated output. Back the session's terminal stdout and stderr with a pipe instead. A reader thread drains the pipe and writes to the terminal through Debugger::PrintAsync, which takes the same output lock as the statusline. Only redirect when a statusline could actually be drawing: the pipe and reader thread are set up only when StatuslineSupported() holds (show-statusline is enabled and the output is an escape-code-capable terminal) and the target is the debugger's own terminal. The interactive interpreter opts out entirely, since input()'s readline line editing and echo need both sys.stdin and sys.stdout to be the real terminal. Python still gets a real line-buffered text file over the pipe, so output stays live and file objects passed to SB APIs (SetImmediateOutputFile, subprocess, fileno) keep working. On session teardown the wrappers are flushed before the pipe is closed so a retained sys.stdout does not strand a trailing line or write into a closed descriptor. rdar://181841574
I plan on removing ConstStrings from DataFormatters where possible. There's a lot of entangled classes in DataFormatters but TypeCategoryMap feels approachable to start with.
…mt() (llvm#208859) After merging llvm#169680, we started getting assertions in IntegerLiteral::Create() on some ARM systems: ``` Assertion `V.getBitWidth() == C.getIntWidth(type) && "Integer type is not the correct size for constant."' ``` The expansion statements patch doesn't ever create an IntegerLiteral directly, but there is one place where we create a TemplateArgument of type 'ptrdiff_t', but we unconditionally set the bit width of its APSInt to 64 bits. Presumably, the assertion is due to 'ptrdiff_t' not being a 64-bit type on these systems, so make sure that we query its bit width and use that as the width of the APSInt. I don't have a way of verifying if this patch fixes the CI issue since pre-commit CI doesn't run on the affected system and I don't have an ARM machine, but I'm merging this anyway since this issue is breaking CI and querying the width of 'ptrdiff_t' is something we should be doing here regardless.
These extension checks apply to 3.1 as well. This fix kernel build fails when OpenCL 3.1 is enabled in intel/opencl-clang#752 Assisted-by: Claude
Adds a new build option for clang, CLANG_INCLUDE_EXAMPLES, which controls if the examples directory is included in the build. It defaults to the value for LLVM_INCLUDE_EXAMPLES (same as CLANG_INCLUDE_DOCS and CLANG_INCLUDE_TESTS) Signed-off-by: Jade Abraham <jademabraham17@gmail.com>
…unctions (llvm#208330) This is a follow up to llvm#133876 and an alternative to llvm#120805 which doesn't rely on aliases and works across both ELF and Mach-O. This mechanism is preferable in baremetal environments since it doesn't require special handling of the custom sections.
…8817) Fixed llvm#191471. The client needs to further update the CFG and DominatorTree after calling `cloneLoopWithPreheader()` to ensure the IR remains valid, the function itself does not automatically update the control flow fully. Clarified and improved the comments for the function.
This was supposed to be part of the original patch, but we lost it because I didn't pay enough attention when I was merging the release notes after the migration from RST -> MD (I deleted the RST file but forgot to move the release note to the MD file...)
orc_rt_log_Level_getName is used primarily in text prefixes (e.g. the upcoming printf backend's "[orc-rt:General:LEVEL]"), where uppercase is the intended rendering. Storing the names as uppercase lets the backend use them directly without case conversion. orc_rt_log_Level_parse performs a case-insensitive parse, so ORC_RT_LOG=info and similar still work. [orc-rt] Hold log level names as uppercase. orc_rt_log_Level_getName is expected to be primarily used in text-prefixes (e.g. in the upcoming printf backend), where it should be printed as uppercase. Storing as uppercase in the first place will save us a toupper conversion on each log call.
) Fixes crashes when the shift amount type is already between s32 and s64, but not s32 or s64. The shift amount should have the same type with the shifted value for the shift instructions, so add the same `widenScalarToNextPow2` legalization that we apply to the shifted value, to the shift amount. Fixes crashes in programs like: define i8 @test(i48 %a) { entry: %b = lshr i48 %a, 15 %c = trunc i48 %b to i8 ret i8 %c } The new test crashes before this PR.
… and lambdas (llvm#157319) Fixes llvm#60789. Currently, the check will never make `auto` variables `const`. Here's the relevant bit of code: https://github.com/llvm/llvm-project/blob/6b200e21adec0e28407def6fcb2e6c7359fd881b/clang-tools-extra/clang-tidy/misc/ConstCorrectnessCheck.cpp#L108-L110 Notice how the matcher's name is `AutoTemplateType`, but it has nothing to do with templates. What it *was* intended to do, I'm not sure, but excluding all `auto` variables can't be right. For lambdas, this is the only justification I can find: https://github.com/llvm/llvm-project/blob/36627e1724504d783dc1cbc466666516d28260e4/clang-tools-extra/test/clang-tidy/checkers/misc/const-correctness-values.cpp#L30-L34 Which doesn't convince me. Looking at the test changes, I believe there's only one new false positive, and that one seems to be a symptom of an existing problem that was only being masked by `auto`, but we can absolutely discuss whether the now-diagnosed cases are correct. --------- Co-authored-by: Victor Baranov <bar.victor.2002@gmail.com>
This PR attempts to address the remaining flang offload test failure after llvm#208617. Bot: https://lab.llvm.org/buildbot/#/builders/67/builds/8412 The problem with is test is that `foo__l8` kernel was not linked into device image without explicitly use the amdgpu-amd-amdhsa triple in the compilation. It only happened to this specific test. Local test results after fix: ``` Testing Time: 146.44s Total Discovered Tests: 3478 Skipped : 77 (2.21%) Unsupported : 341 (9.80%) Passed : 3055 (87.84%) Expectedly Failed: 5 (0.14%) ```
…elements. (llvm#200938) A TBL with out-of-range values will place zero into the respective vector lane. Use this to generate a more efficient 1 operand TBL where possible.
The LoongArch backend does not support emulated TLS, so mark the test as unsupported to fix the LoongArch buildbot failure. Failure: https://lab.llvm.org/staging/#/builders/20/builds/28875
…ion (llvm#208372) In ARM ELF PIC mode, weak symbols referenced via the constant pool use a PC-relative expression like `.long sym-(.LPC+8)`. The assembler eagerly resolves this when both the symbol and reference are in the same section, which prevents the linker from overriding a weak definition with a strong one from another object file. The previous approach (llvm#198577) forced weak symbols to go through GOT indirection to avoid this, but that adds an extra load. This patch instead emits a `.reloc` directive alongside the local PC-relative expression, forcing the assembler to emit a proper `R_ARM_REL32` relocation. This lets the linker perform the override without the runtime cost of a GOT load.
Follow-up of llvm#166004 - Diagnose C++ declarations that combine `auto` with another type specifier, such as `auto int` . - Preserve C/C23 handling where `auto` can still be interpreted as a storage-class specifier in valid combinations. - Fix parser disambiguation so `auto Use = 0` treats `Use` as the declarator name before type lookup, avoiding ambiguous lookup regressions. --------- Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
…ility-redundant-parentheses (llvm#208759) Subscript operators have the same operator procedure as function calls. Treat overloaded `()` as built-in operators as a drive-by. I missed this case when reviewing llvm#192254.
Mechanically migrate the command-line target spelling on llc/opt RUN lines in llvm/test/CodeGen/AMDGPU from -mtriple=amdgcn ... -mcpu=<gfx> to the folded subarch triple form (e.g. -mtriple=amdgpu9.00-amd-amdhsa), dropping the redundant -mcpu. Co-Authored-By: Claude <noreply@anthropic.com> (Claude-Opus-4.8)
Mechanically migrate the command-line target spelling on llc/opt RUN lines in llvm/test/CodeGen/AMDGPU from -mtriple=amdgcn ... -mcpu=<gfx> to the folded subarch triple form (e.g. -mtriple=amdgpu9.00-amd-amdhsa), dropping the redundant -mcpu. Co-Authored-By: Claude <noreply@anthropic.com> (Claude-Opus-4.8)
Mechanically migrate the command-line target spelling on llc/opt RUN lines in llvm/test/CodeGen/AMDGPU from -mtriple=amdgcn ... -mcpu=<gfx> to the folded subarch triple form (e.g. -mtriple=amdgpu9.00-amd-amdhsa), dropping the redundant -mcpu. Co-Authored-By: Claude <noreply@anthropic.com> (Claude-Opus-4.8)
…208671) StackColoring tracks the total size of the stack as `unsigned int`. This will wrap around, even on 64-bit systems, if the stack is greater than that resulting in a wrong size. This can happen on both PPC and RISCV64.
This alters the lowering of bf16 G_TRUNC to exclude the check for nan if the operation being extended is nnan. Flags are then threaded through so that the G_FPEXT and G_FPTRUNC from promoted nodes keep the same FMF.
dpalermo
approved these changes
Jul 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.