[ASan][test] Mark Linux/stack-overflow-recovery-mode.cpp UNSUPPORTED on Android AArch64 (#240097)
Temporarily mark `TestCases/Linux/stack-overflow-recovery-mode.cpp`
unsupported on Android AArch64 while waiting for #236879, matching
#236884 (https://lab.llvm.org/buildbot/#/builders/186/builds/4079).
Assisted-by: Gemini
[ADT] Add LLVM_ATTRIBUTE_WARN_UNUSED to SmallPtrSet (#240080)
This patch adds LLVM_ATTRIBUTE_WARN_UNUSED to SmallPtrSet so that
compilers can diagnose unused SmallPtrSet variables even though
SmallPtrSet has a non-trivial constructor and destructor.
This patch also addresses the existing warnings uncovered by the
attribute:
- ScheduleDAGSDNodes::BuildSchedUnits had an unused local variable
Visited, which this patch removes.
- SmallPtrSetTest.cpp intentionally leaves Other unused in two move
tests, so this patch marks Other with [[maybe_unused]].
Assisted-by: Antigravity
[LLVM] FIx fallout from #239908 (#240096)
The original patch added LLVM_ATTRIBUTE_WARN_UNUSED to some ADT classes,
which caused some more -Wunused-variable warnings under release builds
(that optimize out asserts).
https://lab.llvm.org/buildbot/#/builders/228/builds/17397
[clang][Sema][NFC] Share member template instantiation lookup (#239450)
Use `RedeclarableTemplateDecl` to consolidate the identical
`isInstantiationOf` implementations for class and function templates,
leaving the other overloads unchanged.
I initially considered turning these helpers into a function template,
but the declaration types use different accessors, such as
`getInstantiatedFromMemberTemplate()` and `getInstantiatedFromMember()`.
I'd also like to discuss whether a function template would be preferable
here, although that would likely require a broader change.
BPF: Stop lowering unwinding through nonexistent unwinder calls (#239899)
BPF borrowed the DWARF EH pipeline in an unsound way. DwarfEHPrepare
turned resume into a call of _Unwind_Resume, which will never be
linked in. BPFUnwindLower later replaced it, and calls of
_Unwind_RaiseException, by matching callee names after register
allocation. This fixes the pass pipeline relying on these transient
calls to phantom functions.
Instead add an invokable llvm.bpf.unwind.exit intrinsic, similar to
wasm's throw intrinsics. BPFUnwindPrepare replaces resume with it so
no impossible call to _Unwind_Resume reaches selection.
The intrinsic selects to a pseudo which BPFUnwindLower turns into
either unwind_exit or a branch to the landing pad when invoked. The
pseudo clobbers nothing, so register allocation can be more aggressive
than when the function looked like an ordinary call.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
Commit fixes provided by Chuck Cranor, thank you very much.
The fixes correct color handling glitches which were the result of
the terminal colour incorrectly being reset to the original pair not
the default color that had been set.
[SPARC] Remap the parameter DBG_VALUEs of a leaf procedure (#239545)
A leaf procedure stays in its caller's register window, so
remapRegsForLeafProc rewrites %i0-%i7 to %o0-%o7. PEI calls it from
determineCalleeSaves, while the parameter DBG_VALUEs at the start of the
entry block are stashed outside the function (stashEntryDbgValues), so
they keep naming %i registers and gdb reads the arguments of leaf
functions from the wrong register.
This renames the debug operands that are left once PEI has put the
stashed values back, in processFunctionBeforeFrameIndicesReplaced. Other
DBG_VALUEs on the same value were already renamed, it's only the stashed
parameter ones that were missed.
Fixes #235238.
`leaf.c` from the issue, `break get` in gdb, before:
```
[13 lines not shown]
[SPARC] Expand f64 bitcasts from v2i32 on 32-bit SPARC (#234201)
It is not possible to directly transfer values from integer registers to
floating point registers, so it needs to be done via the stack.
Fixes the following error:
LLVM ERROR: Cannot select: t10: f64 = bitcast t16
t16: v2i32 = BUILD_VECTOR t2, t4
t2: i32,ch = CopyFromReg t0, Register:i32 %0
t4: i32,ch = CopyFromReg t0, Register:i32 %1
In function: v2i32_build_vector
Assisted-by: Claude
[SPARC] Preserve register operand flags in BPR branch conditions (#240077)
parseCondBranch() rebuilt the register operand of a branch-on-register
(BPR) instruction from just its register number, and insertBranch()
re-added it with addReg(), so any operand flags were lost when a branch
was analyzed and reinserted.
When the register is undef (ProcessImplicitDefs marks the use undef
after removing its IMPLICIT_DEF), PHI elimination splitting a critical
edge rewrites the terminator via updateTerminator() and the BPR ends up
reading a virtual register with no def. The machine verifier rejects
this, and without the verifier the greedy register allocator segfaults
in VirtRegAuxInfo::weightCalcHelper.
Copy the whole MachineOperand into Cond and add it back with add(), as
other targets do.
Fixes #233111
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
arm64 pmap: demote L3C pages in pmap_clear_modify()
When pmap_clear_modify() demotes a dirty L2 block mapping, it write
protects the L3 entry that maps "m", so that a subsequent write access
may repromote. However, since fd6cb031f577, the L3 entries created by
pmap_demote_l2_locked() may have ATTR_CONTIGUOUS set, and
pmap_clear_modify() was write protecting one L3 entry within an L3C page
while leaving the page's other L3 entries writeable with ATTR_CONTIGUOUS
still set. A TLB entry that a processor creates from any of those other
L3 entries may translate "m"'s virtual address and permit writes to "m"
without a fault. To fix this issue, as in pmap_remove_write(), demote
the L3C page before write protecting the L3 entry.
(cherry picked from commit 6d7960628f825f1eec0959d6000a79ca8a4ae927)
arm64 pmap: demote L3C pages in pmap_clear_modify()
When pmap_clear_modify() demotes a dirty L2 block mapping, it write
protects the L3 entry that maps "m", so that a subsequent write access
may repromote. However, since fd6cb031f577, the L3 entries created by
pmap_demote_l2_locked() may have ATTR_CONTIGUOUS set, and
pmap_clear_modify() was write protecting one L3 entry within an L3C page
while leaving the page's other L3 entries writeable with ATTR_CONTIGUOUS
still set. A TLB entry that a processor creates from any of those other
L3 entries may translate "m"'s virtual address and permit writes to "m"
without a fault. To fix this issue, as in pmap_remove_write(), demote
the L3C page before write protecting the L3 entry.
(cherry picked from commit 6d7960628f825f1eec0959d6000a79ca8a4ae927)
