[Clang][test] Add inferred nofree to attr-counted-by-issue200014.c checks (#202491)
Commit 89905ff21441 ("[FunctionAttrs] Add support for nofree argument
inference", #201591) infers a `nofree` parameter attribute at `-O2`. The
test `attr-counted-by-issue200014.c` (added later in #201161) was
generated before that change, so its `O2-SAME` lines omit `nofree` and
currently fail on `main`:
```
O2-SAME: ptr noundef readonly captures(none) ... (expected by test)
ptr nofree noundef readonly captures(none) ... (actual codegen)
```
This regenerates the checks with `update_cc_test_checks.py`. Test-only,
NFC.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 (1M context) <noreply at anthropic.com>
[clang][ExprConst] Remove `State::getBottomFrame()` (#202277)
This is not necessary since `Frame` already has a `getCaller()`
function, which can be used to identify the bottom frame.
And the current code never needs the bottom frame for anything other
than checking if another frame is the bottom frame.
[OpenMP] Mark critical region lock variables as dso_local (#201157)
OpenMP named critical regions use lock variables of the form
.gomp_critical_user_<name>.var, which are created through
CGOpenMPRuntime::getCriticalRegionLock().
These variables are created via
OpenMPIRBuilder::getOrCreateInternalVariable() and bypass the normal
CodeGenModule::setDSOLocal() path used for other Clang-generated
globals. As a result, OpenMP critical lock variables do not receive the
usual frontend dso_local inference.
Apply CodeGenModule::setDSOLocal() to critical lock variables after
creation. This matches the existing frontend
dso_local inference logic.
On ELF targets with a static relocation model, this results in direct
accesses to the lock variable instead of GOT-based accesses. For
example, x86-64 code generation changes from R_X86_64_REX_GOTPCRELX
[4 lines not shown]
grpc: updated to 1.81.1
1.81.1
Core
[EventEngine] Fix a potential use-after-free error on Windows.
[ssl] Server side handshaker factory stores a map of key signers.
[Core] Fix completion queue shutdown race on weak memory models (ARM).
[EventEngine] Fix a Windows race that causes an assertion error.
[grpc_error] enable error_flatten experiment in OSS.
[Python] Trim Python2 backward compatiblity syntax - removed (object) inheritance.
Objective-C
[ObjC] Add receiveNextMessage to GRPCUnaryProtoCall.
Python
[12 lines not shown]
[RISCV] Don't require specific extensions to use altfmt with vset(i)vli. (#202458)
The list of extensions that use altfmt is increasing and is becoming
unsustainable. The likelihood of the bit being repurposed is decreasing
with each new use. Let's just allow it unconditionally.
There is some risk here since all of these extensions are still
unratified and experimental so it could be that all of these extensions
get redefined so that this bit doesn't become altfmt. But I think that's
unlikely.
net80211: delete the deprecated ieee80211_wepkey struct
This hasn't been used in a long time, and since I am shuffling around
the net80211 crypto API a bunch, let's just delete it instead of
leaving it here and trying to figure out how to support it if it's
used by userland somehow.
Reviewed by: guest-seuros
Differential Revision: https://reviews.freebsd.org/D57312
net80211: create IEEE80211_KEYBUF_128_SIZE / IEEE80211_MICBUF_128_SIZE
The IEEE80211_KEYBUF_SIZE and IEEE80211_MICBUF_SIZE are sprinkled
throughout the net80211 stack, ioctl API and drivers. This makes it
challenging to (eventually) up IEEE80211_KEYBUF_SIZE to support 256 /
384 bit encryption as, well, it'll break every single driver and the
ioctl API in doing so.
So as part of this, let's start to separate out the current key/mic
buffer size from what drivers and the ioctl layer are using.
Drivers especially shouldn't be using these definitions as their
key sizes are hardware / firmware API limits, not net80211 limits.
Ideally drivers would define their own key buffer / mic buffer
sizes and only copy in keys up to that length (and fail keys
that are too large) but the current net80211 API isn't there yet.
This doesn't yet change what defines / buffer sizes are used in the
ioctl layer. I'm going to plan out some subsequent work to
separate out those defines and ioctl APIs so they maintain using
[4 lines not shown]
[libc++][span][test] Various cleanups for <span> tests (#202319)
This patch does:
- Simplify some test implementations
- Polish comments and synopsis
---------
Co-authored-by: A. Jiang <de34 at live.cn>
[BPF] Emit ABI-accurate BTF prototypes for DW_CC_nocall (#198426)
DW_CC_nocall subprograms can end up with an optimized IR signature that no
longer matches the original source-level DISubroutineType. Dead argument
elimination may drop source parameters, and the return value may be
removed entirely, while the debug type still describes the original
prototype. In that case BTFDebug emits a FUNC_PROTO that no longer
matches the real BPF ABI.
Teach BTFDebug to derive a filtered FUNC_PROTO for nocall functions.
Detecting surviving arguments (collectNocallEntryArgRegs):
Scan all DBG_VALUE instructions in the entry block while tracking which
registers have been redefined by non-debug instructions:
- A DBG_VALUE whose register has not been redefined records a
register-passed argument (R1-R5 at function entry).
- A DBG_VALUE whose register was most recently loaded via LDD $r11,
[35 lines not shown]
Revert "[NVPTX] Support lowering of `(l)lround`" (#202500)
Reverts llvm/llvm-project#183901
Looks like using removeFromUseLists from Transforms doesn’t work in
certain configurations.
[LLDB] Fix DW_OP_implicit_value GetOpcodeDataSize() error (#201344)
LLDB does not handle `DW_OP_implicit_value` right, causing a "cannot get
opcode data size for Unknown DW_OP constant" error when LLDB parses
location expressions containing this opcode.
`DW_OP_implicit_value` takes two operands: a ULEB128-encoded length
followed by a byte sequence of that length. The current
`GetOpcodeDataSize` implementation has no case for this opcode, only
skip. This prevents LLDB from correctly determining opcode boundaries
when scanning multi-operation location expressions.
From DWARFv5
> The DW_OP_implicit_value operation specifies an immediate value using
two operands: an unsigned LEB128 length, followed by a sequence of bytes
of the given length that contain the value.
Although the evaluation path (`DWARFExpression::Evaluate`) handles this
opcode correctly and produces the right result, the validation/parsing
path emits a confusing error message to the user.
misc/zeroclaw: newport
ZeroClaw is a fast, small, 100% Rust AI assistant / agent CLI (model
providers, multi-agent workflows, chat channels, and a local gateway).
WWW: https://github.com/zeroclaw-labs/zeroclaw
PR: 295837
