[clang][P2719] Relax requirements for matching operator new and delete
The most recent revision of P2719 introduced very strict rules about
matching parameter sets between type aware operators new and delete.
The intention was to resolve the classic "no matching operator delete
has been found so the object will silently leak" problem. The strict
rules however made deleting objects that had a placement new
"impossible".
I missed this however as all of our large scale tests involved
projects that were already using manually implemented allocators
(often trying to support type isolation). The problem with this from
a validation point of view is simple: all of these projects had
existing class scoped operators, and the untyped delete was silently
selected, avoiding the need for a non-placement type-aware delete
that would conflict with the placement cleanup delete.
The next revision of P2719 resolves this by removing the exact type
[6 lines not shown]
[mlir][SPIR-V] Add Weak linkage type and SPV_AMD_weak_linkage extension (#195660)
- add 'Weak' linkage type (SPV_AMD_weak_linkage)
- deduce the Linkage capability and linkage-type extension from
linkage_attributes in UpdateVCE pass
---------
Co-authored-by: Jakub Kuderski <kubakuderski at gmail.com>
[PGO][ICP] Prevent indirect call promotion to functions with incompatible target features (#192142)
Profile-driven indirect call promotion was promoting indirect calls to
functions requiring advanced CPU features (e.g., AVX512) even when the
caller function did not support those features. When these promoted
calls were subsequently inlined, it could lead to invalid IR and
backend crashes during instruction selection because the target CPU
could not handle the advanced instructions.
This patch addresses the issue by adding a target feature
compatibility check to `llvm::isLegalToPromote` in
`CallPromotionUtils.cpp`. If the callee requires target features
(prefixed with `+`) that are not present in the caller's target
features, the promotion is skipped. By centralizing this check in
`isLegalToPromote`, we protect all passes relying on this utility
(such as `SampleProfileLoader` and `IndirectCallPromotion`) from
promoting to incompatible targets. This also prevents incorrect
inlining of `always_inline` functions that would otherwise be promoted
via indirect calls and then inlined.
[3 lines not shown]
[MLIR] Add HasAncestor op trait (#195447)
Add HasAncestor/AncestorOneOf traits that verify an operation has a
specific ancestor anywhere in the parent chain, unlike HasParent which
only checks the immediate parent.
[orc-rt] Change SPS controller-interface naming conventions. (#195614)
This commit makes two changes to the naming conventions for SPS CI
symbols:
1. The orc_rt_sps_ci_ prefix is replaced with orc_rt_ci_sps_ (for SPS
wrapper functions) and orc_rt_ci_ (without the "sps_" suffix) for data
symbols.
2. The _sps_wrapper suffix is dropped from wrapper functions, since the
prefix now distinguishes between SPS-wrappers and data symbols.
[X86][APX] Add VirtRegMap to non stack foldMemoryOperand too (#193423)
We need to query mapped physical register through VirtRegMap.
Fixes: https://godbolt.org/z/1KGj3aYeP
[MLIR][Python] Add `ConditionallySpeculatable` interface and `Pure` specifier (#195505)
This PR brings two features: the `ConditionallySpeculatable` op
interface and the `Pure` specifier for Python-defined ops.
The result is that you can mark an op as pure like:
```python
class PureOp(
TestPure.Operation,
name="pure",
traits=[Pure] # just like in the ODS!
):
a: Operand[IntegerType[32]]
b: Operand[IntegerType[32]]
res: Result[IntegerType[32]] = infer_result()
```
Then this op is both `NoMemoryEffect` and `AlwaysSpeculatable`.
Assisted-by: Copilot/GPT5.4
[IR] Add elementwise modifier to atomicrmw (#189517)
This PR implements the IR side modifications of [[RFC] Add elementwise
modifier to atomicrmw](https://discourse.llvm.org/t/rfc-add-elementwise-modifier-to-atomicrmw/90134).
Design Decisions:
- In the IR, the current atomicrmw record layout looks like: [ptrty,
ptr, valty, val, operation, vol, ordering, syncscope, align]. To encode
elementwise, I decided to pack it into the operation field, which also
contains the math op (i.e. fadd, fmin, add etc...). I could have changed
the record structure, but that would be slightly more complicated.
- elementwise vector atomics can be vectors of integers because we can always scalarize legally
- elementwise vector atomics need to have power of 2 size. We can potentially remove this restriction later.
Assisted by AI.
[compiler-rt] Add MSVC CRT flags to ASan coverage test (#195719)
The ASan coverage test also links clang_rt.profile because it uses
-coverage. On Windows MSVC, this can fail if the test is linked with the
static CRT but clang_rt.profile was built with the dynamic CRT.
For example, a profile runtime that uses /MD may reference DLL CRT
symbols
such as __imp_* symbols. Add the same dynamic CRT flags directly to this
one test on Windows MSVC so it keeps linking when clang_rt.profile
changes.
[InlineOrder] Remove unused InlineHistoryMap (#195769)
This patch removes InlineHistoryMap, an unused variable. The last
use was removed by:
commit 3af427539bc6b85a9fe3334b9a0b43d347ea29ac
Author: Arthur Eubanks <aeubanks at google.com>
Date: Wed Apr 8 09:34:52 2026 -0700
[clang][P2719] Relax requirements for matching operator new and delete
The most recent revision of P2719 introduced very strict rules about
matching parameter sets between type aware operators new and delete.
The intention was to resolve the classic "no matching operator delete
has been found so the object will silently leak" problem. The strict
rules however made deleting objects that had a placement new
"impossible".
I missed this however as all of our large scale tests involved
projects that were already using manually implemented allocators
(often trying to support type isolation). The problem with this from
a validation point of view is simple: all of these projects had
existing class scoped operators, and the untyped delete was silently
selected, avoiding the need for a non-placement type-aware delete
that would conflict with the placement cleanup delete.
The next revision of P2719 resolves this by removing the exact type
[6 lines not shown]
[libunwind] Add SME detection for Apple platforms (#193630)
Copy SME detection sysctl code from ZA test. Also fix a
logic issue in the original code while being reviewed.
[libcxx] Remove ASan container overflow checks for SSO strings (#194208)
Essentially a revert of #79536, although manual given how much the code
has changed.
Doing container overflow checks on SSO strings is fundamentally unsound
due to how they interact with compiler optimizations within LLVM, which
assume that the entire object is dereferencable when it is live. LLVM
can sometimes insert speculative loads that will create false positives
when they try and load a partially filled SSO buffer. This was
previously prevented using inline asm barriers within std::string
itself. However, this can also manifest in other ways, with the
motivating example for the revert being GlobalOpt inserting a
speculative load of a std::variant containing a SSO std::string, causing
an ASan failure.
