[libcxx][Github] Bump Github Runner to 2.334.0 (#193339)
To stay ahead of the support horizon. Use the same base image to prevent
any differences beyond the runner binary.
[mlir][func] Avoid to create duplicate symbol during conversion (#192342)
`LLVM::lookupOrCreateFn` only checks for an existing `LLVM::LLVMFuncOp`
before creating a new function declaration. When a symbol with the same
name exists as a different op type (e.g., `func.func` that hasn't been
converted to LLVM dialect yet), the function blindly creates a duplicate
`LLVMFuncOp`, which either causes a "redefinition of symbol" error or
silently introduces a renamed symbol (`@free_0`) that won't resolve at
link time.
This happens in practice when user code declares function that is also
used internally by MLIR lowerings. For example, a Fortran `bind(c,
name="free")` declaration produces a `func.func @free` in the IR. When
`memref.dealloc` is lowered (via DeallocOpLowering), it calls
lookupOrCreateFreeFn which calls lookupOrCreateFn — and since the
existing `func.func @free` is not an LLVMFuncOp, a conflicting duplicate
is created.
The fix adds a check in lookupOrCreateFn: before creating a new
[3 lines not shown]
[clang] Suppress glibc C11 extension warning in c-index-test
`c-index-test.c` is still compiled as gnu89 on purpose. That acts as
a useful guard rail: it helps keep the file compatible with older C
dialects instead of silently picking up newer C features because Clang
defaults to a newer language mode.
Ubuntu 26.04 LTS updates glibc's string.h so `strchr`, `strrchr` and
`strstr` are routed through `_Generic`-based macros. When Clang compiles
`c-index-test.c` with `-std=gnu89` and `-pedantic`, that now triggers
`-Wc11-extensions` warnings even though the source itself is not using
C11 features.
Keep the gnu89 check in place and suppress this warning only for Clang
when building c-index-test.
[compiler-rt][profile] Use runtimes-libc-headers in the GPU runtimes build (#192814)
When compiler-rt is built for a GPU target in the same runtimes build
as LLVM-libc, the profile sources `#include <string.h>`, `<limits.h>`,
... Those headers are generated by LLVM-libc for the GPU triple.
A concrete example is the amdgcn runtimes build:
-DLLVM_RUNTIME_TARGETS='default;amdgcn-amd-amdhsa'
-DRUNTIMES_amdgcn-amd-amdhsa_LLVM_ENABLE_RUNTIMES='compiler-rt;libc'
-DRUNTIMES_amdgcn-amd-amdhsa_RUNTIMES_USE_LIBC=llvm-libc
Even though `libc` is configured before `compiler-rt`, both sets of
targets live in the same ninja graph and race each other. Ninja can
start compiling `compiler-rt/lib/profile/InstrProfiling.c` before
LLVM-libc has finished generating its GPU `string.h`, and even when
hdrgen has finished, the profile compile needs `-isystem` pointing at
the generated header tree.
[26 lines not shown]
[SSAF][Analyses] Add an AST visitor for the contribution model (#191933)
Add an AST visitor that respects the contribution model and will be
shared across SSAF analyses.
---------
Co-authored-by: Balázs Benics <benicsbalazs at gmail.com>
[lldb] Directly access object variable in GetObjectPointerValueObject (NFC) (#193120)
The `GetObjectPointerValueObject` function does not need full variable
path expressions, or any of its functionality. This function simply gets
the value of `this` or `self`.
[CIR] Cache isSafeToConvert results to avoid redundant record layout … (#193122)
…walks
CIRGenTypes::isSafeToConvert() walks record layouts to determine whether
a struct can be safely converted to MLIR types. The walk recurses into
field types and re-runs for the same record every time it is asked, so
workloads with many distinct record types (template-heavy code in
particular) repeat substantial work.
Cache the boolean result in a per-CIRGenTypes DenseMap keyed by the
RecordDecl. Lookup becomes O(1) after the first walk per type.
The impact in isolation is modest — on a synthetic stress with many
records and template instantiations, end-to-end compile time on `clang
-fclangir -S -emit-llvm -O0` improves by roughly 2-3% (e.g. 16.59s ->
16.09s on a 67K-LOC input).
Repro shape (scale records and template instantiations into the
[11 lines not shown]
[libunwind] Add SME detection for ZA test on OpenBSD / FreeBSD (#193148)
Follow up to 588451c160c34b888ced1c3d9263d361df22f757 to
add SME detection on OpenBSD and FreeBSD.
[LegalizeTypes][RISCV] Don't widen expandload or compresstore with VP_LOAD/VP_STORE. (#193294)
We don't support expanding/compressing VP_LOAD/VP_STORE yet.
This probably crashes on scalable vectors, but that's better than
a silent miscompile.
Fixes #193277.
[libc] Improve lit test discovery and execution (#192993)
Updated LibcTest to support cross-compilation and custom test
directories:
* Passed localConfig to _isTestExecutable to check for emulator.
* Skipped host execution permission check if emulator is set.
* Supported tests in libc.test.shared and libc.test.utils.
* Handled fallback if @BINARY@ is missing in test command template.
* Removed UnitTest from excludes in lit site config.
[cross-project-tests] Add llvm-modextract as a dependency (#193296)
cross-project-tests/dtlto/multimodule.test uses it
Some precommit tests are failing because of this missing dependency,
e.g. https://github.com/llvm/llvm-project/actions/runs/24729694507
[Github] Bump Github Runner Version to 2.334.0 (#193318)
Release notes imply this probably shouldn't impact us. Update the runner
version in the containers so that we do not run past the support
horizon.
[lldb] Add synthetic variable support to Get*VariableList. (#181501)
This patch adds a new flag to the lldb_private::StackFrame API to get variable lists: `include_synthetic_vars`. This allows ScriptedFrame (and other future synthetic frames) to construct 'fake' variables and return them in the VariableList, so that commands like `fr v` and `SBFrame::GetVariables` can show them to the user as requested.
This patch includes all changes necessary to call the API the new way - I tried to use my best judgement on when to include synthetic variables or not and leave comments explaining the decision.
As a consequence of producing synthetic variables, this patch means that ScriptedFrame can produce Variable objects with ValueType that contains a ValueTypeExtendedMask in a high bit. This necessarily complicates some of the switch/case handling in places where we would expect to find such variables, and this patch makes best effort to address all such cases as well. From experience, they tend to show up whenever we're dealing with checking if a Variable is in a specified scope, which means we basically have to check the high bit against some user input saying "yes/no synthetic variables".
[clang] implement CWG2064: ignore value dependence for decltype
The 'decltype' for a value-dependent (but non-type-dependent) should be known,
so this patch makes them non-opaque instead.
This patch also implements what's neceessary to allow overloading
on pure differences in instantiation dependence, making `std::void_t`
usable for SFINAE purposes.
This also readds a few test cases from da98651, which was a previous attempt
at resolving CWG2064.
Fixes #8740
Fixes #61818
Fixes #190388
[LifetimeSafety] Add support for `new`/`delete` (#192504)
This PR extends LifetimeSafety to also support heap allocations via
`new`/`delete`.
# Contents
* Adds a new warning that is emitted on use-after-free.
* Renames `reportUseAfterFree` to `reportUseAfterScope` due to the old
name being misleading (warnings are still called `use_after_scope`).
* Adds a new `AccessPath::Kind` value `NewAllocation` that is used for
loans issued from `new` allocations.
* Adds `VisitCXXNewExpr` and `VisitCXXDeleteExpr`, which handle loan
issuance / origin propagation for `new` / `delete`.
[6 lines not shown]
[Clang][AMDGPU] Use unsigned for D# (#193310)
The descriptor should be unsigned in the first place. Before we moved to
`_ExtVector`, everything just relied on implicit type conversion, so
this was never caught. CLR's implementation of D# uses unsigned as well.
Fixes ROCM-23449.
[flang][acc] Update fir.convert rematerialization handling (#193301)
As of https://github.com/llvm/llvm-project/pull/184218 fir.convert was
being treated as a rematerialization candidate always. However, the
primary problem intended to be solved were improper classification of
pointers due to being casted to integers. Thus use optionally
implemented interface instead to only handle this scenario.
[AArch64] Add more scalar testing for hadd patterns. NFC (#193313)
These are mostly taken from hadd-combine.ll, testing scalar instead of
vector
and checking a few extra variants.
